Your PageSpeed Insights Performance score jumped (or dropped) overnight, and nobody deployed anything. Same HTML, same scripts, same tag container. A client has a saved screenshot from last month and wants to know what happened.
Before you credit a release or blame a plugin, check one thing: did the measurement tool change? A lab score is the output of a specific Lighthouse build, and PageSpeed Insights (PSI) moves to new builds on its own schedule. This guide gives you a five-step check, a small logging script, and a client note you can fill in.
A worked example: Lighthouse 13.6.0
A vendor blog post from Apogee Watcher says Lighthouse 13.6.0 shipped on 27 October 2026 and that PSI was running it within about a week (source). It says the Performance weights did not change. What changed is Lantern, the model that estimates how a page would load under mobile throttling.
According to that post, Lantern now prefers Chrome's own render-blocking label for each request and falls back to fetch priority only when the label is missing. It also says text-based LCP in the same frame as first content is now estimated from the same requests and tasks used for FCP. The post adds that Barry Pollard noted scores often come out higher, especially on JavaScript-heavy pages.
Treat those details with care. They come from a single vendor post, so check them against the official Lighthouse 13.6.0 release notes before you repeat them to a client. The method below does not depend on them. It works for any future Lighthouse version bump.
The five-step diagnostic
- Find the Lighthouse version on both reports.
- Confirm the site really did not change.
- Check which metrics moved.
- Read the field data (CrUX) next to the lab score.
- Log the version and re-run before you write to anyone.
Step 1: Find the Lighthouse version on both reports
On the PSI web page, the vendor post says the version appears next to the emulated device in the report details. If you cannot spot it in a saved screenshot, that screenshot is weak evidence on its own.
The API is unambiguous. The PSI API v5 response carries the version at lighthouseResult.lighthouseVersion. If one report says 13.5.x and the other says 13.6.0, you are comparing two different measurements, and some of the gap may be the simulator rather than your code.
If the versions match, stop blaming the tool. A real site change or plain run-to-run noise is now the more likely cause.
Step 2: Confirm the site did not change
Be strict here. Check the last deploy, any CDN purge, tag-manager container publishes, A/B test or consent-banner changes, and third-party script updates. A script you do not own can change a lab score as easily as a commit can.
If nothing moved and the versions differ, the simulator is the leading suspect. That is an inference, not proof, so keep going.
Step 3: Check which metrics moved
Open the lab metrics and compare FCP, LCP, Total Blocking Time (TBT) and CLS between the two runs. The vendor post says the 13.6 changes centre on simulated paint timings. If FCP and LCP moved while TBT and CLS stayed close, that pattern fits a simulation change.
If TBT moved most, look at main-thread work: a new script, a longer task, a third-party tag. If CLS moved, look at layout: late-loading images, injected banners, font swaps. Those are site questions, and a version bump alone is a weaker explanation for them. See related: binary serialization vs json: varints, tags and caches for additional background.
The same post names JavaScript-heavy templates and text-first LCP blocks as the places the jump shows up. Image LCP behaves differently, it says, because work that finishes before the image paints can still stretch simulated LCP. So a template with a hero image may not move much, and that would not mean the tool is broken.
One caution: single Lighthouse runs vary. Run the same URL a few times before you decide a small difference means anything.
Step 4: Read the field data next to the lab score
The CrUX section of the same PSI report shows real Chrome visits over a rolling window. A Lighthouse upgrade does not rewrite it, so field LCP, INP and CLS should not jump overnight because Lantern changed.
That is why the field block settles arguments. If the lab score rose 12 points and the field numbers sit where they were, visitors did not get a faster site.
A higher lab Performance score also says nothing certain about search results. Lab Performance is a diagnostic blend, and field Core Web Vitals are what Google documents for page experience. Do not promise a ranking effect from a lab score change in either direction.
Some URLs will have no field data at all. See the failure case below.
Step 5: Log the version and re-run
A saved screenshot cannot answer this question next month. A dated row with the version can. The script below records it on every run, so the next comparison states which Lighthouse build produced each score.
A minimal logging script (unexecuted)
This script has not been run. It targets Node 18 or later (built-in fetch, no dependencies) and the PSI API v5. The field names follow the API response structure, so test it on one URL before you trust it. An API key is optional for light use, but unauthenticated requests may be rate-limited.
// psi-log.mjs (unexecuted example)
// Usage: PSI_API_KEY=yourkey node psi-log.mjs https://example.com/
import { appendFile } from 'node:fs/promises';
const url = process.argv[2];
if (!url) {
console.error('Usage: node psi-log.mjs https://example.com/');
process.exit(1);
}
const api = new URL('https://www.googleapis.com/pagespeedonline/v5/runPagespeed');
api.searchParams.set('url', url);
api.searchParams.set('strategy', 'mobile');
api.searchParams.set('category', 'performance');
if (process.env.PSI_API_KEY) api.searchParams.set('key', process.env.PSI_API_KEY);
const res = await fetch(api);
if (!res.ok) {
console.error('PSI request failed with status ' + res.status);
process.exit(1);
}
const data = await res.json(); We cover related ground in [schedule a nightly supabase edge function with pg_cron in depth](/schedule-a-nightly-supabase-edge-function-with-pg-cron).
const lh = data.lighthouseResult;
const a = lh.audits;
const field = data.loadingExperience;
// url-level, origin-only, or none
let fieldStatus = 'none';
if (field && field.metrics) {
fieldStatus = field.origin_fallback ? 'origin-only' : 'url-level';
}
const row = [
new Date().toISOString().slice(0, 10),
url,
lh.lighthouseVersion,
Math.round(lh.categories.performance.score * 100),
Math.round(a['first-contentful-paint'].numericValue),
Math.round(a['largest-contentful-paint'].numericValue),
Math.round(a['total-blocking-time'].numericValue),
a['cumulative-layout-shift'].numericValue.toFixed(3),
fieldStatus,
(field && field.overall_category) || 'n/a'
].join(',');
await appendFile('psi-log.csv', row + '\n');
console.log('date,url,lighthouse,score,fcp_ms,lcp_ms,tbt_ms,cls,field,field_category');
console.log(row);
Expected output
The values below are invented to show the shape, not measured results:
date,url,lighthouse,score,fcp_ms,lcp_ms,tbt_ms,cls,field,field_category
2026-11-04,https://example.com/,13.6.0,91,1400,1900,120,0.020,url-level,FAST
The script also appends the row to psi-log.csv. Add the header line to that file once by hand, since the script only prints it to the console.
Verify it works
Run it against one URL, then load the same URL in the PSI web interface with the mobile tab selected. The version string should match the one on the report, and the score should land within a few points.
Also read: how to shut down dev vms at night: tags, schedule, alerts
Run the script twice in a row. A small score wobble is normal, but the version column should be identical.
Failure case: no field data
Low-traffic URLs often lack enough Chrome visits for URL-level CrUX data. The script then logs origin-only (the API fell back to site-wide data) or none (no field data returned). Do not read an origin-only result as proof about that specific page.
In that case you have only the lab score and the version to work with. Say so plainly in the client note instead of guessing at field status. Also watch for an HTTP 429 response, which usually means you are hitting the request limit. Add a key or space out the runs.
The client note
Keep it short and name the versions. Fill in the blanks:
PageSpeed Insights measured [URL] at [score A] on [date A] using Lighthouse [version x], and at [score B] on [date B] using Lighthouse [version y]. We made no changes to code, assets or tags between those dates [confirm this is true]. The changed metrics were [FCP / LCP / TBT / CLS]. Field data from CrUX for the same URL [moved / did not move / is unavailable for this URL because of low traffic]. We now log the Lighthouse version with every run, so future comparisons use one build.
If the versions differ and the field data did not move, add one sentence: the lab change reflects an updated simulation, not a change in what visitors experience. If the versions are the same and the metrics moved, drop that sentence and go back to step 2, because something on the site probably changed.
What to expect next
Your saved history will probably show a step when PSI upgrades Lighthouse, so annotate it when it happens. A scheduled run on the same URLs, using the CSV above or any tool that records the version, turns the next bump into a five-minute check instead of a debate.
Before you quote any 13.6 specifics to a client, read the official Lighthouse 13.6.0 release notes yourself.
