Performance (Core Web Vitals)
Lighthouse 12 lab runs, mobile and desktop · October 3, 2026
55/100
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.
Status, October 7, 2026
Re-estimated score: about 30/100 (was 18)
Mobile speed roughly doubled: homepage Lighthouse 32 (was 16), main content in 7.1 s (was 34.6 s), layout shift 0.09 (was 0.754), server response ~0.35 s (was 0.82 s). Testing on a staging copy on October 7 found the real cause of the remaining weight. It isn't the Divi beta: Divi 5.0.1 produces the same CSS. It's about 1 MB of duplicated styling in the header and footer, copied from the old site by a cloning tool (4,979 CSS rules, only 651 unique; 402 duplicate font declarations). Divi's Critical CSS setting inlines 673 KB of that into every page. The fix is to rebuild the footer as a lean section, tested on staging first.| Item | Status | What's live now |
|---|---|---|
| Server response / page cache | Fixed Oct 7 | WP Super Cache serving static files: ~0.35 s TTFB (was 0.82 s) |
| Images | Fixed Oct 7 | All uploads compressed (250 MB → 75 MB on disk); hero preloaded; van PNG and banner gone from the homepage |
| Two GA4 tags (M5) | Fixed Oct 7 | One gtag.js load for both IDs |
| Hot-linked irp.cdn-website.com icons | Fixed Oct 7 | Replaced with self-hosted SVGs |
| Inline fonts | Fixed Oct 7 | 3,116 → ~415 inline @font-face rules removed from page content |
| Layout shift (CLS) | Fixed Oct 7 | 0.754 → 0.02–0.09 (header logo kept lazy: eager loading raised CLS to 0.66 in testing) |
| Oct 8: lean footer live | Fixed Oct 8 | Footer rebuilt as one small section (383 KB → 11 KB of layout); homepage HTML 922 KB → 532 KB; 13 real service links |
| Oct 8: third-party scripts delayed | Fixed Oct 8 | GA4, Meta Pixel and the GHL chat load on first interaction or after 10 s; blocking time on home 1,680 ms → ~300–1,000 ms |
| Oct 8: service-page layout shift | Fixed Oct 8 | Hero photo gets a reserved box and loads first: CLS 0.23 → 0.03; LCP improved on service pages |
| Oct 8: phone Lighthouse | In progress | Home 45–62, Brake Repair 81–88, Oil Change 51–60, transmission quote 39–48 (GHL form). Local runs vary a lot; PageSpeed API quota was used up |
| Header/footer CSS bloat (~1 MB) | Fixed Oct 8 (footer) | Footer rebuilt and live; the header still carries ~90 KB of cloned CSS |
| Divi 5 beta → 5.0.1 | In progress | Tested on staging: renders fine, no errors, but no speed gain by itself. Can go live together with the footer rebuild. |
| Third-party icon fonts via clonewebx proxy | Not started | dm-font / FontAwesome loaded through clonewebx.softlite.io; remove with the footer rebuild |
| Field data (CrUX) | In progress | Search Console access now exists; the Core Web Vitals report needs ~28 days of data |
Lighthouse Scores (October 3 baseline)
Oct 7: Mobile Home
32
was 16 · LCP 7.1 s (was 34.6 s)
Oct 7: Mobile Transmission
40
LCP 5.5 s · CLS 0.02
Oct 7: Lighthouse SEO
100
was 85–92
Oct 7: Accessibility
89–93
was 77–83
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
| Metric | Home mobile | Home desktop | Brake mobile | Brake desktop | Good threshold |
|---|---|---|---|---|---|
| Largest Contentful Paint | 34.6 s | 5.6 s | 23.1 s | 5.3 s | ≤ 2.5 s |
| First Contentful Paint | 16.4 s | 2.8 s | 16.9 s | 3.0 s | ≤ 1.8 s |
| Total Blocking Time | 610 ms | 40 ms | 910 ms | 40 ms | ≤ 200 ms |
| Cumulative Layout Shift | 0.754 | 0.001 | 0.167 | 0.496 | ≤ 0.1 |
| Speed Index | 16.4 s | 3.8 s | 16.9 s | 3.0 s | ≤ 3.4 s |
| Page weight | 7.6 MB | 10.6 MB | 4.7 MB | 6.1 MB | < 1.6 MB |
| Requests | 76 | 90 | 60 | 63 | — |
| Server response (root document) | 820 ms | 810 ms | 740 ms | 790 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
| Item | Size | Where | Fix |
|---|---|---|---|
| The page HTML itself (about 2.1 MB is inline Divi CSS) | 2,284 KB | Every 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.png | 1,127 KB | Home | Convert to WebP (~100 KB) |
| Depositphotos_479002004_XL-scaled.jpg (hero, 2560 px) | 726 KB | Home | Serve a ~1400 px WebP; don't lazy-load it |
| leaderboard_banner_wide.png | 410 KB | Home | WebP |
| state-inpection-web-final-980x1307.jpg | 262 KB | Home | WebP, smaller |
| Google Analytics gtag.js × 3 loads (two IDs: G-HF68X7Z5KG, G-F3ZB43T30G) | 542 KB | Every page | Keep one property (M5) |
| Divi deferred CSS | 165–172 KB | Every page | Part of the Divi CSS fix |
| Font Awesome 6.5 solid font (cdnjs) | 153 KB | Home | Use 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.svg | 116 + 110 KB | Brake 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 KB | Brake Repair | Load only where a slider is used |
Diagnosis
2.1 MB of CSS inside every page In progress
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.Status, October 7: Inline CSS is now ~760 KB (fonts trimmed). Staging tests show the source is the cloned header/footer styling, not the beta: Divi 5.0.1 produces the same size. With Critical CSS off, page HTML drops to ~205 KB but a 1 MB header/footer CSS file loads instead. The footer rebuild fixes both.
The main image is lazy-loaded In progress
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.Status, October 7: The homepage hero is now preloaded with high priority, and service pages use smaller, compressed shop photos. Making the first image eager on each template is still to do (it must be tested for CLS, like the logo was).
The layout jumps while loading Fixed Oct 7
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.Status, October 7: CLS measured 0.02–0.09 on October 7 (home 0.09, transmission 0.02, cost guide 0).
Server response ~0.8 s Fixed Oct 7
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.Status, October 7: WP Super Cache in mod_rewrite mode serves cached pages as static files: ~0.35 s to first byte from the office, most of it network.
Fix Plan (H4)
| # | Step | Expected effect | Effort |
|---|---|---|---|
| 1 | Divi: 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 KB | Largest single gain; FCP should fall from 16 s to a few seconds on mobile | 1–2 hrs + testing |
| 2 | Add a page cache that works with Divi (the server runs Apache; there's no cache plugin active today), test the sitemap and Shopmonkey button afterwards | TTFB from ~0.8 s toward ~0.2 s | 1 hr |
| 3 | Convert 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 LCP | 1 hr |
| 4 | Remove one of the two GA4 tags (M5) | ~180–360 KB less script on every page | 15 min |
| 5 | Replace the hot-linked irp.cdn-website.com icons and trim Font Awesome | ~380 KB less; no dependency on another site | 30 min |
| 6 | Set fixed sizes on images and the reviews widget; preload the main font | CLS under 0.1 | 1 hr |
| 7 | Plan the move from Divi 5 public beta to the stable release (H2) | Fewer surprises like the sitemap crash | When 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).