前几天,我和来自 Tim Kadlec (WebPageTest)一起对 CSS-Tricks 进行了一些性能测试。基本上就是使用该工具,四处探查,并找出需要改进的性能痛点。您可以在网站上观看此视频,或在他们的 Twitch 频道上观看,值得订阅以了解更多此类的性能调查。
Web 性能工作包括两个方面
步骤 1) 测量数据并探索问题
步骤 2) 解决问题
通过 WebPageTest 这个很棒的工具,我和 Tim 完成了很多步骤 1 的工作。我在我们四处探查的过程中做了笔记。我们发现了一些问题区域,有些问题相当严重!当然,在所有这些之后,我无法摆脱这些问题,因此我不得不立即采取行动并进行步骤 2 的工作,我很高兴地报告我已经完成了大部分工作并看到了改进。让我们深入了解一下!
发现的问题 #1) LCP 较差
最大内容绘制 (LCP) 是 核心 Web 指标 (CWV) 之一,目前每个人都在密切关注它,因为 Google 告诉我们它是一个 SEO 因素。我的 LCP 为 3.993 秒,这并不理想。

我从 Tim 那里了解到,如果首次内容绘制 (FCP) *包含* LCP,那是理想的。我们可以通过 WebPageTest 看到这种情况没有发生。
需要修复的事项
- 确保 LCP 区域(最终是一个大图像)已正确优化,具有响应式
srcset
并且托管在 CDN 上。尽管在其他地方有效,但这些事项在该特定图像上都失败了。 - LCP 图像上带有
loading="lazy"
,我们刚刚了解到 这不是一个好位置。
修复技术和学习
- 所有正确的图像处理内容都已到位,但由于某种原因,其中任何一项都不适用于
.gif
文件,而该图像在测试当天就是.gif
文件。无论如何,我们可能不应该在该区域使用.gif
文件。 - 关闭 LCP 图像的延迟加载。这是一个 WordPress 特色图像,因此我基本上必须执行
<?php the_post_thumbnail('', array('loading' => 'eager')); ?>
。如果是内联图像,我会执行<img data-no-lazy="1" ... />
,这会告诉 WordPress 它需要知道的内容。
发现的问题 #2) 首字节到开始渲染的间隔
Tim 立即发现这是一个相当明显的问题。

在上方的瀑布图中(这里有一篇关于阅读 Matt Hobbs 的瀑布图的超详细文章),您可以看到 HTML 大约在 0.5 秒内到达,但渲染的开始(人们看到的内容,粗绿色线)直到大约 2.9 秒才开始。这太久了。
该图表还以黄色线条标识了问题。我链接到一个第三方 CSS 文件,然后该文件重定向到包含自定义字体的我自己的 CSS 文件。此重定向会占用时间,并且正如我们所深入了解的那样,不仅会占用首次页面加载时间,还会占用每个页面加载,即使是已缓存的页面加载。
需要修复的事项
- 消除 CSS 文件重定向。
- 自行托管字体。
修复技术和学习
- 无论如何,我一直都在关注一些新字体。不久前,我注意到我非常喜欢 Mass-Driver 的许可创新(按员工数量定价),但我同样喜欢 MD Primer,所以我购买了它。对于正文类型,我坚持使用舒适的衬线字体 Blanco,幸运的是,它附带了优化良好的 RIBBI1 版本。下次我发誓我会找到一个可变字体,但是,有时你必须跟随你的内心。我购买了这些字体,现在正在自行托管字体文件。
- 直接在我的 CSS 中使用
@font-face
,无需重定向。还使用font-display: swap;
,但需要对此加载技术进行更多处理。期待size-adjust
。
在重新测试并进行更改后,您可以在大型文章页面上看到,在 4G 连接上,开始渲染速度提高了整整 2 秒。



发现的问题 #3) 网格指南上的 CLS 较差
Tim 有一个巧妙的技巧可以用来测量页面上的累积布局偏移 (CLS)。您可以指示 WebPageTest 为您向下滚动页面。这对于 CLS 来说很重要,因为布局偏移可能会因滚动而发生。
请参阅本文,了解有关 CLS 和 WebPageTest 的信息。
技巧是在测试期间使用高级设置将自定义 JavaScript 注入页面

此时,我们测试的不是主页,而是特意选择了一个非常重要的页面:我们的网格完整指南。有了这个设置,您可以看到 CWV 的状态要糟糕得多

我不确定对于 LCP 我该怎么想。这是由页面中相当靠后的最大图像触发的。

对我而言,CLS 更令人担忧,因为任何布局偏移对用户来说总是令人讨厌的。看到所有这些点状橙色线条了吗?这就是 CLS 正在发生的事情

需要修复的事项
- CLS 由于延迟加载的图像加载并导致布局偏移而变得糟糕。
修复技术和学习
- 我不知道!所有这些图像都是内联
<img loading="lazy" ...>
元素。我明白延迟加载可能会导致 CLS,但这些图像具有正确的width
和height
属性,这应该为图像保留加载前所需的精确空间(即使在灵活的情况下,也感谢纵横比)。所以……怎么回事?是因为它们是 SVG 吗?
如果有人知道,请随时告诉我。这就是性能工作的本质,我发现。它混合了来自愚蠢错误的简单胜利、你可以战斗并赢得的小战斗、有时涉及外部影响更难赢得的大战斗以及需要时间才能解决的神秘未知数。幸运的是,我们有像 WebPageTest 这样的工具来告诉我们网站上发生的真实情况,并为我们提供战胜这些性能挑战所需的洞察力。
- 我刚刚了解到,RIBBI 表示常规、斜体、粗体和粗体斜体。网络上大多数正文副本所需的经典组合。⮑
WordPress 可能是您延迟加载问题的原因。 本文讨论了延迟加载性能 并谈到了 WordPress 中的一个问题
是的,我也链接了它。我认为我们通过从主页最顶部图像中删除延迟加载来“解决”了 LCP 问题。
WordPress 仍然可能是 #3 的原因,因为它我认为并非完全留给 WordPress(Jetpack)中的原生延迟加载,但也涉及一些 JavaScript。我不知道它如何或是否相关,但它可能是一个线索。
我的新网站也遇到了同样的图像 CLS 问题。
即使有精确的宽度和高度,无论如何您都会得到轻微的 CLS。
我不确定这是否是 Chrome 的错误,但它显然违反了规范中所说的内容。
我什至尝试使用纵横比,但它也不起作用。
归根结底,我使用了旧的填充技巧,并解决了 100% 的 CLS 问题。
此网站上发布了如此多的酷炫内容,其中大部分内容我都想尝试实施,但我的该死的职业占据了我的所有时间。
感谢您提供精彩的内容。
关于SVG/CLS问题,我认为这是一个相关的Chromium Bug:https://bugs.chromium.org/p/chromium/issues/detail?id=1218055
错误报告确实使用了直接的svg嵌入,但问题仍然是忽略了设置的纵横比。
不过,有问题的SVG是
<img src="img.svg" ... />
感谢您提供的精彩内容。
虽然是一种变通方法,但您可以尝试通过在包裹所有SVG的<figure>元素上设置宽度和高度来解决SVG问题。您可能需要通过内联CSS来执行此操作,这也不是理想的选择,但肯定会解决CLS问题。