Website Performance Case Study: Mirage Body Shop — from a 6-Second Mobile LCP to a PageSpeed Score of 100

This is the performance half of our work for Mirage Body Shop in Coventry; the search half is in the SEO case study. Every number here was measured, and each one says when and how it was measured, because a speed figure without its method is a guess with a decimal point.

Where the site stood on 20 August 2026

Lighthouse, run against the live site, median of repeated runs (a single run on a desktop machine swings by ten points, so we never quote one):

Read that table the way we did. The server answers in about a tenth of a second, so hosting is not the problem. Desktop is fine. Mobile is the customer's experience — a body shop's visitor is standing next to a damaged car holding a phone — and on mobile the largest element took six seconds to appear and the layout moved after it did. That is the page people were actually seeing.

What was causing it

We did not guess. We pulled the asset list for every theme on the platform (the site runs on a platform that carries eleven themes; the client's live theme is the default) and sorted by bytes. Three things accounted for most of the weight:

1. Images shipped at camera size. One theme's homepage sent 3.5 MB of photographs. Resized and served as AVIF/WebP with a lazy fallback, the same images came to 251 KB.
2. Two icons dragging a 1.3 MB sprite. Two small icons referenced a sprite file that contained the whole icon set — 377 KB transferred for two glyphs — and the reference was repeated seventeen times across four themes. Replaced with inline symbols.
3. A 101 KB logo. The logo was a single PNG with no size variants. The extra-small AVIF variant the site needed is 1 KB.

There was a fourth cause that was not about weight: the layout shift. Chrome's own attribution for what was shifting was wrong three times in this programme, so we stopped trusting the tool's explanation and measured element by element until the number moved.

What changed, measured on the same machine with the same data

Before and after, theme preview on our development box, identical content and settings, medians:

The layout-shift sweep went across every theme on the platform, not only this one: the worst theme went from 0.92 to 0.09, and all eleven finished inside Google's "good" band. One thing we tried and switched off: an asset bundler that helped two themes and made a third slower (LCP 3.6 s to 4.8 s). It stays off until it helps everywhere.

The live site today — Google's own measurement

PageSpeed Insights on the live mobile homepage, run 23 August 2026 at 05:30 (Lighthouse on an emulated Moto G Power with throttled network and CPU, which is why it is slower than any real phone on a good signal):

The field data — what Chrome users actually experienced over the last 28 days — passes Google's Core Web Vitals assessment: LCP 1.7 s, CLS 0.06, with not yet enough interaction samples for an INP figure. Three days earlier the same URL scored 66 with a 6.1-second LCP. That is the whole programme in two numbers.

Why it matters for a body shop

Search Console for the same site shows impressions growing from 655 in February to 34,800 in the first three weeks of August. Every one of those impressions is an offer to load the page on a phone. A six-second largest paint on a phone is where a good share of those offers die before the page has said who the business is. Speed is not a ranking trick here; it is the difference between being seen and being visited.

What we did not do

• We did not change hosting. The server was never the bottleneck and the 106 ms response proves it.
• We did not install a "speed plugin". The site is a custom PHP platform we wrote; the fixes were made in the theme and the asset pipeline.
• We did not quote a single lucky run. Every figure above is a median, and the one that is not comparable to Lighthouse is labelled as such.

If your own site has a good server and a slow phone experience, that gap is usually images, a sprite and a logo, in that order. Our performance optimisation service starts with the same benchmark, and the rest of what we did for this client is in the Mirage success story.

Figures last updated 23 August 2026.