A step-by-step method to improve LCP, INP and CLS: measure field data, diagnose by template, apply the fixes that matter and verify the results.
In this article
- 01The three metrics and their thresholds
- 02Step 1: Measure field data first
- 03Step 2: Prioritize by template
- 04Step 3: Diagnose LCP by its parts
- 05LCP and rendering strategy
- 06Step 4: Find slow interactions for INP
- 07Third-party scripts
- 08Step 5: Eliminate layout shifts for CLS
- 09Mobile first, with realistic conditions
- 10Framework and caching tips
- 11Step 6: Verify and prevent regressions
The three metrics and their thresholds
Core Web Vitals are Google's user-centered measures of page experience. Largest Contentful Paint (LCP) measures loading: when the largest image or text block in the viewport renders. A good LCP is 2.5 seconds or less. Interaction to Next Paint (INP) measures responsiveness: the delay between user interactions and the next visual update, across the visit. A good INP is 200 milliseconds or less. INP replaced First Input Delay as a Core Web Vital in 2024. Cumulative Layout Shift (CLS) measures visual stability, and a good score is 0.1 or less.
A page passes when at least 75% of real visits meet the good threshold for each metric. That 75th percentile matters: your fast office connection is not the benchmark, your slower users are.
Step 1: Measure field data first
Field data comes from real users; lab data comes from a simulated test. Google uses field data from the Chrome UX Report (CrUX), visible in PageSpeed Insights and the Core Web Vitals report in Search Console. Lab tools such as Lighthouse and the Chrome DevTools Performance panel are for diagnosing, not for judging success.
Add real user monitoring with the web-vitals JavaScript library, sending each metric with the page template, device type and, for INP, the element interacted with. CrUX shows you that a problem exists; your own data shows you where.
Step 2: Prioritize by template
Sites are built from templates: home, category, product, article, checkout. Fixing a template fixes every page that uses it. Group your field data by template, find the ones with the most traffic and the worst metric, and start there. Search Console groups similar URLs for the same reason.
Step 3: Diagnose LCP by its parts
LCP can be broken into four parts: time to first byte, resource load delay (how long before the browser starts loading the LCP resource), resource load duration and element render delay. Chrome DevTools shows this breakdown. Each part has different fixes:
- Slow first byte: cache HTML at a CDN, speed up server rendering and avoid redirects
- Late discovery: make the LCP image discoverable in the HTML rather than injected by JavaScript, and add fetchpriority="high" to it
- Never lazy-load the LCP image; lazy-load only images below the fold
- Slow download: serve correctly sized images in modern formats such as AVIF or WebP, with responsive srcset
- Render delay: reduce render-blocking CSS and JavaScript, and avoid hiding content until scripts run
LCP and rendering strategy
Pages that render their main content only after downloading and running JavaScript usually struggle with LCP on mid-range phones. Server-side rendering or static generation puts the main content in the initial HTML, which is often the single biggest LCP improvement for single-page apps. Web fonts matter too: use font-display: swap or optional and preload the most important font file, so text is not invisible while fonts load.
Step 4: Find slow interactions for INP
INP is usually caused by JavaScript keeping the main thread busy. Each interaction has three phases: input delay (waiting for other work to finish), processing time (your event handlers) and presentation delay (rendering the update). Your field data tells you which interactions are slow; the DevTools Performance panel shows long tasks, meaning main-thread work longer than 50 milliseconds, around them.
- Break long tasks into smaller pieces and yield to the main thread between them, for example with scheduler.yield where supported or a setTimeout fallback
- Do only the visible update in the event handler and defer the rest, such as analytics calls
- Reduce JavaScript: remove unused code, split bundles by route and audit third-party scripts
- In React, avoid re-rendering large trees on each keystroke and use transitions for non-urgent updates
- Avoid layout thrashing: do not read layout values and write styles alternately in loops
Third-party scripts
Tag managers, chat widgets, A/B testing tools and ad scripts are frequent causes of poor INP and LCP. List every third-party script, its owner and its purpose. Remove the ones nobody uses, load the rest after the main content with async or defer, and move non-essential widgets behind a user action, such as loading a chat widget only when the user clicks the chat button.
Step 5: Eliminate layout shifts for CLS
Layout shifts happen when content moves after it first appears. The fixes are mostly about reserving space:
- Always set width and height attributes, or CSS aspect-ratio, on images, videos and iframes
- Reserve space for ads, embeds and banners with a fixed-size container
- Never insert content above existing content unless it responds to a user action
- Use font fallback metrics, such as size-adjust, so swapped fonts do not reflow text
- Animate with transform and opacity instead of properties that change layout
Mobile first, with realistic conditions
CrUX reports mobile and desktop separately, and mobile is usually where pages fail. Diagnose on a mid-range Android phone or with CPU and network throttling in DevTools, not on a fast laptop. A script that runs in 50 milliseconds on a developer machine can take several times longer on a budget phone, which is exactly where INP problems appear.
Framework and caching tips
Modern frameworks help when used deliberately. Framework image components generate responsive sizes and can mark the LCP image as high priority. Server components and partial hydration reduce the JavaScript a page ships, which helps both LCP and INP. Avoid hydrating large parts of the page that never change after load.
Do not forget the back and forward buttons. The browser's back/forward cache restores pages instantly, which makes those navigations effectively free. Unload event handlers can prevent pages from using it, and so can some cache headers, so check eligibility in the Application panel of Chrome DevTools.
Step 6: Verify and prevent regressions
CrUX reports a rolling 28-day window, so field improvements appear gradually. Watch your own real user monitoring for faster confirmation. To stop regressions, add Lighthouse checks to CI with performance budgets for bundle size and key metrics, and review third-party additions like code changes.
Better vitals help search visibility as part of page experience, but the stronger case is business: faster, steadier pages convert better. Our technical SEO explainer covers the search side, and Nexzem's performance testing work includes field data analysis and fixes.



