Page Speed Analyzer Example: 72/100 Mobile Performance

This is the single most important thing to understand about a Lighthouse report, and almost every conversation about page speed gets it wrong.

Everything above is lab data — a single synthetic load, on a simulated mid-range Android phone, on a throttled network, in a data centre. It is a controlled experiment, and it is invaluable for finding problems.

Google's page experience signals do not come from this. They come from the Chrome User Experience Report: real Chrome users, on their real devices and real networks, assessed at the 75th percentile over a 28-day rolling window. That is field data, and it is the only thing that feeds ranking.

The Performance score is a weighted composite of five lab metrics — it is not an average, and the weights are wildly uneven. This matters because it tells you which number to attack if you want the score to move.

TBT at 280ms is doing most of the damage here, because it carries the heaviest weight and it is the metric furthest from good. CLS is already 0.02 — excellent, and there is nothing to win there. Attacking the JavaScript is where the score is.

This is the trap in every Lighthouse report and it catches experienced developers.

INP — Interaction to Next Paint — is the Core Web Vital for responsiveness, and it replaced FID in March 2024. It cannot be measured in a lab test, because measuring it requires somebody to actually interact with the page. Lighthouse therefore reports TBT instead: a proxy that measures how long the main thread was blocked during load, on the reasonable assumption that a blocked thread would have been slow to respond had anyone tried.

The assumption holds often and not always. A page can have an acceptable TBT and a terrible INP, because the expensive JavaScript runs in response to the interaction rather than during load — a heavy filter, a re-render, a search-as-you-type handler. None of that is visible to a load-time test.

TTI is a lab-only metric with no field equivalent at all, and Google has steadily de-emphasised it. Do not build a business case on it.

"LCP is 3.1 seconds" is not actionable. LCP decomposes into four sequential phases, and the fix is completely different depending on which one is consuming the time:

First, identify which element the LCP actually is. On a marketing homepage it is usually the hero image or the headline. People routinely optimise an image that was never the LCP element and are baffled when nothing improves.

The report attributes 1.2 seconds to two render-blocking CSS files, one of them Google Fonts. The mechanism is worth understanding because it is a chain of serial round trips, and each link is on the critical path:

• The browser must fetch and parse the stylesheet before it can render anything at all.
• The @font-face rule pointing at the font file lives inside that stylesheet — so the browser cannot even discover the font URL until the CSS has arrived.
• Only then does it request the font. From a different origin, requiring a fresh DNS lookup, TCP handshake and TLS negotiation.
• Text that depends on the font cannot paint until it arrives.

That is at minimum two serial round trips before a word appears, and none of it is under your control.

Self-host the fonts. It removes the third-party origin entirely, it removes a GDPR exposure — a German court ruled in 2022 that loading fonts from Google's servers transmitted visitors' IP addresses unlawfully without consent — and it lets you preload the font from your own domain, where the browser's preload scanner finds it immediately. If you do preload a font, the crossorigin attribute is mandatory even for same-origin files; without it the browser fetches the font twice and you have made things worse.

The four opportunities list savings of 1.2s, 0.8s, 0.6s and 0.4s. Two warnings:

The "280KB of unused JavaScript" is the most valuable line in the report, and not because of the 0.6s. Unused JavaScript is not just a download — the browser must parse and compile it, on the main thread, which is exactly what TBT is measuring. It is one defect showing up in two places, and the report has already identified the culprit: a dashboard bundle loading on a page that has no dashboard.

This gap is expected and it is not a bug. Lighthouse's mobile test applies deliberate CPU throttling and a simulated slow network to approximate a mid-range Android phone. Desktop is tested unthrottled. The same page, the same code — a very different machine.

Optimise for the mobile number. Google indexes with a mobile user-agent and assesses Core Web Vitals separately for mobile and desktop. The desktop 91 is reassuring and it is not the score being judged.

And note where the gap is concentrated: TBT is 280ms on mobile and 40ms on desktop — a sevenfold difference. That is the signature of a CPU-bound problem, not a network one. The JavaScript is not too large to download; it is too expensive to execute on a phone. Sending less of it is the fix; a faster CDN is not.

What is a good PageSpeed score?

90–100 is considered Good. 50–89 is Needs Improvement. Below 50 is Poor. The most important score for SEO is the mobile Performance score as Google uses mobile-first indexing. Focus on the Core Web Vitals within the report (LCP, CLS, INP) as these are direct Google ranking signals.

What causes a poor LCP score?

The most common LCP causes are: unoptimised hero images (too large, wrong format, not preloaded), render-blocking resources preventing early rendering, slow server response times (TTFB above 600ms), and CSS that delays critical content from displaying.

How do I fix render-blocking resources?

Render-blocking resources are CSS and JavaScript that prevent the page from displaying until they finish loading. Fix by: adding rel='preload' for critical CSS, deferring non-critical CSS to load after paint, using defer or async on non-critical JavaScript, and inlining critical above-the-fold CSS directly in the HTML.

Is the Lighthouse Performance score a Google ranking factor?

No. Google has never used the Lighthouse composite score as a ranking signal. It uses the three Core Web Vitals — LCP, INP and CLS — measured in the field via the Chrome User Experience Report, at the 75th percentile of real visits over a 28-day rolling window. A page scoring 72 in the lab with good field vitals is fine; one scoring 95 with poor field vitals is not.

Why does Lighthouse report TBT instead of INP?

Because INP cannot be measured without somebody actually interacting with the page, and a lab test has no user. TBT is a load-time proxy: it measures how long the main thread was blocked, on the assumption that a blocked thread would also have been slow to respond. The assumption often holds and sometimes does not — a page can have acceptable TBT and poor INP when the expensive JavaScript runs in response to the interaction rather than during load.

Do the estimated savings add up?

No. Fixing all the listed opportunities will not save their combined total, because the savings overlap — several compete for the same critical path — and each is modelled independently assuming the others are unchanged. Treat the list as a priority order rather than a budget. Scores also fluctuate several points between runs of the same URL, so take the median of three runs and ignore single-digit changes.

Why is my mobile score so much worse than desktop?

Because the mobile test deliberately throttles the CPU and network to approximate a mid-range Android phone, while desktop is tested unthrottled. The gap is expected. Where TBT is dramatically worse on mobile than desktop, the problem is CPU-bound rather than network-bound — the JavaScript is not too large to download, it is too expensive to execute on a phone. Sending less of it is the fix; a faster CDN is not.