Lighthouse 13.6: how we made PageSpeed Insights more accurate for Framer sites

A Framer page can paint its main content in 300 ms for a real visitor and still get a yellow score in PageSpeed Insights. For years, customers asked us why. And for years, our answer was ”because PageSpeed Insights is wrong here” – which is a hard answer to give when the other side is Google.

So we worked with Google on solving this. Lighthouse 13.6, released last week, makes Lighthouse more accurate on Framer sites (and many other single-page apps). Some of the biggest brands on Framer gained 12 to 25 points:

You don’t need to change anything on your site to get the new score.

The issue: Lighthouse punished preloading

Lighthouse (and PageSpeed Insights, which runs it) doesn’t actually load your page on a slow phone. That’s slow and noisy. Instead, it loads the page on a fast connection, records every request, and then simulates how those requests would play out on a slow phone. This simulation is called Lantern.

The tricky part is figuring out which requests actually slow down loading. Lantern took a shortcut: any request that happened before the page became visible was assumed to hold it back. The only filter was priority: First Contentful Paint (FCP) ignored low-priority requests, and Largest Contentful Paint (LCP) ignored almost nothing.

And that’s a problem for Framer. To make sites load fast, we tell the browser about every JavaScript module a page needs, right in the HTML (<link rel="modulepreload">), and we inline the page’s CSS, including font references (@font-face). The browser fetches all of that early, in parallel, without blocking anything – but with the high priority. Lantern saw a bunch of high-priority requests finishing early – and decided the page couldn’t paint until all of them loaded.

The result? On real devices, the site was fast, but in Lighthouse, it had bad FCP and LCP. If we removed the preloads (we tried!), the page got faster in Lighthouse but slower for real visitors. Obviously, that’s not great.

We reported this as Lighthouse issue #16539 in June 2025. It’s now the second-most-upvoted issue in the Lighthouse repo.

With Lighthouse 13.6, most of the issues are addressed

After a year of advocacy, Chromium changes, and conference chats with Googlers, Lighthouse 13.6.0 shipped on October 27 with two fixes.

Fix 1: preloads and fonts no longer delay First Contentful Paint

Chrome already knows which requests block rendering. Every request it makes comes with a renderBlocking status: blocking, non_blocking, and a few others. Lantern just never looked at it – it guessed from the request’s priority and type instead, so a high-priority preload “looked” render-blocking.

Lighthouse 13.6 now asks Chrome for this status. If Chrome says a request doesn’t block rendering, Lantern no longer makes FCP wait for it. On Framer sites, that removes a lot:

• web fonts from @font-face,

• <link rel="modulepreload">s,

• the page’s main <script type="module">,

• some third-party requests.

This shipped in Chromium change 8508087 and Lighthouse PRs #16869 / #17307.

Fix 2: when the first paint is the largest paint, LCP equals FCP

Here’s the home page of react.dev. The biggest thing on screen is a block of text:

ONE TEXT ELEMENT · TWO METRICSWhen the first paint is the largest paint

Lighthouse 13.5Lighthouse 13.6

SIMULATED PAINT EVENTS

FCP 1.2 sLCP 6.0 sFCP + LCP 1.2 s0 s2 s4 s6 sSame paint · same frame

The text appears at 1.2 s, yet Lighthouse 13.5 reports its LCP at 6.0 s.

Lighthouse 13.6 recognizes that this text appears in the first paint: FCP and LCP both land at 1.2 s.

This block of text is in the HTML, so it shows up in the very first frame the browser paints. FCP and LCP happen at the same moment – literally within the same frame.

Lantern didn’t know that. It estimated FCP and LCP separately, and the LCP estimate waited for (almost) every request that finished before the paint. So Lighthouse would report FCP at 1.2 s and LCP at 6 s – for the same block of text!

Lighthouse 13.6 adds a simple rule: if the real FCP and LCP happened in the same paint, and the LCP element is text, simulated LCP is simulated FCP. (#16782, shipped in #17379.)

What’s still missing: image LCP

One thing remains unfixed. When the LCP element is an image, Lantern still counts ~every request that finished before the image as something the image waited for: module preloads, fonts, fetches, scripts. Fix 1 only applies to FCP.

Say your page looks like this:

<!doctype html>
<body>
  <img src="hero.png" />
  <script type="module" src="small-script.js"></script>
  <!-- This script makes a couple of fetch requests when loaded -->
</body>

<!doctype html>
<body>
  <img src="hero.png" />
  <script type="module" src="small-script.js"></script>
  <!-- This script makes a couple of fetch requests when loaded -->
</body>

<!doctype html>
<body>
  <img src="hero.png" />
  <script type="module" src="small-script.js"></script>
  <!-- This script makes a couple of fetch requests when loaded -->
</body>

If the script and its fetches happen to finish before the image, Lantern simulates the image waiting for all of them. On a fast test connection, unrelated requests finishing early is very common, so

We’ve proposed a fix that we think is reasonable. When Lighthouse simulates LCP, it actually does it not once but twice: once optimistically (“what if everything worked out well / nothing was really blocking LCP except the most obvious things”) and once pessimistically (“what if everything worked out badly / everything was blocking LCP”). Then it takes the average of the two and uses that as the final LCP.

Our proposal is to improve the optimistic LCP: when the image is in the HTML (not inserted by JavaScript), exclude requests that Chrome marks as non-blocking from the optimistic estimate. We think this is a solid assumption, and we also think this scenario is very common on sites, both in Framer and elsewhere. Hopefully this proposal passes!

Impact

Here are the stats from a bunch of most-visited Framer sites:

The median page only gets +2 points better. But it’s not the median pages that matter, it’s the ones that were previously incorrectly scored. And these these see a large improvement!

10% of sites get 12 points better. 5% of sites get 21 points better. One site gets whopping 45 points better. All without a single change to the sites, solely thanks to Lighthouse becoming more accurate.

We also tested a bunch of marketplace templates. These are closer to what a new Framer site looks like, and exclude third-party scripts which we don’t control. These get even better: the average score goes from 74 to 78, and the share of templates without third-party scripts scoring green (90+) nearly doubles, from 18% to 31%:

And it’s not just Framer. Pages built in the same way, single-page apps with preloads, benefit too. React’s own site, react.dev, now gets a perfect score: LCP went from ~7 s to 1.1 s:

Max@maxwellcohen.bsky.social

@developer.chrome.com recently updated Lighthouse, resulting in SPA apps getting much better results. Now @react.dev has a perfect performance score! Like many SPA sites, react.dev was reporting LCP (~7s) and TBT (~2s), but now it's 1.1s (LCP) and 10ms (TBT)!

What’s next

PageSpeed Insights already run Lighthouse 13.6, and Chrome DevTools gets it in Chrome 159. You don’t need to do anything: your just get a better score when the update lands.

We’ll keep pushing for the image-LCP fix. If it lands, image-heavy pages will get more accurate too.

And if you want to make your site faster for real visitors – which is what actually matters – see our guide on optimizing site speed.