GTmetrix, 这是一个业内很多大佬在用的在线测速网站, 在本文中我们将只使用这一个在线工具来对网站进行彻头彻尾(测头测尾, 哈哈 谐音梗)的测速.

对于很多SEOer来说, 应该聚焦于发现和解决问题, 工具再好再多, 往往也只需使用一个.

网站也是随便找的一个公司网站, 某天某招聘平台上主动发网址过来问我有没有意向, 当时大概看了一下, 站点无论是技术上还是内容上都存在很多问题. 像这种网站, 比较接近新手初期建站水平, 适合拿来做案例.

测试网站用的是一个做车用安防方案的网站, 为了避免可能的不必要的麻烦, 我会抹去站点地址.

一般来说, 我们的主要目标市场在哪里, 网站就应该尽量选择当地的服务器主机, 然后同时在服务器套餐上兼顾其他地区市场.

我们先用ChinZ站长工具来确定一下这个域名的服务器位置:

这里可以看出来这个网站使用的是 香港 的服务器主机.

域名服务器托管的物理地域位置很重要, 我们在下一步的测试里将优先选择中国香港线路, 这样测试出来的结果才中肯, 因为测试线路与网站实际存放位置越近, 延迟往往就越少, 加载速度相比之下就更快.

国内的网站就不要用GTmetrix这种工具的国外线路来测, 结果肯定不尽人意.
比如知乎, 本身是没有国外业务的, 服务器地址在河北石家庄, 用加拿大线路去测试, 结果甚至不如一般的外贸公司网站…

看, 这只是一个带登录表单的页面而已, 为什么得分会如此低

首先打开GTmetrix, 不注册可以直接使用, 注册是免费的, 而且注册后可以设置一些选项, 更方便我们进行测试.

网站是全英文站, 如果阅读有困难可以选择鼠标右键翻译来使用, 文章教程将基于英文原版+中文说明演示.

网站登录后的首屏是这样的:

1. 首先我们在图片中黑框的地址栏中填入需要测速的网站地址: br******.com;
2. 选择测试服务器的位置, 因为上面我们测出服务器位于香港, 这里选择香港;
3. 点击 Analyze蓝色按钮开始 测速

对于一般的测试而言, 我们不需要改动其他的数据了, 直接开始测速看看如何:

我们的目的不是测试这个网站, 而是以网站为例来分析GTmetrix各部分的功能, 以及出现的问题如何改进.

可以看出测试结果分为几个区块:

• Summary · 测试总结
• Performance · 性能表现
• Structure · 网站结构
• Waterfall · 直观查看网站各类元素加载速度
• Video · 慢回放直观查看网站加载的测试过程
• History · 历史测试效果对比

6大区块中, 我们只会重点用到前4个功能, 不过现在, 让我们先从GTmetrix Grade(测试评级)开始.

从上图看来案例网站整体得分相当差劲.

但我们的目的不在于查看得分, 而在于发现和改进问题, 所以对于分数这部分的原理直接跳过不聊(做好后面对应的优化分数自然就上去了, 而且分数高低不能说明问题.), 而关于 Performance & Structure 部分, 下文会有说明.

这是一个很重要的指标: Web Vitals 是对页面性能影响最大的关键指标.

LCP(Lagest Content Painting) · 页面最大内容加载用时

有时候英文翻译成中文, 翻译出来的内容是很难直接理解的.

网站页面上占容量最大的模块/元素是什么?

根据每个页面不同, 可能是图片、在线视频、在线音乐 或 其他内容.

以案例网站来看, 页面上最大的是它的首屏横幅大banner图片.

LCP计算的就是从输入网址回车那一刻到这个大banner完全展现在用户眼前的加载所需时间:

这张大banner图片的加载就花费了13秒.

他的图片看起来是没有经过优化的. 也就是说如果去掉或者优化好这张图片, 网站首页的加载速度可以大幅提升.

TBT(Total Blocking Time) · 脚本加载用时

出于用户体验考虑, 脚本的加载用时不应该超过150ms(毫秒).

从案例来看, 得分还不错.

从优化上来看, 尽量减少脚本的加载会有利于页面速度提升.

CLS(Cumulative Layout Shift) · 布局位移累计耗时

网页加载过程中是先加载文本、图片, 然后才到css. 所以当你网络不好的时候点开一个网站你可能发现是先加载的文字, 字体等样式后发生变化.

