从症状入手，而不是从插件入手
一个页面可能响应很快，却仍然让人觉得慢。Time to First Byte（TTFB）衡量导航等待响应第一个字节的时间；Largest Contentful Paint（LCP）关注最大的可见内容；Interaction to Next Paint（INP）关注对点击、触摸和键盘操作的响应。改善其中一项，并不会自动改善其他各项。
这是一份诊断指南，而不是某个已测量客户项目的报告。请用你自己的前后对比数据来判断改动是否有效。
建立可比较的基线
- 选择有代表性的模板：一篇文章、一个分类、一个商品和结账页。同时包含已登录和匿名会话。
- 记录设备、网络、地点、URL、缓存状态和部署版本。在相同条件下重复实验室测试，而不是只挑最好的分数。
- 在 PageSpeed Insights 或 Search Console 中查看实测数据。流量较少的 URL 可能没有单独的数据；源站级别的数据范围更广，应如实标注。
- 区分缓存命中和未命中。热缓存下的快速响应，可能掩盖缓存失效或流量高峰时源站的缓慢。
安全地减少服务器工作量
在浏览器的“网络”面板中查看文档请求，然后分析 PHP、数据库查询和外部 API 调用。慢查询、重复的远程调用、进程饱和以及距离过远的源站，各自需要不同的解决办法。持久化对象缓存可以减少重复的数据库工作，但它与缓存完整的 HTML 响应不是一回事。
整页缓存对匿名访问的内容页面很有帮助。不要把账户页、购物车、结账页、已认证的响应或包含个人信息的响应放入公共缓存。请与托管服务商核对 Cookie、请求方法、查询参数和缓存键。在部署前用两个独立会话进行测试，并确认内容修改会让对应的缓存失效。
改善浏览器绘制的内容
在性能跟踪中找出实际的 LCP 元素。如果是图片，要让它的 URL 出现在初始 HTML 中，提供尺寸合适的版本，并且不要对它使用懒加载。如果是文字，请检查阻塞渲染的样式和字体加载。为图片和嵌入内容预留空间，以减少布局偏移。
对于 INP，请复现缓慢的交互并检查主线程。减少不必要的工作，拆分长任务，并在写入之前集中读取布局信息。把工作推迟到后续任务中，只有在那个任务本身不会变成另一个大块时才有帮助。
// Yield between bounded chunks; feature-detect the scheduling API.
async function yieldToBrowser() {
if (globalThis.scheduler?.yield) {
await globalThis.scheduler.yield();
} else {
await new Promise(resolve => setTimeout(resolve, 0));
}
}
// Process a small, measured batch, yield, then process the next batch.部署后验证用户体验
Core Web Vitals 的“良好”阈值为：按访问的第 75 百分位评估，LCP 不超过 2.5 秒，INP 不超过 200 毫秒，CLS 不超过 0.1。TTFB 有助于诊断，但它本身并不属于 Core Web Vitals。Lighthouse 的加载测试无法测量真实会话的 INP。
重新测试结账、导航、同意管理工具和第三方小部件。持续跟踪实测数据；滚动统计窗口不会立刻反映一次发布。把改动内容和任何回退情况与测量结果一起记录下来。
常见问题
通过 Core Web Vitals 就能保证排名更高吗？
不能。更快的体验对读者有帮助，也可能有助于搜索表现，但相关性、有用的内容和其他信号依然重要。请把速度当作一项可衡量的产品改进，而不是排名承诺。
TTFB 属于 Core Web Vitals 吗？
不属于。TTFB 衡量的是到响应第一个字节的延迟，有助于诊断服务器和网络链路。Core Web Vitals 指的是 LCP、INP 和 CLS。先用 TTFB 排查缓慢的响应，再分别检查有用内容何时出现以及交互表现如何。
为什么缓存的首页很快，结账却很慢？
公开的首页可以复用缓存的 HTML，而结账需要针对每个会话重新处理。请测量未命中缓存的请求，并检查数据库查询、扩展和外部服务。不要为了测试成绩好看而把结账页设为可公开缓存；要核实隐私和交易的正确性。
如何比较改动前后的性能？
保持 URL、设备、网络配置和缓存状态一致，并重复测试。记录结果的波动范围，并测试同一个用户操作。在实测数据可用时加以利用；一次快速的实验室测试并不能代表所有访客。性能检查清单提供了更完整的验证步骤。
参考资料与延伸阅读
继续阅读
使用 WordPress 提速 47 项检查清单扩展审计范围，或了解网站性能优化服务。
Leave a Reply