How to Improve Website Speed and Core Web Vitals

Direct answer：A step-by-step guide to diagnosing and improving LCP, INP, and CLS with verifiable acceptance criteria.

Diagnosing Core Web Vitals

1. Measure Field Data

• Use Chrome User Experience Report (CrUX) for real-user LCP, INP, and CLS data.
• Record the 75th percentile values for each metric.
• Verification: Compare against Google’s thresholds (LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1).

1. Lab Testing

• Run Lighthouse with mobile preset.
• Capture: Largest Contentful Paint (LCP) source, Interaction to Next Paint (INP) culprits, Cumulative Layout Shift (CLS) elements.
• Exception: Lab data may not match field data for dynamic content.

1. Image Optimization

• Audit <img> tags for missing width/height or unoptimized formats.
• Use loading="lazy" for below-the-fold images.
• Acceptance: LCP image loads within 1.5s on 3G throttling.

1. Font Handling

• Check for late-discovered fonts via Font Loading API.
• Apply font-display: swap with fallback metrics.
• Verification: No layout shifts after font load.

1. Third-Party Impact

• Identify slow third parties with WebPageTest’s request map.
• Load non-critical scripts asynchronously or defer them.
• Exception: Some third parties (e.g., payment processors) require synchronous loading.

1. Server Configuration

• Verify Cache-Control headers for static assets (e.g., max-age=31536000).
• Enable Brotli/Gzip compression.

Verification Template

Run these checks before/after changes:

1. Field data shows 75th percentile LCP ≤ 2.5s for 28 days.
2. INP events (e.g., button clicks) complete ≤ 200ms in lab tests.
3. CLS ≤ 0.1 with no new shifts after dynamic content loads.

Core Web Vitals Optimization Protocol

Inputs

1. CrUX Field Data: Export from Google Search Console (3-month window)
2. Lab Data: Lighthouse 10.0+ with mobile throttling (4G, 4x CPU slowdown)
3. Resource Waterfall: WebPageTest.org filmstrip (Moto G4, Chrome)
4. Hosting Logs: TTFB distribution by region (Cloudflare/New Relic)

Execution Steps

1. LCP Candidates:

• Identify >250KB images without fetchpriority=high
• Verify hero images use width/height attributes
• Convert PNG to AVIF using Squoosh (Q=75 threshold)

1. INP Reduction:

• Isolate handlers causing >50ms delay in Chrome DevTools
• Apply will-change: transform to animated elements
• Replace click listeners with pointerdown where valid

1. CLS Mitigation:

• Audit layout shifts via DevTools > Performance > Experience
• Reserve space for ads with min-height containers
• Preload font-display: swap for critical typefaces

Verification Matrix

Metric：Threshold；Measurement Tool；Sample Size

LCP：≤2.5s；CrUX (75th %ile)；1,000+ visits

INP：≤200ms；RUM.js；28-day window

Edge Cases

• CMS Constraints: WordPress requires perfmatters plugin for script deferral
• A/B Tests: Exclude Variant X from metrics during active campaigns
• Geo-Variation: EU cookie banners add 300-800ms INP penalty

Validation Steps

1. Delta Check: Compare CrUX percentiles pre/post (28-day cohorts)
2. Synthetic Confirmation: Run WebPageTest from Mumbai/Dallas/Sydney
3. Business Impact: Correlate with Google Analytics > Conversions

Evidence Sources and Quality Gates

Inputs

1. Field Data: Use Chrome User Experience Report (CrUX) or RUM tools to collect real-user metrics (LCP, INP, CLS).
2. Lab Data: Run Lighthouse or WebPageTest for controlled environment diagnostics.
3. Third-Party Impact: Audit third-party scripts via Chrome DevTools’ Coverage tab.

Verification Steps

1. LCP (Largest Contentful Paint):

• Measure: Identify the largest above-the-fold element (image, video, text block).
• Acceptance: LCP ≤ 2.5s (field data).
• Evidence Gap: Verify if LCP element is dynamically loaded (requires code inspection).

1. INP (Interaction to Next Paint):

