Core Web Vitals 优化与网站速度：优化前后均可测量

Google 的阈值

以真实访问的第 75 百分位进行评估，移动端与桌面端分别计算。

• LCP，即主要内容的加载：2.5 秒或更短为良好
• INP，即对点击、触摸和按键的响应：200 毫秒或更短为良好；它于 2024 年 3 月取代了 FID
• CLS，即视觉稳定性：0.1 或更低为良好

实验室数据

Lighthouse、Chrome DevTools 或 WebPageTest 在模拟的、可重复的条件下加载页面：非常适合诊断问题并即时验证修复效果。模拟的页面加载不包含真实的交互，因此无法测量 INP，而是使用总阻塞时间（TBT）作为替代指标。

实际数据

来自真实 Chrome 用户的数据，可在 CrUX 报告中查看，并显示在 PageSpeed Insights 和 Search Console 中。这是 Google 所采用的数据，统计周期为 28 天，因此改进需要数周才能完全显现。

LCP

• 主图采用 AVIF 或 WebP 格式，尺寸合适，并设置较高的获取优先级
• 首屏可见的内容不使用懒加载
• 更快的服务器：缓存、CDN 或更好的主机

INP

• 拆分过长的 JavaScript 任务，并延迟加载非必要代码
• 审查第三方脚本：聊天组件、地图、像素代码及堆积的标签
• 在非常繁重的页面上精简 DOM

CLS

• 为图片、视频、广告和 iframe 预留空间
• Cookie 横幅不会推动页面内容移动
• 网页字体加载时不产生布局偏移

测量、修复、再次测量

• 按模板建立基线：首页、服务页、分类页、商品页
• 诊断每项不达标指标背后的原因
• 按影响与投入排定修复优先级，并在发布前测试
• 每次改动后进行实验室验证
• 持续 28 天的实际数据追踪，并在 Search Console 中验证

值得做，如果

• Search Console 将部分网址标记为较差或需要改进
• 您投放广告，而落地页在移动端加载缓慢
• 您的商店在商品页或购物车中速度较慢

不是当前重点，如果

• 您的实际数据已经良好，问题出在内容上
• 您希望仅凭速度提升排名：相关性更为重要
• 您即将重建网站：请在新项目中就考虑性能

报告与改动

• 按模板的基线报告，包含实际数据与实验室数据
• 按指标排序的原因清单
• 已实施并记录的修复
• 前后对比：交付时为实验室数据，28 天后为实际数据
• 为保持成效而设定的页面体积与脚本限制

一个模板，测量并修复

我们与您共同选择一个关键模板，例如商品页或广告落地页，修复其表现最差指标的主要原因，并在实验室中确认改进效果。需要 28 天的实际数据对比将安排在之后进行。范围与条款会在开始前以书面形式商定。