Back to Details

algo-seo-technical

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Core Web Vitals Optimization

Core Web Vitals优化

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.
Core Web Vitals是谷歌的页面体验指标：LCP（加载）、INP（交互性）和CLS（视觉稳定性）。基于真实用户数据（CrUX）进行衡量。达标阈值：LCP < 2.5秒，INP < 200毫秒，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)
触发条件：
  • 诊断网站未通过Core Web Vitals评估的原因
  • 为SEO优化页面加载性能
  • 减少布局偏移或提升交互性
不适用场景：
  • 问题源于内容相关性而非速度（请使用内容SEO相关技能）
  • 分析链接权重（请使用PageRank/反向链接分析相关技能）

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)
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

阶段1：输入验证

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.
从CrUX API或Search Console收集真实用户数据。运行Lighthouse获取实验室基准数据。确定哪些指标未达标。 **准入条件：**同时拥有真实用户数据和实验室数据；已明确未达标指标。

Phase 2: Core Algorithm

阶段2：核心算法

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.
**LCP优化方案：**1. 优化最大元素（首屏图片/文本）。2. 预加载关键资源。3. 缩短服务器响应时间（TTFB）。4. 消除阻塞渲染的资源。
**INP优化方案：**1. 将长任务（>50毫秒）拆分为更小的任务块。2. 减少JavaScript执行时间。3. 使用
requestIdleCallback
处理非关键任务。4. 最小化主线程阻塞。
**CLS优化方案：**1. 为图片/视频设置明确尺寸。2. 为广告/嵌入内容预留空间。3. 避免在现有内容上方插入新内容。4. 为动态元素使用CSS 
contain
属性。

Phase 3: Verification

阶段3：验证

Re-run Lighthouse, deploy, then monitor CrUX for 28-day rolling average improvement. Gate: Lab scores pass; await field data confirmation (28-day cycle).
重新运行Lighthouse，部署优化方案，然后监控CrUX的28天滚动平均值是否有所提升。 **准入条件：**实验室指标达标；等待真实用户数据确认（28天周期）。

Phase 4: Output

阶段4：输出

Return audit results with specific fix recommendations prioritized by impact.
返回审计结果，并按影响优先级列出具体的修复建议。

Output Format

输出格式

json
{
  "audit": {"lcp": {"value_ms": 3200, "status": "poor", "element": "hero-image.jpg", "fixes": ["preload", "compress"]}},
  "metadata": {"url": "...", "data_source": "crux", "device": "mobile"}
}
json
{
  "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)
**输入：**URL的LCP=4.1秒，CLS=0.32，INP=150毫秒 **预期输出：**LCP和CLS标记为不达标；INP达标。修复优先级：CLS（图片尺寸）→ LCP（首屏图片预加载）

Edge Cases

边缘案例

InputExpectedWhy
SPA with client renderingHigh LCP likelyNo server-rendered content for LCP element
Page with adsHigh CLS likelyAd slots inject content dynamically
All metrics pass in labMay still fail fieldReal devices on slow networks differ from lab
输入预期结果原因
客户端渲染的SPA大概率LCP值较高没有服务器渲染的LCP元素内容
含广告的页面大概率CLS值较高广告位会动态插入内容
实验室指标全部达标真实用户数据仍可能不达标真实设备在慢速网络下的数据与实验室环境差异较大

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.
  • 实验室与真实用户数据差距：Lighthouse在模拟的高速设备上运行。使用3G网络的旧手机等真实设备的数据会与实验室数据有很大差异。
  • LCP元素变化：不同页面加载过程中，LCP元素可能不同（图片 vs 文本）。针对最常见的LCP元素进行优化，而非仅针对某一个元素。
  • CLS归因：布局偏移通常被归咎于移动的元素，但原因往往是上方插入了其他元素。要追溯根源而非仅处理表象。
  • INP替代FID：自2024年3月起，INP已替代FID。旧的FID相关参考内容已过时。
  • 28天延迟：CrUX采用28天滚动窗口。优化效果最多需要一个月才能在真实用户数据中体现。

References

参考资料

  • For element-specific optimization techniques, see 
    references/optimization-techniques.md
  • For CrUX API usage and monitoring setup, see 
    references/crux-monitoring.md
  • 有关元素特定的优化技术，请参阅
    references/optimization-techniques.md
  • 有关CrUX API使用和监控设置，请参阅
    references/crux-monitoring.md