# Lighthouse used to punish useful preloads. Framer spent a year fixing that.

Framer spent roughly a year working with the Lighthouse team on a quiet but expensive bug: sites that painted quickly for real visitors still looked slow in PageSpeed Insights. Their [engineering write-up](https://www.framer.com/blog/lighthouse-13-6/) and [announcement on X](https://x.com/framer/status/2118356391136301526) were published after Lighthouse **13.6.0** (27 October 2026) and the PageSpeed Insights roll-out of that build. The claim is blunt. Many Framer pages were already fast; the lab score was wrong about *why* paint waited.

That matters for agencies, not only for Framer customers. The same Lantern shortcut punished other single-page apps and any stack that preloads modules and fonts early on purpose. Some teams then did the worst rational thing: they removed useful preloads to please the old model, and made real visits worse. What follows is the agency reading of that story: what broke, what 13.6 fixed, what is still messy for image Largest Contentful Paint (LCP), and what to put in the client note when a lab Performance score jumps without a release.

For the longer scoring mechanics on our monitoring blog, see [Google Lighthouse Score Explained: How Scoring Works](https://apogeewatcher.com/blog/how-lighthouse-performance-scores-recorded-calculated?utm_source=hashnode&utm_medium=referral&utm_campaign=lighthouse-preload-framer-13-6). For when `preload` belongs on the current page at all, keep [Preload, Prefetch, and Preconnect: Resource Hints for Faster Core Web Vitals](https://apogeewatcher.com/blog/preload-prefetch-preconnect-resource-hints-faster-core-web-vitals?utm_source=hashnode&utm_medium=referral&utm_campaign=lighthouse-preload-framer-13-6) open. If you only need the “did the site change or did Lantern change?” checklist, our earlier DevLog note [Why did PageSpeed Insights jump overnight? (Lighthouse 13.6, site unchanged)](https://devlog.apogeewatcher.com/why-pagespeed-insights-jumped-overnight-lighthouse-13-6) covers that path.

## Why Lighthouse punished Framer preloads (and other SPAs)

PageSpeed Insights does not throttle a phone for every run. It captures a fast load, then **Lantern** estimates how that graph would play on a slower mobile profile. Until 13.6, Lantern leaned hard on fetch **priority** to decide what blocked First Contentful Paint (FCP) and LCP. High-priority work that finished before paint looked like a queue the paint had to wait for, even when Chrome itself did not treat that request as render-blocking.

How Framer loads pages made the bug loud. The product preloads the JavaScript modules a page needs and inlines CSS that references fonts. Real browsers fetch that work in parallel without blocking paint the way a classic blocking stylesheet does. Lantern saw a cluster of high-priority early requests and held simulated FCP and LCP for them anyway. Framer’s public examples show double-digit Performance gains on some brand sites after 13.6 with **no site change**. The median change across their sample is smaller; the point is the minority of pages that were scored unfairly, not a universal +20 for everyone.

Agencies meet the same pattern outside Framer: Vite and modern SPA shells, `modulepreload` lists, font `preload` or `@font-face` that resolve early, marketing sites that look “JS heavy” in the lab while the hero text is already in the first HTML frame. The retainer conversation then splits. Engineering trusts the field or a real device. The PDF trusts the yellow Performance integer. Both parties are looking at honest artefacts that answered different questions.

## Lighthouse priority vs render-blocking: why modulepreload looked slow

Chrome already labels requests with a **render-blocking** status. Lantern mostly ignored that label and guessed from priority and type instead. A high-priority `modulepreload` therefore “looked” like something FCP had to wait for. A font fetched early looked the same. Removing those hints could raise the old lab score while slowing interactivity or font readiness for visitors. Framer tried that path and rejected it for the obvious reason: visitors come first.

Lighthouse 13.6 changes the rule for FCP simulation. If Chrome says a request does not block rendering, Lantern no longer makes simulated FCP wait for it. Module preloads, many font fetches, and some third-party early work stop counting as blockers when they should not. That is the core of the Framer improvement, and it is also why a careful preload strategy can look better overnight without a code change on the site.

A second fix covers a narrower case: when the largest paint is **text in the same frame as first content**, simulated LCP now tracks simulated FCP instead of waiting on a wider set of earlier requests. Ivan Akulov’s react.dev example in the Framer post is a clear case. One text block, two metrics that used to disagree by seconds in the lab.

Neither fix rewrites Chrome UX Report (CrUX) or Search Console field status. They rewrite the **lab** timings that feed the weighted Performance score. Treating a 13.5→13.6 step as a client win without naming the Lighthouse version is how retainers invent an unverified “we made it faster” story.

## Image LCP in Lighthouse 13.6: what still over-counts

Framer is explicit about the remaining gap. When LCP is an **image**, Lantern can still treat many requests that finished before the image as work the image waited for, including module preloads and fonts. The FCP render-blocking fix does not fully carry over. Image-heavy templates may still look worse in the lab than on a mid-range phone, especially when unrelated early fetches finish quickly on the fast capture connection.

So the honest agency line after 13.6 has two clauses. Text-first and SPA shells with early module preloads often get a fairer lab story now. Hero-image LCP still needs field data, real-device checks, and the usual image work (discoverable URL, sizing, priority) rather than faith that Lantern finally matches every visit. Framer has proposed further optimistic-LCP changes; those are not the same as “already shipped everywhere.”

## Should you remove modulepreload to improve PageSpeed Insights?

Three habits age badly after this release:

1. **Stripping** `modulepreload` **or font hints solely to raise a 13.5-era Performance score.** When those hints helped real navigation and interactivity, restoring them and re-measuring on 13.6 is usually wiser than leaving the slower visitor path in place for the next PDF.
2. **Crediting a sprint for an overnight lab jump when the Lighthouse version moved.** Both PageSpeed Insights cards name a Lighthouse version. Same HTML with 13.5 vs 13.6 is a simulation change until someone shows a real site change.
3. **Collapsing lab Performance and field Core Web Vitals into one sentence.** A greener lab score after Lantern got smarter does not mean Search Console moved. Dated cold-load lab rows and field percentiles on the same URL set let the next person see which measurement changed.

Resource hints still need care. Speculative or duplicate preloads that compete with the LCP image remain a current-page problem; that is the resource-hints guide, not a reason to delete every early fetch. The Framer case is specifically about **useful** early work that Chrome did not treat as render-blocking, yet Lantern did.

## Lab Performance vs field Core Web Vitals after Lighthouse 13.6

When a Framer site or similar SPA jumps twelve or twenty lab points, the client note can stay short: which Lighthouse versions you compared, whether the HTML changed, and what field LCP, INP, and CLS show on a rolling window. If preloads were removed earlier only to improve the lab Performance colour band, say you are restoring them and watching lab and field side by side. That is enough for most account emails without a Lantern lecture.

Scheduled monitoring still helps here. A single PageSpeed Insights run cannot tell you whether next week’s theme update undid the preload list again, or whether image LCP stayed poor while text templates looked fine. Portfolio schedules, version-aware lab history, and field rows are how you separate a fairer simulator from actual shipping work. Apogee Watcher is built for that monitoring across many client properties; the Framer story is another reminder that the lab Performance score moves for reasons that are not always “we made the site faster.”

## FAQ

**Did Framer make sites faster in Lighthouse 13.6?**\
For many of their examples, the sites were already fast for visitors. The lab model stopped over-counting early high-priority work as render-blocking for FCP. Some pages gain a lot; many gain a little. Check your own URLs.

**Is removing modulepreload still a good PageSpeed Insights tip?**\
Usually not as a default. If you removed them under 13.5 to chase the score, re-test on 13.6 before you leave visitors on the slower path.

**Is image LCP fixed too?**\
Not fully, per Framer’s write-up. Image LCP can still over-count early requests. Lean on field data and image delivery work for hero-heavy templates.

**How is this different from the “overnight jump” checklist?**\
That note is the short diagnostic: same site, new Lighthouse version, what to tell the client. This piece is the Framer lineage: why preloads were punished, what still fails for images, and what agencies should stop undoing.

## Restore useful preloads after Lighthouse 13.6; keep lab and field dated

Agency technical leads who inherited “we made PageSpeed green by removing preloads” can treat Lighthouse 13.6 as a reason to reverse a bad trade when the hints were serving visitors. Key templates usually need a fresh run on the new build. What was stripped only for the old model can go back; image LCP still belongs on a field and lab check; a dated schedule keeps the next simulator change from becoming another unverified win in the PDF.

That history across client sites is what Apogee Watcher is for when spreadsheets stop scaling. [Start a trial](https://apogeewatcher.com/sign-up) or [run a free PageSpeed check](https://apogeewatcher.com/check) on the URLs that moved. Leaving stripped preloads in place after the model improved is how real visits stay slow while the PDF celebrates a lab simulation.

## References

- [Lighthouse 13.6: how we made PageSpeed Insights more accurate for Framer sites](https://www.framer.com/blog/lighthouse-13-6/) (Framer Engineering)
- [Framer on X: Lighthouse 13.6 / slow-phone simulation](https://x.com/framer/status/2118356391136301526)
- [Why did PageSpeed Insights jump overnight? (Lighthouse 13.6, site unchanged)](https://devlog.apogeewatcher.com/why-pagespeed-insights-jumped-overnight-lighthouse-13-6) (Apogee Watcher DevLog)
- [Google Lighthouse Score Explained: How Scoring Works](https://apogeewatcher.com/blog/how-lighthouse-performance-scores-recorded-calculated) (Apogee Watcher)
- [Preload, Prefetch, and Preconnect: Resource Hints for Faster Core Web Vitals](https://apogeewatcher.com/blog/preload-prefetch-preconnect-resource-hints-faster-core-web-vitals) (Apogee Watcher)