PageSpeed Insights now runs Lighthouse 13.6.0, a release that shipped Oct. 27, and the new version changes how the tool simulates page load time. Barry Pollard, Web Performance Developer Advocate at Chrome, announced the switch on Bluesky, and Search Engine Journal reported on his post Nov. 2. A page can now get a different score with no change to the page.
Pollard said the update improves the simulated First Contentful Paint (FCP) and simulated Largest Contentful Paint (LCP) estimates. He described both as more accurate than before and as generally producing higher scores. The word “generally” carries weight. No typical size of gain was given, and individual pages will vary.
JavaScript-heavy sites are the most likely to notice. Pollard replied to a developer who had said single-page apps saw big improvements, opening with “True!” and adding: “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.” React.dev was the example the developer cited.
The mechanics sit in Lantern, the part of Lighthouse that estimates slow-connection behavior after loading a page at full speed. Per the 13.6.0 release notes, Lantern now decides what blocks rendering from a label Chrome itself assigns to every request. Fetch priority is a fallback for requests lacking one. Version 13.5 judged blocking by priority alone.
A second change targets pages where the LCP element is text rendered alongside the first content. Lantern now builds that LCP estimate from the requests and tasks behind FCP, rather than a wider pool that might take in everything requested ahead of LCP.
A GitHub issue from Ivan Akulov shows the old behavior. His Framer test page had only text above the fold, so one element served as FCP and LCP at once, yet Lighthouse reported a much later LCP. Preloading the JavaScript modules sped up interactivity on the real page but made simulated LCP worse. Pollard thanked Akulov and said he “kicked off some of these improvements.”
This is a lab-test change, not a field-data change. Lighthouse produces the performance score through a simulated load on one device under fixed network conditions. Field data is gathered from actual Chrome visitors through CrUX, the Chrome UX Report, and covers the previous 28 days. Google’s own documentation warns that “having good lab data does not necessarily mean real-user experiences will also be good.” Neither Pollard’s post nor the report ties the update to search rankings, so treat it as a measurement shift.
The practical risk is false attribution. Scores taken before and after 13.6 came from different simulations. Part of the gain on a freshly optimized page could belong to the tool, and trend lines of lab scores may show a step at the switch. Each PageSpeed Insights report names its Lighthouse version beside the emulated device, which makes the check easy.
Two items are still moving. Lighthouse’s release notes say the team expects 13.6 to land in Chrome 159 DevTools, a build now in the desktop Dev channel and Canary. Chrome’s schedule, checked Nov. 2, puts stable release on Dec. 8. A separate open GitHub issue investigates simulated LCP landing well beyond measured LCP, citing big JavaScript and SPA sites.
Before you report a speed win to a client or executive this quarter, confirm both reports name one Lighthouse version, then check the CrUX field numbers alongside. Annotate performance dashboards with the 13.6 switch date so a tooling step is not mistaken for engineering progress.
Search Engine Journal, Matt G. Southern, published November 2, 2026, citing Barry Pollard of Chrome on Bluesky.
