Core Web Vitals help describe loading, responsiveness and visual stability for real page visits. Before changing code, identify which metric is affected, which page or template is involved, and whether the evidence comes from real users or a controlled lab run. Then connect the symptom to a page element, make one safe change and repeat the same check.
Google's current Web Vitals guidance defines good experiences at the 75th percentile as Largest Contentful Paint (LCP) at or below 2.5 seconds, Interaction to Next Paint (INP) at or below 200 milliseconds, and Cumulative Layout Shift (CLS) at or below 0.1. These are assessment thresholds, not a promise that meeting them will increase sales.
Start with the kind of evidence you have
Field data comes from actual visits over a period of time and reflects a mix of devices, networks and user interactions. PageSpeed Insights and Search Console may show field data when enough eligible visits are available. It can be segmented, delayed or unavailable for a particular URL.
Lab data is collected under a controlled test setup. It helps reproduce loading and layout behavior and inspect a trace, but it cannot represent every visitor. A lab result for one page load is not a substitute for the field experience. If field data is absent, say so. Use a lab test to investigate, then gather field evidence as traffic and measurement allow.
Begin with the affected URL and template, date, viewport, browser, test mode and relevant field segment. Record the metric and value, plus whether the source is field or lab. Retest the same page type after the fix. A homepage score alone does not diagnose a slow product page or form.
Diagnose LCP: what is the largest content arriving late?
LCP measures when the largest visible content element in the viewport is rendered. On many pages this is a hero image, but it can also be a text block or another image. Find the reported element before optimizing unrelated assets.
Check the chain in order: server response, discovery of the LCP resource, resource priority and transfer, then the time needed to render it. If the element is a hero image, verify it is appropriately sized, compressed and discoverable from the initial HTML. A critical above-the-fold image should not be lazily loaded. Avoid preloading multiple speculative assets because they compete for bandwidth.
If the delay is before the resource can be requested, inspect server response and render-blocking work. If transfer dominates, compare actual image dimensions and format with the rendered slot. If the file arrives quickly but appears late, inspect client-side rendering and CSS. Do not add a CDN or rewrite hosting configuration unless the evidence points to a delivery problem.
Diagnose INP: which interaction leaves the page unresponsive?
INP evaluates the latency of interactions during a visit and reports a representative interaction. The interaction can include input delay, event-handler processing and the time until the next frame is presented. A page can load quickly but still feel slow when a menu, filter, form or dialog is used.
Try the same interaction on the affected template and inspect a browser performance trace. Look for long main-thread tasks, expensive event handlers, repeated layout work or too much JavaScript during the action. Break up work when the trace shows a long task, avoid recalculating layout repeatedly, and defer scripts that are not needed for that interaction. A web worker is useful only when the work can move off the main thread and the trace supports that choice.
After changing code, retest the exact action and verify that the control still works with keyboard input, focus changes and form errors. Do not infer INP from a page-load score or a single click in a lab run.
Diagnose CLS: which element moved unexpectedly?
CLS describes unexpected visual movement across a page visit. Common causes include images or embeds without reserved dimensions, late banners inserted above existing content, asynchronous content that changes its height, and font swaps that alter line wrapping.
Use layout-shift diagnostics to find the elements that moved and the likely source. Give media intrinsic dimensions or a stable aspect ratio. Reserve space for consent notices, embeds and other content that arrives later. Load suitable font files and fallbacks, then compare text wrapping. Avoid inserting new content above what a reader is already using. A transform animation does not fix a layout problem if the element still changes document flow.
Symptom, evidence, fix and retest
| Symptom | Evidence to collect | Candidate fix when evidence supports it | Retest |
|---|---|---|---|
| Main heading or hero appears late | LCP element, request timing, image discovery and server response | Resize or compress the actual LCP image, improve its discoverability, or address the measured server/render delay | Load the same URL and viewport; verify the same element and timing chain |
| Menu or submit action responds late | Interaction trace, long tasks and handler duration | Reduce or split work tied to the interaction; remove only scripts shown to be unnecessary | Repeat the same interaction and confirm all states still work |
| Text or controls jump as page loads | Shifted element, layout-shift entries, media dimensions and font timing | Reserve media or banner space, stabilize font metrics, avoid late insertion above content | Reload under the same setup and inspect the original shifting region |
Treat this as a diagnostic table, not a priority ranking. Severity depends on the task and the number of affected page types you have actually checked.
Safe order for making changes
- Capture a baseline with URL, template, viewport, browser, test type and available field segment.
- Identify the affected metric and page element from a trace or diagnostic report.
- Form one cause hypothesis. For example: “The hero image is the LCP element and is requested only after client rendering.”
- Make the smallest reversible change that addresses that cause.
- Check that the page still renders, the main interaction works, media is visible, analytics and consent behave as intended, and no new layout issue appeared.
- Repeat the original measurement and compare like with like.
- Record what remains unknown, especially when field data is missing or the lab setup differs from real users.
Changes that are often low risk when supported by evidence include using the correct responsive image size, adding width and height to media, reserving space for late content, loading a font subset actually used, and deferring a noncritical script. Each can also cause regressions if applied without checking its role. For example, deferring a script that controls form submission can break the task even if a synthetic score looks better.
Keep a reusable diagnostic record
For each issue, note the template and representative URLs, metric and data source, device segment, observed element or interaction, suspected cause, one proposed change, owner and acceptance test. The retest should repeat the original symptom and include a check that the page's intended task still succeeds. See the full evidence-based website audit checklist for an owner and retest worksheet.
If no field data is available, keep that limitation visible instead of describing lab data as a real-user result. Continue with controlled diagnostics and review field data when it becomes available. Improving a metric is a performance finding, not evidence of a particular revenue or conversion outcome.