谷歌Core Web Vitals（CWV）查看及优化指南

Core Web Vitals (CWV) Google用于衡量用户体验的页面体验的标准之一，包含最大内容绘制 (LCP) 的视觉负载、累积布局移位 (CLS) 的视觉稳定性，以及首次输入延迟 (FID) 的交互性。

自2021年5月以来，移动页面体验和包含的Core Web Vital指标已正式用于对页面排名。截至2022年2月，PC段也已被使用。

衡量Core Web Vitals（CWV）的指标包括：

最大内容绘制 (LCP)，衡量加载速度
首次输入延迟 (FID)，用于衡量页面交互性
累计布局偏移 (CLS)，用于衡量视觉稳定性

每个Core Web Vitals（CWV）指标的阈值如下：

指标	良好的	需要改进的	不良
LCP	<=2.5s	<=4s	>4s
FID	<=100ms	<=300ms	>300ms
CLS	<=0.1	<=0.25	>0.25

一、Core Web Vitals（CWV）报告概览

查看网站指标的最简单方法是使用Google Search Console中的Core Web Vitals报告，想要直观了解自家网站的CWV表现，最便捷的方式是借助Google Search Console（GSC）中的CWV专项报告。该报告可以查看网站的状态（欠佳、需要改进、良好）、指标类型（CLS、INP、LCP）和网址群组（一组组类似的网页）分组的网址性能。

以下是Core Web Vitals报告的外观：

点击报告中的任意一项指标或状态分类，就能深入查看具体问题类型及受影响的URL数量。

若进一步点击某一问题，还能看到受影响页面的详细细分。多数CWV需改进的问题往往集中在某一类使用相同模板的页面上，只要针对该模板做一次优化调整，同类型页面的CWV问题就能同步解决，大幅提升优化效率。

二、深度解析Core Web Vitals（CWV）三大指标及改进方法

1、最大内容绘制（LCP）

最大内容绘制（LCP）主要用于衡量网页核心内容加载效率的指标，具体指网页加载过程中，“最大可视内容元素”（通常是主图、大段标题文本或核心信息区块）完全呈现到用户屏幕上所需的时间。

根据谷歌标准，LCP≤2.5秒为“良好”，但行业共识是越快越好，因为用户对加载速度的感知越流畅，留存意愿越强。但是LCP不测量整个网页完全加载的时间（如底部次要内容、隐藏的异步元素），不过能精准反映用户感知加载速度，网页最大元素往往是用户最关注的核心内容，其加载完成时间，基本与用户感觉页面已加载好的时间一致。

LCP的前身是首次有效渲染时间（FMP），后者曾用于衡量主要内容何时开始可见，但谷歌后续发现FMP数据稳定性差，不同设备、网络下波动大，无法准确反映用户体验，因此已从多数工具中移除，转而用LCP替代。

如何查看LCP？

在PageSpeed Insights中，LCP元素将在 “诊断” 部分中显示。请注意有一个选项卡可以选择LCP，它只会显示与LCP相关的问题，例如：

如何优化LCP？

从PageSpeed Insights（PSI）的检测结果来看，LCP是三大指标中最难优化的一项，因此这里建议大家需针对性突破：

（1）越小越快

删除未使用的冗余文件，如闲置的CSS/JS 脚本，或通过“tree shaking”（借助Webpack等工具）剔除代码中未调用的部分；对所有文件进行压缩：文本类文件（HTML/CSS/JS）用Gzip或Brotli压缩，图像用WebP/AVIF格式，在保证画质的前提下，体积比JPG小30%-50%。

（2）越近越快

数据传输延迟与用户到服务器物理距离相关，若网站服务全球或跨区域用户，建议部署内容分发网络（CDN），CDN在全球多个地区设边缘节点，缓存网站静态资源（图、JS、CSS），用户访问时会连接最近的节点，大幅减少传输时间。

中小型网站建议尝试CloudFlare等免费CDN加速服务商，提供安全且可靠的DNS服务，响应时间平均11毫秒，目前已覆盖超过330座城市，具备先进的安全性。

（3）尽可能使用同一台服务器

当你第一次连接到服务器时，浏览器需与服务器建立HTTPS安全连接，耗时约100~300毫秒），如果资源托管在多个服务器（如主站用A服务器，图片用B服务器），每次连接都需重复这一步骤。

