You run PageSpeed Insights on Tuesday. Mobile performance looks acceptable. INP is not perfect, but nothing looks urgent, so you paste the link in Slack (maybe attach a screenshot) and move on.
By Thursday the account manager forwards a client message: checkout feels slow, organic traffic dipped, or a campaign page went live without web in the loop. You open PSI again. The score moved, sometimes by a lot. You are comparing two runs with nothing saved in between: no deploy note, no list of URLs, no record of which device profile you used.
That gap shows up on most agency rosters. It usually means spot checks are standing in for repeat testing and stored results.
What one Tuesday run actually tells you
A single PSI run answers a narrow question: what did Lighthouse report for this URL, on this device profile, at this moment?
That is useful. It is not a baseline for the rest of the week.
Between Tuesday and Thursday you might have:
- A deployment that added one script to the global header.
- A marketing tag that started firing on product pages only.
- A CDN cache change that improved LCP in the lab while field data was still updating.
- A traffic mix shift (more mobile, more logged-in users) that CrUX will reflect later than your manual run.
None of that appears in a tab you closed two days ago. Unless someone stored the run, named the build, and tested the same template the same way, Tuesday's green score is easy to misread on Thursday.
Thursday stress is often missing records, not a new crisis
When a spot check surprises the team on Thursday, the first move is often blind optimisation: defer scripts, shrink images, toggle a feature flag. Sometimes that helps. Often it happens because the timeline between runs was never written down.
Questions that usually settle Thursday faster:
- Which URL or template regressed (not only the homepage you always test)?
- Did lab and field move together, or did only one move?
- Was there a deployment, content publish, or third-party change between runs?
- Is the issue on one device strategy or both?
PageSpeed Insights can start that investigation. It cannot answer (3) or keep (1) comparable across many sites unless you add discipline or automation.
For a clear split between when manual PSI is enough and when it is not, see the longer comparison on the Watcher blog:
Weekly PSI without storage
Some agencies run PSI once a week to show the client they are paying attention. The client sees activity. The team feels responsible. What is missing is evidence: stored runs, thresholds, and a named owner.
Weekly spot checks without storage tend to produce two outcomes:
- Looks fine on Tuesday: Thursday's complaint gets treated as noise until someone reruns the same URL and finds a real regression.
- Looks worse on Thursday: nobody can tell whether the drop is a one-off lab flake, a cold cache, or a trend across several runs.
Both waste time. What you need is the same routes tested the same way, with scores kept so you can compare this week to last.
Lab moves fast; field data updates later
PSI can show CrUX when the origin has enough traffic. Field metrics still lag lab. A deployment on Wednesday may not show clearly in field summaries for days, while lab can move on the next run.
That timing gap drives a lot of Thursday arguments. "PSI was green" and "Search Console looks rough" can both be true for a few days if you only spot-check lab scores.
If your team needs shared definitions for LCP, INP, and CLS before you argue about tools, start with the primer, then return to scheduling:
Changes that reduced repeat Tuesday/Thursday gaps
We still open PSI for a single URL in a hurry. We stopped treating that habit as portfolio governance.
Concrete habits that helped:
- Same routes every time: homepage plus two revenue templates, not whichever URL someone remembers.
- Paired mobile and desktop: one bad strategy is easy to miss if you only run mobile because it is quicker.
- Named builds: paste the deploy tag or git SHA beside the score, even in a spreadsheet, so Thursday has a short list of suspects.
- Thresholds written down: agree what triggers action on LCP and INP before the client email arrives.
That is still manual work. It is also visible work: you can see when the spreadsheet stops scaling and scheduled monitoring is worth the setup time.
Thursday triage (about fifteen minutes)
When a client pings and your last PSI run is stale, run this before you change code:
- Re-run PSI on the reported URL and on the template you usually skip (category, checkout, logged-in home).
- Compare mobile and desktop; screenshot both if you need to share upward.
- Note whether the regression is lab-only, field-only, or both (use PSI's field section when available).
- List deployments and tag-manager changes in the last 72 hours; ask one person to own the answer.
- Decide: hotfix now, scheduled fix, or monitor for 48 hours with a stored re-run.
If step 5 is always "monitor" but nobody saves the follow-up run, you are back to comparing two isolated scores.
Closing
PSI on Tuesday is accurate for that moment. On Thursday, the issue is often that nobody stored Tuesday's run, named the deployment, or agreed which URLs and thresholds count.
Keep manual PSI for one URL and one urgent decision. For a client portfolio, add repeat routes, stored results, and thresholds the team agreed before the week filled up. The comparison and CWV primer linked above go deeper on when manual checks stop being enough and how to read the metrics before you choose tools.
Top comments (0)