What the three measurements tell you
Think of a visitor opening a product page, choosing an option and pressing the purchase button. LCP concerns the arrival of the main visible content. INP concerns the response to an interaction. CLS concerns unexpected movement that could push the button away just as the visitor reaches for it.
Google publishes a good, needs improvement and poor range for each metric. Lower values are better. LCP and INP measure time; CLS is a score without a time unit. Read each measurement separately so you can assign the right kind of investigation.
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP: Largest Contentful Paint | 2.5 seconds or less | Above 2.5, up to 4 seconds | Above 4 seconds |
| INP: Interaction to Next Paint | 200 milliseconds or less | Above 200, up to 500 milliseconds | Above 500 milliseconds |
| CLS: Cumulative Layout Shift | 0.1 or less | Above 0.1, up to 0.25 | Above 0.25 |
What passing actually means
The recommended assessment uses the 75th percentile for each metric, with mobile and desktop evaluated separately. Put plainly, at least 75% of the recorded experiences for that metric should be at or below its good threshold. An average can hide slow experiences, so ask for the percentile when someone reports a result.
Where all three metrics have sufficient data, passing requires all three to be good. PageSpeed Insights can assess LCP and CLS when INP has insufficient data; that exception does not prove interactions are fast. Missing LCP or CLS data prevents an assessment. Always read which measurements are actually present.
Google recommends good Core Web Vitals as part of page experience for Search. Treat them as technical quality targets. Your project still needs useful content and a working enquiry or purchase journey. A performance report cannot establish whether visitors understand your offer.
Read field data and lab results separately
PageSpeed Insights combines two kinds of evidence. Field data comes from eligible real Chrome experiences in the Chrome User Experience Report, or CrUX, over a rolling 28-day period. Lab results come from Lighthouse running a controlled test. Field data describes observed visits; lab diagnostics help investigate a particular load.
Check whether the field report covers the exact page or the origin, meaning the broader collection of pages under that origin. When page data is insufficient, PageSpeed Insights may show origin data instead. Record that distinction before comparing a product page with a homepage. Missing field data is neither a pass nor a failure.
Keep Lighthouse's performance score separate from the Core Web Vitals assessment. A standard Lighthouse navigation test does not interact with the page and therefore cannot measure INP. Total Blocking Time can help diagnose responsiveness problems, but it is a different measurement.
Use repeated lab runs under matching conditions to investigate changes. Then examine field trends as fresh visits enter the collection window. Device capabilities, connections and visitor behaviour can make field and lab results differ. Save the report details so a later comparison has context.
Illustrative report note: “Field data is available only for the origin, not this individual URL. The lab test shows a late hero image; we will trace its request and retest the changed template. There is not enough INP data to assess that interaction metric.” This labels evidence and missing data separately. It is a reporting example, not a measurement of this website or a claimed improvement.
LCP: get the main visible content onto the screen
Largest Contentful Paint measures when the largest eligible image, text block or video content visible in the viewport is rendered. On a product page, that might be the product photograph. On an article, it might be the heading or introductory text. Identify the measured element before assuming the main image is responsible.
LCP includes the wait for the document as well as the work needed to display that content. Ask a developer to separate server response time, delay before the resource starts loading, download time and delay before rendering. Compressing an image addresses only part of that sequence.
If the image arrives late because code inserts it after startup, making its file smaller may leave the main delay untouched. If the image has already downloaded but remains hidden, inspect the code and styles that prevent it appearing. The useful question is where the time goes.
Request a screenshot identifying the LCP element and a before-and-after timing breakdown. This keeps the proposed fix tied to evidence. Also inspect image quality and cropping on the actual page; a quick download is only useful when the content still serves its purpose.
- Make the LCP image discoverable in the initial page markup where possible, and avoid lazy-loading it.
- Serve an appropriately sized, compressed image; check whether an efficient image format suits the asset.
- Investigate slow document responses, redirects and render-blocking resources when the timing points there.
- Use resource priority or preloading selectively after identifying the resource that needs earlier delivery.
INP: make taps and typing feel responsive
Interaction to Next Paint measures the delay between a click, tap or keyboard interaction and the next visual update. It observes interactions throughout a visit and generally reflects the slowest one, with outlier handling for visits containing many interactions. It is not the average time for every button click.
INP measures how promptly the browser can display feedback. It does not measure the entire wait for a server to complete a search or purchase. A form can acknowledge submission promptly while the request continues. That acknowledgement must accurately show a pending state, rather than claiming the operation has succeeded.
Give the developer a reproducible journey: open the menu during loading, select a product option, apply a filter and type into search. Record which action stalls and whether it happens immediately or later. Test the controls that matter to your business, including those inside embedded tools.
Ask where the delay occurs: before the interaction handler starts, while its code runs, or while the browser prepares the next frame. Depending on the trace, fixes can include reducing unnecessary JavaScript, splitting lengthy work and simplifying expensive page updates. Recheck the same journey after each change.
- Include interactions during page startup in the test brief.
- Check whether typing, filtering and menu opening remain responsive on a less powerful phone.
- Retest loading, success and error states after changing interaction code.
CLS: keep the page from moving under the visitor
Cumulative Layout Shift measures unexpected movement of visible content. Its score reflects how much content moves and how far, using the largest burst of qualifying shifts during the page's lifetime. It is not a count of animations or a measurement in seconds.
Imagine reading a service description when an image loads above it and pushes the paragraph down. A late banner, an expanding embed or a font change can cause similar movement. The element highlighted as moving may be the victim; the cause can sit elsewhere on the page.
Ask the developer to reserve space for images and video using dimensions or an aspect ratio. Give embeds and other inserted content a planned space. Review font loading if text changes size and wraps differently. Check the result at mobile and desktop widths.
Continue testing after the opening screen has loaded. Scroll through articles, wait for embedded content and use the page normally. A short load test can miss shifts that happen later. A recording of the movement, with the affected page and device, gives the developer a concrete starting point.
Choose the next fix with evidence
Make a short inventory of important page types: a campaign landing page, service page, article, product listing and product detail page where relevant. Include the routes visitors use to enquire or buy. Ask the people responsible for marketing and operations which pages deserve attention first.
For each issue, write down the affected page type, the failing metric, the evidence, the suspected cause and the next test. Keep suspected causes labelled as hypotheses until a trace or controlled comparison supports them. A red result alone does not identify a plugin, hosting service or framework as the cause.
Prioritise an issue that blocks a critical journey or affects a shared template. Give each proposed change an owner and an acceptance condition. For example: the product image starts loading earlier, its lab LCP improves under comparable conditions, and image selection still works. Track field performance separately after release.
For an agency handoff, request the affected templates and reproduction steps before estimating implementation. Confirm who controls the theme, hosting, scripts and embedded services. That makes dependencies visible and helps avoid promising a fix in code the agency cannot change.
A checklist for the first investigation
Use this checklist as a brief for an internal developer or an external studio. Keep the reports and decisions together so the next person can understand what was measured and what remains unresolved.
- Select representative pages and describe the visitor task on each.
- Save mobile and desktop reports, including the field-data scope and collection period.
- Record LCP, INP and CLS separately; mark missing data explicitly.
- Identify the LCP element, a slow interaction or the content that shifts.
- Document the suspected cause and the evidence needed to confirm it.
- Agree on a bounded change, a rollback method and who will verify it.
- Repeat comparable lab checks and complete the important visitor journeys.
- Review field trends after release and investigate any remaining slow experiences.
How hehe.software can help
hehe.software is a small, independent web and app studio based in Vancouver, British Columbia, working remotely with businesses across Canada and the United States. We offer website fixes, speed optimization, technical SEO and maintenance, including work on sites we did not build and sub-projects for agencies. Email mwe@hehe.software with the affected pages, reports and the visitor journey that feels slow, or use the contact form. We scope the work and provide a fixed quote or an hourly estimate; paid discovery is available when the cause needs investigation.