Core Web Vitals: What they mean and how to verify an improvement
Your website feels fast in the office, but its mobile report says otherwise. First identify the experience that is failing: loading content, responding to input or keeping the page stable. Fix that cause, then repeat the same checks.
01Start with a page and a customer task
A customer opens a product, selects a variant and adds it to their basket. Each step can be delayed by something different. Replace a vague request to “make the website faster” with a page address, device type and description of the problem. Your developer needs a way to reproduce it.
Begin with one important template, such as a service page or checkout. Record the date, release, tool and starting measurements. Changing images, hosting and measurement together makes it harder to identify what helped. A useful brief connects one problem, a proposed explanation and a way to test it.
02Three metrics describe three different problems
Core Web Vitals documentation defines LCP, INP and CLS. Recommended thresholds are assessed at the 75th percentile, separately for mobile and desktop. In practical terms, that is the value covering three quarters of recorded visits, rather than an average.
| Metric | Good threshold | What to investigate |
|---|---|---|
| LCP | At most 2.5 s | When main content renders |
| INP | At most 200 ms | Response to clicks and typing |
| CLS | At most 0.1 | Unexpected changes in layout |
LCP concerns the largest visible image or text block. INP assesses responsiveness to interactions throughout a visit, beyond the initial load. CLS is a unitless score for unexpected changes in layout. A good result for one metric cannot compensate for a poor result in another. Keep each metric's unit and threshold distinct.
03Separate visitor data from a single lab test
In PageSpeed Insights, first check whether you are viewing the specific URL or its entire origin. An origin generally groups pages sharing a protocol, domain and port. An aggregate result may not describe the particular product page you are investigating. Missing public data does not mean a page has passed.
Google describes CrUX data in PageSpeed Insights as a rolling summary of the previous 28 days, updated daily. Today's deployment cannot immediately replace that entire period. Use a lab test to investigate causes and check a change quickly, then use visitor data to confirm the experience in production.
A standard automated Lighthouse run without interactions cannot measure INP. Its Total Blocking Time metric provides a useful diagnostic signal, but an improvement there does not establish the field INP result. Record interactive tasks in browser developer tools while actually clicking and typing.
04For LCP, find what the browser is waiting for
A slow main image is not necessarily an oversized file. The LCP optimisation guide separates server response, the delay before downloading the resource, its transfer and the wait before rendering. Target the part that causes the delay on your page.
Ask to see the actual LCP element in a trace. If an important image becomes discoverable only after a script runs, investigate making it available earlier. If the transfer has finished but the content is still hidden, further compression may not remove the rendering delay. Do not lazy-load the image responsible for LCP.
The following model demonstrates arithmetic for a single illustrative load. Reducing the delay before downloading from 900 to 100 ms, with every other duration unchanged, reduces the total from 2,700 to 1,900 ms. These are invented teaching values, not client measurements, a percentile or a forecast. Other parts may change after a real implementation.
- Server responseBefore change: 600After change: 600
- Delay before downloadBefore change: 900After change: 100
- Resource downloadBefore change: 400After change: 400
- Rendering delayBefore change: 800After change: 800
Illustrative LISTIFY values, not website measurements. Unit: ms. Total before: 2,700 ms; after: 1,900 ms. Only the delay before download changes.
05For INP, repeat the slow interaction
Record whether the problem occurs when opening a menu, filtering a catalogue, entering text or submitting a form. Then inspect what occupies the browser's main thread at that moment. A server response time alone does not describe how promptly the interface reacts.
INP guidance distinguishes the wait before processing input, event handling and the delay until the next paint. Verify your change against the same interaction. Possible work includes splitting long tasks, removing unnecessary scripts or reducing the area that needs updating. Check the resulting behaviour on a less powerful phone as well.
06For CLS, reserve space before content arrives
If a customer aims at a button and different content moves under their finger, find the element that shifted the layout. CLS documentation covers causes including images without dimensions and content inserted later. Reserve space for an image, advert or embed before it loads.
Also inspect web font loading, notices appearing and results added below a form. Unexpected movement may happen after the opening screen. Scroll and use the page as part of your test. Fixing the dimensions of one hero image does not establish that the entire visit is stable.
07Define what counts as a completed fix
Put the URL, scenario, affected device, starting trace and expected change into one work item. Include a functional check. Removing a script might make the page faster, but if the basket stops working, the task is not complete. Agree who reviews the evidence before the change is accepted.
- Save repeated measurements under consistent conditions before making the change.
- Repeat the same task afterwards and compare the relevant part of the trace.
- Record the release date so you can identify it in production data.
- Assess visitor results and other templates once there is a sufficient sample.
Public reports may be unavailable for a website with little traffic. Consider your own real user monitoring with a proportionate collection scope. Do not include form values or personal information in performance events. Describe a small sample as a limitation rather than turning a handful of measurements into certainty about every customer.
08Treat a green report as evidence for a decision
Google Search Central explains that good Core Web Vitals do not guarantee leading search positions. Alongside performance, check whether people complete their tasks, find the information they need and can operate the interface. Measure the technical improvement and the business outcome separately.
Keep the device, network limits and cache state consistent when repeating a test. A first visit without cached files and a returning visit are different conditions. Record the task alongside the result. Otherwise, you might mistake a faster connection or a previously downloaded resource for an improvement caused by your change.
If performance deteriorates again after a few weeks, investigate recent changes: a new embedded service, image or template update. Assign someone to review releases. A one-off improvement has limited value if the next content edit introduces another oversized image. Keep the scenario and starting evidence so the team can repeat the check.
Want a fix that can be accepted on evidence? Prepare the URL, failing scenario and initial report. When discussing custom website work, you can then make decisions around a specific cause and a verified result.