网站上线前审核 Core Web Vitals
设定 Core Web Vitals 达标标准
审核应从为三项 Core Web Vitals 指标定义可衡量的发布标准开始：最大内容绘制（Largest Contentful Paint）、交互到下一次绘制（Interaction to Next Paint）和累积布局偏移（Cumulative Layout Shift）。良好的用户体验要求 LCP 不高于 2.5 秒、INP 不高于 200 毫秒、CLS 不高于 0.1。Google 会分别针对移动端和桌面端，按页面访问数据的第 75 百分位数评估这些阈值。应将其视为上线要求，而不是可选的优化目标。
在运行任何工具之前，先创建一份具有代表性的 URL 列表。列表应包括首页、每个主要模板对应的一个页面，以及产品页、定价页、结账页、注册页或潜在客户表单等高价值转化路径。对于一个由八种模板构建的 500 页网站，通常应针对这八种模板以及特殊页面进行更深入的测试，而不是对全部 500 个 URL 执行完全相同的检查。为每个样本记录模板、设备配置、测试环境、指标结果、疑似原因、负责人和复测状态。
在类生产环境中测试页面
应审核类生产构建版本，因为开发模式可能会使性能结果失真。启用上线时计划使用的相同配置，包括代码压缩、图片压缩、缓存、内容分发网络、重定向、分析工具、用户同意管理器和第三方脚本。确认测试页面没有意外提供未经优化的 source map、调试 bundle 或本地资源。通过身份验证或适当的索引控制阻止搜索引擎访问预发布环境，同时应使应用本身的配置尽可能接近生产环境。
网络位置和服务器配置同样重要。某个页面从靠近源服务器的办公室访问时，LCP 可能达到 1.8 秒，但对于位于另一大洲的移动用户，可能会超过 3 秒。应从目标受众所在的地区进行测试，并加入较慢的移动网络和 CPU 配置。热缓存和冷缓存测试结果应分别记录，因为首次访问者无法受益于浏览器中已经存储的资源。
结合 Lighthouse 与现场数据
使用 Google Lighthouse 或 PageSpeed Insights 进行可重复的实验室诊断，但不要把单一分数误认为完整证据。每个页面至少运行三次移动端测试，并采用中位数结果，因为不同次测试之间的网络和 CPU 条件会有所变化。应检查各项具体指标、瀑布图、主线程工作、阻塞渲染的资源以及布局偏移证据，而不要只关注总体性能分数。分数达到 90 分，仍可能掩盖业务关键模板中的某项失败指标。
真实用户数据反映了实际访客的情况，因此在可用时至关重要。PageSpeed Insights 和 Chrome User Experience Report 可能会按 URL 或来源级别展示滚动的 28 天视图，但新域名或新模板在上线前可能没有可用的历史数据。在这种情况下，可以比较当前网站上的等效页面，运行受控的 beta 测试，或针对发布前流量加入真实用户监控。请记住，实验室测试会估算 Total Blocking Time，将其作为有用的代理指标，而 INP 本身取决于真实用户交互。
诊断 Largest Contentful Paint
当 LCP 失败时，首先确定报告中被识别为最大可见内容项的确切元素。它通常是主视觉图片、产品照片、海报图片或大型标题，但瓶颈可能在该元素开始下载之前就已经出现。将该指标拆分为服务器响应延迟、资源发现延迟、资源加载时间和渲染延迟。这样的分解可以避免团队在真正问题是服务器缓慢或客户端渲染时，误去压缩图片。
对于以图片为 LCP 的页面，应使用尺寸适当的 AVIF 或 WebP 资源，提供响应式图片候选资源，并避免对首屏可见内容进行懒加载。仅对确实关键的图片进行预加载，在适当情况下设置较高的获取优先级，并确认浏览器能够直接从初始 HTML 中发现该图片。如果 HTML 响应耗时 900 毫秒，而主视觉图片在 1.4 秒时才开始下载，那么将图片解码时间减少 100 毫秒并不能解决更大的延迟问题。此外，还要测试需要身份验证、本地化和个性化的页面，因为它们的服务器响应路径可能不同。
测量 Interaction to Next Paint
INP 衡量页面在整个访问过程中响应用户交互并提供视觉反馈的速度。审计期间，不要只测试页面加载，还应点击菜单、筛选器、折叠面板、表单控件、搜索建议、加入购物车按钮和同意控制项。使用 Chrome DevTools 的性能录制功能来定位长任务和开销较大的事件处理程序。在桌面设备上 80 毫秒即可响应的筛选器，在中端手机上可能需要超过 250 毫秒，因为大型 JavaScript bundle 会阻塞主线程。
通过移除未使用的 JavaScript、按路由或功能拆分 bundle，以及延后加载非必要的第三方代码，来减少交互延迟。将 CPU 密集型工作拆分为更小的任务，使浏览器能够在这些任务之间处理输入并渲染反馈。只更新界面中必要的部分，而不是每次点击后都重新构建大型组件树。例如，更改一个产品筛选条件时，不应在显示选中状态之前，同步重新计算数百个隐藏项目。
查找并防止布局偏移
当图片、广告、嵌入内容、横幅或 Web 字体在初始渲染后改变布局时，通常会出现 CLS 问题。为媒体添加明确的 width 和 height 属性，或设置 CSS aspect ratio，使浏览器能够在文件到达之前预留空间。为广告和嵌入内容预留可预测的容器，即使当前没有可用的广告资源。尽可能将延迟出现的通知插入现有内容下方，而不是把导航、标题或购买控件向下推移。
通过完整的用户操作流程测试布局稳定性，而不仅仅是在页面加载最初几秒内进行测试。打开 Cookie 横幅，触发验证消息，切换筛选条件，加载更多结果，并等待延迟加载的促销组件。DevTools 可以突出显示发生偏移的区域，并将相关的布局偏移归为一组，从而更容易识别责任元素。即使单次移动看起来并不明显，小幅偏移重复五次也可能导致较差的累积结果。
执行最终技术 SEO 上线检查
修复部署完成后，使用基线测试所采用的相同 URL、设备、网络、位置和缓存条件重新运行测试。比较多次运行的中位数结果，并调查传输大小、请求数量、长任务以及服务器响应时间方面的回退。在常见的响应式断点进行测试，因为移动端模板加载的图片或脚本可能与桌面端模板不同。同时确认性能变更没有破坏规范链接标签、结构化数据、重定向、分析工具、无障碍功能或转化跟踪。
定义一个同时反映性能风险和业务风险的发布门槛。例如，要求每个关键模板在可重复的实验室场景中满足全部三个阈值；仅在有负责人负责的情况下允许记录在案的例外，并安排在上线 28 天后进行现场数据复核。将 Lighthouse CI 或其他自动化 Web 性能检查加入部署流水线，防止后续发布悄悄重新引入过大的图片或阻塞脚本。Core Web Vitals 为技术 SEO 提供支持，但最终的上线决策还应考虑可抓取性、可索引性、内容质量和功能测试。
延伸阅读
标签 :
- 技术 SEO
