A page can look polished and still feel slow or unstable when someone uses it on a real phone, connection, or browser. Core Web Vitals provide a practical way to measure three parts of that experience: how quickly the main content appears, how quickly the page responds to input, and whether content shifts unexpectedly while the page is being used.
They are not a substitute for usability research or business metrics, but they help teams identify experience problems that deserve attention. The current Core Web Vitals set is LCP, INP, and CLS.
Article key takeaways
The ideas worth carrying forward.
- LCP measures loading, INP measures responsiveness, and CLS measures unexpected visual movement.
- Good field thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1.
- Assess the 75th percentile of real user visits, not only one lab run.
- Optimize the bottleneck behind the metric instead of applying generic speed tricks.
- Re-test mobile devices, templates, and real interactions after each meaningful change.
Core Web Vitals at a glance
Swipe to compare
4 columns| Metric | What it measures | Good threshold | Poor threshold |
|---|---|---|---|
| LCP | Time until the largest visible content element is rendered | ≤ 2.5 seconds | > 4.0 seconds |
| INP | Responsiveness across user interactions | ≤ 200 ms | > 500 ms |
| CLS | Unexpected visual layout movement | ≤ 0.1 | > 0.25 |
These thresholds are documented by web.dev's Core Web Vitals guidance. A page should be assessed with real user data where available, because hardware, network conditions, interaction patterns, and page types can affect outcomes.
LCP: make the main content appear sooner
Largest Contentful Paint estimates when the main visible content has appeared. Depending on the page, that element may be a hero image, a large heading block, or a primary content image. Reducing unrelated asset size will not necessarily help if the actual LCP element is delayed by discovery, server response, or render-blocking resources.
Common causes of slow LCP
- A slow server response or expensive initial rendering.
- A hero image discovered late or loaded with low priority.
- Oversized images that take too long to download and decode.
- CSS or JavaScript that blocks rendering before the main content is ready.
- Third-party scripts competing for bandwidth and main-thread time.
A useful LCP investigation
Identify the LCP element in browser performance tools and separate server response, resource load delay, resource load duration, and render delay. Give priority to the actual LCP asset, reserve appropriate space for it, and ensure the browser can discover it early. Test the result on realistic mobile conditions.
INP: keep interactions responsive
Interaction to Next Paint reflects how quickly the page responds visually after user interactions, such as opening a menu, applying a filter, submitting a form, or switching a tab. It looks across interactions rather than measuring one isolated click.
Common causes of poor INP
- Long JavaScript tasks that block the main thread.
- Heavy event handlers or repeated synchronous calculations.
- Rendering too much content after one action.
- Large third-party scripts competing with the interface.
- A slow interaction design that waits for the whole request before giving feedback.
Make the next visible state clear
Break up long tasks, reduce unnecessary re-renders, defer non-critical work, and keep event handlers small. For network-bound actions, show a clear pending state and then update the relevant region when the response arrives. Feedback does not replace performance work, but it helps users understand that their action was received.
CLS: prevent unexpected movement
Cumulative Layout Shift measures unexpected movement of visible content. A button that shifts just as someone tries to tap it is more than a cosmetic issue; it can cause mistakes and make the page feel unreliable.
Common causes of layout shift
- Images or video elements without reserved dimensions or aspect ratios.
- Ads, embeds, and banners inserted above existing content.
- Fonts that change text metrics after the first render.
- Components that expand without reserved space when data arrives.
- Animations that change layout properties instead of transform or opacity.
Stabilize the layout before content arrives
Reserve image dimensions, use aspect-ratio containers, avoid inserting content above the user's current position, and handle font loading intentionally. Test the real page while content, fonts, and embeds load rather than evaluating only the final static state.
Use field data and lab tools together
Field data shows how visitors experience the page across real devices and networks. Lab testing helps reproduce and diagnose a specific cause under controlled conditions. Use field trends to decide what matters, then use lab traces and browser tools to investigate why the metric is poor.
A practical optimization workflow
Performance checklist
- Identify the affected page templates, devices, and user journeys.
- Check field data and separate it by page type where data is available.
- Find the actual LCP element and inspect its request and render delays.
- Record long tasks and heavy event handlers that affect key interactions.
- Reserve dimensions for media and late-loading components to reduce CLS.
- Re-test with realistic mobile CPU and network conditions.
- Monitor after release to confirm that field experience improves.
Prioritize fixes by user impact
Start with issues affecting important entry pages or common conversion journeys. A dramatic lab score improvement is not automatically the highest business priority if users rarely visit that template. Pair performance metrics with measures such as form completion, product exploration, and support reports so improvements serve the actual audience.
Conclusion: optimize the experience, not just the score
Core Web Vitals work best as a repeatable engineering practice. Measure the real experience, identify the bottleneck, fix the cause, and validate the result. Treat LCP, INP, and CLS as complementary signals: a page should appear quickly, respond when people interact, and stay stable while they use it.