# Why did PageSpeed Insights jump overnight? (Lighthouse 13.6, site unchanged)

Lighthouse **13.6.0** shipped on **27 October 2026**. Within about a week, PageSpeed Insights was running that build. The change is not a new weight table for the Performance score. It is a change to **Lantern**, the model that estimates how a fast capture would look under mobile throttling. Simulated First Contentful Paint and Largest Contentful Paint get closer to reality, and Barry Pollard noted that scores often come out higher, especially on JavaScript-heavy pages.

So a URL can show a different lab Performance score when the HTML, CSS, and scripts are the same as yesterday. That is awkward for anyone who keeps saved PageSpeed Insights screenshots for clients. The useful question is not “did Google make us faster?” It is “are we comparing two Lighthouse versions, or two states of the site?”

What follows is a short path through that question: what Lantern changed, where the Lighthouse version appears on the PageSpeed Insights card, why field CrUX will not move with the lab score, and what usually belongs in the client note. For the longer scoring guide 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=pagespeed-insights-lighthouse-13-6). For why one-off reports still sit poorly next to a schedule, see [PageSpeed Insights vs Automated Monitoring](https://apogeewatcher.com/blog/pagespeed-insights-vs-automated-monitoring-when-manual-checks-arent-enough?utm_source=hashnode&utm_medium=referral&utm_campaign=pagespeed-insights-lighthouse-13-6).

## What Lighthouse 13.6 changed in the lab simulation

PageSpeed Insights loads the page quickly, then Lantern estimates how that load would behave on a slower mobile profile. Until 13.6, that estimate relied heavily on fetch priority to decide what blocked rendering. Lantern now prefers Chrome’s own **render-blocking** label for each request, and only falls back to priority when that label is missing.

A second change affects pages whose Largest Contentful Paint is **text in the same frame as first content**. Lantern now estimates that LCP from the same request and task set it uses for FCP, instead of folding in a wider set of earlier work that could push simulated LCP later. Ivan Akulov’s Framer example showed how the old model could punish useful module and font preloads; the Lighthouse team closed that class of issue in the 13.6 Lantern upgrade.

None of that rewrites CrUX. It rewrites the **lab** timings that feed the weighted Performance score. When an overnight jump sits on a JavaScript-heavy template or a text-first above-the-fold block, the simulator is usually the first place to look before crediting a release.

## How to tell a simulation jump from a real site change

The two PageSpeed Insights reports under discussion each name a **Lighthouse version** next to the emulated device. When one says 13.5.x and the other says 13.6.0, the runs are not on the same measurement. Part of the Performance difference may be Lantern, not a code change.

Three questions usually settle the case:

1. **Did the site change?** Same commit, same CDN purge window, same tag-manager container? If nothing moved, simulation is the more likely explanation.
2. **Did FCP or LCP move more than Total Blocking Time or CLS?** Lantern’s 13.6 notes centre on simulated paint. A swing that is mostly Total Blocking Time still points at main-thread work.
3. **Does field data agree?** The CrUX block on the same PageSpeed Insights page still covers a rolling window of real Chrome visits. It will not jump overnight because Lantern changed.

If modulepreloads or font preloads were removed earlier to improve a lab colour band, it is worth running the same URL again on 13.6 before leaving them out. A preload that helped real visits may no longer cost as much in the lab. Image LCP is a different story: work that finishes before the image paints can still stretch simulated LCP.

## Lab scores and field CrUX after the update

Lab Performance is one controlled navigation under a fixed profile. Field Core Web Vitals are percentiles from eligible Chrome users. Both can mention LCP; only the lab score folds Speed Index and Total Blocking Time into a 0–100 blend with documented weights.

A higher lab Performance score after 13.6 does not mean Search Console’s Core Web Vitals report improved. Google’s field status still comes from CrUX, not from the Lighthouse Performance integer. Claiming “we gained twelve points overnight” without naming the Lighthouse version credits a lab change the field never showed.

Charts that track only the lab Performance score will show a step at the PageSpeed Insights roll-out, so that step belongs as a note on the monitoring board. Metric budgets (LCP, INP, CLS, and lab Total Blocking Time where you use them) on the same URLs still give engineering a clear ticket when the Performance score improves while visitor experience does not.

## What to put in the client note

A short, honest note usually beats a celebration deck:

- PageSpeed Insights now runs Lighthouse **13.6.0**, which changed how simulated FCP and LCP are estimated.
- Our lab Performance score moved on \[URL\] between \[date A\] and \[date B\]; versions were \[x\] then \[y\].
- Field CrUX on the same report \[moved / did not move\] for LCP, INP, and CLS.
- We keep the same URLs on a short schedule so the next comparison uses one Lighthouse minor and a dated trail.

That is enough for most account threads. When someone wants the weight table and calculator path, the Watcher scoring guide linked above already names the Lighthouse 10 weights and the version footnote, so a second methodology essay in Slack is rarely needed.

## FAQ

**Can PageSpeed Insights scores rise when the site has not changed?**\
Yes. When PageSpeed Insights upgrades the Lighthouse build (for example to 13.6.0), Lantern can change simulated FCP and LCP even if HTML and assets are identical. Matching the Lighthouse version on both reports and reading the field block usually comes before attributing the jump to a release.

**Is a higher lab score better for SEO ranking?**\
Not by itself. Lab Performance is a diagnostic blend. Field Core Web Vitals (via CrUX and Search Console when eligible) are the experience signals Google documents for page experience. The Performance score stays useful as engineering context.

**Why did my local DevTools Lighthouse disagree with PageSpeed Insights?**\
Version, throttling preset, and machine noise all differ. Matching Lighthouse versions before comparing, and preferring a short schedule of the same live URLs over two one-off screenshots, usually closes that gap. That is a monitoring problem as much as a scoring problem.

## CTA

Before the next client email about an overnight PageSpeed Insights jump, it is usually enough to match the Lighthouse versions, read the field block, and keep the same live URLs on a short schedule so LCP, INP, and CLS still have dates beside the Performance score. The scoring walkthrough lives in [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=pagespeed-insights-lighthouse-13-6). The schedule argument is in [PageSpeed Insights vs Automated Monitoring](https://apogeewatcher.com/blog/pagespeed-insights-vs-automated-monitoring-when-manual-checks-arent-enough?utm_source=hashnode&utm_medium=referral&utm_campaign=pagespeed-insights-lighthouse-13-6).

## References

- [Lighthouse 13.6.0 release notes](https://github.com/GoogleChrome/lighthouse/releases/tag/v13.6.0) (Lighthouse project)
- [PageSpeed Insights Scores May Rise After Lighthouse Update](https://www.searchenginejournal.com/pagespeed-insights-scores-lighthouse-update/595698/) (Search Engine Journal)
- [Lighthouse variability](https://github.com/GoogleChrome/lighthouse/blob/main/docs/variability.md) (Lighthouse project)
- [Lighthouse performance scoring](https://developer.chrome.com/docs/lighthouse/performance/performance-scoring) (Chrome for Developers)
- [Google Lighthouse Score Explained: How Scoring Works](https://apogeewatcher.com/blog/how-lighthouse-performance-scores-recorded-calculated) (Apogee Watcher)
- [PageSpeed Insights vs Automated Monitoring](https://apogeewatcher.com/blog/pagespeed-insights-vs-automated-monitoring-when-manual-checks-arent-enough) (Apogee Watcher)