A Better Lighthouse Score Is Not Proof Your Marketing Site Got Faster

A higher Lighthouse score is worth investigating, not announcing as a faster website. After Lighthouse 13.6.0, some simulated paint results may improve even if nobody deployed a change to your marketing site. The useful question for a CTO or marketing lead is narrower: did visitors get a better experience on the pages they actually use?

The score rose. What actually changed?

Lighthouse 13.6.0 was released on October 27, 2026. It changed parts of Lantern, the model Lighthouse uses to simulate page loading. Calibre moved its test agents to that version on October 31 and said simulated First Contentful Paint (FCP) and Largest Contentful Paint (LCP) would mostly improve on its PageSpeed test profiles. That could raise Performance scores without a site deployment.

This is not evidence that Lighthouse is broken. A better model can produce a more accurate estimate. Nor does it mean every page will get a higher score: the effect depends on the page and test profile. But it does create a reporting trap. If your dashboard shows a step change near a tool upgrade, a chart labeled “site speed improved” may be attributing a measurement change to engineering work.

The Performance score is a weighted average of metric scores. Change a simulated paint value and the overall number can move. The score is useful for spotting and diagnosing a problem under stated test conditions; it is not a direct measurement of what your visitors experienced. A rounded score also hides which metric moved. Before prescribing a redesign—or claiming a successful one—look at FCP, LCP and the underlying run.

Start by keeping both reports. Record the tested URL, time, Lighthouse and Chrome versions, device profile and throttling mode. Check whether your team deployed code or content, or whether ads, experiments or other third parties changed. Annotate the tool upgrade separately from deployments. Without that record, the before-and-after story is guesswork.

What changed in the FCP and LCP simulation

The 13.6.0 release notes describe changes to Lantern’s request and dependency modeling. One concerns Chrome’s render-blocking status: the simulation needs to understand whether a request actually holds up rendering, rather than treating recorded request priority as a reliable stand-in. Another changes the dependency graph when text LCP occurs in the same frame as FCP. Both affect how a captured load is modeled, not necessarily how the live site loads.

A reported reproduction with Lighthouse 13.4.1 shows why that distinction matters. Re-auditing the same captured artifacts after changing only a module request’s recorded priority moved simulated FCP by about 180 ms. Observed FCP did not change. That demonstrates sensitivity in the earlier model; it is not a measured 13.6.0 improvement for your site and should not be turned into an expected uplift.

The throttling mode matters too. Calibre says these two paint fixes do not affect profiles using runtime throttling. If two dashboards disagree, check their profiles before deciding that one is wrong. Server response, content, ads and ordinary run-to-run variation can also move results. You need controlled comparisons, not a universal adjustment factor for Lighthouse 13.6.0.

For a defensible lab comparison, test the same production URL and content with pinned Lighthouse and browser versions under the same device and network conditions. Repeat runs and compare the metrics and their spread, rather than choosing the best rounded score. Lighthouse CI supports multiple URLs and repeated runs, with three runs as its documented default; Lighthouse’s variability guidance likewise recommends aggregate comparisons. If you are investigating a version jump, keep the site and test conditions fixed while comparing tool versions. If you are evaluating a site release, keep the toolchain fixed while comparing releases. Changing both at once makes attribution much harder.

Read PageSpeed Insights as two different reports

PageSpeed Insights puts CrUX field data alongside Lighthouse lab results. They answer different questions. The on-demand lab run gives you a controlled, reproducible way to inspect a page. CrUX describes eligible Chrome users’ experiences over a rolling 28-day period and reports field metrics at the 75th percentile. It is not an immediate verdict on yesterday’s release, and it does not represent every visitor.

Check the scope of the field result before quoting it. Page-level CrUX needs eligibility and sufficient traffic, so a campaign landing page may have no page-level result. An origin-level result describes the broader origin, not the specific URL you just tested in Lighthouse. Presenting the two side by side is helpful; describing the origin number as proof that one landing page improved is not.

Field data should guide which user problems deserve attention. Lab data should help reproduce and diagnose them, as Google’s guidance on lab and field differences explains. A lab run can see a different LCP element from real users because devices, viewports, cache states, personalization and A/B variants differ. Stable field LCP immediately after a release does not prove the release did nothing, either: the rolling window and changing traffic mix can obscure a recent improvement.

When CrUX cannot answer a page-level question, instrument an appropriate real-user view. Google’s web-vitals library exposes onLCP, onINP and onCLS; its attribution build can add diagnostic details such as an LCP target. Those callbacks are collection points, not a reporting system. You still need to decide how to report, store, segment and analyze results, and to note consent and sample-size limits. Separate mobile from desktop and compare relevant URLs or templates rather than averaging unlike pages into one reassuring number.

Test the marketing site you actually publish

A homepage audit does not describe a CMS-driven site. Build a URL matrix from published output: a text-led article, an image-led story, a lead-generation landing page, and localized or campaign variants where applicable. For each important template, include a high-traffic example and an unusually heavy one. Heavy means actual content and integrations, not just a synthetic page built for a test: the image-led story with large media, the form page with third-party scripts, or the article with its real font and component choices.

Repeat comparable lab runs across that matrix. Look at FCP and LCP values and the trace before deciding what to fix. Is the LCP element text or an image? If it is an image, inspect its delivery on affected templates. If it is text, look at fonts and the requests or JavaScript delaying rendering. Check third-party requests on the pages that load them. A single score cannot tell you which of these is responsible, and a fix on one template may do nothing for another.

Experiment variants deserve their own coverage. If a campaign or A/B test changes the content or components visitors receive, testing only the control page can miss a slower variant. Record the variant in both lab comparisons and field analysis where you can. Similarly, Search Console’s Core Web Vitals groups can point to problematic page types, but its example URLs need not represent every page in a group. Use them to choose what to inspect, not as a complete inventory of CMS output.

Do not make stack selection a substitute for this work. Astro, Next.js and a headless CMS can support a fast marketing site, but none guarantees one. Rendering choices, content components, images, fonts, caching and third-party scripts still determine what users receive. If you are planning a CMS rebuild, make template coverage, performance testing and launch monitoring part of the scope of headless CMS website development, rather than treating a framework switch as the performance deliverable.

Decide what evidence earns a faster-website claim

Agree on the wording before the project starts. “The lab result improved” means you can reproduce a diagnostic finding under comparable conditions. “Visitors got a faster website” needs supporting real-user evidence for the relevant pages and an appropriate observation period. Neither statement requires you to dismiss the other: a corrected simulation is welcome, and a controlled lab improvement can be real even before a rolling field metric reflects it.

Use this release checklist when a score changes:

• Preserve the baseline: Save before-and-after reports, URLs and timestamps. Record Lighthouse and Chrome versions, throttling mode, device profile and any changes to deployments, CMS content, ads or experiments.

• Separate causes: Annotate measurement-tool upgrades independently. Compare tool versions on unchanged pages to investigate a scoring jump; compare site versions with a fixed toolchain to evaluate engineering work.

• Cover the published site: Test representative and heavy examples of each important CMS template, including relevant locales and campaign variants. Repeat runs and inspect FCP, LCP and traces, not only the aggregate score.

• Check visitor evidence: Use page-level CrUX where available. Label origin-level data honestly; where page-level data is missing, use suitable real-user monitoring. Review mobile and desktop LCP, INP and CLS by URL or template, with traffic, consent, sample size and the 28-day window in view.

• Make the claim match the evidence: Report a reproducible lab gain as a lab gain. Credit the project with a visitor-speed win when field evidence supports it on the pages the project was meant to improve.