博客速度怎么检查？LCP、INP、CLS 的含义与改进方法

检查博客性能时，可以在 PageSpeed Insights 中分析公开网址，比较移动设备与桌面结果，并用 LCP、INP 和 CLS 分别判断加载、响应速度及布局稳定性。先区分真实用户数据与实验室诊断，再针对指标背后的原因改进，而不是只盯着一个性能分数。

LCP、INP 和 CLS 分别是什么？

Core Web Vitals，即核心网页指标，是 Google 用于衡量网页用户体验的重要指标。目前包含以下三项。三者都是数值越低越好，但衡量对象与单位不同。

Google 的 Web Vitals 指南采用第 75 百分位，并分别评估移动设备和桌面。通俗地说，是观察约 75% 的访问不超过哪个值。它不是平均值，也不是某次测试中最快的结果。三项都有充分数据时，必须全部达到良好才能通过；只有 LCP 良好并不代表整体通过。

一篇文章可能很快显示出来，但打开菜单时反应迟缓；另一篇可能交互流畅，却在广告出现时把正文挤到下面。应先确定哪一部分体验不好，不要对一个尚未明确的“速度问题”反复压缩图片。

运行 PageSpeed Insights 检查

1. 选择不登录也能打开的文章网址，排除编辑器与预览地址。
2. 在 PageSpeed Insights 中输入地址并运行分析。
3. 查看移动设备结果时，将真实用户体验与性能诊断分开阅读。
4. 再检查桌面结果，记录网址、日期、设备类别、表现不佳的指标和主要发现。

不要只检查最新文章，应选择有代表性的页面类型。普通文字文章、图片较多的文章，以及包含表格或代码的页面，有助于区分共用模板问题与个别内容问题。选择博客实际拥有的格式即可。

确认被分析的网址是否与输入的地址不同。如果重定向把测试带到了别处，之后比较时应使用相同的最终目标。保持记录一致，是为了判断修改效果，而不是让分数看起来更好。

区分真实用户数据与性能分数

真实用户数据来自 Chrome User Experience Report，简称 CrUX，覆盖此前 28 天。样本不足时，工具可能显示源（origin）级数据，也可能没有现场数据。源级数据汇总同一网站源下的页面体验，不只代表当前文章。实验室诊断则使用 Lighthouse，在模拟环境中测试。PageSpeed Insights 文档说明了两者的区别。

性能分数达到 90 与真实用户 Core Web Vitals 通过，是不同的评估。查看现场数据究竟针对单个网址还是整个源。没有数据既不证明性能良好，也不证明存在故障。

CrUX 的滚动统计周期与当前 Lighthouse 测试使用不同样本及条件。下图把两者提供的证据和用途分开，帮助判断修改后应该比较什么。

例如，更换图片可能立即改善实验室结果，但滚动的现场数据仍包含修改前的访问。应先确认新图片正常加载，并查看条件可比的测试是否出现改善迹象，再单独跟踪真实用户体验随时间的变化。

没有 INP 值不等于零毫秒。INP 数据不足时，只要 LCP 和 CLS 的第 75 百分位都良好，PSI 仍可判定通过；如果 LCP 或 CLS 数据不足，则无法评估。PSI 的评估规则说明了这一例外。不能只看通过标签，还要看实际有哪些数据。

LCP 不佳：找出主要内容迟迟不显示的原因

先确认报告认定的最大内容元素。它可能是文章顶部图片、大文本块，也可能是其他内容。不要在没有检查实际元素之前，给所有页面套用相同的图片设置。

• 如果是图片，比较实际传输尺寸与显示尺寸。
• 选择合适的尺寸、压缩和格式，同时检查必要细节及文字清晰度。
• 检查首屏 LCP 图片是否使用延迟加载。适合文章下方图片的设置，可能反而推迟主要图片出现。
• 如果诊断指出服务器响应或阻塞渲染的资源问题，也应调查这些原因。

LCP 优化指南区分了发现资源、传输资源和显示内容的延迟。如果适合调整格式，可阅读将图片转换为 WebP 的方法。修改后访问者仍收到旧文件时，应检查缓存及实际请求的资源。

