Algo Seo Technical

Core Web Vitals Optimization

Overview

Core Web Vitals are Google's page experience metrics: LCP (loading), INP (interactivity), and CLS (visual stability). Measured on real user data (CrUX). Pass thresholds: LCP < 2.5s, INP < 200ms, CLS < 0.1.

When to Use

Trigger conditions:

• Diagnosing why a site fails Core Web Vitals assessment
• Optimizing page load performance for SEO
• Reducing layout shift or improving interactivity

When NOT to use:

• When the issue is content relevance, not speed (use content SEO)
• When analyzing link authority (use PageRank / backlink analysis)

Algorithm

IRON LAW: CrUX Field Data Is the Source of Truth
Lab scores (Lighthouse) that pass can still FAIL in the field.
Google ranks based on REAL USER data (75th percentile):
- LCP < 2.5s (Good), 2.5-4.0s (Needs Improvement), > 4.0s (Poor)
- INP < 200ms (Good), 200-500ms (Needs Improvement), > 500ms (Poor)
- CLS < 0.1 (Good), 0.1-0.25 (Needs Improvement), > 0.25 (Poor)

Phase 1: Input Validation

Collect field data from CrUX API or Search Console. Run Lighthouse for lab baseline. Identify which metrics fail.

Gate: Have both field and lab data; failing metrics identified.

Phase 2: Core Algorithm

LCP fixes: 1. Optimize largest element (hero image/text). 2. Preload critical resources. 3. Reduce server response time (TTFB). 4. Eliminate render-blocking resources.

INP fixes: 1. Break long tasks (> 50ms) into smaller chunks. 2. Reduce JavaScript execution time. 3. Use requestIdleCallback for non-critical work. 4. Minimize main thread blocking.

CLS fixes: 1. Set explicit dimensions on images/videos. 2. Reserve space for ads/embeds. 3. Avoid inserting content above existing content. 4. Use CSS contain for dynamic elements.

Phase 3: Verification

Re-run Lighthouse, deploy, then monitor CrUX for 28-day rolling average improvement.

Gate: Lab scores pass; await field data confirmation (28-day cycle).

Phase 4: Output

Return audit results with specific fix recommendations prioritized by impact.

Output Format

{
  "audit": {"lcp": {"value_ms": 3200, "status": "poor", "element": "hero-image.jpg", "fixes": ["preload", "compress"]}},
  "metadata": {"url": "...", "data_source": "crux", "device": "mobile"}
}

Examples

Sample I/O

Input: URL with LCP=4.1s, CLS=0.32, INP=150ms

Expected: LCP and CLS flagged as poor; INP passes. Fix priorities: CLS (image dimensions) → LCP (hero image preload)

Edge Cases

| Input | Expected | Why |

|-------|----------|-----|

| SPA with client rendering | High LCP likely | No server-rendered content for LCP element |

| Page with ads | High CLS likely | Ad slots inject content dynamically |

| All metrics pass in lab | May still fail field | Real devices on slow networks differ from lab |

Gotchas

• Lab vs field gap: Lighthouse runs on a simulated fast device. Real users on 3G with old phones produce very different numbers.
• LCP element changes: The LCP element can differ across page loads (image vs text). Optimize for the MOST COMMON LCP element, not just one.
• CLS attribution: Layout shifts are blamed on the element that moved, but the CAUSE is often an element inserted above it. Trace the cause, not the symptom.
• INP replaced FID: As of March 2024, INP replaces FID. Old references to FID are outdated.
• 28-day lag: CrUX uses a 28-day rolling window. Fixes take up to a month to reflect in field data.

References

• For element-specific optimization techniques, see references/optimization-techniques.md
• For CrUX API usage and monitoring setup, see references/crux-monitoring.md