PageSpeed Insights (PSI) now runs Lighthouse 13.6.0, a release that changes how simulated page load timing is calculated. Pages can receive a different score without any change to the page, and JavaScript-heavy sites are more likely to be affected.
- PageSpeed Insights now runs Lighthouse 13.6.0, released Oct. 27, which changes how simulated FCP and LCP are calculated.
- Chrome’s Barry Pollard says the simulated metrics are now more accurate and generally produce higher scores.
- A page can score differently without any change to it, and JavaScript-heavy sites are more likely to be affected.
- Charts of lab scores over time may show a jump at the switch, so the Lighthouse version in each report should be checked.
- Lighthouse 13.6 is expected in Chrome 159 DevTools, scheduled for stable release Dec. 8.
PageSpeed Insights has moved to Lighthouse 13.6.0
PageSpeed Insights is now using Lighthouse 13.6.0, which was released Oct. 27, according to Search Engine Journal. Barry Pollard, Chrome’s Web Performance Developer Advocate, said on Bluesky that the updated PageSpeed Insights with Lighthouse 13.6.0 is now available.
Pollard said the update improves the simulated First Contentful Paint (FCP) and simulated Largest Contentful Paint (LCP). He says these will be more accurate than before and generally result in higher scores.
A page may therefore receive a different PageSpeed Insights score even though nothing on it has changed, because the test itself changed.
Websites heavily dependent on JavaScript are more likely to see an impact from the updated test. Pollard said the change is not limited to single-page applications (SPAs). His note read: “Note this is not SPA-specific (and unrelated to other SPA things we’ve been working on), but more likely to impact JS-heavy sites.”
No figure for the typical size of the score change appears in the sources. They don’t say how large the shift is for any given page.
How the Lantern simulation changed
Lighthouse is Google’s open-source automated tool for auditing web page quality, including performance. Lantern is the simulation behind Lighthouse’s estimates of how a page would load on a slower connection.
The simulation matters because of how Lighthouse tests by default. Its default method, simulated throttling, loads the page at full speed and then simulates a slower connection, so the slow-connection numbers are modeled rather than observed directly.
Google’s own Lantern documentation puts Lantern’s error at roughly 6 to 13 percent against DevTools throttling, which loads the page on a genuinely slowed connection. That is about as much as single runs of the same page vary on their own, so the model is useful but not exact. A few points of movement in a simulated score can come from either source.
Two metrics are affected. First Contentful Paint (FCP) is a metric for when the first content appears on a page. Largest Contentful Paint (LCP) is a metric for when the largest content element loads.
Both changes in 13.6 concern how Lantern decides which requests and tasks sit on the path to those two moments. One deals with rendering blockers, the other with text-led pages.
Render-blocking detection
Lighthouse 13.5 used each request’s fetch priority to decide whether that request blocked rendering. In Lighthouse 13.6, Lantern uses Chrome’s own render-blocking label for each request instead. It falls back to priority only when that label is missing.
The change replaces an inference with a label supplied by the browser. It affects which requests the simulation treats as holding up the first paint, and therefore the simulated FCP.
LCP estimation for text content
The second change concerns pages where the LCP element is text appearing in the same frame as the page’s first content. Lantern now estimates LCP from the same requests and page tasks it uses for FCP.
Before, the estimate came from a set that can include every request made before LCP. For a text-led page, that could push the simulated LCP well past the simulated FCP even though both describe the same moment on screen.
The new approach removes that gap for this case. Pages whose largest element is an image or other non-text content are not described in the sources as using this path.
The GitHub issue behind the change
Ivan Akulov showed the problem in a GitHub issue. His Framer test page had only text above the fold. Under the old simulation, one element counted as both FCP and LCP, yet the simulated LCP came out much later than the FCP.
Pollard thanked Akulov, saying he “kicked off some of these improvements.” The Lighthouse team closed the issue as completed in the Lantern upgrade listed in the 13.6 release notes.
What site owners and SEO teams should expect
Each PageSpeed Insights report includes the Lighthouse version used, shown next to the emulated device. That label is the quickest way to tell whether a report came from the new simulation.
Scores from before and after the Lighthouse simulation update were not produced by the same model. Charts of lab scores over time, such as those in monitoring tools or client reports, may therefore show a jump at the switch that reflects the test and not the site.
A rise in a lab score right after the update is not, on that evidence alone, a result of optimization work. Marking the date of the change on trend charts keeps readings from before and after from being treated as equal.
The version label tells you which simulation produced a score, but not whether that score is reliable. For that, open the report’s audit data. Each Lighthouse report keeps observed metrics, the values recorded during the unthrottled load, next to the simulated ones produced by the PageSpeed Insights Lantern model. In the JSON output they sit in the details of the metrics audit, under names such as observedLargestContentfulPaint. Compare the simulated FCP and LCP with what the page shows when you run it with DevTools throttling applied. A simulated value that comes out much slower than the throttled run points to a problem in the simulation rather than in the page. In that case, we suggest treating the score with caution before you plan any optimization work around it.
The scoring bands are described in Google’s documentation. Google for Developers says PSI classifies scores of 90 or above as good, 50 to 89 as needs improvement and below 50 as poor. The sources differ on labels: GreenGeeks Blog calls the same ranges Fast, Average and Slow, with 49 and below as Slow.
| Score | Google for Developers | GreenGeeks Blog |
|---|---|---|
| 90 or above | Good | Fast |
| 50 to 89 | Needs improvement | Average |
| Below 50 (49 and below) | Poor | Slow |
Core Web Vitals are INP, LCP and CLS. Because the update changes simulated LCP, it touches one of the three in the lab.
Lab data versus field data in PageSpeed Insights
PSI provides two kinds of data: lab data generated by Lighthouse, and field data from the Chrome User Experience Report (CrUX). CrUX is a dataset of real-user performance data from opted-in Chrome users. The Lighthouse 13.6 change applies to the lab side.
Field data covers real users over the previous 28-day collection period. PSI reports the 75th percentile for all metrics, and the field data is updated daily. The CrUX dataset on BigQuery works differently. It is updated monthly and limited to origin-level data.
Lab data is a controlled simulation. For mobile tests it simulates a mid-tier Moto G4 device on a mobile network, and for desktop it uses an emulated desktop with a wired connection. PSI reports the Google datacenter location of a run as North America, Europe or Asia.
Lab scores can also vary from run to run. Google lists local network availability, client hardware availability and client resource contention as sources of that variability.
The sources do not say that field data changes with this update. A shift in the lab score does not by itself show that real users are seeing a faster or slower page.
Why PageSpeed Insights scores have differed from other tools before
PageSpeed Insights scores have been calculated using Google Lighthouse since 2018, so a change in Lighthouse can move PSI results.
Version differences have caused gaps between tools before. In 2023, a GitHub discussion reported that lab scores in Chrome DevTools were often 20 to 25 points higher than in PageSpeed Insights. At that time PSI used Lighthouse 10.0.0 and DevTools used 10.1.0.
Version mismatches remain a recurring reason for diverging results. Lighthouse 13.6 is expected in Chrome DevTools only with Chrome 159, so DevTools and PSI may run different versions for a while. That is why the version label in each report matters when results are compared.
Lighthouse 13.6 also changes the Agentic Resource Discovery audit
Agentic Resource Discovery (ARD) is a manifest audit checked by Lighthouse, using an ard.json file. Lighthouse 13.6 updates this audit from the version in Lighthouse 13.5.
The audit now looks for an Agentmap line, a rel=”ard” link tag or Link header, and /.well-known/ard.json before it checks the ai-catalog names.
If Lighthouse finds the ARD manifest only at an ai-catalog location, it notes that ARD consumers are not required to check there. Sites that publish an ard.json file are therefore pointed toward the earlier locations.
Open questions and what comes next
The simulation is not settled. An open issue on Lighthouse’s GitHub is looking into cases where Lantern’s simulated LCP runs far above measured LCP, with large JavaScript and SPA sites as examples.
That issue is easier to judge against the accuracy limits Google documents. Lantern’s own evaluation compares its estimates with repeated DevTools throttling runs and reports errors in roughly the same range as the variance between single runs and repeat views of one page. A score shift of a few points after 13.6 may therefore be noise, while a simulated LCP several seconds above the measured value, as in the open issue, points to a real gap in the Lighthouse LCP simulation.
Lighthouse’s release notes say 13.6 is expected to ship in the DevTools of Chrome 159, which is in Chrome’s desktop Dev channel and Canary. As of Nov. 2, Chrome’s release schedule lists Chrome 159 for stable release on Dec. 8.
Sources
Photo: Search Engine Journal
Frequently asked questions
Why did my PageSpeed Insights score change without any site changes?
Why did my PageSpeed Insights score change without any site changes?
PSI now uses Lighthouse 13.6.0, which changes how simulated FCP and LCP are calculated. A page can score differently even though nothing on it has changed.
Which sites are most likely to see a different score?
Which sites are most likely to see a different score?
Pollard said websites heavily dependent on JavaScript are more likely to be affected. He said the change is not SPA-specific.
How can I tell which Lighthouse version a PageSpeed Insights report used?
How can I tell which Lighthouse version a PageSpeed Insights report used?
Each report includes the Lighthouse version, shown next to the emulated device.
When will Lighthouse 13.6 reach Chrome DevTools?
When will Lighthouse 13.6 reach Chrome DevTools?
It is expected in Chrome 159 DevTools. As of Nov. 2, Chrome 159 is scheduled for stable release on Dec. 8.
Does PageSpeed Insights use field data as well as Lighthouse?
Does PageSpeed Insights use field data as well as Lighthouse?
Yes. PSI provides Lighthouse lab data and field data from the Chrome User Experience Report, covering real users over the previous 28-day collection period.
What score counts as good in PageSpeed Insights?
What score counts as good in PageSpeed Insights?
Google for Developers lists 90 or above as good, 50 to 89 as needs improvement and below 50 as poor. One third-party source labels the same ranges Fast, Average and Slow.