一般来说这是正常现象, 只要加载前后对应的文本、图像位置没有发生改变, 影响不大, 如果后面加载的内容导致前面已经加载的内容位置发生了变化, 这就叫布局位移.

布局位移累计耗时就是所有导致内容位置变化的加载总用时.

那么布局位移如何影响用户体验? 直接引用GTmetrix上的视频来形象说明.

这种因布局位移而导致用户错误操作的例子, 是网站最应该避免的.

在大多数情况下, 布局位移并不会出现如视频一样给用户带来糟糕的体验. 但如果可能的话, 尽量优化所有的布局位移.

Speed Visualization · 动态加载过程

这个阶段使用了一个幻灯片式的加载过程供我们大致了解一些基础信息:

TTFB(Time to First Byte) · 网站连通速度

从英文上来看意思是访问到第一个字节的时间, 可以理解为网站连通速度.

Redirect: 重定向时间, 0ms表示这个链接是解析到服务器, 没有经过重定向跳转.

Connect: 这个词大家都认识, 代表从测速节点到网站服务器主机的连接时间,如果这个数据过高, 那么就要考虑更换更好的服务器主机.

Backend: 后端持续时间, 也称为页面响应时间, 如果这个数据很长, 还有很多地方需要分析.

First Contentful Paint · 第一个内容加载

这个指标说明的是第一个内容(文字、图片等等)加载所耗的时间

Time to Interactive · 交互时间

什么是交互时间?
就是互动内容加载到网页上所花费的时间.

什么是互动内容?

谷歌的定义是对访问用户有用的内容, 比如文字、图片等等

Lagest Content Paint · 页面最大内容加载

这个在上面有讲过, 页面上最大容量的内容加载完成时间

注意我说的是容量而不是尺寸和体积, 压缩过的大图是有可能比没优化过的小图尺寸小的.

Onload Time & Fully Loaded Time · 加载完成时间

这两个指标有时并不一定相同. 但是他们都定义为网页的加载完成时间.

如果两者之间差别不大可以直接略过, 如果差别很大那么我们需要进行后续的加载项排查.

Top Issues · 首要解决的问题

这里列举的内容, 从影响程度(Impact)上来看, 分为 High > Med(Medium) > Med-Low > Low 4个级别.

同时我们也可以查看右侧的灰色框内的 “See all Structure audits” 来查看所有问题项目的检查情况.

当我们点开某个子项抽屉的时候, 下面会有对应的问题描述以及如何解决的方法, 大多数时候我们可以按照给出的指引来解决问题.

比如这个问题就只是一个图片没有经过压缩的问题而已.

对于我们SEOer来说, 一个958kb的图片, 整成100kb以内也就是分分钟的事, 虽然像这种问题严重性大, 但解决难度非常低.

既然我们选择了做外贸做SEOer, 那么就不能给自己找借口. 有工具能够免费为我们检测能够给我们提供可参考的解决方案, 就要尽量用起来, 英语不行就翻译, 解决不了就多问问题, 总能解决的.
每个网站的问题可能都不同, 我们很难找到全中文讲解所有网站可能存在的问题, 毕竟不同问题的案例也难找到.

说实话我也是偶然看了一下这个网站才想到去写这样的内容.

Page Details · 页面资源情况

从这里我们可以更直观的看到, 使用香港测试线路来测试加载这个页面, 完全打开居然花了20.8秒! 这应该是网站首先要解决的问题了.

如果淘宝.com打不开, 我们可能会怀疑是不是自己的网络出问题了;
如果一个不知名的网站打不开, 我们首先会怀疑是不是这个网站有问题.
所以当我们还是默默无闻的时候, 做好自己尤其重要.

从下面两项来看, 也可以看出一些问题:

Total Page Size · 页面总大小

一个网页9mb, 国内的朋友可能没有什么很大的概念, 毕竟现在U盘动辄几百g, 网速分分钟千兆, 但是你要想一想:

我们做外贸网站是要面对全球的访客, 每个国家的基建情况都不一样, 有很多国家是比不上中国国内的网络环境的, 这些人用1~2m小水管来加载你这么大的页面, 加载速度一定快不了了, 很多客人往往没有那么有耐心等待网页加载, 漏斗原理的第一步你的漏斗就比别人小了几圈, 获客范围就更小了.

Total Page Request · 页面总请求数

这里面多张大容量的图片占据了主要核心71.1%, 其余的一个问题就是JavaScript脚本占据请求过多.

