AI 建的站跑不动 Core Web Vitals，八成不是主题问题，而是生成结果里塞了未压缩的首屏大图、一堆第三方脚本，以及没有预留高度的动态组件。修的顺序应该是 LCP（目标 ≤ 2.5 秒）→ INP（≤ 200 毫秒）→ CLS（≤ 0.1），按这个顺序来，通常一半的工作量就能拿到大部分收益。
三个指标到底在量什么
| 指标 | 衡量对象 | 良好 | 需改进 | 差 |
|---|---|---|---|---|
| LCP | 最大内容元素的渲染时间（加载性能） | ≤ 2.5s | ≤ 4.0s | > 4.0s |
| INP | 页面上所有交互延迟的观测最大值（响应性） | ≤ 200ms | ≤ 500ms | > 500ms |
| CLS | 整个生命周期内的最大布局偏移爆发（视觉稳定性） | ≤ 0.1 | ≤ 0.25 | > 0.25 |
判定口径是第 75 百分位的真实用户数据，按移动端和桌面端分别统计——这也是为什么只看 Lighthouse 分数经常会误判。
LCP：先找到那个”最大元素”
LCP 元素在移动和桌面端往往不是同一个，先定位再优化，别一上来就全站压图。
- 首屏主图转 AVIF / WebP，并配好
srcset做响应式尺寸。 - 首图不要 lazy load。它恰恰是最该立刻加载的元素，给它
loading="eager"加fetchpriority="high"，必要时preload。 - 把 TTFB 压到 800ms 以内：页面缓存 + 对象缓存 + CDN，这一步决定 LCP 的天花板。
- 清掉阻塞渲染的资源：首屏关键 CSS 内联，其余延后；非关键 JS 加
defer。
INP：主线程被谁占满了
INP 高几乎都是 JavaScript 的锅，尤其是第三方脚本。
- 拆长任务：任何超过 50ms 的任务都会阻塞输入响应，用
scheduler.yield()或setTimeout切片。 - 第三方脚本延后：统计、聊天挂件、 A/B 实验脚本统一
defer/async，能晚加载就晚加载。 - 重计算丢给 Web Worker，别在主线程跑解析和排序。
- 先给视觉反馈：点击后立刻出 loading 态，让用户感知到”响应了”，虽然不改 INP 数值，但对转化的影响常常更大。
CLS：把空间提前留出来
CLS 是三项里最容易一次修干净的，核心就一句：凡是会晚到的元素，先给它占位。
- 图片、视频、 iframe 全部显式写
width/height，或用 CSSaspect-ratio。 - 广告位、公告条、 Cookie 提示先预留容器高度。
- 字体用
font-display: swap，并尽量缩小 fallback 字体与正式字体的度量差异。 - 不在已渲染内容上方插入新元素——这是最常见的误触来源。
AI 生成站点特有的三个坑
- hero 图直接用原图：AI 生成配图动辄几 MB，首屏一张图就把 LCP 拉到 4 秒以上。
- 脚本叠加失控：为了”看起来高级”，一次接了动画库、聊天机器人、两套统计，主线程被切得七零八落，INP 直接破 500ms 。
- 动态 banner 无占位：顶部通知条异步插入，把整页内容往下顶，CLS 一次就超标。
上线前用一张检查表过一遍：首屏图是否已转 WebP/AVIF 、首图是否 eager 、第三方脚本是否 defer 、所有图片是否有尺寸属性。这四项做完，多数 AI 生成站点的 CWV 就能进”良好”区间。
怎么看数据：Field 做决策，Lab 做诊断
- Field Data（真实用户）：Search Console 的核心网页指标报告、 CrUX，按 28 天滚动统计，这是排名用的数据。
- Lab Data（实验室）：Lighthouse 、 PageSpeed Insights 的诊断部分，用来定位具体是哪个资源、哪段脚本。
改完之后别立刻下结论：CrUX 是 28 天滚动窗口，生效需要时间，短期用 Lighthouse 的改动对比来判断方向对不对就够了。
- 用 PageSpeed Insights 打开首页，记录 LCP 元素是哪个、 INP 和 CLS 当前数值。
- 把 LCP 元素（通常是首图）转成 AVIF 或 WebP，配置 srcset，并改为 eager + preload 。
- 给全站图片补上 width/height 或 aspect-ratio，广告与公告容器预留高度。
- 把所有非关键第三方脚本改成 defer 或 async，能删的先删。
- 开启页面缓存与 CDN，确认 TTFB 降到 800ms 以内。
- 重跑一次对比数值，然后在 Search Console 里持续观察 28 天滚动数据。
相关阅读
LCP 、 INP 、 CLS 应该先修哪个？
按 LCP → INP → CLS 的顺序。 LCP 通常回报最快（一张图的优化就能掉一秒），INP 改动成本最高，CLS 最容易被一次性修干净。当然如果你的核心转化路径是表单提交卡顿，就该优先 INP 。
为什么 Lighthouse 分数很高，Search Console 却显示不达标？
因为两者数据源不同。 Lighthouse 是实验室模拟（Lab Data），Search Console 用的是 CrUX 真实用户数据（Field Data），后者才是排名依据。真实用户的设备、网络、地理位置差异，实验室模拟不出来。
首图到底该不该懒加载？
不该。首图大概率就是 LCP 元素，懒加载会让它更晚出现，直接推高 LCP 。懒加载应该用在首屏之下的图片上。
Core Web Vitals 对 SEO 的影响有多大？
它是确认的排名因素，但属于”体验类信号”——在内容质量相近时才起决定作用。更实际的收益在转化率：达标站点普遍能观察到 20%–35% 的转化提升和明显的跳出率下降。
评论 (0)