Lighthouse 13.6 Can Raise PageSpeed Insights Lab Scores: What Changed

According to Search Engine Journal's 2 November report citing Chrome's Barry Pollard, PageSpeed Insights now runs Lighthouse 13.6.0, a version the Lighthouse team released in the GoogleChrome GitHub repository on 27 October 2026 with changes to Lantern, the engine that simulates how a page loads. Chrome Web Performance Developer Advocate Barry Pollard said the update makes simulated First Contentful Paint (FCP) and Largest Contentful Paint (LCP) more accurate and generally produces higher scores, with JavaScript-heavy sites more likely to be affected. A page can therefore get a better PageSpeed Insights lab score without any change to the page itself.

The Lighthouse v13.6.0 release notes on GitHub said the team expected the version to reach PageSpeed Insights "within a week" and to ship in the DevTools of Chrome 159. Search Engine Journal reported on 2 November 2026 that PageSpeed Insights had switched, citing Pollard's post on Bluesky. This article explains what changed in the simulation, why score histories will show a step, and how lab data differs from the field data Google uses for Core Web Vitals reporting.

What changed in Lighthouse 13.6.0

The release notes group the 13.6.0 changes into a few headline areas. The table below lists the ones that matter for performance reporting and site audits, as stated in the release notes, with the date and status facts reported around the rollout.

How Lantern simulates a page load

Lighthouse does not, by default, slow the network down while it tests. Search Engine Journal summarised Lighthouse's throttling documentation this way: the page loads at full speed, and Lighthouse then estimates how it would have loaded on a slower connection. That estimate is the job of Lantern. It builds a dependency graph of the page's requests and main-thread tasks, models the network, and calculates when FCP, LCP and the other metrics would have happened under the throttled profile. Search Engine Journal also noted that the throttling documentation says this simulated throttling matches PageSpeed Insights' setup.

Because the reported metrics are calculated, any change to the model changes the numbers, even if the page and the real network are identical. That is the core of this story. Lighthouse 13.6.0 changed the model, so PageSpeed Insights lab results before and after the switch were produced by different simulations.

The render-blocking change

The release notes say Lighthouse now "used protocol renderBlocking status for render-blocking priority." Search Engine Journal explained the before and after: Lighthouse 13.5 used each request's fetch priority to decide whether that request blocked rendering, while Lantern in 13.6 uses Chrome's own render-blocking label for each request and falls back to priority only when the label is missing. A request that Chrome does not treat as render-blocking, but that has a high fetch priority, would previously have been counted as delaying the first paint in the simulation.

The text-LCP change

The second change applies when the LCP element is text painted in the same frame as the page's first content, so one paint counts as both FCP and LCP. According to the release notes, Lantern now uses the FCP graph in that case. Search Engine Journal described the effect: Lantern estimates that LCP from the same requests and page tasks it uses for FCP, instead of from a set that can include every request made before LCP.

Search Engine Journal traced part of this to a GitHub issue filed by developer Ivan Akulov. His test page, built with Framer, had only text above the fold, so FCP and LCP were the same element. The old simulation still reported a much later LCP than FCP. Preloading the page's JavaScript modules improved interactive time on the real page but made simulated LCP worse. Pollard replied that Akulov had "kicked off some of these improvements," and the Lighthouse team closed the issue as completed in the Lantern upgrade listed in the 13.6 notes.

Network and JavaScript modelling

The remaining Lantern items in the release notes are about network and script attribution. HTTP/3 connections are now treated as multiplexed, consumed HTTP/2 overflow bytes are credited across simulation steps, connectionless requests are excluded from active connection counts, and origin round-trip time, throughput and redirect handling were improved. Lighthouse also added attribution for the v8.compileModule and v8.evaluateModule trace events, which relate to JavaScript modules, and fixed the calculation of the simulated LCP breakdown. The release also upgraded the trace engine to versions 0.0.66 and 0.0.67.

Why JavaScript-heavy sites see the biggest jump

Pollard's comment, as quoted by Search Engine Journal, was that the change is "not SPA-specific (and unrelated to other SPA things we've been working on), but more likely to impact JS-heavy sites." He was replying to a developer who had noticed a large improvement for single-page apps, citing react.dev. The release notes themselves do not rank which sites are affected most, so Pollard's statement is the authority on that point.

The mechanism is consistent with the changes listed. Sites that load many scripts, preload JavaScript modules or serve several resources with high fetch priority were the most exposed to the old way of counting render-blocking requests and the old text-LCP estimate. That is analysis, not a claim from Google: the release notes describe the model changes, and Pollard gives the direction of the score effect.

The change does not mean the simulation is now perfect. Search Engine Journal pointed to an open Lighthouse GitHub issue investigating cases where Lantern's simulated LCP runs far above measured LCP, with large JavaScript and SPA sites as examples.

Lab data versus field data

PageSpeed Insights shows two kinds of data, and only one of them changed on this update. Google's PageSpeed Insights documentation says lab data is generated by Lighthouse in a simulated environment, and that for mobile Lighthouse simulates a mid-tier device (Moto G4) on a mobile network. Field data comes from the Chrome User Experience Report (CrUX) and covers real users' FCP, LCP, CLS and INP over the previous 28-day collection period. The documentation states that a lab score of 90 or above is considered good, but "having good lab data does not necessarily mean real-user experiences will also be good."

The field section of a PageSpeed Insights report is untouched by Lighthouse 13.6, because it is not simulated. Only the lab performance score and the lab metrics underneath it moved.

