Core Web Vitals are field metrics for three parts of user experience: how quickly the main content appears, how responsive the page feels when a person interacts, and how stable the layout remains while it loads. A useful optimization process does not chase a single green screenshot. It starts with real-user evidence, isolates the slow phase, changes one cause and verifies the result.
This guide explains Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS) without treating them as abstract scores. You will learn the current thresholds, the difference between field and lab data, and a practical order for fixes. For a complete investigation workflow, continue with the frontend performance audit checklist.
Core Web Vitals thresholds at a glance
A page is evaluated using a distribution of visits, not its fastest load. Current guidance classifies a metric using the 75th percentile of page views. That means at least three quarters of measured visits should meet the good threshold.
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| LCP | When the largest visible content element renders | 2.5 seconds or less | More than 4 seconds |
| INP | Overall interaction responsiveness | 200 milliseconds or less | More than 500 milliseconds |
| CLS | Unexpected visual movement | 0.1 or less | More than 0.25 |
These thresholds are diagnostic boundaries, not a promise of search position or business success. A technically good page can still be confusing, inaccessible or irrelevant. Treat the metrics as part of a broader page experience.
Field data and lab data answer different questions
Field data comes from real visits. It includes the variety that matters in production: different devices, networks, caches, geographic routes, account states and interactions. It is the right evidence for understanding how users actually experience a page, but it takes time and sufficient traffic to form a stable distribution.
Lab data comes from a controlled run. It is reproducible and useful for debugging a specific page under chosen conditions. A lab run can reveal a request chain or a long task even when field data only says that a route is slow. The correct workflow is field data to find the problem, lab tools to explain it, and field data again to verify the outcome.
Fix LCP by separating its phases
LCP is often called a loading metric, but the final number can contain several delays. The server may respond slowly. The browser may discover the hero image late because JavaScript inserts it. The image may be too large. The resource may finish quickly while CSS, fonts or main-thread work delays rendering. Label the phase before selecting the fix.
- Server delay: inspect redirects, application work, database calls, cache misses and origin distance.
- Discovery delay: place important content in the initial HTML and avoid hiding the LCP resource behind a client-only request.
- Transfer delay: send an appropriately sized modern image, compress it and use effective caching.
- Render delay: reduce blocking CSS, font delay and long JavaScript tasks before the element can paint.
An image confirmed as the LCP element normally needs intrinsic dimensions and should not be lazy-loaded. High fetch priority can help that specific resource, but marking every image high priority only creates competition.
<img
src="/images/dashboard-hero.webp"
width="1200"
height="675"
fetchpriority="high"
alt="Analytics dashboard showing frontend performance trends"
>Improve INP by shortening work after input
INP is not simply the time spent inside one click handler. It reflects the delay before the event can run, the work performed by the handler and the time until the browser can present the next frame. A fast API response does not rescue a page that performs a large synchronous sort, renders thousands of rows and recalculates layout after every keystroke.
Start by reproducing a slow interaction in the performance panel. Look for long main-thread tasks, repeated style and layout work, expensive event handlers and an unexpectedly large render subtree. Break large computations into smaller tasks where appropriate, avoid layout thrashing, reduce unnecessary UI work and give immediate visual feedback. If React rendering is the dominant cost, use the measured techniques in the React performance optimization guide.
Prevent CLS by reserving the final geometry
CLS increases when visible content moves unexpectedly without a recent user interaction. Images without dimensions, ads with no reserved slot, injected banners and late font swaps are common causes. The durable fix is to make the final layout predictable before delayed content arrives.
- Set intrinsic width and height on images and video so the browser knows the aspect ratio.
- Reserve a stable minimum size for ads, embeds and asynchronous widgets.
- Place consent banners and notices in reserved or overlay space instead of pushing an already visible page down.
- Choose font loading and fallback metrics deliberately, then test real text at multiple viewport widths.
The detailed responsive images guide shows how candidate selection and intrinsic dimensions work together.
Collect real-user measurements
The small example below uses the maintained web-vitals package. The endpoint and sampling policy are application decisions. Record page type, release and device context without collecting unnecessary personal information.
import { onCLS, onINP, onLCP } from 'web-vitals';
function reportMetric({ name, value, delta, id, rating }) {
const body = JSON.stringify({ name, value, delta, id, rating });
if (!navigator.sendBeacon('/api/rum', body)) {
fetch('/api/rum', {
method: 'POST',
headers: { 'content-type': 'application/json' },
body,
keepalive: true
});
}
}
onCLS(reportMetric);
onINP(reportMetric);
onLCP(reportMetric);A practical priority order
- Choose a high-value route with poor field evidence and enough traffic to measure.
- Identify the failing metric and representative device segment.
- Reproduce the problem with a controlled trace.
- Find the dominant phase instead of applying a generic checklist blindly.
- Ship one bounded change, guard it with functional tests and monitor the field distribution.
Common pitfalls
- Optimizing only the home page while signed-in product routes remain slow.
- Reporting an average that hides a poor 75th-percentile experience.
- Preloading many resources until the truly important request loses priority.
- Changing a metric without checking accessibility, correctness or conversion behavior.
- Assuming a one-time desktop lab score represents mobile users in production.
Frequently asked questions
Do good lab scores guarantee good Core Web Vitals?
No. Lab tests are controlled samples. Field measurements include real devices, networks, cache states and behavior, so a production distribution can differ substantially.
Should every image use high fetch priority?
No. Priority is scarce. Use it for a resource demonstrated to be important, such as a true LCP image, and verify the network waterfall after the change.
Can JavaScript improve LCP while making INP worse?
Yes. For example, eagerly executing a large client bundle might reveal content sooner in one test but occupy the main thread during interactions. Evaluate the complete user journey.
Authoritative references
Test your frontend skills
Apply the measurement, rendering, image and accessibility concepts from this guide in a focused assessment.
A practical assessment of Core Web Vitals, React rendering, JavaScript loading, responsive images, caching, semantic HTML, and accessible forms. Start the trivia-style player right inside the article.Modern Frontend Performance & Accessibility Mock Test
Discussion
0 comments
Ask a question or share what stood out to you.