We ran Lighthouse 12 locally in headless Chrome on the homepage and the Brake Repair page, mobile and desktop. These are lab numbers from a simulated mid-range phone on a slow 4G connection. On a phone, the homepage scores 16 out of 100. The first text takes 16.4 seconds to appear, the main content takes 34.6 seconds, and the layout jumps around badly while it loads (CLS 0.754). The biggest cause isn't images or plugins. It's the page itself: every page's HTML is about 2.3 MB, and about 2.1 MB of that is CSS written inline by the Divi 5 public beta. A phone has to download and process all of that before it can show anything. On top of that come a 1.1 MB PNG photo, a 726 KB hero photo, two separate Google Analytics tags, and icons hot-linked from another website platform's servers. Server response is also slow at about 0.8 seconds. Desktop does better (59 home, 39 Brake Repair), but most people looking for a mechanic search on their phone.

Lighthouse Scores

Mobile Performance
16
Home · LCP 34.6 s
Mobile Performance
27
Brake Repair · LCP 23.1 s
Desktop Performance
59 / 39
Home / Brake Repair
Accessibility
77–83
Alt text, contrast, zoom
Best Practices
100
All four runs
Lighthouse "SEO"
85–92
Alt text, link text

The category score of 18 reflects what a phone user actually experiences: a page that stays blank for most of 16 seconds. Lighthouse's "SEO" score only checks basics like titles and crawlability; it doesn't measure rankings.

Core Metrics

MetricHome mobileHome desktopBrake mobileBrake desktopGood threshold
Largest Contentful Paint34.6 s5.6 s23.1 s5.3 s≤ 2.5 s
First Contentful Paint16.4 s2.8 s16.9 s3.0 s≤ 1.8 s
Total Blocking Time610 ms40 ms910 ms40 ms≤ 200 ms
Cumulative Layout Shift0.7540.0010.1670.496≤ 0.1
Speed Index16.4 s3.8 s16.9 s3.0 s≤ 3.4 s
Page weight7.6 MB10.6 MB4.7 MB6.1 MB< 1.6 MB
Requests76906063—
Server response (root document)820 ms810 ms740 ms790 ms≤ 200 ms (playbook)

These are lab results. Real-user (field) data from Chrome would come from Search Console's Core Web Vitals report, which we can't see until access is sorted out (C4).

The Heaviest Items

ItemSizeWhereFix
The page HTML itself (about 2.1 MB is inline Divi CSS)2,284 KBEvery page (site average 2.9 MB)Turn on Divi's static CSS file generation / critical CSS, so styles load as a cached file, or test a page-cache plugin. Test on staging first: it's a beta theme.
van-work-no-letters-980x653.png1,127 KBHomeConvert to WebP (~100 KB)
Depositphotos_479002004_XL-scaled.jpg (hero, 2560 px)726 KBHomeServe a ~1400 px WebP; don't lazy-load it
leaderboard_banner_wide.png410 KBHomeWebP
state-inpection-web-final-980x1307.jpg262 KBHomeWebP, smaller
Google Analytics gtag.js × 3 loads (two IDs: G-HF68X7Z5KG, G-F3ZB43T30G)542 KBEvery pageKeep one property (M5)
Divi deferred CSS165–172 KBEvery pagePart of the Divi CSS fix
Font Awesome 6.5 solid font (cdnjs)153 KBHomeUse only the few icons needed, or Divi's built-in icons
Icons hot-linked from irp.cdn-website.com (another platform's servers): phone--white.svg, map-pin--white.svg116 + 110 KBBrake Repair (service template)Upload small copies to the site, or use built-in icons. If that server removes them, they break.
swiper.min.js (softlite-io-integration)140 KBBrake RepairLoad only where a slider is used

Diagnosis

2.1 MB of CSS inside every page
Divi 5 (public beta 9.3) is writing each page's full style rules straight into the HTML. That's why the homepage HTML is 2,284 KB, and why nothing can paint until that's downloaded and parsed. It's the same Divi code that crashes the page sitemap (C3). This is the single biggest speed problem on the site.
The main image is lazy-loaded
On Brake Repair, the largest element is a 2560 × 1435 AdobeStock image with loading="lazy". That tells the browser to wait before fetching the one image that most needs to load first. The homepage's largest element is the hero section with a 726 KB background photo.
The layout jumps while loading
Home mobile CLS 0.754 and Brake desktop CLS 0.496 are far above the 0.1 limit. Content moves as fonts, the reviews carousel and images arrive, and visitors can tap the wrong thing. Give images and the reviews widget fixed dimensions, and preload the main font.
Server response ~0.8 s
Three curl tries measured 0.82, 0.83 and 0.87 seconds to first byte. The playbook target is around 200 ms, because AI crawlers work on tight timeouts. A page cache (served before WordPress and Divi run) is the usual fix and would also help the sitemap.

Fix Plan (H4)

#StepExpected effectEffort
1Divi: turn on static CSS file generation and critical CSS (Divi → Theme Options → Performance), clear et-cache, confirm the page HTML drops from ~2.3 MB to a few hundred KBLargest single gain; FCP should fall from 16 s to a few seconds on mobile1–2 hrs + testing
2Add a page cache that works with Divi (the server runs Apache; there's no cache plugin active today), test the sitemap and Shopmonkey button afterwardsTTFB from ~0.8 s toward ~0.2 s1 hr
3Convert the van PNG, banner PNG, hero and state-inspection images to WebP; remove loading="lazy" from the first image on each template~2 MB less on the homepage; faster LCP1 hr
4Remove one of the two GA4 tags (M5)~180–360 KB less script on every page15 min
5Replace the hot-linked irp.cdn-website.com icons and trim Font Awesome~380 KB less; no dependency on another site30 min
6Set fixed sizes on images and the reviews widget; preload the main fontCLS under 0.11 hr
7Plan the move from Divi 5 public beta to the stable release (H2)Fewer surprises like the sitemap crashWhen stable ships

Target: homepage mobile Lighthouse 60+ and LCP under 4 seconds within a month, then 80+. Re-run Lighthouse on the homepage and one service page after each step, so we can see which change made the difference. Take a backup before touching Divi settings (and store it outside public_html, see C1).