PageSpeed Insights now runs Lighthouse 13.6.0, a release published on GitHub on October 27 that changes how the tool simulates a slow connection. Barry Pollard of the Chrome team wrote on November 2 that the version is live on PSI. A lab score can therefore move with no change to the page itself.
Why did my PageSpeed Insights score change?
PageSpeed Insights now runs Lighthouse 13.6.0, released on October 27, and its simulated load works differently. Chrome’s Barry Pollard wrote on Bluesky on November 2 that the update improves simulated FCP and LCP, giving “more accurate” and “usually better” scores. Your page may be unchanged.
What changed in Lantern’s simulation?
By default Lighthouse loads a page at full speed and estimates how a slower connection would have behaved, according to Search Engine Journal’s report on the update. The 13.6.0 release notes file the work under “Lantern simulation improvements”, and say it was done “to improve simulation accuracy”.
| Change in 13.6.0 | What it touches in a report |
|---|---|
Render-blocking read from Chrome’s renderBlocking status |
Which requests the simulation treats as render-blocking (13.5 used fetch priority, per SEJ) |
| FCP graph used when text LCP lands in the same frame as FCP | Simulated LCP on those pages |
| HTTP/3 treated as multiplexed | Connection modeling for HTTP/3 sites |
The same list includes a fix to the simulated LCP breakdown calculations, better origin RTT and throughput estimates, and improved redirect handling. Pollard added that the change is “not SPA-specific”, though “more likely to impact JS-heavy sites”.
What have developers reported so far?
Max Cohen posted that react.dev “was reporting LCP (~7s) and TBT (~2s), but now it’s 1.1s (LCP) and 10ms (TBT)”, with a perfect performance score. Ivan Akulov, who is credited as a new contributor in the release notes, wrote on November 3 that “some Framer sites (previously incorrectly scored) get +20-30 perf points.” Both are individual reports, not Google figures, and their numbers cover react.dev and “some Framer sites”, not sites in general.
We ran react.dev through the PageSpeed Insights API on November 3 (mobile). The response reported Lighthouse 13.6.0 and a performance score of 96, with LCP at 1.3 s and TBT at 160 ms. That is one run, and lab scores vary from run to run, so it is not a baseline.
How do you tell a tool change from a site change?
Start with the version label: according to SEJ, each PSI report shows the Lighthouse version next to the emulated device. Compare only runs that show the same one. We found no exact switch time, only that PSI was on 13.6.0 by Pollard’s November 2 post, so treat the change as a break in your series and annotate it on dashboards.
Then check field data. The CrUX section of a PSI report covers the last 28 days of real Chrome visits, so it is a separate dataset from the simulation. PSI’s documentation, as quoted by SEJ, notes that good lab data “does not necessarily mean real-user experiences will also be good”. If you want real-user monitoring of your own, remember that such a script runs inside your pages: our report on the DebugBear RUM script incident at Polymarket shows what a compromised one can do.
What else changed in Lighthouse 13.6?
The CLI can now audit several URLs in one command, by listing them or passing --url-file, and --fail-fast stops at the first failure. Default report filenames now include the URL path.
The robots-txt and llms-txt audits now fail on HTTP 429, so a robots.txt that answers with that status will show as failing. Our robots.txt generator covers the file’s contents, not the status your server returns. The release also updates the ard-schema audit to Agentic Resource Discovery v0.91; the audit now looks for ard.json and warns on legacy ai-catalog locations.
When does 13.6 reach Chrome DevTools?
The release notes expect it in DevTools with Chrome 159, which Pollard says is currently in Canary. Chrome’s release schedule lists the 159 branch point on November 9 and the stable release on December 8. Until then, a Lighthouse run in stable Chrome and a PageSpeed Insights run can come from different versions, which is one more reason to read the label before comparing numbers.
