如何检查
网站速度

检查什么，以及应得到什么结果

网站速度检查应产出可复现的问题清单和相应的修复任务。彩色圆圈中的分数有助于比较不同测试，但单靠它无法解释访客为何迟迟看不到产品图片，或为何打不开菜单。本指南将从选择待测页面讲起，一直覆盖到修改后的复测。

为每种重要模板选一个网址：主页、服务页、分类页、产品详情页、文章页和联系页。再加入负载较大的场景，例如长图库、大型目录或含计算器的页面。如果要优化整个网站，应建立全部 URL 的台账，并标明哪些已逐页检查，哪些目前仅以同模板的代表页面进行测试。

为每个网址记录设备、日期、网站版本和页面状态：首次访问、再次访问、菜单已展开或筛选项已选择。未登录时测试公开页面，并不能证明用户中心的速度正常。应另行约定用户中心的访问权限和测试场景。

如何选择工具

初步检查使用 PageSpeed 和浏览器即可。要了解真实访客体验时再使用 Metrica；要验证特定假设时再增加其他实验室工具。进行付费测试前，应确认当前套餐支持的设置，因为可选地区和设备可能变化。

运行 PageSpeed 并保存检查结果

1. 在浏览器中打开PageSpeed Insights，输入待测页面的完整 HTTPS 地址，然后开始分析。
2. 等待分析完成，并确认最终 URL 确实指向待测页面。若跳转到了主页或占位页面，测试的含义就会改变。
3. 分别查看移动端和桌面端结果，保存报告链接及日期。
4. 在报告顶部确认是否有真实用户数据，以及数据范围是当前 URL 还是整个来源（origin）。
5. 在实验室部分记录 Performance 评分和各项指标值，再展开与表现最差指标有关的问题详情。
6. 保存报告列出的运行参数：Lighthouse 版本、网络限速设置及设备。复测时需要使用这些信息，才能保证结果可比。

检查记录中不要把四项评分合成一个结果。Performance、Accessibility、Best Practices 和 SEO 对应不同的自动检查项目。SEO 部分显示绿色，不能替代完整的索引审计；Performance 高分也不能证明表单咨询已成功送达。

如果工具报错，应将此次测试记录为未完成，不要把旧评分填入新记录。若提示服务过载，稍后再测；若页面无法访问，先在浏览器中检查 URL 和服务器响应。

为什么真实用户数据与实验室结果不同

根据PageSpeed 文档，实验室部分是在受控条件下进行的一次加载测试。CrUX 数据反映过去 28 天真实用户的体验。因此，今天发布的修复可能立即体现在新的实验室测量中，而真实用户统计会逐步变化。

如果某个页面的数据不足，工具可能展示整个来源（origin）的数据。该数据涵盖更多网址，不能证明所选页面的表现。如果完全没有统计数据，应注明“数据不足”，继续进行实验室测试并分析自有统计。仅仅缺少数据，既不代表通过，也不代表未通过。

前后对比时应同时记录两类数据，但要按各自的时间尺度进行评价。不要承诺发布当天真实用户统计就会更新。

除总分外还应记录什么

LCP、INP 和 CLS 的阈值属于Core Web Vitals。真实用户体验按第 75 百分位数评估，移动端与桌面端分别计算。常规 Lighthouse 加载测试如果没有用户操作，就无法测量 INP；TBT 可辅助诊断，但不能替代 INP。

根据Lighthouse 评分说明，Performance 由各项指标计算得出。处理建议通过改变这些指标影响评分，而不是以关闭了多少条警告来计分。指标构成与权重随版本而异，不要把旧文章中的公式直接套用到新报告。

如果 LCP 良好，但总分低于预期，应查看其他指标。例如，Speed Index衡量的是视觉加载进度；一个较大的内容块及时出现，并不能反映完整的加载过程。

如何比较 PageSpeed、GTmetrix 与多次测试结果

相同 URL 并不保证测试条件相同。测试服务器位置、浏览器、网络与 CPU 限制、引擎版本、缓存和第三方请求都可能不同。GTmetrix 解释了测量方法的差异，因此不能把两个总分直接视为等价。

打开 GTmetrix 报告，先查找测试运行条件，再与 PageSpeed 对照具体请求和加载阶段。如果条件不同，应借助报告查找原因，而不是直接认定“某个工具测错了”。

团队可在内部测试规范中约定：同一版本在相同条件下连续测量三次，同时记录中位数与取值范围。这是团队工作规则，并非 Google 要求。不要只挑最好的一次，也不要反复测试直到偶然出现 100 分。