• Measure: Track event latency for clicks, taps, keypresses.
• Acceptance: INP ≤ 200ms (field data).
• Exception: Complex interactions (e.g., drag-and-drop) may require custom thresholds.

1. CLS (Cumulative Layout Shift):

• Measure: Sum layout shifts during page load.
• Acceptance: CLS ≤ 0.1 (field data).
• Verification Item: Check if width/height attributes are missing on images.

Quality Gate Template

Metric：Data Source；Target Threshold；Verification Method；Common Exceptions

LCP：CrUX, Lighthouse；≤ 2.5s；Element timing API；Dynamic content loading

INP：RUM, WebPageTest；≤ 200ms；Event timing traces；Complex UI interactions

CLS：DevTools；≤ 0.1；Layout shift tracker；Unstyled dynamic content

TTFB：Server logs；≤ 600ms；CDN/backend latency analysis；High-traffic spikes

Third Parties：Coverage report；≤ 500KB；Script blocking analysis；A/B testing or analytics tools

Exceptions

• Fonts: Use font-display: swap but verify FOIT/FOUT trade-offs.
• Caching: Validate cache headers but note dynamic content exceptions.
• Servers: TTFB improvements may require backend profiling (outside frontend scope).

Core Web Vitals Optimization Process

Step 1: Baseline Measurement

• Inputs:
• Lab: Lighthouse 12.6.0 (DevTools)
• Field: CrUX API (3-month dataset)
• Fields to Record:

Metric：Target；Tool；Verification Method

LCP：<2.5s；PSI；CrUX 75th percentile

INP：<200ms；RUM；90th percentile

CLS：<0.1；LayoutShift API；95th percentile

Step 2: Root Cause Analysis

• Image Issues:
• Missing fetchpriority=high on LCP element
• AVIF conversion potential (check browser support)
• Font Issues:
• FOIT duration >100ms (font-display: optional)

Step 3: Targeted Optimizations

• Critical Path:
• Preload LCP image after <link rel=preconnect>
• Inline critical CSS (<14KB compressed)
• Third Parties:
• Load analytics after requestIdleCallback
• Sandbox ads in iframe with loading=lazy

Verification Protocol

• Acceptance Tests:

1. Lab LCP variance <300ms across 3 runs
2. INP <150ms for key interactions (menu, search)
3. CLS = 0 during initial 5s load

• Exception Handling:
• Dynamic pricing widgets: exempt from CLS if <0.15
• Geo-based CDN: allow TTFB up to 800ms

Monitoring Implementation

• Automation:
• Lighthouse CI: fail on LCP >3s
• CrUX API: weekly delta alerts
• RUM: real-time INP outliers

Assign and verify speed optimization ownership

1. Business owner (e.g., marketing lead):

• Field: Quarterly revenue impact threshold
• Acceptance: Signs off budget for tools/developers when CrUX data shows ≥0.5s LCP regression
• Exception: Bypasses if security patch requires immediate deployment

1. Editorial owner (e.g., content lead):

• Criteria: Rejects hero images >150KB after Squoosh processing
• Verification: Checks WebPageTest filmstrip for LCP element load

1. Technical owner (e.g., devops):

• Field: Server TTFB (acceptance: ≤400ms)

• Artifact: Chrome DevTools Network tab screenshot with timing breakdown

1. Third-party auditor:

• Field: CLS contribution score (fails if >0.1)
• Method: Runs Lighthouse with simulated throttling
• Exception: Allows analytics scripts during compliance reviews

1. Review cadence:

• Field: CrUX data delta (biweekly)

• Verification: Compares RUM data vs. synthetic tests

Acceptance methods

• LCP: WebPageTest side-by-side comparison (before/after above-the-fold resource optimization)
• INP: Chrome DevTools Interaction panel with 10x throttling
• CLS: Layout Shift debugger with annotated screenshots

Limited Rollout Plan for Core Web Vitals Improvement

Step 1: Establish Baseline Metrics

