之前博客网站没迁移那会写过一篇关于如何使用GTmetrix免费给网站测速和分析网站加载问题过程的教程, 我自己之前也是一直用的GTmetrix比较多, 整体感觉他家这产品做的还是不错的. 最近想着博客迁移有些文章打算不要了, 而且新年新气象想着重新写更新下, 结果GTmetrix他这个免费账户的功能进一步限制了, 就很没意思.
索性就重新写一篇, 改用完全免费的Google Test Speed来带大家从头捋一遍.

确定测试对象

本来还想着偷个懒, 用以前案例中的网站来测, 结果他们的网站应该是整体重做了, 风格不同了, 网站效果现在也做得挺好的, 不再适合作为反面案例了, 得重新找一个.

这年头, 反面案例反而比正面案例难找呀, 毕竟做得不好的网站知名度也不见得高, 更难让人看到了.

想了一下, 之前有个人推过来一个网站让看看, 索性就用他的, 然后我自己这个新站, 也拿来测试一下, 看看还有哪里可以查漏补缺.

反面案例的网站会打个码保护隐私, 那我自己的站就没什么所谓, 因为现在也是新建, 很多细节还没有完善, 后期还会进一步更迭版本, 也可以作为一个整改参考.

直接开测

直接访问: Google PageSpeed Insights, 在输入框中输入想要分析的网址, 点击分析.
等待片刻, 结果就能出来, 整个过程完全免费, 不会存在GTmetrix那种想要看细节还需要开通付费套餐的情况.

反面教材网站测试结果:

我这个博客网站测试结果:

从图片上我们可以看到, 整个结果主要分为手机(移动端)和桌面设备(PC和平板)两个大的部分. 接下来我们将逐一解读各个部分的各项数据.

测试结果解读

移动端和桌面端的测试项都是大致相同的, 区分开来主要是为了测试网站的响应性.
我们将从性能, 无障碍, 最佳做法和SEO这4个大项逐一来查看这一份测试报告.

性能

先来简单解释一下性能区块的一些名词属性:

• FCP(First Contentful Paint): 页面首屏内容加载耗时
• LCP(Lagest Content Painting): 页面上最大体积的内容加载耗时
• TBT(Total Blocking Time): 灵敏指数, 指页面从开始呈现到用户可以交互所需耗时. 有些时候你会感觉页面很卡, 点不了, 这就是页面没有完全加载到用户可以进行点击等操作的步骤. 这样应该好理解一点
• CLS(Cumulative Layout Shift): 视觉稳定性指标, 用来衡量布局是否偏移的指标. 通俗来讲, 就是页面从开始加载到完全加载的过程中, 某些页面布局是否会发生变化, 这个加载过程是否足够快以适应用户需求. 有些急性子的人他在操作某些很熟悉的页面的时候比如说刚开始加载, 他就对准了某个按钮的位置来点击, 以实现快速跳转. 如果说加载过程中这个按钮的位置发生了变化, 那么用户的点击就有可能会落空, 这会给用户带来不好的体验.
• Speed Index: 用于衡量网页加载期间内容可视化显示的速度, 算是一个综合指标, 一个是SEO的优化, 以及网站服务器的响应速度.

首先这个测试的分值由各项加总得出, 鼠标移动在上面可以查看到每一个细项具体获得的分数以及该分数占所在项的大致比例.

这个图里面的结果区有两个链接, 分别对应下列两个功能:

• 计算性能得分: 点进去就是整个谷歌速度测试工具的文档, 可以了解每个指标的含义. 基础的指标我上面已经有简单解释, 想要详细了解的可以看看.
• 查看计算器: 这次测试计算过程详细的可视化和公式构成, 细化到每个步骤的加载和得分, 还可以模拟得分下的计算状况.

我们来看下反面案例结果图

他这个网站在加载方面存在比较大的问题, 从图片上看就是加载速度太慢了. 接下来我们再看下面细节部分, 具体是哪里需要优化.

数据分析

我们来具体看一下数据分析里面的细项, 每个细项还可以点开右侧的向下箭头来查看更细致的内容说明:

使用高效的缓存生命周期
这个站点没有向浏览器声明各类资源的缓存周期

改进图片传送
通过下拉箭头可以看到, 一些图片的尺寸和体积大小不符合SEO最佳实践. 图片太大影响加载速度, 一般我们都是在保证一定清晰度的前提下将图片压缩到100kb以下. 我一般会将图片格式转为WebP, 既能保证画质, 又能降低体积.

渲染屏蔽请求
这里面主要的问题就是脚本的加载妨碍了网页的其他可视元素的加载, 例如LCP. 这是在视觉上导致用户主观觉得网页加载慢的主要原因. 一般来说应该将一些可以延迟加载(Lazy Load)的脚本延迟加载, 优先让网页内容和可视化样式先加载.