因此核心资源尽量托管在同一服务器，若用第三方资源，可以通过<link rel=”dns-prefetch” href=”https://xxx.com”>（DNS预解析）或<link rel=”preconnect” href=”https://xxx.com”>（提前建立连接），让浏览器更早启动连接（DNS-prefetch 兼容性更好）。

（4）缓存优先

缓存能让资源一次下载多次复用，用户首次访问时，浏览器将静态资源（图、CSS）缓存到本地，二次访问时直接读取缓存，无需重新下载，二次加载速度可提升50%以上，对LCP优化效果比较明显。

（5）优先级调整

想要顺利通过LCP检查，我们应该优先考虑如何在关键渲染路径中加载资源，意思是重新排列资源下载和处理的顺序，应该首先加载让用户立即看到内容所需的资源，然后再加载其余的。

扩展阅读：

《WordPress速度和性能终极优化指南》

《如何有效提升Elementor网站速度》

2、首次输入延迟（FID）

什么是FID？首次输入延迟（FID）是是从用户与你的页面交互到页面响应的时间，也可以将其视为 “响应性”。根据谷歌标准，FID≤100毫秒为良好，用户基本无延迟感知。

举个例子，用户点击网页轮播的右箭头，FID测量的是点击瞬间到浏览器开始加载下一张图的时间，不关心图片最终加载完成需多久，只关注浏览器何时响应交互。

FID来源真实用户的访问数据，属于现场指标，可以准确反映实际体验，但是需收集大量真实日志才能获取。在实验室环境中，经常用总阻塞时间（TBT）和可交互时间（TTI）替代：

TBT：衡量首次内容绘制（FCP）到TTI之间的总时间，这段时间主线程被任务阻塞，无法响应交互，TBT越长，延迟越明显；
TTI：指页面看起来已加载到能流畅交互的时间差，如元素显示但点击无响应，就是TTI未到）。

并非所有用户都会与页面交互，因此有些页面可能没有FID值，这也是为什么实验室测试工具没有价值的原因，因为它们不与页面交互。很多用户可能想要查看的实验室测试是总阻塞时间 (TBT)。在PageSpeed Insights中可以使用TBT选项卡查看相关问题。

FID优化方法：

FID若不达标，可能需要减少浏览器主线程阻塞，需主要聚焦于JavaScript方面的优化：

（1）减少JS运行量与复杂度

浏览器主线程负责HTML解析、CSS渲染、JS执行，若JS体积大、逻辑复杂（如嵌套循环、频繁DOM操作），主线程会被长时间占用，导致交互延迟。可以删除未使用的JS代码，简化复杂计算逻辑（如用高效算法替代循环）。

（2）用预渲染转移浏览器负担

Vue等框架需加载大量JS才能渲染页面，会占用主线程。可采用预渲染让服务器提前生成静态HTML，如此一来用户访问时直接加载，而无需客户端JS渲染。

也可以采取拆分JS的方法，将长任务拆为短任务。通过 “代码拆分（Code Splitting）”（如 Webpack 按路由拆分），将 “执行时间超50毫秒的长任务” 拆成多个短任务，主线程执行完一个短任务后，会有间隙响应交互，避免无响应。

（3）部分JS迁移至Service Worker

Service Worker是独立于主线程的线程，可处理缓存、数据请求等非DOM任务。如果JS不涉及DOM操作（如接口请求），可迁移到Service Worker中执行，不占用主线程，从根本上避免阻塞。但需注意，Service Worker无法访问DOM，且缓存配置不当可能导致旧数据，需专业开发评估。

3、累积布局偏移（CLS）

累积布局偏移（CLS）是衡量网页视觉稳定性的指标，指页面从加载到交互过程中，所有布局偏移中最大的一次‘偏移突发’的分数，这里的“偏移突发” 是1秒内连续发生的偏移（最长可覆盖5秒）。

根据谷歌标准，CLS≤0.1为良好，用户基本无跳动感知；若大于0.25，页面会明显晃动，严重影响体验。例如当用户准备点击轮播箭头，此时底部广告突然加载，导致轮播下移50像素，用户最终点到文本，这种情况CLS分数通常较差，因为核心元素移动直接影响交互意图。

CLS的常见原因包括：