• Inputs: Use tools like Lighthouse, PageSpeed Insights, or CrUX Dashboard to measure LCP, INP, CLS, and field data.
• Record Fields: Initial LCP, INP, CLS, FCP, TTFB, and server response times.
• Acceptance Check: Ensure metrics are captured consistently across three sessions.

Step 2: Identify Key Areas for Optimization

• Criteria: Focus on elements contributing to poor scores (e.g., large images, render-blocking scripts, inefficient caching).
• Exceptions: Exclude third-party scripts if they are critical for functionality.
• Verification Item: Confirm identified elements are the primary bottlenecks.

Step 3: Implement Changes

• Steps: Optimize images, defer non-critical scripts, enable caching, and upgrade server infrastructure.
• Record Fields: Changes made, time taken, and resources allocated.
• Acceptance Check: Ensure changes do not break functionality.

Step 4: Monitor and Record Post-Optimization Metrics

• Inputs: Re-run Lighthouse, PageSpeed Insights, or CrUX Dashboard.
• Record Fields: Post-optimization LCP, INP, CLS, FCP, TTFB, and server response times.
• Acceptance Check: Compare with baseline metrics.

Step 5: Evaluate Results

• Criteria: Significant improvement in LCP, INP, and CLS scores.
• Exceptions: Minor improvements may require further optimization.
• Verification Item: Confirm improvements are statistically significant.

Step 6: Decide on Full Rollout

• Decision Criteria: If improvements meet acceptance criteria, proceed with full rollout.
• Rework: If not, revisit optimization steps.
• Stop: If no improvement, consider alternative strategies.

Core Web Vitals Execution Checklist

Preconditions

• Verify access to Google Search Console (field: GSC_connected)
• Confirm production environment matches test (field: env_match)
• Baseline field data from CrUX (field: crux_28d_percentile)

Ordered Checks

1. LCP Diagnosis

• Identify top 5 LCP elements (field: lcp_elements)
• Check image format (criteria: WebP/AVIF for >100KB)
• Verify preload for critical images (field: preload_hint_count)

1. INP Optimization

• List event listeners per interactive element (field: event_listeners)
• Measure main thread blocking time (criteria: <50ms per task)
• Audit third-party scripts (exception: payment processors)

1. CLS Mitigation

• Measure layout shifts after load (field: cls_after_onload)
• Reserve space for dynamic ads (criteria: width/height defined)
• Check font display swap (verification: font-display: swap)

Acceptance Methods

• Compare CrUX 75th percentile before/after (field: crux_improvement)

• Document regression tests (field: rollback_plan)

Diagnosing and Remediating Core Web Vitals

1. Identify Failure Signals

• LCP (Largest Contentful Paint): >2.5s (field data) or >4.0s (lab data).
• INP (Interaction to Next Paint): >200ms (field data) or >500ms (lab data).
• CLS (Cumulative Layout Shift): >0.1 (field or lab data).

2. Root-Cause Diagnosis Order

1. Images: Check uncompressed sizes, missing width/height, lazy-loading conflicts.
2. Fonts: Render-blocking @font-face, missing font-display: swap.
3. Scripts: Third-party delays, unminified JS, excessive DOM size.
4. Caching: Missing Cache-Control headers, stale preloads.
5. Servers: TTFB >600ms, missing CDN, slow DNS.

3. Remediation Evidence

• Before/After: Capture Chrome DevTools traces, WebPageTest filmstrips.
• Acceptance: Field data (CrUX) must show 75th percentile improvement within 28 days.

4. Recurrence Controls

• Images: Enforce srcset with AVIF/WebP fallbacks.
• Fonts: Host WOFF2 locally with preload.
• Scripts: Audit third parties monthly using requestBlocking in Lighthouse.

Exceptions: INP may require user interaction replay tools like WebPageTest scripting. CLS fixes often need layout stability tests across viewports.

Related reading

• GEO optimization guides
• What GEO optimization means
• End-to-end GEO workflow
• GEO visibility solution

References

• Google: Creating helpful, reliable, people-first content
• Google: AI features and your website
• Google: Guidance on generative AI content
• 2026 critical survey of GEO research