The thresholds in use
The current Core Web Vitals are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). Google's good thresholds are 2.5 seconds or less for LCP, 200 milliseconds or less for INP, and 0.1 or less for CLS. Assessment uses the 75th percentile of visits, with mobile and desktop evaluated separately.
These metrics describe different problems. LCP concerns loading the largest eligible visible content element. INP concerns responsiveness to interactions. CLS concerns unexpected movement of visible content. A page can pass one and fail another; a single overall score hides that distinction.
Find the affected page before changing code
Use field data to identify where the problem occurs. CrUX supplies aggregated measurements from eligible Chrome visits where enough data exists. Your own real-user monitoring can provide more specific page and interaction context. Check the sample size and whether you are looking at one URL or an entire origin.
Then reproduce the behavior in a controlled test. A Lighthouse load test can help investigate loading, but it does not establish INP for a visit with real interactions. For a slow filter, record the action in browser performance tools. For a late layout shift, keep recording while scrolling and using the page.
LCP: inspect discovery as well as download time
Identify the element recorded as LCP. For an image, divide the wait into server response time, delay before the resource starts loading, download duration, and the delay before it renders. A smaller file helps the download portion; it cannot fix every other delay.
For example, an image URL created only after a script fetches page data may start downloading late. Making that URL discoverable in the initial HTML can address that delay. Avoid lazy-loading the image expected to be LCP. Inspect priority and competing requests before assigning high priority to more assets.
INP: record the slow interaction
Click the filter that feels slow and examine the trace. The wait may begin before its event handler runs because another task occupies the main thread. It may also continue after the handler finishes while the browser calculates layout and paints.
If filtering rebuilds thousands of rows synchronously, reduce the amount of work and consider breaking it into tasks that allow the browser to respond. If the trace shows repeated forced layout, inspect code that alternates reading geometry and changing styles. Test on a slower device; a powerful laptop can conceal the delay.
CLS: find what moved and what caused it
An image without reserved space can push the next paragraph down when it loads. Give media appropriate dimensions or an aspect ratio so the browser can allocate space. Also check late banners, embeds, and font changes that alter line breaks.
The element highlighted as moving may be the victim of a change above it. Trace the cause before editing its layout. Continue the recording beyond initial load: a page that looks stable at arrival can shift when later content is inserted. Some shifts shortly after qualifying input are excluded, but scrolling does not make subsequent shifts harmless to the metric.
Verify the specific repair
Keep a before-and-after trace using the same test conditions. If you moved image discovery earlier, confirm that the request starts earlier. If you reduced DOM work, repeat the same interaction and inspect the main-thread cost.
After release, watch the affected field measurements over a comparable period. An immediate lab improvement and a slower-moving field aggregate can both be correct. Record what you changed and what evidence would show it helped; passing thresholds alone says nothing about whether the form works or the page is accessible.
Sources & further reading
Technical references checked on 17 September 2026.