Website Speed Optimization 2026: Fix LCP, INP and CLS Step by Step

Website Speed Optimization 2026: Fix LCP, INP and CLS Step by Step

What are Core Web Vitals? Core Web Vitals are three Google metrics — LCP (Largest Contentful Paint), INP (Interaction to Next Paint) and CLS (Cumulative Layout Shift) — that measure the user experience quality of a web page. Google uses them as direct ranking signals. Passing all three at "Good" thresholds (LCP < 2.5s, INP < 200ms, CLS < 0.1) is a prerequisite for competing in modern organic search. Free Consultation →

Core Web Vitals became a confirmed Google ranking factor with the Page Experience update and have grown in weight since. In 2026, failing CWV metrics actively suppresses your rankings relative to competitors who pass them. This guide gives you the diagnostic process, technical fixes and tooling to achieve "Good" status across all three metrics.

Table of Contents

• Why Core Web Vitals Matter for Rankings in 2026
• Diagnosing Your Current CWV Status
• LCP Optimization: Load the Main Content Faster
• INP Optimization: Make Every Interaction Responsive
• CLS Optimization: Eliminate Visual Instability
• CWV Metric Targets and Thresholds
• Tools for CWV Measurement
• Common Issues and Fixes Table
• Step-by-Step Optimization Process
• Frequently Asked Questions
• Conclusion

