PageSpeed Insights Scores May Rise After Lighthouse Update

It is a strange feeling to spend weeks optimizing a website, only to see a sudden jump in performance scores after a weekend where you didn't touch a single line of code. While we usually celebrate a higher score, it is important to know when that improvement is a result of your hard work and when it is simply a change in how the measuring tool works.

Google has updated PageSpeed Insights to use Lighthouse 13.6.0. This update changes the underlying simulation of how pages load, which means your lab scores might shift regardless of any actual changes to your site. If you see a sudden spike in your metrics, it might not be your latest optimization, but rather a more accurate simulation from Google. A useful companion note is I Tested DeepSeek’s New Search Api, because it looks at a nearby part of the same system.

The Impact on JavaScript Heavy Sites

Barry Pollard, Chrome's Web Performance Developer Advocate, has noted that this update specifically improves the simulation of First Contentful Paint (FCP) and Largest Contentful Paint (LCP). Because the simulation is now more accurate, many sites will see their scores rise naturally.

While this affects many types of sites, those that rely heavily on JavaScript are likely to see the most significant shifts. There has been particular mention of Single Page Applications (SPAs) seeing improved results, though Pollard clarified that this isn't an SPA specific feature, but rather a general improvement to how JS heavy sites are handled.

It is worth noting that these changes are distinct from the experimental soft navigation metrics in Chrome. While soft navigation data comes from real users via the Chrome User Experience Report (CrUX), the Lighthouse updates we are discussing here affect the simulated lab environment. The same pattern also shows up in Image Search Data in GSC, where the practical question is how the signal becomes visible.

Expert Interpretation: When you see a score increase on a JS heavy site, the first question should be: "Did I change the code, or did the tool change?" If you are managing a React or Vue app, you might see a "free" boost. The tradeoff here is that while the score looks better, the actual user experience hasn't changed. You should avoid reporting this as a "performance win" to stakeholders until you verify it against real user data.

Technical Changes in the Simulation

To understand why the scores are changing, we have to look at Lantern, the simulation engine that Lighthouse uses to estimate how a page loads on slower connections. By default, Lighthouse loads a page at full speed and then calculates how it would have performed under throttled conditions.

In version 13.6.0, two primary changes were made to improve this accuracy:

First, the way render blocking is determined has shifted. Previously, in version 13.5, Lighthouse relied on the fetch priority of each request to decide if it blocked rendering. Now, Lantern uses Chrome's actual render blocking label for each request, only falling back to priority if that label is missing.

Second, there is a change in how LCP is estimated when the largest contentful element is text that appears in the same frame as the first content. Lantern now estimates LCP using the same requests and page tasks it uses for FCP. Previously, it used a broader set that could include every request made before the LCP occurred.

This solves a specific issue where some sites, particularly those built with tools like Framer, showed a massive gap between FCP and LCP even when a single text element served as both. In those cases, preloading JavaScript modules actually made the simulated LCP look worse, even though it improved real world interactivity.

Expert Interpretation: This is a move toward "truth" in simulation. By using Chrome's internal render blocking labels rather than guessing based on priority, Google is reducing the noise in lab data. The decision you need to make here is whether to continue aggressive preloading of scripts that might have previously "penalized" your simulated LCP. If the simulation was wrong, your previous "fixes" to satisfy the tool might actually be hindering real performance.

Updates to the ARD Audit

Beyond performance metrics, Lighthouse 13.6 has updated the Agentic Resource Discovery (ARD) audit. This is a more niche area of the tool, but it is important for those implementing AI discovery manifests.

In version 13.5, the audit looked for manifests under old ai catalog names. This created a problem for sites using the updated ard.json specification; unless they had a specific Agentmap line in their robots.txt file, the audit would simply return "Not Applicable."

The new version is more thorough. Lighthouse 13.6 now checks for the following in order:

An Agentmap line in robots.txt. A rel="ard" link tag or Link header. The /.well known/ard.json path. The older ai catalog names.

If the tool only finds the manifest in the old ai catalog location, it will now explicitly notify you that ARD consumers are not required to check that location anymore.

Expert Interpretation: This is a cleanup of technical debt in the audit process. If you are using AI manifests to guide agents on your site, you should ensure you are using the ard.json standard. The tradeoff for ignoring this is simply a lack of visibility for AI agents, not a direct hit to your SEO rankings, but it is a signal of technical maturity.

Distinguishing Lab Scores from Field Data

This update highlights a fundamental truth about PageSpeed Insights: the performance score is a lab result. Lab data is a simulation using a single device and a fixed set of network conditions. It is a controlled environment designed for consistency, not a mirror of reality.

Field data, on the other hand, is the real world. This data comes from the Chrome User Experience Report (CrUX) and reflects actual visits from real users over the last 28 days. Google explicitly states that having good lab data does not guarantee that real user experiences are good.

Because the simulation logic in Lighthouse 13.6 has changed, the lab score is a moving target. You can find the specific version of Lighthouse used for any given report right next to the emulated device in the PageSpeed Insights interface.

Expert Interpretation: The danger here is "score chasing." When the simulation changes, the "perfect" way to optimize for the tool also changes. You must prioritize field data over lab scores. If your lab score goes up but your CrUX data remains flat, your users aren't feeling any difference. Use the lab data to test hypotheses, but use the field data to prove success.

Why This Shift Matters for Reporting

If you track your performance metrics in a spreadsheet or a dashboard over time, you will likely see a "jump" or a "cliff" around the time Lighthouse 13.6 was implemented. If you are reporting these numbers to a client or a manager, this is a critical point of clarification.

A higher score on a page you recently optimized might be a combination of your actual improvements and the new simulation logic. To get an honest assessment of your work, you should:

• Verify that the "before" and "after" reports were generated using the same version of Lighthouse.
• Compare the field data (CrUX) to see if the real world experience improved alongside the simulation.

Without this check, you risk attributing a tool update to your own technical skill, which leads to a misunderstanding of what actually drives performance on your site.

Expert Interpretation: This is a lesson in baseline management. Whenever a primary measurement tool updates its methodology, your previous baselines become obsolete. The decision here is to reset your baseline. Don't try to "normalize" the old data to fit the new; instead, mark the date of the Lighthouse update in your logs and start a new tracking period.

What to Expect Moving Forward

The rollout of Lighthouse 13.6 is already underway in PageSpeed Insights, but it will also reach the Chrome browser's built in DevTools. It is expected to ship with Chrome 159, which is currently in the Dev and Canary channels and slated for a stable release around December 8.

Despite these improvements, the work isn't finished. There are still open discussions on GitHub regarding cases where the simulated LCP is significantly higher than the measured LCP, particularly on large JavaScript sites and SPAs. This suggests that while 13.6 is a step forward, the simulation of complex, modern web apps is still a challenge for Google.

As these updates continue, the gap between "simulated" and "real" should shrink, but the fundamental difference between lab and field data will remain. The goal is not to have a perfect score in a simulation, but to ensure that the simulation is an accurate enough proxy to help us improve the actual experience for the person visiting the page.

Expert Interpretation: The fact that Google is still investigating LCP discrepancies for SPAs tells us that lab scores for complex apps are still "estimates" at best. If you run a heavy application, take your lab scores with a grain of salt. The most reliable path forward is to build a culture of monitoring real user metrics (RUM) rather than relying solely on a once-a-week PageSpeed Insights check.