You run PageSpeed Insights on a page that feels fast on your phone, and mobile comes back red. The client sees the same report. Before anyone touches the build, find out whether the number describes your page or describes the way Lighthouse guessed at it.
What happened on 5fourdigital.com.
The page had a Calendly booking embed. Calendly brings about 4MB of its own scripts. On a normal load they arrive after the page has painted, and nobody waits on them.
The default Lighthouse run reported First Contentful Paint at 8.8 seconds. Re-run with devtools throttling, which actually slows the connection, the same page measured 1.6. Same build, same mobile settings, two numbers. Only one of them was something a visitor would ever see.
Why the simulated run gets it wrong.
By default, Lighthouse does not load your page on a slow connection. It loads it fast, records every request and what each one waited on, then calculates how long that would have taken on a slow phone. PageSpeed Insights works the same way. It is quick and repeatable, which is why it is the default.
The calculation is only as good as the map it builds. If a third-party embed starts requesting files before first paint on the fast run, the model treats those files as standing between the visitor and the first paint. Then it charges the full slow-network cost of every one of them to your FCP.
Devtools throttling does the slow load for real. The browser fetches over a throttled connection and the page paints when it actually paints. The embed loads behind it, where it always did.
The simulation is an estimate. On a page with a heavy embed, it is an estimate of the wrong page.
This is not a reason to ignore Lighthouse. Most of the time the simulated number and the real one agree, and a bad score is a real problem. Confirm it first, then fix it.
How to check the number before you chase it.
Run Lighthouse from the command line with --throttling-method=devtools, or from the Lighthouse panel in Chrome DevTools with simulated throttling switched off. Compare First Contentful Paint between the two runs. If they are close, the score is real and you have work to do. If they are far apart, look at what loads before first paint.
- A bad mobile score is re-run with devtools throttling before anyone starts fixing it.
- If the two runs disagree, look in the simulated run for a third party that starts before first paint. That is usually the whole gap.
- Booking widgets, chat, maps and video embeds load after the page
loadevent either way. It costs the visitor nothing and takes the question off the table. - A looping background video keeps Speed Index open for as long as it plays. Expect that page to read lower than the rest of the site, and tell the client before they find it.
- Both numbers go in the launch notes, with the throttling method written next to each.
What the score is for.
A page speed score is a diagnosis, not a grade. I aim for 75 to 80 in most competitive sets and then stop arguing with it. Past that, the time is better spent on the page itself.
What matters is that the number you report is one a visitor would recognize. Hand a client a red 8.8 without checking it and you have taught them to distrust every score after it, including the ones that are right.
Confirming a bad mobile number is part of the performance pass in the 5Four Launch Checklist, on every launch we run.
Related: which Core Web Vital to fix first, Core Web Vitals in the glossary.
Designer, developer and educator in Miami. I run strategy and creative direction at 5Four Digital, a web design and development agency that leans on AI. I have spoken at AIGA, Adobe MAX and Webflow Conf, and I put the whole process on YouTube.