这里就涉及到技术层面的优化了, 从文件上可以看出这个网站用的是bootstrap样式. 其实不管是Tailwind, Bootstrap, 还是像可视化编辑器的古腾堡, Elementor或者Divi Builder, 现在整体的优化都做得相对比以前好, 像有些基础的可以延后加载, 没必要全部加载的都做了优化的.

布局偏移原因
这个站还是稍微有点布局偏移上的问题, 不过看起来还好, 得分计减上不太严重, 说明影响不是很大. 这个方面有些如果做错的话, 很容易弄巧成拙.

这个方向用语言还是不太好说清楚, 这里贴一个视频给大家参考:

下面其他项看了下影响, 基本不是这个站问题的重点, 这里略过不谈.

诊断结果

谷歌这里的诊断结果就是相对于上面数据分析部分产生的问题给的优化建议.

这里第一个和第二个其实说明的是同一个事情: JavaScript脚本的加载用时太大了.
而且这还是一个第三方的脚本, 不应该安排在第一时间加载的. 如果是我的话, 可能会考虑想办法去替换掉脚本本身, 或者优化加载和效率.

另外, 这种报告一般我们优先看影响最大的部分: 先看体积和毫秒, 先针对性优化那些占用体积以及耗时大的问题项. 有些项目虽然列出来, 但暂时没有太大影响的可以先放一放.

无障碍

这个部分主要是影响用户体验和SEO实践的地方, 从理论上来看, 他没有第一部分"性能"中对于网站加载那么的重要, 但是也会影响收录和网页跳出率.

背景色和前景色没有足够高的对比度
这种就属于用户体验方面的问题: 有些人觉得还ok, 有些人觉得阅读太困难就跑了. 有些人单纯就是不喜欢你的网站风格也有.

一般来说, 这种还是应该去优化的. 从0到1规划一个品牌的话, 首先定品牌, 然后定LOGO. 网站主体色调和网站三原色应该根据LOGO和品牌的调性来定, 然后拓展到全站风格.

链接缺少可识别的名称
这里是alt文本没有做好, 常见的是链接锚文本, 按钮锚文本和图片锚文本, 这个是基础SEO应该做好的地方, 这里不再多讲.

表格和列表部分, 同样也是SEO范畴下的结构化数据(Schema)问题, 属于锦上添花的效果.

导航部分, 这个也是必要的: 主要的H1基本上应该排靠前, 后面其他的就可以随意点.

最佳做法

这里的错误就有点冤枉了: 使用了谷歌字体, 然后用了一个第三方镜像站来加载该字体, 结果镜像站挂了. 网站本身是部署了SSL的.

这里也很好解决, 更换字体, 或者本地部署字体等都是可选的解决方案.

下面的已弃用的API也是类似的原因, 应该立即去针对性优化掉对应的方向.
这个部分本来应该是很好拿分的.

SEO

这个部分基本没什么大问题了, 得分也是算OK的.

博客站测试对比

说实话我自己也是第一次测, 看到的时候我也是有点不爽, 因为无障碍这项太糟糕了, 看来现在用的这个wordpress主题还有待迭代.

从性能方面来看, 我这个主题的问题不大, LCP效率基于我用了相对便宜的服务器, 也算是可以理解, 但还有进步的空间.

相比正规的官网, 我这个文章瀑布流的首页可能会占点便宜, 因为官网一般首页会有些大尺寸的横幅banner插图之类的; 而我的博客需要加载的图相对要少一些.

关于无障碍
这个主题其实是我在Github上一个开源主题的基础上二次开发的, 有些地方细节原作者没有考虑更周全, 我现在的版本也是自己优化了很多细节, 比如移动端暗黑模式, 还有一些细节上的改动等.

对我来说, 这次测试也能为我提供一些细节上的优化指引, 对主题日后的更新提供方向.
后续可能也会针对这个主题在Github上做一个开源分享吧, 挺喜欢这种类似微信朋友圈的风格的, 但是配色这些还在考虑.

关于SEO
现在主要还是处于网站迁移阶段, 有些历史文章不打算保留但仍有流量的, 我自己的想法是直接写一篇新的来替换旧文章, 后续做301跳转. 所以当下没有做SEO优化, 所以测出来分数会低.

总结

其实谷歌的这个工具使用起来还是挺简单的, 主要是对每个细项的理解, 以及相应解决方案的实施.

还是之前那句话: 作为SEOer不要被这些看似深奥且麻烦的内容吓倒, 应该把我们的首要任务放在如何优化网站速度上, 而不是用在钻研这些词汇术语中.