展开诊断中的 LCP 时间分解，确认时间花在哪个环节。优先处理较大或可避免的延迟，不要对每个部分采用同一种措施：

1. Time to First Byte（TTFB，首字节时间）：从开始导航到收到 HTML 响应第一个字节的时间。检查服务器响应、重定向链与缓存使用情况。
2. Resource load delay（资源加载延迟）：收到上述响应后，到主要图片等 LCP 资源开始下载之间的等待。检查延迟加载或资源发现过晚的问题。
3. Resource load duration（资源加载时长）：下载资源本身所用的时间。合适的尺寸与压缩直接作用于这一部分。
4. Element render delay（元素呈现延迟）：文件到达后，到元素真正显示之间的等待。脚本或显示条件仍可能阻止呈现，因此仅缩小图片未必改善总 LCP。

如果 LCP 元素是无需额外下载资源的文本，就可能没有资源加载区间。应按照测试实际识别到的元素来使用这套分解方法。

INP 不佳：检查交互之后执行的工作

INP 评估从交互发生到下一次视觉更新的响应速度。长时间运行的 JavaScript 任务可能占据浏览器主线程，即处理脚本和屏幕工作的主要执行路径，导致输入处理延后。INP 优化指南分析了输入延迟、事件处理与呈现延迟。

博客运营者可以先在手机上重现实际操作：打开菜单、使用搜索、点击目录链接。记录哪项操作感觉迟缓，再检查该页面启用的不必要或重复功能插件、小工具和外部脚本。

基础 Lighthouse 页面加载测试中的 Total Blocking Time（TBT，总阻塞时间）可以提示长任务问题，但它不是 INP。INP 需要点击、轻触或键盘交互；只滚动阅读或没有交互的访问，可能没有 INP 值。还应区分按下搜索后的下一次视觉反馈，例如加载提示，与整个服务器搜索完成。INP 的定义与测量范围说明了这些限制。

不要一次停用很多插件。先准备备份或测试环境，一次只改一项，才能辨认效果。如果启用延后执行 JavaScript，除了看分数，还要确认菜单、搜索和同意控制功能仍然正常。

CLS 不佳：为可能移动的内容预留空间

晚加载的图片、广告和嵌入内容，可能挤动正文或读者正准备点击的链接。CLS 优化指南强调图片尺寸与预留后加载内容空间的重要性。

• 为图片提供 width、height，或预留合适的宽高比。
• 针对不同设备尺寸，为广告与嵌入视频安排适当空间。
• 检查未填充的广告位是否突然收起，从而制造新的布局移动。
• 观察字体或横幅出现时，文字与按钮是否移动。

布局偏移诊断中列出的元素不一定就是原因。在文章上方插入广告，可能让下方文章被记录为发生偏移的元素。应检查周围内容，以及紧邻上方新加入的元素。只测试初始加载，也可能漏掉滚动后才出现的广告或图片造成的偏移。因此还应浏览公开文章，并测试菜单与同意控制功能。

减少空白与保持布局稳定之间，有时需要取舍。不要假设桌面广告高度适合手机。打开实际文章，检查屏幕上部、中部和下部附近的移动情况。

在可比条件下重新检查

1. 保存原始设置、文件和测试结果。
2. 选择一个重要原因，进行针对性修改。
3. 刷新相关缓存，并在公开页面确认修改后的资源确实被使用。
4. 对同一网址、同一设备类别重新测试，然后检查菜单、图片、广告和文章布局。
5. 如果功能损坏或其他指标变差，恢复修改，再缩小原因范围。

修改缓存设置时，要区分提供已缓存资源与延后执行脚本。可参阅 WordPress 缓存插件的作用与选择方法。应记录能够恢复的设置，不要同时开启多项优化。

不要因为单次测试中的小幅差异就宣告成功。在下一次修改前，对比记录与反复出现的问题。如果提高分数的代价是破坏读者需要的功能，这种改善就没有实际价值。

速度分数本身不能决定搜索可见性。Google 的网页体验指南说明，排名系统会使用 Core Web Vitals，但指标良好不保证名列前茅。也应改善读者阅读文章和完成有用操作的体验。