图片是肯定可以优化的, JS脚本需要酌情考量, 看具体是哪些占用较大, 分别是实现哪些功能, 然后进行考量和取舍, 因为每个网站情况不同, 这是没法一刀切的.

我截取了一个手头上的网站结果供对比参考:

不是让你看分数, 而是对比参考下页面构成大小占比以及类型.

More from GTmetrix · 来自GTmetrix的建议

这里是一些参考和建议, 我就不截图了, 第一条往往是广告, 因为他们也提供付费优化服务, 其他的大致看看就好, 我们主要还是从其他细节里面看具体问题.

以上就是测试总结部分内容, 下面我们来看性能部分:

图片上绿色显示Good的部分属于良好, 我们需要重点关注红色部分. 右上角的 Metrix details 开关可以打开.

由于每个网站设计排布内容和功能都不一样, 所以只要保持绿色Good就可以,

每个人测试出来的数值都不一样, 因为测试的内容也不一样, 因此测试结果也就存在很大差异
比如有些人的Time to Interactive可能是图片/视频/文字, 这些不同容量的内容肯定会加载时间导致存在差异, 只要满足范围内就好.

将鼠标移动到对应区块的 “?” 问号中可以查看到帮助指引以及对应项目的推荐优化时间.

这些项目都是我们在上文中有提到并解释过的项目

比如这个 Speed Index(速度指标)
How quickly the contents of your page are visibly populated.
A good user experience is 1.3s or less.

翻译过来就是:

页面内容可视化加载所耗时间. 好的用户体验加载时间是1.3秒甚至更少.

而这里的加载时间是9.7s, 结合上面我们发现的图片容量情况, 首要目的肯定是优化替换压缩后的图片, 再来重新测试一下, 看数值在什么位置, 然后再看其他问题.

不过此时我建议你先完整看完其他问题在总结归纳一并处理.

下面的这个 Browser Timings, 同样的, 很多项目在测试概括部分已经有提及, 而且这部分的项目对我们的性能得分没有直接影响, 同样的, 这部分内容也会因为网站不同数据跨度往往也比较大.

这里其实就是对于 测试总结部分 的 Top Issue 上的问题的进行全部展开.

我们尽量把 High > Med > Med-Low 的问题依次解决掉, 根据颜色深浅来决定处理先后顺序

如果我们展开来看, 会发现其实排在最前面的3个问题其实是一个问题: 都是图片容量大小惹的祸

对于页面提及的问题, 针对性解决就好.

下方的灰色框, 左边是对于上述审计问题的解释, 右侧则是他们的付费优化广告. 个人感觉没必要用, 不推荐(最主要的是他没有给我广告费doge).

这个横向柱状图像瀑布一样从少到多冲刷下来, 利用这张动态图表我们可以查看具体是哪些页面元素影响了网站加载的速度, 在某些方面来看, 图表往往比文字更具直观性.

这张图表从左到右依次为:

• URL: 文件名 & 文件路径, 比如说图中的1648458760.jpg, 这就是一张图片
• Status: http响应状态, 返回200表示成功, (failed)表示请求失败, 鼠标移动到上方会出现说明, 比如图片中的 net::ERR_HTTP2_PROTOCOL_ERROR 200 就存在多种可能, 需要查验分析后判断
• Domain: 就是我用马赛克遮挡住的地方, 是加载文件的位置, 一般来自域名服务器或CDN, 也有来自GTM和GA的统计 & 分析代码
• Size: 对应元素的文件大小, 当你看到一个较大尺寸的内容时, 应该优先考虑是否可以对其进行优化, 因为页面总大小越低加载速度往往越快.
• Timeline: 加载时间线分解, 这个地方需要展开来说明

这两个功能用的其实并不多:

Video 就是把测试总结部分的Speed Visualization(动态加载过程)用视频方式展现出来, 可以更为直观地看到是页面在哪些元素/状态下进展缓慢.

History 会将我们每一次使用GTmetrix对该网站进行测试的时间以及状态记录下来, 用图表的形式供我们查看测试之间的数据变化, 通常用于我们优化了相应的问题后和优化前的进行比较.

我知道对于新手而言, 这里面有太多太复杂的简写缩写以及专业术语, 我也试图用中英文并列的形式来尽量让大家能够在页面上找到对应的选项.
需要注意的一点是, 我们作为SEOer不要被这些看似深奥且麻烦的内容吓倒, 应该把我们的首要任务放在如何优化网站速度上, 而不是用在钻研这些词汇术语中.