You opened Search Console and a Core Web Vitals group moved from green to red. Or your own monitoring says LCP jumped after yesterday’s deploy. Either way, the temptation is to open Lighthouse, run it once, and start changing whatever audit has the largest red number.
That usually wastes the first 20 minutes.
The useful first half hour is triage: prove which signal changed, narrow the affected pages, connect it to a release, and leave with one testable hypothesis.
If Lighthouse and field data appear to disagree, read Lighthouse vs. Core Web Vitals first. The tools may be answering different questions.
Minute 0–5: name the dataset
Write down exactly where the regression came from:
- Search Console page group
- PageSpeed Insights URL-level or origin-level field data
- CrUX API or History API
- Your own real-user monitoring
- A synthetic or Lighthouse regression check
Do not call all of that “the score.”
CrUX data is aggregated over a rolling 28-day period. A change from yesterday can begin influencing it, but the older 27 days dilute the movement. Your own RUM can show the same release immediately. The CrUX API documentation explains that collection window and the difference between page and origin data.
Check mobile and desktop separately. Confirm whether the data describes one URL, an origin, or a Search Console group of similar pages. A product-template problem and a site-wide header problem require different searches.
At the end of five minutes, you should be able to finish this sentence:
Mobile LCP field data for product pages began worsening around July 14; desktop and article pages did not.
That is a bug report. “Performance got worse” is not.
Minute 5–10: line up releases and page changes
Now compare the signal with deployments that overlap the first visible movement. For a fast RUM regression, start with the release immediately before it. For CrUX, inspect changes across the rolling window instead of jumping to a deploy exactly 28 days ago.
Look for changes in four buckets:
- Shared layout: navigation, consent banner, hero, announcement bar, fonts, or global CSS.
- Content: a new image, embed, ad slot, personalization block, or larger result set.
- JavaScript: analytics, experimentation, chat, hydration, event handlers, or a dependency update.
- Infrastructure: cache policy, image transformation, CDN routing, server region, or rendering mode.
If only one template regressed, start with its content and route code. If unrelated page types moved together, start with shared layout, third parties, and infrastructure.
I also compare the production response with a known-good release. A source diff will not show a changed tag-manager container or CDN rule.
Minute 10–20: reproduce the metric, not the score
Run the production page in a repeatable lab setup. Keep the viewport, network, CPU throttling, cache state, and test location fixed. Three runs are enough for triage; take the median instead of picking the best screenshot.
Then debug the metric that changed.
If LCP regressed
Find the actual LCP element in the Performance panel. Do not assume it is the hero image.
Break the delay into:
- Server response time
- Resource discovery delay
- Resource download time
- Render delay after the resource is available
An image that starts late may need correct HTML discovery or priority. An image that downloads quickly but paints late points toward CSS, fonts, client rendering, or main-thread work. A slow document response will not be fixed by converting one JPEG to WebP.
If INP regressed
Reproduce a real interaction: open the navigation, type in search, change a filter, add to cart, or submit the slow form.
Record the interaction and inspect the long task around it. Common causes include a handler doing too much synchronous work, a large render triggered by one state change, repeated layout measurement, or a third-party listener running on the same event.
Total Blocking Time can point toward main-thread pressure in a lab run, but it is not INP. Field INP comes from actual interactions.
If CLS regressed
Watch the Layout Shifts track and click each shift cluster. The moving element is not always the element that caused the movement.
Check for:
- Images, ads, and embeds without reserved space
- Fonts changing line breaks after load
- Banners inserted above existing content
- Hydrated components replacing server markup at a different size
- Late content that moves a focused or recently clicked control
A zero score on the initial load does not clear a page that shifts after interaction or route navigation.
Google’s Web Vitals tools guide maps field and lab tools to the questions each can answer.
Minute 20–27: try to falsify your theory
Before editing production code, try to make the regression disappear.
- Block the suspected third-party request.
- Replace the new image with the previous asset.
- Disable the new component behind its existing flag.
- Test a route that shares the layout but not the content.
- Compare logged-in and logged-out states.
- Repeat with a warm cache if the complaint affects returning users.
One controlled removal is more useful than five speculative optimizations. If blocking the chat widget changes nothing, stop blaming the chat widget.
Keep notes. “LCP improved from 3.1s to 2.3s in the same lab setup when the new hero video was removed” is evidence another developer can reproduce.
Minute 27–30: choose one fix and one follow-up
Make the smallest change connected to the evidence. Record the before and after metric under the same lab conditions. Then decide how the field result will be watched after release.
For your own RUM, annotate the deployment and monitor the affected route and device class. For CrUX, expect movement to appear gradually through the 28-day window. Do not wait a week to discover that the lab result improved for the wrong reason.
The end of the half hour should produce:
- The affected metric, scope, and device class
- The likely release or runtime change
- A reproducible lab case
- One measured experiment
- An owner and date for field verification
That is enough to turn an alarming dashboard change into ordinary engineering work.
What I automate afterward
The best time to investigate a regression is while the responsible change is still a small diff. I keep a stable synthetic check for representative pages, store the metric and LCP element with each release, and alert on meaningful movement rather than a perfect-score threshold.
SiteCMD’s live-site checks keep repeatable page, asset, header, metadata, and lab-performance signals beside deployment history. They do not replace field data. They shorten the distance between “users got a slower page” and “this release changed the thing that paints.”