Core Web Vitals: metrics, thresholds and troubleshooting

Good thresholds are LCP no higher than 2.5 seconds, INP no higher than 200 milliseconds and CLS no higher than 0.1 at the 75th percentile, assessed separately for mobile and desktop. Assessment therefore concerns each metric in the appropriate data, not the best individual test.

The assessment uses the 75th percentile, separately for mobile and desktop. Source: web.dev on Web Vitals. These thresholds are not a promise of rankings or conversions.

What does LCP show?

LCP shows when the largest qualifying content element in the viewport has rendered. This may be a large image or a text block. It does not indicate when every resource on the page has finished loading. Identify the element actually being measured before changing images or fonts. See web.dev on LCP.

What does INP show?

INP describes how quickly a page gives visual feedback to clicks, taps and keyboard interactions. It covers responsiveness up to the next frame, not the entire time needed to complete a network-dependent form submission, for example. A menu can therefore respond slowly even if the initial page content loaded quickly. See web.dev on INP.

What does CLS show?

CLS describes unexpected movement of visible content. It is a score without a time unit. An example is text moving when an image loads without reserved space. Intentional changes following a user action do not automatically all count as unexpected shifts. See web.dev on CLS.

Field data comes from real user experiences, while lab data comes from a controlled test. Lab tests help with troubleshooting, but a single run does not establish how every visitor experiences the page.

Why is field data sometimes missing?

Field data may be missing when a page is new or has too few observations from real users. PageSpeed Insights may then show data for the website’s entire origin instead. If that data is also insufficient, no such assessment is shown. Its absence does not indicate whether the page is fast or slow.

How do you check a page in PageSpeed Insights?

Test the page’s full URL in PageSpeed Insights and read the mobile and desktop results separately. Then check the scope and period covered by the data:

1. Enter the URL in PageSpeed Insights and start the analysis.
2. Check whether the field data covers the individual page or the website’s origin: the combination of protocol, hostname and port. An origin result is not a separate measurement for every page.
3. Note the measurement period. Field data in PageSpeed Insights covers the latest 28 days, so it does not immediately show the effect of a change.
4. Use the lab results for troubleshooting. Lighthouse does not measure INP in its standard page load test; Total Blocking Time (TBT) may provide clues but is a different metric.
5. Save the URL, date, device type and relevant values. Repeat the test after the change and monitor field data over time when it is available.

Google’s explanation of PageSpeed Insights describes the data scopes and measurement period. See also web.dev on what lab tools can measure.

Is a green Lighthouse score the same as passing Core Web Vitals?

No. Lighthouse provides a lab result, while the Core Web Vitals assessment in PageSpeed Insights uses field data. Check both the data source and the metric being assessed. A high overall lab score can coexist with poor responsiveness during real visits. The PageSpeed Insights documentation explains these separate parts.

Illustrative example: you fix a large image and obtain better LCP in a new lab test. This does not directly establish anything about a slow form further down the page, nor replace earlier visits still included in the field period. Record it as a test of the new version, not proof that every visitor’s experience has already improved.

Start with the metric that is performing poorly and investigate its causes on the relevant page type. A low overall test score does not, on its own, tell you which action is needed.

• For content that appears late: investigate the content resource, server response and blocking resources.
• For slow interactions: investigate work that prevents the browser from responding.
• For layout shifts: investigate elements that appear or change size without reserved space.

Test relevant page templates. A form or shared component can affect several pages at once.

Illustrative example: if the page’s large main image is the element appearing late, check when the image request starts, the resource size and whether other content blocks its display. Simply compressing every image may miss a priority or server response problem. After the fix, the same page type needs to be tested again, and the image must still work within the approved layout.

How do you investigate a slow LCP resource?

Separate the wait into the first server response, delayed resource start, loading and delayed rendering. If the image starts downloading late, a smaller file addresses only part of the problem. If the resource is ready but code prevents its display, investigate rendering. web.dev divides LCP into these four parts.

Save a page-load recording and identify the LCP element and the part consuming the time. Then test a targeted change and check the same element again. Record, for example, that the resource starts loading earlier; do not simply say that “images were optimised”.

How do you investigate a slow interaction?

Reproduce the slow action and investigate whether the delay occurs before, during or after its event handling. Other JavaScript may block the main thread before the action is processed. The processing itself and the browser’s work on the next frame can also take time. web.dev describes these three parts of interaction latency.

Illustrative example: a filter button needs to provide feedback when tapped. If substantial work starts at the same time, a developer can test reducing or splitting that work. After the change, check both responsiveness and whether the filtering returns the correct results. Hiding the button or removing its function is not equivalent to fixing the delay.

How do you find the cause of layout shifts?

Identify what moves and which content changes the space around it. Images, embedded content and late-arriving elements may need reserved space. Text can also move when fonts change. Follow web.dev’s CLS troubleshooting guidance and check the page after initial loading too.

Illustrative example: an embedded form initially occupies no space, then pushes text down when it appears. Test the space within the existing layout, both when the form loads normally and when it fails to load. Empty space that permanently hides the next step is not a finished solution.

Check both the metrics and whether menus, forms and accessibility still work after a performance change. Document what you change, measure again and check the page as a visitor.

Once you have identified a recurring problem in the appropriate measurement data, it needs to be linked to a technical cause. Read about Core Web Vitals work and how changes are followed up.

Document both the improvement and what has not been measured. A good lab result after a change can be useful immediately, while the field data still includes visits from before the change. Avoid presenting an immediate lab test as a confirmed improvement for all users.

How do Core Web Vitals relate to SEO?

Google uses Core Web Vitals in its ranking systems, but good values do not guarantee high positions. The content still needs to answer the search. Google recommends a good overall experience rather than pursuing a single perfect test value. See Google on Core Web Vitals and search results.

Finish with a concise change log: affected page type, reproduced problem, change, new test and remaining uncertainty. If metrics are good but visitors cannot read conditions or complete an enquiry, also test the mobile functionality. Performance metrics do not replace that check.