This distinction is also the one Google draws for search. Google Search Central's page "Understanding Core Web Vitals and Google search results" describes Core Web Vitals as metrics that "measure real-world user experience" for loading, interactivity and visual stability, and says good Core Web Vitals align with what Google's core ranking systems seek to reward. Search Console's Core Web Vitals report, according to its help page, is based on real-world usage data, sometimes called field data, from CrUX. A higher Lighthouse score after 13.6 therefore says nothing new about the real-user metrics that Search Console reports.

What this means for performance reports

Search Engine Journal described the practical risk: PageSpeed Insights scores from before and after the update were not measured with the same simulation, so part of a higher lab score on a page you just optimised may come from the new version, and charts that track lab scores over time may show a jump at the switch. Each PageSpeed Insights report shows the Lighthouse version used, next to the emulated device, which makes it possible to tell which side of the switch a result sits on.

The following is analysis for teams that report lab scores, not guidance from Google:

• Annotate dashboards and monthly reports at the date your tooling moved to Lighthouse 13.6, so a score step is not read as a site improvement or a team win.
• Compare like with like. Before claiming an improvement, check that the before and after reports name the same Lighthouse version, as Search Engine Journal recommended, and compare the field data.
• If you run Lighthouse yourself, through the CLI, CI pipelines or third-party monitoring, check which version each tool uses. DevTools is expected to get 13.6 with Chrome 159, which Search Engine Journal said was in the Dev and Canary channels as of 2 November, with a stable release listed for 8 December 2026. Until then, DevTools and PageSpeed Insights may disagree.
• For client or stakeholder reporting, lead with CrUX field data and Search Console's Core Web Vitals report where the site has enough traffic to appear in CrUX, and treat lab scores as a debugging aid.

Teams that include performance checks in a wider SEO audit should record the Lighthouse version alongside every lab result from now on.

Other changes in the release

Bulk URL auditing in the CLI

The Lighthouse CLI can now audit several URLs in one command, either by passing multiple URL arguments or with --url-file, and --fail-fast stops the run at the first failure. Default report filenames now include the URL pathname, in the form hostname-pathname_date, to avoid collisions between pages on the same host. For anyone auditing a template set across a site, that removes a scripting step.

Agentic Resource Discovery audit updated to v0.91

The ARD audit, introduced in Lighthouse 13.5, was updated to the ARD v0.91 specification, with ard.json replacing ai-catalog.json. The release notes say discovery is supported via Link HTTP headers, a <link rel="ard"> element and /.well-known/ard.json, that Lighthouse warns on legacy ai-catalog locations, and that the report footer shows the ARD spec version. Search Engine Journal added that 13.6 also looks for an Agentmap line in robots.txt before checking the old ai-catalog names, and that under 13.5 a site using only the new file name without that robots.txt line could show as Not Applicable.

Smaller fixes worth knowing

The release notes also list that robots.txt and llms.txt audits no longer throw when content is null and now fail on an HTTP 429 response, that performance insight audits populate numericValue from estimated time or byte savings, and that peak memory use during runs was reduced by streaming traces.

What this means for Thai marketers

Nothing in this update is specific to Thailand. PageSpeed Insights is a global tool, so any Thai site tested there after the switch is scored by Lighthouse 13.6, and the same step in score histories applies. PageSpeed Insights' documentation also notes that tests run in a Google data centre in North America, Europe or Asia, and that the location can vary, so the report's environment block is worth checking when comparing runs.

The practical points for Thai businesses are about reporting. If an agency, developer or in-house team reports a sudden PageSpeed Insights gain in early November 2026, ask whether the site changed or the tool did. For sites with enough Chrome traffic to have CrUX data, the field section of the same report is the steadier measure, because it reflects real visitors over 28 days. When a site is rebuilt, the baseline and post-launch lab measurements should come from the same Lighthouse version. If a site needs real performance work rather than a better-looking number, Relevant Audience's web design team can help plan it.

Frequently asked questions

Why did my PageSpeed Insights score go up without any changes?

Your score most likely rose because PageSpeed Insights switched to Lighthouse 13.6.0, whose new simulation generally produces higher FCP and LCP results according to Google's Barry Pollard. The lab score is calculated by a model, and the model changed; the page did not.

Does the Lighthouse 13.6 update change my Core Web Vitals?

No, the update changes lab results only. Core Web Vitals as reported in Search Console and in the field section of PageSpeed Insights come from CrUX data on real Chrome users, which Lighthouse does not simulate.

Which sites are most affected by Lighthouse 13.6?

JavaScript-heavy sites are more likely to be affected, according to Pollard, who also said the change is not specific to single-page apps. The release notes describe model changes around render-blocking requests, text LCP painted with FCP, HTTP/3 and JavaScript module events.

How can I tell which Lighthouse version produced a result?

Each PageSpeed Insights report lists the Lighthouse version next to the emulated device, according to Search Engine Journal. Comparing two reports is only fair when both name the same version.

When will Chrome DevTools use Lighthouse 13.6?

The Lighthouse team expects 13.6 to ship in the DevTools of Chrome 159. Search Engine Journal reported that Chrome's release schedule listed Chrome 159 for stable release on 8 December 2026, as of 2 November.

A score jump that comes from a new simulation is easy to explain once the version is on the report. If your team wants performance and technical checks tied to real-user data, Relevant Audience's SEO services can help set that up.