结果波动较大时，应单独提出待验证的假设：外部组件过慢、服务器响应不稳定、返回内容不同，或缓存是否已预热。每次只改变一个因素。若同时启用缓存、压缩和新插件，就难以判断哪项有效、哪项导致页面故障。

如何在 Network 中定位延迟来源

1. 在 Chrome 中打开页面，再打开开发者工具并选择标签页Network。
2. 选择约定的网络配置。若单独测试首次访问，请启用Disable cache，并保持开发者工具打开，同时在记录中注明缓存状态。
3. 重新加载页面，等待主要内容出现。先找到文档请求，再检查图片、字体和脚本。
4. 打开较慢的请求，并进入标签页Timing。比较等待响应与传输数据分别耗费的时间，再查看Initiator，确认是什么发起了该请求。
5. 保存请求瀑布图（waterfall）截图和可疑资源的 URL。再把正常缓存条件下的加载作为单独场景进行测试。

这些界面控件的说明见Chrome Network 文档。单凭请求条很长，不能证明是主机问题。如果图片在脚本执行后才被请求，即使服务器很快，也无法消除图片被发现过晚造成的延迟。

向开发者发送 HAR 文件前，先检查文件内容及导出选项：网络数据中可能包含请求参数和已登录会话的信息。公开示例通常只需提供瀑布图截图，以及不含个人数据的具体资源 URL。

在 Metrica 和 Webmaster 中查看什么

在Metrica中，选择网站的统计计数器，再打开 Reports → Monitoring → Page load time（报告 → 监控 → 页面加载时间）。设置时间段，使用 View URL（浏览 URL）条件选择具体页面，然后比较设备、浏览器或地区细分数据。展开各个加载阶段，找到耗时增加的位置。

报告帮助文档介绍 DNS、建立连接、服务器响应及页面处理等阶段。默认使用 50% 分位数，也可自行调整，因此不能直接把它等同于 CrUX 的第 75 百分位数。应同时记录所选分位数、时间段与筛选条件。

实用流程是：先发现某个细分群体的体验恶化，再选择示例 URL，在浏览器中复现，最后才判断原因。不做细分的整体趋势可能掩盖某种重要模板的问题。

在 Webmaster 中，工具Server response check（服务器响应检查）可检查指定爬虫访问 URL 时的可用性、响应状态码及 SSL。输入页面地址、选择爬虫并运行检查。HTTP 响应成功不能证明浏览器渲染足够快；要判断渲染情况，还需使用 PageSpeed 和 Network。

如何把工具提示转化为待验证的假设

检查 LCP 时，可参考加载阶段拆解说明：服务器响应、资源发现与获取，以及资源显示前的延迟。压缩图片无法解决图片请求发起前的延迟。对于 CLS，应依据视觉稳定性建议检查空间预留。操作响应缓慢时，则需要在实际交互场景中进行INP 诊断。

不要只为优化报告而禁用图片、表单或统计功能。每次修改后，都应确认元素仍能完成其原本的用途。优先处理妨碍访客重要操作的问题，而不是机械地追求消除最长的一串建议。

如何提出比“让网站更快”更明确的需求

好的任务应包含观察到的现象、测试条件、证据和复测标准。不要预先断定原因：未分析文档请求就写“主机太慢”，可能把工作引向错误方向。

附上报告链接、标出相关请求的截图、日期及网站版本标识。另起一行写明预期标准，例如约定的指标阈值，或某项特定延迟已消除。如果原因尚不明确，应先安排诊断任务。

不同问题应分别列项，这样可以验收图片修复，同时保留尚未解决的筛选延迟问题。进行综合检查时，也可使用我们的网站验收指南。

发布后如何确认确有改善

先确认测试的是已发布版本；旧缓存或不同域名都可能彻底改变结论。复现最初的测试条件，然后走一遍用户操作流程。如果修改涉及共用模板，也要检查其他使用该模板的页面类型。

把修改前后的报告保存在一起。如果只有评分提高，但有问题的操作场景仍然缓慢，任务就尚未解决。若工具暂时不可用，应把测量项保留为待完成，并单独记录已完成的功能检查。

网站速度检查常见问题

如果需要测量、诊断和验收修改，可从网站技术开发入手。要把技术问题与搜索可见性联系起来，可使用SEO 审计与优化服务。关于不同屏幕下的界面检查，请阅读专题指南。