前几天，我和WebPageTest的Tim Kadlec一起在CSS-Tricks上做了一些性能测试。基本上是使用该工具，四处探查，并确定要解决的性能痛点。你可以在网站上观看这个视频，或者在他们的Twitch频道上观看，那里值得订阅更多像这样的性能调查。
网络性能工作有两个方面：
第1步，测量事物和探索问题
第 2 步 ，修复它
Tim和我，通过WebPageTest这个神奇的工具，做了很多步骤1的工作。我一边做着笔记，一边四处打探。我们发现了一些问题区域，有些问题相当大当然，在所有这些之后，我无法把它们从我的脑海中抹去，所以我必须立即行动起来，尽快做第二步的工作，我很高兴地报告，我已经做了大部分工作，并看到了改进。让我们深入了解一下
发现的问题#1）LCP不佳
Largest Contentful Paint(LCP)是Core Web Vitals(CWV)之一，现在每个人都在仔细关注它，因为谷歌告诉我们它是一个SEO因素。我的LCP的时间是3.993秒，这不是很好。
WebPageTest清楚地告诉你你的CWV是否有问题。
我还从时间上了解到，最理想的情况是第一张内容丰富的图片（FCP）_包含_LCP。我们可以通过WebPageTest看到这一点并没有发生。
要解决的问题：
- 确保LCP区域（最终是一张大图片）被适当优化，有一个响应的
srcset，并且是CDN托管。所有这些东西在那个特定的图像上都失败了，而在其他地方却正常。 - LCP图片上有
loading="lazy"，我们刚刚知道这不是一个好地方。
修复技术和经验：
- 所有适当的图像处理方法都到位了，但不知什么原因，这些方法对
.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的许可创新（按员工人数定价），但我同样喜欢MDPrimer，所以我买了那个。对于体型，我坚持使用舒适的衬线字体Blanco，幸运的是，它有非常好的优化的RIBBI1版本。下一次，我发誓我会找到一个可变的字体，但是，嘿，有时你必须跟随你的心。我购买了这些字体，现在正在自行托管这些字体文件。
- 使用
[@font-face](https://css-tricks.com/snippets/css/using-font-face/)就在我自己的CSS中，没有重定向。也使用[font-display: swap;](https://css-tricks.com/almanac/properties/f/font-display/)，但要在加载技术上多下点功夫。不能等待[size-adjust](https://web.dev/css-size-adjust/).
在重新测试了这个变化之后，你可以看到在一个大的文章页面上，在4G连接上开始渲染的时间整整快了2秒。
这是一个巨大的变化。特别是它也影响到了缓存的页面加载。
看看在没有CSS重定向的情况下，瀑布是如何拉回左边的。
识别的问题#3）网格指南上的CLS是坏的
蒂姆有一个巧妙的技巧来测量页面上的累积布局移动（CLS）。你可以指示WebPageTest为你向下滚动页面。这对于像CLS这样的东西是很重要的，因为布局移动可能是由于滚动而发生的。
诀窍是在测试过程中使用高级设置将自定义的JavaScript注入到页面中。
在这一点上，我们不是在测试主页，而是有目的地测试一个非常重要的页面：我们的《网格指南》。有了这个，你可以看到CWV的情况要差很多。
我不知道对LCP到底该怎么想。那是由恰好是最大的图片引发的，在页面的相当远处。
我并不十分担心有滚动功能的LCP。那只是一些像页面上其他图片一样的图片，被懒散地加载。
对我来说，CLS更令人担忧，因为_任何_移动的布局都会让用户感到厌恶。看到所有这些橙色的虚线吗？那就是CLS的发生。
橙色的CLS线与图片的加载相关（当页面向下滚动时，懒惰加载的图片就会出现）。
需要解决的问题：
- CLS是坏的，因为懒惰加载的图片进来了，并改变了布局。
修复的技术和经验：
- 我不知道!所有这些图片都是内联的
<img loading="lazy" ...>元素。我知道懒惰加载_可能_导致CLS，但这些图片有适当的width和height属性，这应该是在加载前就为图片保留了确切的必要空间（即使是流体，由于长宽比的原因）。那么......是什么原因呢？是不是因为它们是SVG？
如果有人知道的话，欢迎来找我。我发现，这就是性能工作的本质。这是一个从愚蠢的错误中轻松获胜的混合体，你可以打赢的小仗，有时涉及外部影响的更大的战役，很难获胜，以及需要时间来治愈的神秘的未知因素。幸运的是，我们有像WebPageTest这样的工具来告诉我们网站上发生的真实故事，并给我们提供我们需要的洞察力来打这些性能战。
