Core Web Vitals Optimization Guide: Fix LCP, CLS, INP and TTFB

Core Web Vitals are a set of user-centered performance metrics that affect search ranking and user experience. This guide explains how to optimize Core Web Vitals with clear steps for developers and site owners to fix LCP, CLS, INP (or FID), and related server and network issues.

How to optimize Core Web Vitals: step-by-step checklist

Understand the metrics and targets

Core Web Vitals include Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP) as the modern replacement for First Input Delay (FID). Typical thresholds: LCP < 2.5s, CLS < 0.1, INP (good) < 200ms. Use field data from real users (PageSpeed Insights, Search Console, Chrome UX Report) and lab tools (Lighthouse, WebPageTest) to get both perspectives. For official definitions and thresholds, consult the Google Web Vitals documentation: web.dev/vitals/.

FAST Core Web Vitals Checklist (named framework)

• F — Fonts & Critical CSS: Preload key fonts, include font-display: swap, inline critical CSS for above-the-fold content to avoid FOIT/FOUT and render-blocking.
• A — Above-the-fold content: Prioritize LCP element by preloading hero images or critical media. Lazy-load images below the fold.
• S — Server & Network: Reduce TTFB with caching, CDN, HTTP/2, and keep-alive. Optimize server rendering paths and database queries.
• T — Third-party control: Audit and defer or async third-party scripts (ads, analytics, widgets) to reduce main-thread blocking and unpredictable layout shifts.

Practical measurement steps

Start with production field data: review the Search Console Core Web Vitals report and Chrome User Experience Report for long-term trends. Reproduce issues in a controlled lab test (Lighthouse or WebPageTest) to isolate assets and scripts that affect metrics. Use browser devtools Performance tab to record paint events, layout shifts, and long tasks.

Common fixes to improve LCP, CLS and reduce TTFB

Improve LCP and CLS with concrete actions

• Preload the LCP image or hero font using or rel="preload" as="font" for fonts used by the LCP element.
• Set width/height or aspect-ratio on media and reserve space for embeds to prevent layout shifts (reduces CLS).
• Compress images (AVIF/WebP where supported) and use responsive srcset to serve the right size.

Reduce TTFB and server latency

Implement server-side caching (page and object caches), enable a CDN, use HTTP/2 or HTTP/3, and optimize backend queries. Consider edge rendering or static generation for high-traffic pages where possible. Reducing TTFB often improves LCP indirectly by getting HTML and resources to the browser faster.

Control third-party scripts

Defer or async non-critical scripts, load analytics after interaction, and use performance budgets. Move tag managers and ads into containers that load only when visible to the user. Third-party code can cause long tasks and layout shifts that damage both INP and CLS.

Real-world example: ecommerce homepage

Scenario: An ecommerce homepage had an LCP of 4.0s and CLS of 0.2. Steps taken: identify the LCP element (hero image), add preload for the hero image, optimize and responsive-size the image, inline critical CSS for the hero area, reserve height for promotional banners and lazy-load below-the-fold carousels. Server response was improved with a CDN and page cache, reducing TTFB. Result: LCP dropped to 1.9s and CLS to 0.03 in lab tests; field data improved over the next week.

Practical tips to implement now

• Measure first: collect field data (Search Console, CrUX) and run a Lighthouse baseline.
• Preload one or two critical resources (LCP image, primary font) and test for positive impact before preloading more.
• Reserve layout space for images, ads, and embeds by setting explicit dimensions or using CSS aspect-ratio.
• Defer non-essential JavaScript and break up long tasks using web workers or code-splitting.
• Set a performance budget (e.g., max main-thread blocking time) and enforce it in CI using Lighthouse or WebPageTest APIs.

Trade-offs and common mistakes

Trade-offs

Inlining critical CSS reduces render-blocking but increases HTML size and may impact caching efficiency. Preloading fonts improves LCP but can lead to wasted bandwidth if the pattern doesn't match user behavior. Use targeted preloads and measure net benefit.

Common mistakes

• Fixing only lab results without checking field data — lab improvements can fail to translate to real users.
• Preloading too many resources — this can delay other critical downloads and hurt overall performance.
• Ignoring third-party scripts — widgets and ads are common sources of layout shifts and long tasks.

Implementation checklist

• Collect field metrics and identify problem pages.
• Locate the LCP element and preload it if appropriate.
• Reserve space for images and embeds to avoid CLS.
• Minimize main-thread work and defer non-critical JS.
• Optimize server and network: CDN, caching, HTTP/2/3.
• Re-measure in production and iterate.

FAQ: How to optimize Core Web Vitals for a site?

Measure field and lab data, then apply the FAST checklist: preload fonts and LCP assets, reserve space to eliminate layout shifts, reduce server latency, and control third-party scripts. Prioritize fixes that affect the largest user segments and re-test.

What is the best way to improve LCP and CLS on mobile?

Prioritize mobile-specific LCP assets with responsive images, compress and serve proper image formats, use a fast CDN close to users, and ensure CSS and font loading are optimized to avoid blocking rendering. On mobile, network and CPU constraints make main-thread work reductions especially important.

How long before Core Web Vitals changes appear in reports?

Field metrics like CrUX and Search Console can take days to reflect changes because they aggregate real-user data. Lab tests show immediate changes for verification. Use both to validate improvements over time.

Which tools best measure Core Web Vitals?

Use PageSpeed Insights and Chrome DevTools for combined lab and field insight, Lighthouse for actionable audits, and WebPageTest for detailed waterfall and filmstrip analysis. Monitor over time with real-user monitoring (RUM) solutions.

Can a static site always pass Core Web Vitals?

Static sites have an advantage due to simpler render paths and stronger caching, but poor images, fonts, or third-party scripts can still cause failures. Follow the checklist and measure to ensure good scores.