Our mobile homepage scored 78 on Lighthouse, with a 5.0-second Largest Contentful Paint. We found the causes, made three small changes and re-tested in production. Mobile now scores 99–100 and shows its main content in about 0.9 seconds in lab tests. Here’s what changed, and what the numbers do and don’t prove.
The results
Our first production audit on 6 November scored 78 on mobile and 96 on desktop. The mobile problem was one number: a Largest Contentful Paint of 5.0 seconds, against Google’s 2.5-second “good” threshold.
We didn’t guess at the cause. We read the PageSpeed Insights diagnostics, recorded a Chrome performance trace and went through the page source. Two things stood out: the opening paragraph was hidden behind an entrance animation, and a decorative canvas animation was running on phones.
The changes went through a dedicated branch, a preview deployment and automated checks before reaching production. We changed no Google Tag Manager, GA4 or Clarity configuration.
The homepage wasn’t loading Google Fonts, but the page still told the browser to open connections to two Google font servers. We confirmed in Chrome DevTools that no requests went to either one, then removed the hints.
An entrance animation kept the introductory paragraphs invisible for a moment, and in one test that paragraph was the LCP element. On phones it now appears straight away. The desktop animation is unchanged.
Our performance trace showed repeated frame work from the hero canvas animation. It’s now skipped below 768px, while the desktop version and the reduced-motion setting stay as they were.
PageSpeed Insights results for the production homepage, before the changes on 6 November and after them on 7 November 2026.
| Metric | Mobile before | Mobile after | Desktop before | Desktop after |
|---|---|---|---|---|
| Performance score | 78 | 99–100 | 96 | 99 |
| First Contentful Paint | 0.9 s | 0.9 s | 0.9 s | 0.2 s |
| Largest Contentful Paint | 5.0 s | 0.9 s | 1.1 s | 0.6 s |
| Total Blocking Time | 200 ms | 60 ms | 70 ms | 110 ms |
| Cumulative Layout Shift | 0 | 0 | 0 | 0 |
| Speed Index | 2.6 s | 0.9 s | 1.0 s | 0.5 s |
“After” figures are from our latest run on 7 November 2026 (mobile on an emulated Moto G Power with slow 4G, desktop emulated, Lighthouse 13.6.0). Accessibility, Best Practices and SEO also scored 100 on both devices in that run. Total Blocking Time on desktop is the one metric that moved the wrong way.
Lighthouse scores move between runs even when nothing changes, so here is the full run history.
| Run set | Mobile score | Desktop score |
|---|---|---|
| Before the changes (6 November, single run) | 78 | 96 |
| After deployment, first check (7 November) | 85, 85, 100, 100 | 95, 93, 93 |
| After deployment, repeat runs (7 November) | 99–100 | 99–100 |
The same code scored anywhere from 85 to 100 on mobile across these runs. In the two early mobile runs where we captured the full metrics, LCP was 3.3 s in one and 0.9 s in the other. That spread is normal Lighthouse variability, which is why we report the range and not a single best result.
These are lab results, not real-user results. Lighthouse tests one page load in a simulated environment. Google assesses Core Web Vitals on real-user data at the 75th percentile, and our site doesn’t yet have enough Chrome UX Report data for that assessment. So we’re not claiming a Core Web Vitals pass.
The “before” figures are a single run. We can’t show that test conditions were identical between the first audit and the later ones, so the change is directional, not a controlled measurement. We also shipped the three changes together, so we can’t say how much each one contributed.
Desktop blocking time went up. Total Blocking Time on desktop is 110 ms against 70 ms before. It’s still well inside Google’s good range, but it’s higher, and we’re looking into it.
We haven’t measured business impact. No change in leads, conversions or search rankings is claimed here. For how Google recommends reading these tests, see Google’s Core Web Vitals guidance and the Lighthouse notes on score variability.
Lighthouse still flags a few opportunities on our homepage: unused JavaScript (mostly from Google tag scripts), a render-blocking stylesheet, cache lifetimes for static files, and main-thread work on desktop. We’ll work through them without removing the tracking we rely on, and keep watching Search Console as real-user data builds up.
It’s the same approach we take with client sites: measure first, change what the evidence points to, re-test, and say plainly what’s still open.
Book a free website speed and SEO audit. We’ll test your site on mobile and desktop, show you what’s holding it back, and tell you which fixes are worth making first.
Book a free speed & SEO audit