The score is not the thing being measured
A Lighthouse performance score is a weighted average of five timing metrics, mapped onto a curve derived from how real websites perform. It is a summary. Treating it as the goal produces the familiar pattern of a site that scores in the nineties in testing and still feels slow to the people using it.
Underneath the number are the measurements that mean something, and three of them are the ones worth knowing by name.
The three that matter
- Largest Contentful Paint. When the biggest thing above the fold finished rendering — usually a hero image or a block of heading text. It is the closest single number to when did this page appear. Under 2.5 seconds is the target.
- Interaction to Next Paint. How long the page takes to visibly respond when someone taps or clicks. It replaced First Input Delay as a Core Web Vital in 2024, and it is a harder test, because it measures every interaction rather than only the first. Under 200 milliseconds.
- Cumulative Layout Shift. How much the page jumps about while loading. This is the one users feel most sharply, because it is what makes them tap the wrong thing. Under 0.1.
These three are Core Web Vitals; the rest of the score is made of supporting metrics. If you fix nothing else, fix these, and fix them in the order the report ranks them by estimated saving.
Lab and field are different measurements
This distinction resolves most of the confusion about page speed reporting.
A Lighthouse run is a lab measurement: one page load, on a simulated device over a simulated network, from a data centre. It is reproducible enough to compare a change against a baseline, and it is not what anybody experienced.
Field data is what real visitors experienced, collected from actual Chrome users over a rolling twenty-eight day window. It appears in the Core Web Vitals report in Search Console. It is the data Google uses for the ranking signal, and it is the answer to is my site fast.
The two disagree often and legitimately. A page can score seventy in the lab and pass on field data because most of its visitors are on fast connections. A page can score ninety-five and fail, because its real audience is on mid-range phones in places with slow networks and the simulation was kinder than reality.
Why the mobile score is always worse
Because the mobile audit throttles deliberately. It simulates a slow connection and a mid-range phone, on the reasonable grounds that this is closer to how most people browse than a fast desktop on office broadband is.
Desktop and mobile are separate audits producing separate scores for the same page, and comparing them tells you something useful: a large gap means the page depends on processing power or bandwidth that many of your visitors do not have. A small gap on a low score means the problem is the server or the payload rather than the device.
Expect the number to move
Run the same unchanged page twice and the score will differ by a few points. Lighthouse measures a real page load, so server response time, network conditions and whatever third-party scripts happen to be slow at that moment all feed into it.
The practical rule: movement under about five points is noise, and a sustained change of ten or more is real. Compare like with like — same strategy, same time of day, several runs rather than one — before concluding that a change helped.
The [msm_tool slug="page-speed-auditor"] runs the audit through Google's PageSpeed Insights service, which is the one tool in this category that leaves your browser, because performance cannot be measured for somebody else's URL from your own machine. Results are cached, and the result says whether you are looking at a stored run or a fresh one. That matters when you are checking whether a fix worked: a cached result from before the deploy will show you the old page.
Working the opportunities
The report lists opportunities ordered by estimated saving, and the ordering is the most useful thing in it. The first two items usually account for most of the achievable difference. The rest frequently cost more engineering time than the milliseconds are worth.
In practice a handful of causes explain most slow pages: images served far larger than they are displayed, render-blocking CSS and JavaScript in the head, third-party scripts — chat widgets, tag managers, analytics stacks — and fonts that block text from painting. Fixing images and deferring third-party scripts resolves more real-world slowness than every micro-optimisation combined.
When to stop
When the field data passes. That is the whole answer.
Ninety is not a goal, and neither is a hundred. Core Web Vitals are a ranking signal, but a small one — enough to separate two pages of otherwise equal relevance, and nowhere near enough to lift a page that does not answer the query. A site chasing a score past the point where real users pass is spending effort that would earn more if it went into the content.
Audit before and after a change, watch the field data over the following weeks, and let the number be a diagnostic rather than a target.