GTmetrix 怎么用？看瀑布图和趋势，比只看一个分数更有用

先固定测试条件，再比较前后变化

不同测试地点、网络速度、设备和缓存状态会让结果差很多。优化前先记录测试位置和条件，再用同样设置复测，否则“从 70 分变 85 分”未必说明代码真的变快。

性能测试最怕“测一次就下结论”。同一个站点在不同时间、地点和网络条件下结果会波动，所以优化前最好先固定测试地点、设备条件和页面版本，至少记录几次结果。这样后面看到变化时，才更容易判断是代码优化带来的，还是测试环境本身在变。

打开 waterfall 可以看到每个请求什么时候开始、等待多久、下载多久。大图片、第三方脚本、字体、重定向和慢接口通常能在这里更直观地暴露出来。

实验室指标适合定位问题，但真实用户体验还受到设备、网络和地区影响。生产站点应结合 Search Console 或其他真实用户数据，避免为了某个测试分数做对用户没价值的优化。

GTmetrix 当前支持按日、周、月自动测试并查看性能历史，也可以设置告警。对经常发版的网站，这比偶尔手动跑一次测试更容易发现某次发布导致的性能退化。

PageSpeed Insights 更适合同时看 Lighthouse 与可用的 Chrome 用户体验数据；GTmetrix 更适合深入实验室请求链和多场景测试。两者结果不同很正常，关键是先确认你在回答哪个问题。

GTmetrix 更适合看资源加载顺序、请求瀑布和前后对比；PageSpeed Insights 则更适合结合 Google 的性能指标和真实用户数据理解问题。两者一起用时，不要追求分数完全一致，而是寻找重复出现的瓶颈，例如首屏图片过大、第三方脚本阻塞或字体加载过慢。

GTmetrix 会给出很多指标和建议，但不是每一条都值得优先处理。最有效的顺序通常是先看核心加载体验：首屏大图是否过重、主线程是否被长脚本占满、第三方代码是否过多、缓存和压缩是否明显缺失。

测试结果还会受测试地点、设备和网络条件影响，所以不要只跑一次就下结论。优化前后用相同测试条件重复几次，结合 PageSpeed Insights 或真实用户监测一起看，才能判断改动是否真的有效。

对于业务站点，性能目标也不应该脱离转化。删掉一个影响很小的脚本可能只能提高几分，而优化首屏图片、结账页或关键交互却可能直接改善用户体验。分数是线索，不是最终目标。