Tools Snippet

Lighthouse 13.6 Stops Penalising Some Preloads in Simulated FCP and LCP

Markdown
View as Markdown Open this page as plain text
This page as Markdown, ready to paste into ChatGPT, Claude or a doc.
RSS
A lighthouse at night shines its yellow beam on two sailing boats whose sails read HTML and CSS, while two boats with sails reading JS and FONT sail on below the beam, unlit.
From Lighthouse 13.6, a headline's simulated paint waits on the HTML and CSS, not on module scripts or, where the headline paints with the first paint, preloaded fonts. Illustration: AI-generated.

Lighthouse 13.6.0, released on 27 October 2026, changes how its default simulated throttling estimates First Contentful Paint (FCP) and Largest Contentful Paint (LCP). Simulated throttling loads the page on a fast connection and then calculates how it would have loaded on a slow mobile one, and until this release that calculation counted resources loaded early against both metrics whether or not the page waited for them. The release notes expect it to reach PageSpeed Insights within a week and the DevTools of Chrome 159, and do not say how much scores will move.

What changed in Lighthouse’s simulated FCP and LCP?

Two fixes matter for pages that preload. For FCP, Lighthouse treated every high-priority script, including <script type="module"> and <link rel="modulepreload">, and every very-high-priority font as render-blocking; it now checks Chrome’s own record of whether each request blocked rendering. For LCP, when the largest element is text painted in the same frame as FCP, simulated LCP now depends on the same resources as FCP, where before any font, image, async stylesheet or non-blocking script that finished downloading first pushed it later. Ivan Akulov, a performance engineer at the website builder Framer, reported the problem in June 2025 as “Lighthouse Punishes Good Asset Preloading”, using a page whose real FCP and LCP were around 1.0 to 1.1 seconds and which scored yellow or red for FCP in PageSpeed Insights.

Two panels showing the same four requests as bars on a time axis: HTML, a stylesheet, a module script and a font preload. Before Lighthouse 13.6, all four are counted, the FCP marker sits at the end of the module script and the LCP marker at the end of the font. From Lighthouse 13.6, the module script and font are drawn faded as not counted, and a single FCP equals LCP marker sits at the end of the stylesheet.
A simplified model, not to scale, of a page whose largest element is a headline in a system font, as Lighthouse simulates it. Where the largest element is an image, files that finish downloading before it paints still count.

What to re-test after Lighthouse 13.6

If you removed modulepreloads or font preloads to raise a Lighthouse score, re-run the page on 13.6 before leaving them out, because a preload that made real visits faster no longer has to cost you in the lab. The text fix does not extend to image LCP: requests that finish before an image paints still count towards its simulated time. If a Performance score moves in early November on a page that has not changed, check which Lighthouse version produced the report before looking for a cause on the site. The lab score is not what Google Search measures: Google describes Core Web Vitals as metrics that “measure real-world user experience”, and Search Console’s Core Web Vitals report is based on field data from real visits, so a score that moves for this reason changes the diagnosis, not the page’s standing in Search.

Sources

More news

Add as a preferred source on Google