第十五课 · 阶段四 技术 SEO
慢一秒、抖一下，用户就走了
页面快不快、稳不稳，是实实在在的体验。Google 把它拆成三个可量化的指标——Core Web Vitals（核心网页指标）。这一课认识这三个数，也把「它到底影不影响排名」这件事说清楚，不夸大也不忽视。
加载、交互、稳定，各测一件事
Core Web Vitals 目前是三个指标，各盯着体验的一个侧面：
首个视口中最大的符合条件的图片或文本块，多久呈现。它不等于整页全部加载完。回答：「主要内容多快能看到？」
衡量访问期间点击、轻触、键盘交互到下一次画面更新的响应表现，重点关注慢交互。回答：「操作跟不跟手？」
衡量页面生命周期中非预期的版面位移（如正要点的按钮突然被挤走），按位移的会话窗口计算。回答：「画面稳不稳？」
拖一拖，看每个数落在哪一档
每个指标都分三档：良好 / 需要改进 / 差。下面三条轨道是教学示意——拖动手柄，看数值落进绿区、黄区还是红区，感受一下各自的阈值在哪：
记住三个「良好」线就够用了：LCP ≤ 2.5 秒、INP ≤ 200 毫秒、CLS ≤ 0.1。注意 CLS 是个没有单位的分数（衡量位移比例），不是时间。
是「会被看的信号之一」，但不保证排名
这里最容易被人写错，我们用 Google 的原话来把分寸拿准：
- Core Web Vitals 会被 Google 的排名系统使用——所以它确实是个信号，值得做；
- 但没有「单一信号」：排名系统综合看很多与整体页面体验相符的信号，CWV 只是其中可量化的一部分；
- 所以拿到满绿也不保证排到前面——内容相关性、质量仍是根本。体验好，是让好内容不被拖累，而不是让平庸内容逆袭。
PageSpeed Insights 上方看真实数据，下方看 Lighthouse 诊断，别混成一个分数。常规 Lighthouse 加载测试不能直接测出完整访问的 INP，可用 TBT（总阻塞时间）等诊断线索定位脚本问题。新站或流量少的页面可能没有足够 field 数据；「暂无数据」既不是通过，也不是失败。还要看报告显示的是该 URL 还是整个来源站点的数据。
每个优化手段，主要帮哪个指标？
三个指标的毛病不一样，药方也不同。下面每个做法，主要改善哪个指标？点错会给提示：
速度之外：手机和渲染也要能读到内容
移动优先索引（mobile-first indexing）指 Google 主要使用移动版内容来索引。手机端应保留与桌面端等价的主要正文、标题、图片说明和必要标记；布局可以不同，内容可以合理折叠，不要为了手机「清爽」删掉关键答案。响应式页面通常更容易保持一致。
JavaScript 渲染是脚本运行后才生成页面内容。自己浏览器里看得到，不等于爬虫一定读到：不要让关键正文只能在点击、滚动或登录后加载，也别屏蔽必要的脚本资源。有站点权限时，用 Search Console 网址检查的实时测试查看渲染后的 HTML 与截图，确认主要内容、链接和 meta 指令正确；无权限时检查手机预览与源代码，将爬虫渲染状态记录为未验证。
点一点、填一填，检查你会了没
读报告，选一项最影响使用的问题
- 把一个公开页面放入 PageSpeed Insights，记录测试日期、移动端结果，以及是否有该 URL 的真实数据。
- 记录 LCP、INP、CLS 与数据范围；没有 field 数据就如实标记。查看实验室诊断，选一个具体问题，例如首屏大图过大、按钮响应被长任务阻塞或图片没有预留尺寸。
- 写出「现象—可能原因—拟改动—复测方法」。有站点权限时处理一项后用相同设备设置复测，并实际操作页面；field 改善要等数据窗口更新。对照手机与桌面主要内容，JS 页面另检查渲染后内容是否可读；无权限时交付检查清单，不改线上。