Core Web Vitals 是衡量加载、互动反应与视觉稳定性的 Field Metrics。它把部分用户体验变成共用衡量系统，但报告变绿不能取代相关内容、无障碍流程、可抓取性或商业成果。
CrUX 和 First-party RUM 说明符合样本条件的访客经历了什么；Dev工具 与可重复 Lab Test 找出背后的 Element、Interaction、Resource 或 Task。Lighthouse 100 不是目标。
认识三个当前指标与门槛
Mobile 与 Desktop 分开，以 Page Visit 的第 75 百分位判断。三个指标都是越低越好；LCP 与 INP 是时间，CLS 是没有单位的视觉稳定分数。
INP 已在 2024 年 3 月 12 日取代 First Input Delay（FID）成为 Core Web Vital，Chrome Performance 工具 也在同年停止支持 FID。Lighthouse 的 Total Blocking Time 是有用的 Lab Diagnostic，但不能代替 Field INP。
| 指标 | 良好 | 需要改善 | 差 | 衡量的体验 |
|---|---|---|---|---|
| LCP | ≤ 2.5 秒 | > 2.5 至 4 秒 | > 4 秒 | 可能的主要内容何时显示 |
| INP | ≤ 200 毫秒 | > 200 至 500 ms | > 500 ms | 符合条件互动的反应速度 |
| CLS | ≤ 0.1 | > 0.1 至 0.25 | > 0.25 | 访问期间的意外视觉移动 |
了解 Assessment 如何通过或失败
当 LCP、INP 与 CLS 的第 75 百分位都属于“良好”，Page 或 Origin 才通过 Core Web Vitals Assessment。PageSpeed Insights 中，如果 INP 资料不足，而 LCP 与 CLS 良好，Aggregation 仍可能通过；如果 LCP 或 CLS 资料不足，就无法评估。
Search Console 会以最差的 Core Web Vital 决定 URL Group 状态。“No Data”不是通过或失败，而是 CrUX 样本不足以作出判断。
| 情况 | Assessment | 解释 |
|---|---|---|
| 三个指标都良好 | 通过 | 至少 75% 被衡量访问符合每个门槛 |
| 一个指标需要改善 | 不通过 | 修复该体验维度 |
| 一个指标差 | Poor Group/Status | 优先处理代表性用户旅程 |
| INP 不足；LCP/CLS 良好 | PSI 可能通过 | 符合条件互动不足以评估 INP |
| LCP 或 CLS 不足 | 无法评估 | 使用 RUM 与 Lab，不要称为通过 |
| 没有 CrUX | 未知 | 通常是符合条件流量不足，不是速度证据 |
把 Core Web Vitals 放回 Page 经验 与 搜索
Google 表示 Ranking Systems 使用 Core Web Vitals，但不存在单一 Page-experience Signal。相关性仍然最重要，完美报告也不保证第一名。HTTPS、Mobile 呈现、Intrusive Interstitial、干扰广告与清楚区分 Main Content，仍会影响用户体验。
用 Core Web Vitals 改善重要旅程与摩擦，不要为了颜色移除所有功能。还要衡量 Accessibility、任务完成率与 Conversion Quality 是否被保护。
| 说法 | 准确解释 |
|---|---|
| “CWV 保证排名” | 错误；它只是众多 Signal 中的一组 |
| “内容能排名，所以 CWV 不重要” | 错误；差体验会降低用户价值，也可能影响 搜索 Outcome |
| “只有 Green URL 才能使用” | 错误；门槛不是完整 UX 诊断 |
| “Page 经验 是一个分数” | 错误；Google 描述多个层面，并有页面与部分全站评估 |
让每一种证据回答它能回答的问题
| 证据 | 最适合回答 | 常见来源 | 主要限制 |
|---|---|---|---|
| CrUX Field Data | 符合条件的 Chrome 用户经历什么？ | PSI、Search Console、CrUX API/History/BigQuery | 聚合样本，Segmentation 与 Eligibility 有限制 |
| First-party RUM | 哪个 Route、Element、Interaction、用户环境或版本退步？ | web-vitals Library 或 RUM Platform | 需要 Governance、Sampling、Privacy 与分析 |
| Lab Load Test | 可重复 Navigation 被什么阻挡？ | Lighthouse 与 PSI Lab | 单次模拟；较难发现 Post-load 问题 |
| Interactive Trace | 哪个 Task、Handler、Layout 或 Paint 拖慢流程？ | Chrome Dev工具 Performance | 人工条件可能和真实用户不同 |
| Delivery Evidence | Server、CDN 或 Asset 是否改变？ | Server-Timing、CDN 与 App Log | 不是完整视觉体验 |
| Business Analytics | 更快旅程是否改善有效结果？ | Analytics 与 Conversion Record | Correlation 需要版本与 Cohort 控制 |
清楚 CrUX 包含什么，也不包含什么
CrUX 汇总符合条件的 Chrome 用户体验，平台包括受支持 Desktop 与 Android Chrome。Chrome iOS、Android WebView、其他 Chromium Browser，以及不符合设定条件的用户不会进入样本。Page 与 Origin 还需要能够公开发现，并达到一定 Popularity。
因此 CrUX 是有代表性的证据，不是每位访客的普查。Page-level Aggregation 会移除 Query Parameter 与 Fragment，SPA Soft Navigation 也受 Web Platform Measurement 限制。低流量、分群或 App-specific 问题应补充 First-party RUM。
| CrUX 特性 | 运营影响 |
|---|---|
| 28 天滚动聚合 | 新版本会混合最多 27 天旧体验，数据逐步变化 |
| API/PSI 每日更新 | 每日新资料并不是新的独立 28 天测试 |
| URL 与 Origin 层级 | Origin Fallback 可能掩盖单一 Template 的快慢 |
| 符合条件的 Chrome 样本 | 不能直接代表所有 Browser 与 Audience |
| Popularity 门槛 | 新页面或低流量页可能没有 Field Data |
| Privacy Filtering/Fuzzing | 看 Distribution 与 Trend，不反推流量数量 |
正确阅读 PageSpeed Insights 与 Search Console
PageSpeed Insights 把 28 天 CrUX View 与新的 Lighthouse Lab Run 放在一起。先确认 Field Section 是“This URL”还是“Origin”，两个范围可能讲不同故事。Search Console 会把相似体验的 URL 分组，适合 Group Diagnosis，不是查询每个 URL 的精确分数。
Search Console Group Status 使用最差指标。打开代表性 Example，比较 PSI 的 URL 与 Origin Data，并确认真正 Template 后，才把修复应用到整组。
- 分开 Mobile 与 Desktop。
- 记录 Collection Date、URL/Origin Scope 与 Group。
- 不要直接比较 Search Console Group 与单次 Lighthouse Run。
- 确认 Tested URL 是否有足够 Page-level CrUX。
- 查看三个指标的 Distribution，不只 Overall Label。
- 保存受影响 Template、Release Version 与代表 URL。
- 用 CrUX History 或 RUM 看趋势，不只保存 Screenshot。
- 把“No Data”视为未知。
修改代码前先定义受影响单位
报告里的 URL 常常只是 Shared Header、Hero、篇文章 Template、Product Gallery、Form 或 Consent Layer 的一个例子。至少重现多个 URL，并按 Template、Device、Navigation Type 与重要 User State 分段。
如果 CMS Rule 在数百页产生同一问题，只优化一个 URL 的图片价值很低；反过来，也不要因为一个 Personalized Page 是 Outlier 就重写 Global Component。
| 模式 | 可能的受影响单位 | 第一次比较 |
|---|---|---|
| 同一 Template 都有相同指标 | Template Markup 或 Shared Asset Rule | 三个代表 URL |
| 大部分页面都有问题 | Header、Font、Consent、Analytics 或 CDN | 首页、篇文章、Service 与 Form |
| 只有 Repeat Visit 慢 | Cache、Service Worker 或 Client State | Cold 与 Warm Navigation |
| 只有登录后流程 | Application Route/State | Anonymous 与 Authenticated RUM |
| 只有一个地区 | CDN、Origin Distance 或 Third Party | Region 与 Network Cohort |
| 只有新版本出现 | 改变的 Bundle、Component 或 Backend | Version 与 Deployment Annotation |
通过四个 Subpart 诊断 LCP
LCP 衡量 Initial Viewport 内最大合资格 Content Element 何时完成 Paint。Candidate 会因 Viewport、Content 与 User 不同，因此要捕获真实 Element，不能假设每页都是 Hero Image。
每个 LCP 可分为 Time to First Byte、Resource Load Delay、Resource Load Duration 与 Element Render Delay。优先修复证据显示最大的那一段；真正原因是延迟发现或 Client Rendering 时，单纯压缩图片可能没有效果。
| LCP Subpart | 证据 | 常见原因 | 集中处理 |
|---|---|---|---|
| TTFB | Document Response 很迟开始 | Origin 工作、Redirect、Cache Miss、网络距离 | Cache HTML、减少 Backend、移除 Redirect、适合的 CDN |
| Resource Load Delay | LCP Request 在 TTFB 后很迟才开始 | CSS Background、JS 注入、Lazy Load、Parser Block | Initial HTML、取消 Lazy Load、有证据才设 Priority/Preload |
| Resource Load Duration | Request 本身很久 | 过大 Image/Font 或慢 Asset Host | Responsive Size、Compression、Modern Format、Cache/Delivery |
| Element Render Delay | Resource 已到但很迟 Paint | Blocking CSS/Font、Hydration、Animation、Hidden State | 减少 Blocking Work，让主要内容更早渲染 |
实施 LCP 修复时不要制造新问题
如果 LCP 是图片，在 Initial HTML 提供可抓取的 src/srcset，请求合适尺寸，而且不要 Lazy-load。明确的 fetchpriority="high" 或 Preload 能帮助真正关键、发现较迟的 Resource；但 Preload 太多文件会争夺 Bandwidth。
如果 LCP 是文字，检查 Font 与 CSS Delivery。更快 TTFB 也能让后续资源更早开始。Responsive Image 与 Intrinsic Size 可参考Image SEO 指南。
- 记录 LCP Element 与四个 Subpart。
- 测试 Cold 与 Warm Cache。
- 尽量让 Primary Resource 出现在 Initial Document。
- 不要 Lazy-load LCP Image。
- 按 Rendered Size 与 DPR 提供合适尺寸。
- 只 Preload 已确认的关键 Resource。
- Font 加载期间文字仍可见。
- 检查 Mobile Viewport，不只 Desktop。
- 复测 Redirect、CDN Cache 与 Third-party Hero。
诊断整个访问期间的 INP
INP 会观察 Page Visit 内符合条件的 Click、Tap 与 Keyboard Interaction，并报告高延迟互动；通常是最慢互动，互动很多时会容许一个 Outlier。没有符合条件互动的 Page Visit 不会产生 INP。
Interaction Latency 分为 Callback 开始前的 Input Delay、Event Callback 的 Processing Duration，以及下一 Frame 呈现前的 Presentation Delay。要找出真正慢的段落与 Target；第一次 Click 快并不能证明整个体验 Responsive。
| INP 部分 | 延迟来源 | 证据 | 常见处理 |
|---|---|---|---|
| Input Delay | 现有 Long Task、Script Evaluation、Timer 或重叠工作 | Interaction Trace 与 Load State | 减少 Startup JS、拆分/让出 Task、控制 Recurring Work |
| Processing Duration | 复杂 Event Callback 或同步计算 | Event Timing 与 Call Stack | Handler 少做事，移动/延后非关键工作 |
| Presentation Delay | 大量 DOM 更新、Style/Layout/Paint 或 Framework Render | Callback 后的 Rendering Work | 缩小更新范围，降低 DOM/Layout/Animation Cost |
| Iframe Interaction | Widget 有独立 Main Thread，但共享受限设备资源 | 尽可能确认 Frame Target 与 Provider Trace | 延迟、替换、隔离或重新要求 Vendor |
测试用户真正使用的互动
Lighthouse Load Audit 无法发现所有缓慢 菜单、搜索、Filter、Checkout、Form Validation 或 Chat。用 Field Attribution 找出慢 Target 与 Interaction Type，再用 Dev工具 Performance 在受限硬件重现。
把 Long Task 拆开，并在紧急 UI Update 后 Yield，让 Browser 先 Paint；Analytics、Save、Spellcheck 等次要工作可以延后。小动作不要重新渲染庞大 DOM。Rendering 选择可参考JavaScript SEO 指南。
- 打开与关闭 Navigation、Mega 菜单、Dialog。
- 在 搜索 输入并使用 Filter。
- 展开 FAQ 或 Accordion。
- 验证和提交 Lead/Checkout Form。
- 接受与拒绝 Consent。
- 打开 WhatsApp、Chat 或 Embedded Tool。
- 在页面启动期间互动。
- 使用低端或中端 Mobile 环境。
- 记录 Target、Type、Load State 与三个 INP Subpart。
诊断整个 Page Lifetime 的 CLS
CLS 是根据可见内容移动多少与移动距离计算的 Unitless Score。它使用最差 Session Window，Shift 间隔为一秒，并以五秒为上限；不是只计算 Load Event 前的画面。
符合条件 User Input 后 500 ms 内的部分移动可以视为预期。滚动 与 Hover 不属于这类 Input，因此过程中发生的 Shift 仍可计入。CrUX 还能包括用户看得到、但 Page JavaScript RUM 不一定能观察的 Iframe Shift。
| CLS 来源 | 为什么移动 | 证据 |
|---|---|---|
| 没有尺寸的 Image/Video | Browser Layout 后才知道大小 | Layout Shift Track 与 Element Attribute |
| Ad/Embed/Widget | 迟到的 Creative 使用未知或不同高度 | Field Target、Slot Lifecycle、Provider Timing |
| 动态插入 Banner/Content | 新 Block 出现在已有内容上方 | Post-load 与 滚动 Flow |
| Web Font | Fallback 与 Final Font Metric 不同 | Font Waterfall 与 Text Shift |
| Animation/Transition | Layout Property 改变 Geometry | Dev工具 Rendering/Animation Trace |
| Back/Forward 或 Long-lived Page | Load-only Test 漏掉后续 State | RUM、pageshow 与完整 Journey |
预留空间并控制迟到内容，改善 CLS
为 Image 与 Video 提供 Intrinsic width/height 或正确 aspect-ratio。为 Ad 与 Embed 预留现实空间，并在周围内容稳定前决定 Empty Slot 是否收起。
使用 Metric-compatible Fallback Font 或 font-display 策略，合适时用 transform 与 opacity 做 Animation。Consent 或 Promotion 可以不推开内容的方式 Overlay，但必须 Accessible，也不能遮挡主要任务。
- 在 Mobile 与 Desktop 宽度加载每个 Template。
- 滚动经过 Lazy Image、Ad 与 Embed。
- 打开 菜单、Accordion、Filter 与 Validation Error。
- 触发 Consent、Promotion、Chat 与语言 UI。
- Cold Cache 和慢网路下测试 Web Font。
- 使用 Back/Forward Navigation。
- 检查 Hover 与 Responsive Breakpoint。
- 捕获移动的 Element 与真正造成移动的 Element。
把 Third-party Code 当作产品决定
Tag Manager、Ads、Consent Platform、Chat、Heatmap、A/B Tool、Social Embed 与 Video Player 都可能影响三个指标。Third Party 可以延迟 LCP Request，在互动时占用 Main Thread，或改变没有预留空间的 Container。
盘点 Owner、Purpose、Load Rule、Data Destination 与 Performance Cost。适合时等到 Consent、Idle、Viewport 或 Intent 才加载，预留 UI 空间，并移除 Duplicate Tag。如果业务保留高成本功能，应记录 Tradeoff，而不是用表面分数掩盖。
| 决定 | 问题 |
|---|---|
| 保留 | 它是否支持已衡量的用户或商业结果？ |
| 延迟 | 能否在 Consent、Idle、接近 Viewport 或明确 Intent 后加载？ |
| 限制 | 能否只在需要的 Template 运行？ |
| 替换 | 更轻 Provider 或 Static Preview 是否足够？ |
| 移除 | 是否未使用、重复、过期或没有 Owner？ |
| 监控 | 能否观察 Version、Load Failure 与 CWV Attribution？ |
修复 Platform Rule，不只修生成后的页面
WordPress 与 Page Builder 常见原因包括过大 Source Image、多个 Optimization Plugin、未缓存 HTML、Global Animation、太多 Font Variant、Slider Hero、Plugin JavaScript、重复 Analytics 与 DOM-heavy Component。先找到负责的 Template、Theme 或 Plugin Setting，不要在不知道原因前继续叠加 Plugin。
Custom Site 应把 Route Data、Image Component Default、Code Splitting、Hydration Boundary、CSS Delivery 与 CDN Caching 当作 Shared Rule。性能修改后仍要测试 Update、Form、Analytics、Accessibility 与 SEO Output。
| 症状 | Platform 层应检查 |
|---|---|
| 每页都有相同的大 Hero | Media Pipeline 与 Responsive Image Component |
| 未缓存首次回应慢 | Page Cache、Origin、Database 与 CDN Policy |
| Consent 后 INP 变差 | Tag Manager、CMP Callback 与 Vendor Script |
| 所有 Card 都 CLS | Shared Image Dimension 与 Skeleton Component |
| Staging 快、Production 慢 | Ads、Analytics、CDN、Personalization 与 Consent |
| 只有停用 Plugin 才改善 | 确认 Plugin 功能与替代方案，不长期盲目关闭 |
当聚合资料解释不了时，使用 First-party RUM
web-vitals Library 能收集与 Google Tooling 定义相近的 LCP、INP 与 CLS；Attribution Build 还能记录有用的 Debug Target 与 Subpart。建议收集 Route/Template、Metric ID、Value、Rating、Navigation Type、Release Version 与不含隐私的 Component Label。
在适合的 Lifecycle Point 发送，不要依赖不可靠的 unload/beforeunload。Sampling、Consent、Retention 与 Data Minimization 必须符合网站 Privacy Obligation。因为样本、Iframe、Browser API、SPA Attribution 与 Aggregation 不同，RUM 和 CrUX 不一定相同。
| RUM 字段 | 作用 | Privacy/Control |
|---|---|---|
| Template/Route Group | 找出 Shared Failure | 使用 Normalized Path，移除个人参数 |
| Release Version | 分开 Cached 与新代码 | 使用不含个人资料的 Build ID |
| Metric Value/Rating/ID | 正确汇总与 Deduplicate | 没有必要就不连接 Session Identity |
| Attribution Target | 定位 LCP/INP/CLS Component | 使用安全 Component Label，不收 User Text |
| Navigation/Device Context | 解释 Cold、bfcache 与受限旅程 | 只保留必要的粗略维度 |
| Business Event Link | 衡量任务成果 | 通过受管控 Analytics 与 Consent |
把性能优先级当作商业与 Accessibility 决定
先处理 Poor 再处理 Needs Improvement；如果 Audience 与问题主要来自 Mobile，就先 Mobile；先处理高价值 Journey 与 Shared Template，再处理低流量 Archive。还要关注 Average 掩盖的慢设备、Assistive Technology 与网络。
Performance Budget 是上线 Guardrail，不代表某个 Byte 数等于用户体验。根据已证实原因设置限制，例如 Hero Bytes、Third-party Execution、Route JavaScript 或 Layout Shift，同时保留 UX、Accessibility 与 Conversion Gate。
| 优先信号 | 这些情况优先级更高 |
|---|---|
| Status/Severity | Poor、反复发生、影响大量 Visit |
| Template Reach | 一个原因影响许多 Indexable 或 Transactional URL |
| Journey Value | Lead、Signup、Purchase、Reading 或 Support |
| Audience Risk | Mobile、受限设备或关键地区受影响较大 |
| Change Confidence | Trace 指向可控制 Root Cause |
| Regression Risk | 修复可 Staging、衡量与安全 Rollback |
运行可重复的 Field-to-fix Workflow
把 Evidence、Owner、Risk 与 Retest 结果放进SEO 审核流程。性能应成为受管理的上线纪律，不是偶尔清理 Plugin。
- 选择 Metric、Device、Date Range 与 Affected Group。
- 确认 URL/Origin CrUX Scope 与 Sample Limit。
- 把 Example 映射到真实 Template 与 Journey。
- 有资料时使用 RUM Attribution 或代表 Field Evidence。
- 在相近 Lab 条件重现 Route 与 Interaction。
- 确认 Element、Target、Shift 与 Metric Subpart。
- 追踪 Server、Network、Asset、CSS、JavaScript 或 Third-party Root Cause。
- 选择最小完整改变并定义 Success/Guardrail。
- 在 Staging 使用 Release Version 实施。
- 回归测试 Content、Accessibility、Analytics 与 Conversion。
- 风险较高时分阶段部署。
- 先监控 Lab/RUM，再等待 CrUX Window 才关闭问题。
用 Release QA 保护比分数更多的东西
| Gate | 通过条件 | 证据 |
|---|---|---|
| Content | Main Answer、Media 与 CTA 仍然有用 | Visual/Content Review |
| Accessibility | Keyboard、Focus、Label、Motion 与 Contrast 可用 | 人工 + 自动检查 |
| SEO Delivery | Status、Canonical、Metadata、Link、Image、Schema 正确 | Build/Crawl Sample |
| Analytics | Consent、Pageview、Conversion 不重复或丢失 | Debug + Production Event |
| Performance | 目标 Subpart 改善，其他 Vital 没有退步 | Matched Trace + RUM Canary |
| Resilience | Slow API、Third Party、Cache Miss 与 Error 仍可使用 | Failure-path Test |
| Rollback | 可以恢复前一版本与设定 | Release Record + Owner |
衡量改变，不夸大因果关系
记录 Release，并比较相同 Device、Template、Navigation Type 与 Business Cohort。即时 Lab/RUM 改变可以确认机制；CrUX 与 Search Console 会逐渐移动，因为 28 天 Window 仍混合上线前 Visit。
把性能接入SEO 衡量流程：追踪 CWV Distribution、受影响 URL、Impression、合作方式 与 Qualified Conversion。如果 Design、Content、Campaign 或 Ranking 同时变化，就不能简单声称“速度造成 Revenue”。
| 时间 | 证据 | 决定 |
|---|---|---|
| 上线前 | Baseline Distribution、Trace 与 Business Metric | 定义 Target 与 Rollback Threshold |
| 数分钟/小时 | Synthetic Check、Error 与 Canary RUM | 发现破坏或明显退步 |
| 数天 | 按 Template/Device 分组的 Versioned RUM | 确认真实用户 Root-cause 改善 |
| 接近/超过 28 天 | CrUX、PSI 与 Search Console Trend | 验证符合条件的 Aggregate Response |
| 持续 | Performance Budget 与 Release Monitoring | 防止复发 |
常见 Core Web Vitals 迷思
- “Lighthouse 100 代表每位用户体验都快。”
- “PageSpeed Insights 的 Field 与 Lab 数字应该一样。”
- “没有 CrUX Data 代表页面很快。”
- “Search Console 会报告每个 URL 的精确分数。”
- “优化一个 Example 就修复整个 URL Group。”
- “压缩 Hero 一定能修复 LCP。”
- “Total Blocking Time 等于 INP。”
- “页面加载完成后 CLS 就结束。”
- “Click 后的任何移动都会排除。”
- “Performance Plugin 能找出所有 Root Cause。”
- “移除 JavaScript 自动改善商业旅程。”
- “通过 CWV 就保证排名或转化。”
常见问题
2026 年的 Core Web Vitals 是什么？
Largest Contentful Paint、Interaction to Next Paint 与 Cumulative Layout Shift 仍是当前三个指标，分别衡量加载、反应与视觉稳定。
Core Web Vitals 是 Google 排名因素吗？
Google 表示 Ranking Systems 使用 Core Web Vitals，但没有单一 Page-experience Signal，强分数也不保证最高排名。
为什么 PageSpeed Insights 有两组数字？
Field Section 使用过去 28 天汇总 CrUX；Lab Section 是新的 Lighthouse Simulation，用于诊断。
为什么 Search Console 与 PageSpeed Insights 不同？
Search Console 使用相似 URL Group，并以最差指标定状态；PSI 有足够资料时通常显示单一 URL，否则使用 Origin。
Core Web Vitals 修复多久才会显示？
Lab 与 First-party RUM 可以马上改变。CrUX 是 28 天滚动聚合，旧与新体验会一直混合到 Window 更新。
每个页面都需要有 CrUX Data 吗？
不需要。新页面或低流量页可能不符合样本门槛。使用代表 Template、RUM 与 Lab，而且不要把“No Data”当成通过。
LCP 一定是 Hero Image 吗？
不一定。它可以是 Image 或 Text Element，也会因 Viewport 与用户状态变化。必须捕获真实 Candidate 与 Subpart。
页面加载快，为什么 INP 还是差？
INP 衡量整个访问的互动。Startup Task、菜单、Form、Filter、大型 DOM Update 与 Third-party Widget 都可能在画面完成后变慢。
为什么 Field CLS 比 Lighthouse 差？
真实访客会 滚动、打开 UI，也会遇到 Ads、Font、Embed 与 Long-lived State；Load-only Lab Test 未必执行。CrUX 还可能看到部分 Iframe Shift。
为了通过，应不应该移除有用功能？
应先衡量用户与商业价值。优先减少、延迟、隔离或替换真正成本，再同时衡量性能和任务结果。
官方参考资料
- Google 搜索 Central: Core Web Vitals and 搜索结果
- Google 搜索 Central: page experience in 搜索
- Google Search Console 帮助: Core Web Vitals report
- Google PageSpeed Insights: field and lab data
- web.dev: how Core Web Vitals thresholds are defined
- web.dev: Web Vitals measurement and tools
- web.dev: getting started with Web Vitals measurement
- web.dev: why lab and field data differ
- web.dev: debug performance in the field
- web.dev: optimize Largest Contentful Paint
- web.dev: optimize Time to First Byte
- web.dev: optimize Interaction to Next Paint
- web.dev: INP replaced FID as a Core Web Vital
- web.dev: diagnose slow interactions in the lab
- web.dev: find slow interactions in field data
- web.dev: optimize Cumulative Layout Shift
- web.dev: field measurement best practices
- Chrome Dev工具: Performance panel reference
- Chrome UX Report: methodology and eligibility
- Chrome UX Report: tools, cadence and granularity
分享受影响 Template、PageSpeed Result 与近期发布，我们可以分开 Server、Image、CSS、JavaScript 与第三方原因。
Google 排名如何演变：从 PageRank 到现代搜索系统2026年9月2日
Google AI 内容与 SEO：什么被允许、什么是垃圾内容，以及怎样安全发布2026年9月2日
Google Florida Update 2003：事实、理论与 SEO 教训2026年9月2日