Site speed test: PageSpeed, Lighthouse and CrUX explained
Why site speed test results never agree: what PageSpeed, Lighthouse and CrUX each measure, the field vs lab data difference, and the right reading order.
By Roozbeh Nazari · CEO
Everyone who runs a site speed test hits the same confusion: PageSpeed Insights says 62, Lighthouse says 91, the Core Web Vitals report in Search Console says "needs improvement", and all three appear to have measured the same page. This is not an inconsistency; three tools measure three different things, and each answer belongs to a different question. This article explains what PageSpeed Insights, Lighthouse and the Chrome User Experience Report (CrUX) measure, from whom and under which conditions; then it sets out the order in which a site speed test should be read, and which number can support which decision. The goal is to improve the speed users actually experience, rather than to "raise the score".
Lab data versus field data
The basic distinction is this: lab data is a load simulation run right now on a single virtual device under fixed network conditions. Field data is the sum of what real users experienced on real devices and connections over a past period. Google's PageSpeed Insights documentation draws the line clearly: field data compiles users' FCP, INP, LCP and CLS experiences historically; lab data is a simulation on a standard device, which is why the two can give different results. Lab data is repeatable and suited to debugging; field data is user reality, and it is the side Google uses in its page experience evaluation. The first question when reading a site speed test should be: is the number I am looking at a simulation or a user?
What the three tools measure
Lighthouse is an open-source audit tool built into Chrome; it loads the page from scratch and produces scores in categories such as accessibility and SEO alongside performance. Its performance score is entirely lab data and varies with the device, extensions and network you run it on; two consecutive runs on the same page can differ. CrUX is a dataset compiled from the real experience of Chrome users; it contains data only for publicly discoverable origins and pages with enough traffic, which is why it says "not enough data" for new or low-traffic pages. PageSpeed Insights shows both on one screen: at the top, the field data from CrUX (if any); below, the Lighthouse lab result run at that moment. So the upper part of PageSpeed rests on the same source as Search Console's Core Web Vitals report, and the lower part is Lighthouse itself. That is why three tools give "three different scores for the same page": there are really two data sources and two summary formats.
Core Web Vitals thresholds and the right reading order
The three main metrics in field data are the Core Web Vitals. By web.dev's current definition, a good experience needs LCP within 2.5 seconds, INP at or below 200 milliseconds and CLS no higher than 0.1; the assessment is made at the 75th percentile of users. The right reading order: look at field data first; if the page passes the thresholds in CrUX, there is no user problem even if the lab score is low, and the improvement priority lies on another page. If field data misses a threshold, see which metric fails; for LCP look for a large image, server response time or a render-blocking resource; for INP, scripts that occupy the main thread; for CLS, unsized images and late-loading blocks. Only at this point move to Lighthouse: the lab report shows line by line what breaks the metric the field data pointed at. Teams that work in reverse, starting from the Lighthouse score, can spend weeks fixing problems users never experience. There is also a third layer: Search Console's Core Web Vitals report shows the same CrUX data grouped by page, revealing at a glance which template (product page, blog post, category) is the problem; looking at that report before testing single pages directs the work to the right template. In our technical SEO service the speed audit runs in this order, and every finding in the report is tagged "field" or "lab".
Extra notes for multilingual and mobile sites
CrUX data is split by device type, and on most Turkish sites the mobile slice is markedly worse than desktop; reading a site speed test on desktop only means ignoring most of your users. Multilingual sites carry a second trap: CrUX gives data at origin level and at page level; Arabic and Persian pages can produce different LCP and CLS from Turkish pages because of separate font files and right-to-left layout, but as low-traffic pages they may show no page-level data. In that case the origin-level data carries the weight of the Turkish pages and the problem is hidden. The fix is to watch language-based page groups separately in Search Console's Core Web Vitals report, and to repeat lab measurement regularly with the same device profile for languages that have no data. Our Core Web Vitals for international patients article handles this distinction with the example of clinic sites.
Which number supports which decision
The number that goes into the management report should be field data: "the share of pages whose mobile LCP exceeds 2.5 seconds", for example. The number that goes into a developer task is lab data: "3 render-blocking scripts on this page", for example. If an agency or developer asks for sign-off with "we raised the PageSpeed score to 90", ask which section they mean; a lab score can change in a day, while field data accumulates over a 28-day window and improvement shows only weeks later. That delay is not a flaw but the price of measurement based on real users. Teams that read a site speed test as a two-layer diagnostic tool rather than a score race improve the speed that both users and the search engine see; teams that raise the score and leave the user where they were only produce screenshots.
A five-minute site speed test protocol
A quick diagnosis for one page goes like this. Enter the page address into PageSpeed Insights and look first at the upper section of the mobile tab: if field data exists, note the pass or fail status of the three Core Web Vitals; if not, move to origin-level data and state in the report that this is a site average, not the page. Then read only the Lighthouse audits in the lower section that belong to the failing metric: the largest content element and server response time for LCP, long tasks for INP, unsized elements for CLS. Hand the findings to the developer by metric and element name, not as "raise the score". After the fix goes live, re-read Lighthouse the same day and the field data four weeks later; both improving is a real gain, only the first improving is a change that has not reached users yet.