Why Core Web Vitals Matter for Rankings in 2026 {#why-cwv-matter}

Google's ranking systems use two types of CWV data: lab data (from Lighthouse, measured in controlled conditions) and field data (from the Chrome User Experience Report, CrUX, measured from real users). Field data carries more weight in rankings because it reflects actual user experience.

A site with a 90+ Lighthouse score but poor field data CWV will still face ranking suppression. Real-world performance on real user devices and connections is what Google measures. This matters because:

• Lab data is measured on a simulated mid-range device on a throttled 4G connection
• Field data reflects your actual visitor base — if your users are on older devices or slower connections, field data will be worse than lab data
• Improving lab data is necessary but not sufficient; real-world optimizations like CDN placement, bundle size and third-party script management drive field data improvements

Our SEO consulting services address both lab and field CWV metrics as part of technical SEO audits.

Diagnosing Your Current CWV Status {#diagnosis}

Before fixing anything, establish your baseline across all three metrics using both lab and field data.

Step 1: Check Google Search Console

Navigate to Search Console > Experience > Core Web Vitals. This shows your field data CWV status across all indexed pages, segmented by device (mobile and desktop). Pages are classified as Good, Needs Improvement or Poor.

Focus on mobile first — Google's mobile-first indexing means mobile CWV scores receive more weight in ranking decisions.

Step 2: Run PageSpeed Insights

Enter your URL at pagespeed.web.dev. The report shows both field data (from CrUX, if available) and lab data. For pages without sufficient CrUX data (low-traffic pages), only lab data is shown. The "Opportunities" and "Diagnostics" sections identify specific elements causing each CWV failure.

Step 3: Run Lighthouse

Open Chrome DevTools (F12), go to the Lighthouse tab and run a Performance audit. Lighthouse provides lab data with specific resource attribution — it tells you exactly which image is causing your LCP, which JavaScript tasks are blocking INP and which layout shifts are occurring.

Step 4: Use WebPageTest for Advanced Diagnostics

WebPageTest.org provides waterfall charts, filmstrips and advanced metrics that Lighthouse does not capture. Particularly useful for: identifying render-blocking third-party scripts, measuring Time to First Byte (TTFB) from different global locations and diagnosing LCP elements in complex pages.

LCP Optimization: Load the Main Content Faster {#lcp}

LCP measures when the largest visible content element (usually an image or text block) finishes loading. Target: under 2.5 seconds.

Identify Your LCP Element

Lighthouse labels the LCP element in its audit. Common LCP elements:

• Hero images (most common)
• Above-the-fold H1 text blocks
• Video poster images
• Large background images

Image-Based LCP Fixes

Preload the LCP image. Add a <link rel="preload"> tag in your <head> for the LCP image. This tells the browser to start fetching it as early as possible:

``html <link rel="preload" as="image" href="/hero.webp" fetchpriority="high" /> ``

In Next.js, set the priority prop on your hero <Image> component — it handles preloading automatically.

Convert to WebP. WebP images are typically 25-35% smaller than JPEG at equivalent visual quality. Smaller file size means faster download time, directly improving LCP.

Serve from a CDN. Content delivery networks serve images from servers geographically close to the user. A visitor in Istanbul fetching an image from a Frankfurt CDN node gets it significantly faster than fetching from a New York origin server. CDN is often the single highest-impact LCP improvement available.

Compress images. Use tools like Squoosh, ImageOptim or Sharp to compress without visible quality loss. Aim for hero images under 200KB and content images under 100KB.

Reduce server response time (TTFB). LCP cannot improve beyond your server's response time. Slow TTFB (> 600ms) indicates server-side bottlenecks: slow database queries, no caching, cold function starts in serverless. Implement page caching, optimize database queries and use CDN-level caching for static pages.

Text-Based LCP Fixes

If your LCP element is a text block:

• Ensure the font is preloaded or use a system font for the LCP element
• Avoid CSS that delays text rendering (complex selectors, imported fonts not preloaded)
• Use font-display: swap or optional to avoid invisible text during font loading

INP Optimization: Make Every Interaction Responsive {#inp}

INP replaced First Input Delay (FID) as a Core Web Vitals metric in March 2024. It measures the delay between a user interaction (click, tap, keyboard input) and the next visual response. Target: under 200ms.

What Causes High INP

INP failures occur when the main thread is too busy to respond to interactions promptly. Common causes:

• Large JavaScript bundles that take long to parse and execute
• Long tasks (JavaScript execution > 50ms) blocking the main thread
• Heavy third-party scripts (analytics, chatbots, ad networks)
• Expensive re-renders in React/Vue/Angular applications
• Event handlers doing too much work synchronously

JavaScript Bundle Reduction

Audit your JavaScript bundles using @next/bundle-analyzer or the Chrome Coverage tool (DevTools > Coverage tab). Identify modules that are:

• Loaded on every page but only needed on specific pages
• Large libraries where only a small portion of functionality is used

Fixes:

• Dynamic imports: Load non-critical components on demand rather than in the initial bundle
• Tree shaking: Ensure your bundler eliminates unused exports from imported libraries
• Replace heavy libraries: moment.js (70KB) can be replaced by date-fns (< 10KB for used functions)
• Defer third-party scripts: Load analytics, chat widgets and ad scripts after the initial interaction window

Long Task Breaking

JavaScript tasks longer than 50ms block the main thread and prevent interaction responses. Break long tasks using:

• setTimeout(fn, 0) to yield to the browser between work chunks
• requestIdleCallback for non-urgent background work
• Web Workers for CPU-intensive computation that does not need DOM access

Debouncing and Throttling

Search inputs, filter controls and scroll handlers that trigger expensive operations on every keypress/scroll event cause INP failures. Implement:

• Debounce for search inputs (wait 300ms after the last keypress before executing)
• Throttle for scroll handlers (execute at most once per 100ms)

CLS Optimization: Eliminate Visual Instability {#cls}

CLS measures unexpected layout shifts — content jumping around as the page loads. Target: under 0.1.

Reserve Space for Images

The most common CLS cause is images loading without reserved dimensions. The browser does not know how tall an image will be until it loads, so it collapses the space to zero and then expands it — pushing all content below down.

Fix: Always set explicit width and height attributes on images. Modern browsers use these to calculate the aspect ratio and reserve the correct space before the image loads:

``html <img src="photo.webp" width="800" height="600" alt="Description" /> ``

In CSS, use aspect-ratio for responsive images where you cannot set fixed pixel dimensions.

Font Loading and CLS

Web fonts cause CLS when they load and replace the fallback system font, reflowing text. Solutions:

• `font-display: swap` shows text immediately with a fallback font, then swaps when the web font loads — this causes a CLS event but reduces total CLS because only one swap occurs
• `font-display: optional` only uses the web font if it loads within the first 100ms — prevents CLS entirely but may show system fonts on slow connections
• `next/font` handles self-hosting, subsetting and font-display configuration automatically in Next.js

Dynamic Content Placement

Ads, banners, cookie consent notices and dynamically loaded recommendations cause CLS when they appear above existing content after the page has rendered. Solutions:

• Reserve space with a minimum height container before dynamic content loads
• Position sticky elements so they do not affect document flow (use CSS position: fixed)
• Load dynamic content at the bottom of the page or in reserved spaces that do not affect surrounding layout

Animations and CLS

Animations that change width, height, top, left, margin or padding trigger layout recalculation and contribute to CLS. Use transform and opacity instead — these run on the compositor thread and do not trigger layout:

```css / Causes CLS / .element { transition: top 0.3s; }

/ No CLS / .element { transition: transform 0.3s; } ```

CWV Metric Targets and Thresholds {#metric-targets}

All three metrics must be in the "Good" range for a page to pass Core Web Vitals assessment. Google measures the 75th percentile of field data — meaning 75% of your real users must experience each metric within the "Good" threshold.

Tools for CWV Measurement {#tools}

For production sites, set up continuous monitoring with Lighthouse CI in your deployment pipeline. Catch CWV regressions before they affect rankings — a deploy that adds a large JavaScript dependency should fail the performance budget check before reaching production.

Common Issues and Fixes Table {#issues-table}

Step-by-Step Optimization Process {#how-to}

Follow this sequence for systematic CWV improvement. Each step builds on the previous.

Step 1: Establish baseline metrics. Run PageSpeed Insights on your 5 highest-traffic pages. Note current LCP, INP and CLS values for both mobile and desktop. Save these as your baseline for measuring improvement.

Step 2: Fix TTFB. If PageSpeed Insights shows TTFB > 600ms, address server-side performance first. Implement page caching (Redis, CDN edge caching), optimize slow database queries and ensure your hosting provider has servers in or near your target market.

Step 3: Optimize LCP images. Identify the LCP element on each key page via Lighthouse. Convert to WebP, compress to target file size, add preload link tags or Next.js priority prop, and serve from CDN.

Step 4: Audit and reduce JavaScript bundles. Run bundle analyzer. Identify the largest contributors to your initial JavaScript payload. Apply dynamic imports to above-the-fold components that are not immediately needed. Defer all third-party scripts.

Step 5: Break long tasks. Use Chrome DevTools Performance tab to record a page load and identify tasks longer than 50ms (shown in red). Refactor these to yield to the browser between work chunks.

Step 6: Fix image dimension CLS. Audit all <img> tags in your HTML. Add missing width and height attributes. For CSS background images used as layout elements, add explicit height or aspect-ratio rules.

Step 7: Fix font CLS. Switch to next/font or add font-display: optional to your font-face declarations. If font swap CLS is acceptable, use font-display: swap and ensure the fallback font metrics match the web font as closely as possible.

Step 8: Audit dynamic content. Identify all JavaScript-injected content that appears above the fold. Add minimum height CSS to containers before content loads. Move non-essential dynamic content below the fold.

Step 9: Verify improvements and deploy. Re-run Lighthouse and PageSpeed Insights. Compare against baseline. Deploy changes and monitor Search Console CWV report over the following 28 days (the window Google uses for field data aggregation).

Step 10: Set up continuous monitoring. Configure Lighthouse CI with performance budgets in your CI/CD pipeline. Set up alerts in Search Console for CWV regressions. Schedule monthly CWV audits.

Get a free Core Web Vitals audit →

Frequently Asked Questions {#faq}

How long does it take for CWV improvements to affect Google rankings? Google's field data (CrUX) aggregates over a 28-day rolling window. After deploying fixes, it takes approximately 28 days for the improved metrics to fully reflect in your field data. Search Console CWV reports update approximately weekly. Expect to see ranking improvements 4-8 weeks after deploying significant CWV fixes.

Does Lighthouse score directly correlate with Google ranking? Lighthouse provides lab data — measured under controlled conditions with a simulated device and connection. Google rankings use field data from real users. A high Lighthouse score improves your chance of good field data, but they are not identical. A site with consistent 90+ Lighthouse scores can still have poor field data if real users are on slower devices or connections. Optimize for both, but prioritize field data.

What is the fastest way to improve LCP? Image compression and CDN deployment are typically the fastest paths to LCP improvement. If your LCP image is currently 800KB JPEG served from an origin server, converting to WebP (approximately 200KB) and serving from a CDN can improve LCP by 1-2 seconds without any code changes.

Why is my INP good in Lighthouse but poor in field data? Lighthouse measures INP on a simulated device under lab conditions. Field data captures real user interactions across all your visitors' devices. Low-end Android devices on slower connections are far more common in real-world traffic than the simulated Lighthouse environment. INP failures on real devices often involve JavaScript that executes fine on a fast developer machine but causes delays on a budget smartphone.

Can I improve CLS without changing my site's visual design? Yes. Most CLS fixes are invisible to users: adding width and height attributes to images does not change how they display, it only tells the browser to reserve space. Using font-display: optional makes the font either load instantly or not swap — users may see the system font occasionally but the overall visual experience is stable. Reserving ad space with a minimum height placeholder may add a small gap before the ad loads, but this is a minor visual change for a significant CLS improvement.

What causes CLS on single page applications (SPAs)? Route transitions in SPAs can cause CLS if content heights differ between pages and the transition does not manage layout gracefully. Additionally, SPAs often load data after navigation, causing content to shift when it arrives. Solutions: reserve space with skeleton screens during data loading, maintain consistent layout containers across routes, and animate route transitions using transform rather than layout-affecting properties.

How do I measure INP in the field if I cannot reproduce it locally? Use the Chrome User Experience Report (CrUX) via PageSpeed Insights or the CrUX API to see real-user INP data. For deeper field data collection, add the Web Vitals JavaScript library (web-vitals) to your site to log INP events to your analytics platform. This lets you identify which specific interaction types (clicks on which elements, keyboard events on which inputs) are causing INP failures for real users.

Should I optimize for mobile or desktop CWV first? Mobile first, always. Google's mobile-first indexing means mobile CWV scores are more influential for rankings. Mobile devices are slower, have less memory and operate on more variable network connections — mobile CWV scores are typically worse than desktop and harder to improve. Fixing mobile CWV also tends to improve desktop CWV as a byproduct.

Conclusion {#conclusion}

Core Web Vitals optimization is not a one-time project — it is an ongoing discipline. Every new feature, third-party integration or content update is a potential regression. The teams that maintain "Good" CWV status over time are those that have built performance into their development process: bundle size budgets, image optimization pipelines, CWV checks in CI/CD and monthly audits.

The payoff is compounding. Better CWV means better rankings, which means more traffic, which means more conversions. A site that consistently passes Core Web Vitals outperforms identical content on a slow site — and that advantage grows as competition in your category increases.

Our team at Modern Web SEO builds Core Web Vitals optimization into every project from day one. Explore our services, SEO consulting packages and portfolio to see how we approach performance.

Get a Free Quote →