网站改版后 Core Web Vitals QA 检查清单

网站改版可能通过视觉 QA，却在性能上倒退。新的首屏媒体、动效、字体加载、追踪脚本、表单嵌入、CMS 组件和页面搭建模块，都可能让网站看起来更精致，但实际体验更慢。

这份清单适合准备上线新版营销网站、B2B 网站、Shopify 店铺、WordPress 主题或 headless commerce 前端的团队。建议在 staging 内容接近最终版本后、重定向表、分析追踪和上线日期完全锁定前使用。

Core Web Vitals QA 不应该从一个首页 Lighthouse 分数开始。先列出真正影响搜索、广告和收入的模板。改版网站的首页、服务页、集合页、商品页、博客页、案例页、联系页和活动落地页，性能风险通常并不一样。

每种模板至少选择一个相对轻的 URL 和一个真实偏重的 URL。偏重 URL 应包含正常图片、嵌入组件、表单、追踪、客户评价、相关内容，以及多语言站点里的本地化文案。这才是客户和搜索引擎上线后会看到的页面。

• 上线前至少覆盖 5 到 10 个重点模板 URL。
• 移动端和桌面端分开测试，因为实测数据会按设备类型评估。
• 给每个 URL 标记必须通过、只监控，或本次上线明确排除。

新版替换旧站前，先保留一份基线。抓取 PageSpeed Insights、Search Console Core Web Vitals、可用的 Chrome UX Report 数据，以及重点模板的实验室测试结果。目的不是让实验室数据和实测数据完全一致，而是知道上线后性能到底改善还是倒退。

记录当前 URL、计划目标 URL、设备类型、测试日期、LCP、INP 或 Total Blocking Time 这类实验室代理指标、CLS、页面体积、请求数和明显瓶颈。把性能基线和重定向表放在一起，方便上线决策同时看 SEO 风险和性能风险。

• 读取实测数据时看第 75 百分位，因为 Core Web Vitals 通常按这个口径判断通过与否。
• 每个必须通过模板保留一张瀑布图截图。
• 低流量页面没有实测数据时，明确记录不可用，不要靠猜。

Largest Contentful Paint 衡量加载表现。当前良好目标是页面开始加载后 2.5 秒内完成 LCP。改版网站常见的 LCP 倒退原因，是首屏图、视频封面、标题区、字体或第一张 CMS 图片比预期更重。

打开每个重点 URL，确认 LCP 元素到底是什么。然后判断这个元素是否必要、是否已经优化、是否以正确优先级加载。一个漂亮但过重的首屏，会让其他优化都显得吃力，尤其是在移动端和跨境访问场景下。

• 按照实际渲染断点压缩和裁切 LCP 图片，不要直接上传最大设计稿。
• 可视区域内的 LCP 图片不要 lazy-load，也不要放在很晚才执行的 JavaScript 后面。
• 检查字体加载，因为延迟的 webfont 可能拖慢首屏标题显示。
• CMS 页面还要检查服务端响应和缓存，不要只看前端包大小。

Interaction to Next Paint 衡量响应速度。当前良好目标是实测数据中的 INP 不超过 200 毫秒。没有用户输入的实验室测试无法完整测 INP，所以 staging QA 需要真实交互，再结合 Total Blocking Time 这类实验室代理指标判断风险。

按客户真实使用方式操作页面。打开菜单、筛选、折叠面板、语言选择器、购物车抽屉、搜索浮层、线索表单、价格切换、对比表和 Cookie 横幅。如果页面刚加载完的第一次交互明显卡顿，说明脚本仍在阻塞主线程，改版还没有准备好。

• 页面刚加载后测试一次，页面稳定后再测试一次。
• 优先检查每页都会出现的组件，例如导航、聊天、同意管理、分析追踪和表单。
• 首个用户动作不需要的脚本，应移除、延迟或按交互加载。
• 第三方组件单独记录，方便知道每个延迟问题由谁处理。

Cumulative Layout Shift 衡量视觉稳定性。当前良好目标是 CLS 不超过 0.1。改版常见问题包括图片缺少尺寸、Cookie 横幅把内容往下推、字体较晚替换、吸顶导航改变高度，或者应用组件在主布局显示后才插入页面。

不要只测默认桌面视口。请覆盖移动端、平板和桌面状态，并分别加载有无同意横幅、公告栏、聊天组件、嵌入表单、登录状态和翻译长文案的页面。很多 layout shift 只会在特定状态下出现。

• 为图片、视频、iframe、嵌入组件和商品媒体预留明确尺寸。
• 除非已经预留空间，否则不要在初始渲染后把横幅插到内容上方。
• 检查翻译后的长标题和按钮文案，避免换行后影响周围布局。
• 在较慢网络下复测，因为延迟资源会暴露快速 Wi-Fi 下看不见的位移。

当内容录入、分析追踪和利益相关方验收同时进行时，性能问题会越来越难修。上线冻结前，先盘点全站资源：分析、像素、热力图、聊天、预约组件、表单嵌入、评论组件、个性化、A/B 测试、字体、图片格式、视频嵌入和 CMS 插件。

每一项都要决定是全站加载、只在特定模板加载、同意后加载，还是交互后加载。这也是清理旧站遗留脚本的时机。改版不应该把没人负责的追踪和嵌入组件原样带到新站。

• 把每个第三方脚本映射到负责人、页面范围、业务目的和加载条件。
• 对字体做 subset，不加载最终设计系统里没有使用的字重。
• 不服务页面目标的装饰视频，优先改成静态封面。
• 确认图片组件能为 CMS 编辑生成响应式尺寸，而不只适配手工挑选的图片。

不是每个 URL 都需要相同的上线门槛。带来自然搜索收入的核心模板，应该比低流量法律页面有更严格的门槛。请提前定义什么问题会阻塞上线，什么必须在交付前修，什么可以上线后继续监控。

一个实用的规则是：必须通过的模板不能相对基线出现明显倒退，移动端可见问题上线前修复，所有只监控问题都必须有负责人和复查日期。这样性能 QA 才能进入上线管理，而不是变成没人处理的单独报告。

• 布局破坏、严重移动端 LCP 倒退、不稳定页头或无法使用的表单，应阻塞上线。
• 如果一个共享组件影响多个模板，应在交付前修复。
• 实测数据缺失或依赖真实流量的问题，可以上线后按计划监控。