2026 年如何通过 Core Web Vitals
Core Web Vitals 是搜索给你做的一次公开体检：三个指标、三条达标线，在你的真实访客身上测量，并被计入 Google 的排名。进入 2026 年，标准没变——LCP ≤ 2.5 秒、CLS ≤ 0.1、INP ≤ 200 毫秒——但赌注变了，因为同一批速度信号，如今还决定着 AI 引擎能否在超时之前抓到并引用你。这份指南按问题真实发生的顺序，逐个拆解三个指标：它量的是什么、什么会拖垮它，以及能真正改动字段数据（而不只是实验室分数）的修复。
Core Web Vitals 是什么，2026 年要达到什么才算通过？
Core Web Vitals 是三个用户体验指标——LCP 管加载、CLS 管视觉稳定、INP 管响应。2026 年要通过，三项都得在真实访问的第 75 百分位上达标：LCP ≤ 2.5 秒、CLS ≤ 0.1、INP ≤ 200 毫秒。只要挂一项，整体就算不过。
LCP（最大内容绘制）量的是加载：从开始加载，到视口内最大的图片或文字块完成渲染所用的时间。它代表用户要等多久，才能看到这一页的主体内容。
CLS（累积布局偏移）量的是视觉稳定：页面加载过程中，可见内容意外移动了多少。你正伸手要点的按钮突然被挤走，就是 CLS 在扣你的分。
INP（下次绘制交互）量的是响应：从你点击、轻触或按键，到屏幕给出反馈之间的延迟。它于 2024 年 3 月取代了 FID，也是如今大多数站点最容易挂的指标。
『通过』指的是第 75 百分位——四分之三的访问都要优于达标线。换句话说，是你最慢那 1/4 用户的体验，定义了你的 Core Web Vitals 成绩。
- LCP（加载）≤ 2.5 秒——视口内最大的图文块完成绘制。
- CLS（视觉稳定）≤ 0.1——内容加载时可见元素不跳动。
- INP（响应）≤ 200 毫秒——点击与交互无卡顿地更新画面。
- 通过 = 三项都在真实访问第 75 百分位达标。
字段数据还是实验室数据——到底哪个决定你能不能过？
字段数据说了算。Google 用 Chrome 用户体验报告（CrUX）为 Core Web Vitals 评分——那是真实 Chrome 用户在 28 天滚动窗口内的匿名测量。Lighthouse 这类实验室工具只在一台机器上模拟单次加载，它们用来排错，不用来判定你是否通过。信字段数据，用实验室去解释它。
在你那台快电脑上，Lighthouse 跑出满屏绿，可能正好盖住中端手机上的糟糕体验——字段数据覆盖的设备和网络，是你的实验室测试永远看不到的。
Search Console 的 Core Web Vitals 报告，就是把字段数据按 URL 模式归了组——想最快看出哪套模板在挂、影响多少用户，就看它。
实验室数据依然重要，但它是显微镜，不是判决书——它复现单次加载，好让你追出到底是哪个资源或脚本拉高了数字。这只是完整技术 SEO 审计里的一层。
28 天窗口意味着修复不会立刻显现——先把改动上线，再在随后几周里看字段曲线怎么动，而不是反复刷新 Lighthouse。
- 字段数据（CrUX）——真实 Chrome 用户、28 天滚动窗口——才是 Google 的评分依据。
- Search Console 的 CWV 报告把字段数据按 URL 模式分组。
- 实验室数据（Lighthouse）只模拟一次加载——用来排错，不用来定判。
- 修复会在数周内反映到字段数据，而非即时。
LCP 不达标，怎么修？
当视口里最大的元素——通常是主图或大标题——超过 2.5 秒才渲染出来，LCP 就挂了。常见元凶有：服务器响应慢、渲染阻塞的 CSS 或 JavaScript、未优化或被惰性加载的主图，以及客户端渲染。要修的，是通往那一个元素的交付路径。
先从 TTFB（首字节时间）查起——如果服务器要一秒才响应，LCP 无论如何都快不了，所以 CDN、缓存和边缘渲染是第一根要拉的杠杆。
永远不要惰性加载 LCP 元素——给主图加 loading='lazy' 是最常见的自伤；应当反过来用 fetchpriority='high' 把它标成高优先级。
用 AVIF、WebP 这类现代格式输出主图，按容器尺寸裁好，并预加载它，让浏览器在解析完 CSS 之前就开始抓取。
渲染阻塞资源会拖住绘制——内联关键 CSS、延迟非关键 JavaScript、自托管字体，别让第三方服务器卡在你的关键路径上。
- 用 CDN、缓存和边缘渲染压低 TTFB。
- 永远不要给 LCP 元素加 loading='lazy'，改用 fetchpriority='high'。
- 把主图输出成 AVIF/WebP，按容器尺寸裁切，并预加载。
- 内联关键 CSS、延迟非关键 JS、自托管字体。
怎么止住布局跳动、通过 CLS？
CLS 量的是页面加载时可见内容跳动了多少，≤ 0.1 才算过。几乎每一次跳动，都源自没预留空间就加载的内容——没写尺寸的图片、插在既有内容上方的广告和嵌入、以及切换后导致文字回流的网页字体。要在内容填进来之前，先把位置占好。
永远给图片和视频设好 width 和 height（或 CSS aspect-ratio），让浏览器在文件到达前就把那块位置留出来。
用带 min-height 的容器为广告、嵌入和横幅预留空间——最大的跳动，往往来自一条晚到的广告把下面的一切顶开。
字体带来的偏移更隐蔽——回退字体切换成网页字体会让文字回流；font-display: optional 加上一个经 size-adjust 调过的回退字体，能让这次切换几乎无感。
除非是直接响应用户交互，否则不要在既有内容上方插入新内容——顶部弹出的 cookie 条或促销位，会把整页往下推。
- 给每张图片和视频设定 width/height 或 aspect-ratio。
- 用 min-height 容器为广告、嵌入和横幅预留空间。
- 使用 font-display: optional 和经过 size-adjust 的回退字体。
- 除非是用户交互触发，否则不要在首屏上方插入内容。
INP——如今多数站点最容易挂的指标——怎么修？
INP 量的是每一次轻触或点击，到屏幕绘制下一帧之间的延迟，≤ 200 毫秒才算过。它挂掉，是因为 JavaScript 霸占了主线程——长任务、沉重的第三方脚本、昂贵的框架 hydration，都会挡住浏览器去响应。把这些活儿拆成更小的块。
INP 于 2024 年 3 月取代 FID，且严格得多——FID 只量首次交互的输入延迟，INP 则盯住每一次交互，一直看到画面更新为止。
长任务是根因——任何运行超过 50 毫秒的脚本都会阻塞输入；把它拆开，并在块与块之间让出主线程，好让浏览器有空回应。
第三方脚本——标签管理器、聊天挂件、分析——是常见的罪魁；审一遍，把不关键的延后，其余的等首次交互之后再加载。
在框架站点上，hydration 是隐藏成本——为了让服务端 HTML 变得可交互，要下发并执行一大包 JavaScript；做代码分割、延迟，只对真正需要交互的部分做 hydration。
- 把任何超过 50 毫秒的任务拆开，并让出主线程。
- 审查第三方脚本，延迟或惰性加载非关键项。
- 对框架 hydration 做代码分割与延迟，只激活真正可交互的部分。
- 记住：INP 盯的是每一次交互，不只是第一次。
为什么页面速度还决定着 AI 引擎会不会引用你？
因为 AI 检索是有预算的。ChatGPT 和 Perplexity 在查询时实时抓取页面，会放弃那些又慢又重的；Google AI 概览取材的索引，本身就已被速度设了门槛。一个要六秒才渲染完的页面，就是一个赶时间的爬虫会直接跳过的页面。
速度一直是抓取信号——又快又稳的页面会被抓得更深、更频繁，于是它更多的内容进入了 AI 概览据以合成答案的索引。
让你通过 Core Web Vitals 的那套字段数据功夫，也让你的页面更省抓取和解析成本，从而把你留在生成式引擎真正会读的候选集里——这正是 GEO 的地基。
速度必要但不充分——再快的页面，也仍要匹配意图、答上问题，而这要从上游的能带来排名的关键词研究和可提取的答案式内容做起。
合起来看，性能如今是一笔面向两类受众的投资：它抬高传统排名，也决定着当模型在组织答案时，你是否根本可达——而这，正是你被 ChatGPT、Perplexity 与 AI 概览引用的方式。
- 实时抓取的引擎（ChatGPT、Perplexity）会放弃加载太慢的页面。
- AI 概览取材于一个早已被速度设了门槛的索引。
- 又快又稳的页面会被抓得更深、更频繁。
- 速度是必要而非充分——意图和可提取性仍是决定因素。
让智能体替你执行这套打法
免费开始