没有尺寸的图像
没有尺寸的广告、嵌入和iframe
使用JavaScript的内容注入
在加载后期应用字体或样式

如何查看CLS？

在PageSpeed Insights中选择CLS可以看到所有相关问题，主要是“Avoid large layout shifts（避免大的布局变化）”。

如何优化CLS？CLS优化的核心是提前为元素预留空间，避免加载后尺寸突变：

（1）图像优化

70%的CLS问题都是未指定尺寸的图像导致的。优化方案如下：

静态图像：在<img>标签中加width和height（如<img src=”cat.jpg” width=”640″ height=”360″>），浏览器会按比例预留空间；
响应式图像：用srcset配合固定宽高（如<img srcset=”puppy-1000.jpg 1000w, puppy-2000.jpg 2000w” width=”1000″ height=”1000″>）；
动态内容（如广告）：预留 “最大可能尺寸” 的空间（如广告高度波动200-400像素，按照400像素预留）。

（2）字体优化

字体加载时浏览器会先显示默认字体，再替换为自定义字体会导致文本尺寸变化。优化方案如下：

优先用系统字体（如font-family: -apple-system, BlinkMacSystemFont, “Segoe UI”, Roboto），无需加载，无替换；
自定义字体：用 “预加载 +font-display: optional”——<link rel=”preload” as=”font” href=”font.woff2″>提前下载，font-display: optional设置 100 毫秒窗口期，未加载完则用系统字体，后续缓存后再显示。

（3）动态注入内容

动态插入内容，如滚动加载的评论、弹窗会导致下方内容下移。可以在中间插入内容，如初始化时预留固定空白区域，加载后填充；悬浮内容（如顶部通知）用position: fixed/sticky定位，不影响其他元素布局。

三、Core Web Vitals（CWV）测量工具选择指南

谷歌提供多款官方工具，覆盖现场数据（真实用户）和实验室数据（模拟环境），满足不同需求：

1、核心工具解析

工具	核心功能	数据类型（移动+PC）	适用场景
Chrome UX 报告（CrUX）	提供全球Chrome用户的真实访问数据	现场数据	了解网站在真实环境中的整体 CWV 表现
Google Lighthouse	实验室环境下的深度性能分析，生成优化建议	实验室数据	开发人员迭代测试，定位技术问题
Google PageSpeed Insights（PSI）	整合CrUX与Lighthouse数据，输入网址即查	现场+实验室	快速评估任意网站的 CWV，新手首选
Google Search Console（GSC）	按URL群组监控自家网站的CWV表现	现场数据	网站所有者批量定位问题页面，跟踪优化效果

2、实际测量流程建议

（1）用PSI输入网址，查看移动端和PC端的CWV评级，判断是否需优化；

（2）若为网站所有者，通过GSC按“URL群组”筛选出 “欠佳/需改进” 的页面类型；

（3）用Lighthouse或web.dev（Web版Lighthouse）生成实验室报告，查看具体影响因素，详见《Lighthouse前端性能工具怎么样 Lighthouse插件使用教程》；

（4）优化后通过GSC跟踪近28天的CWV变化，确认是否达标。

四、Core Web Vitals在SEO的作用

谷歌的搜索排名体系包含超过200个因素，其中不少因素对排名的实际影响有限。对于Core Web Vitals，谷歌官方人员曾明确将其归为微小排名因素，也就是说，即便大幅优化Core Web Vitals，也很难看到排名有显著提升。

事实上，页面速度相关指标影响排名这一规则早已存在，因此2021年移动端页面体验更新推出时行业内并未预期它会对排名产生太大波动。更关键的是，页面体验更新的时间窗口内，谷歌还同步推出了其他核心算法更新，导致我们无法通过数据精准判断，某一页面的排名变化到底是由Core Web Vitals影响，还是其他核心更新所致。

虽然有部分行业研究指出Core Web Vitals表现与排名提升存在正相关，但我个人对这类结论持谨慎怀疑态度。就像专注做SEO的网站往往排名更好，一个愿意投入资源优化Core Web Vitals的网站大概率也在内容质量、外链建设、关键词布局等其他SEO关键环节做了更多工作。总体来说，Core Web Vitals的优化效果可能被其他SEO动作的影响覆盖，很难单独归因。