场地-速度地形-一一网

几年前，我在一个新的网络性能项目上的最初几天总是进展缓慢。那么多错误的开始，乏味的工作流程，以及完全缺乏的效率，真的让我难以找到动力。为了解决这个问题，我在我的武器库中引入了一个新的工具，这样我就能更快地进入状态，并更快地给我的客户提供答案。

当第一次从事一个新的网站速度的工作时，你需要迅速找出慢点、盲点和低效率的地方。除非客户雇用你来专门改善一个页面的性能，否则你需要对整个网站或应用程序有一个广泛的了解。以前，我可能会看一下谷歌分析，或者如果客户已经有了RUM解决方案，但这只对我显示特定的异常值有用，而不一定是整个项目的任何模式。

见第6条。谷歌分析可以向我们展示个别缓慢的页面，但不一定能帮助我们建立一个网站整体的大画面。

不仅如此，谷歌分析在默认情况下，只报告加载时间，现在在性能优化领域，这几乎是完全多余的。

我需要一个更全面的方法来可视化整个网站的性能，而且–最好是–比加载时间更有用的东西。

识别页面类型

对整个网站进行可视化有点矫枉过正，特别是考虑到许多网站可能会有数万个页面。相反，对于世界上几乎所有的网站，我们可以做的是将项目分割成页面类型。这些页面类型通常也会对应于代码库中的不同模板。例如，我的网站有一个主页、内容页（例如我的关于页）和文章页，就像你现在正在阅读的这篇文章；一个电子商务网站会有一个主页、一个产品列表页（PLP）、一个产品细节页（PDP）和一个搜索结果页（SRP）。

通过捕捉和比较这些页面的行为，我们可以立即开始建立整个网站状态的代表性图片。虽然我们可能无法通过这种方式捕捉到异常值，但如果需要，我们仍然可以将这些异常值作为一个单独的工作体进行审计。

在文章的其余部分，我将对我的一个匿名的电子商务客户进行审计，但你可以轻松地把我的页面类型换成你自己的。

收集数据

如果一张图片胜过千言万语，那么一个瀑布就胜过一千张图片。让我们从黄金标准开始：WebPageTest。

当你用WebPageTest运行一个测试时，你会得到这个不同里程碑和指标的表格。我们感兴趣的是前七个技术计时，即_第一个字节_到_总阻塞时间_。

WebPageTest提供了大量的洞察力，但现在我们不需要比这更深入地了解。

我们现在需要做的是为我们的每个页面抓取这些信息，并将其粘贴到电子表格中。如果你想要一份我所使用的精确电子表格，你可以在这里得到它。

注意最下面一行显示的是测试结果的标准偏差。较高的方差意味着各页的指标不太稳定。

有了这组数字，我现在可以开始做评估了。

从上面的截图中我可以看到，TTFB是我最稳定的指标–没有一个页面看起来有特别昂贵的数据库查询或后端的API调用。相反，LCP则不稳定得多，这意味着我们很可能在不同的页面上有高度不同的内容（这个指标本身并_不坏_，但它是高度可变的），而且它有可能没有得到平等的优化或交付。其他一切都在两者之间，而且在这个阶段没有提供真正的见解。当我们开始绘制数据图表时，有用的模式就会出现。

数据的可视化

在一个单独的表格中–可在之前的同一链接中获得–我简单地按页面类型绘制了数据图表。

**注意：**CLS是唯一没有以秒为单位的指标，因此在右边的Y轴上单独绘制。

在新的标签页中打开上述图表，并在这篇文章的其余部分中保持它的方便性可能是一个好主意。

下面的练习的全部意义在于让我快速行动，从远处发现模式，_还_不需要做任何缓慢或细致的工作。我希望能够在不查看任何一个URL或一行源代码的情况下形成假设并得出结论。这项工作是接下来要做的。

现在，我通常坐在那里，喝着咖啡，听着音乐，用老式的笔和纸做笔记。我希望确定的是，当我进入审计阶段时，我需要先看哪里。我想排除任何死胡同或错误的开始。我想最大限度地提高未完成的工作。

让我们开始吧!

建立地图

首先，我想一次比较整个页面。我马上就能看到，到目前为止，PLP是最糟糕的罪犯。几乎所有的条形图都比其他页面高。这意味着我最终可能会给它比其他页面多一点的关注。接下来，其他三个页面也很相似，主页的情况稍差一些。

接下来，我将寻找任何个别的异常值或极端值。我马上可以看到，我们在主页上有一个离群的 “最大内容画”，在搜索结果页上有一个离群的 “累计布局转移“。用我的笔和纸，我会在我的测试中记下专门调查这些。

在极端情况之后，我想真正找到一致的地方。再次注意到TTFB是非常一致的–正如在表格视图中看到的那样–我可以得出结论，后端时间（以及里面可能发生的其他事情）在每个页面类型中都是统一的。这意味着我可能不需要在任何单独的页面上做任何具体的工作，但也表明我在_A_区所做的任何一般的后端改进也会在_B_和_C区_感受到。但也许最重要的是，TTFB的稳定性意味着所有后续的里程碑都是在一个非常可靠的基础上衡量的–我不需要为了相互参照而对其他指标做任何临时调整。换句话说，如果一个页面的TTFB晚了整整一秒，那么在比较任何一个条形图之间的延迟时，我就需要考虑到这一秒。

这给我带来了下一个问题：deltas。在这里你会发现一些真正迷人的见解，这些见解可能会有令人惊讶的深度。

**TTFB_和_First Paint**之间的差距，大体上可以被认为是你的关键路径。这基本上就是每个页面有多少渲染阻塞资源。当然，它比这要复杂一些，但对于这个练习来说，它是一个非常可靠的代理。现在，这里是真正有趣的地方。

如果我们所有的TTFBs都是相同的，那么任何错误的FPs都表明了不同数量的渲染阻塞资源。鉴于渲染阻塞资源位于文档的head ，这意味着该页面上不同的head 标签。请注意，PDP的FP几乎比其他页面慢了一秒钟？我认为PDP有一些不同之处。它仅仅是一个或两个额外的阻碍渲染的资源吗？或者，也许一个更极端的情况是，它有完全不同的head 标签？也许这是一个完全不同的应用？这并不是闻所未闻的。

我想关注的下一件事是 **First Paint_和_First Contentful Paint**之间的deltas。FP被定义为第一个像素，无论它是什么，都被放在屏幕上。另一方面，FCP是指呈现在屏幕上的第一个图像或文本像素。请注意，大多数页面都有几乎相同的FP和FCP？这有力地表明，一个页面要么是。

在HTML或CSS中嵌入其标志，而不是使用外部图像，或者。
使用font-display 作为其网页字体，或者。
根本不使用网页字体。

基本上，第一遍和第一遍的油漆是相同的，这告诉我们一些文本或图像是在第一遍中呈现的。这也意味着，如果我们设法改善FP，我们很可能会免费改善FCP!

然而，PLP，确实显示了两者之间的差异。我会在我的笔记本上记下，调查本页的字体加载策略（根据我的经验，基于字体的问题比基于图像的问题更常见，尽管我不会完全排除它）。

现在，让我们继续讨论 ” **_第一丰富的油漆 “和_速度指数**之间的差距。SI是对折叠以上内容随时间变化的视觉完整性的衡量。它比这更复杂一些，但它基本上是处理视觉上的进步。FCP和SI之间的差距越大，视觉完整性的尾巴就越长。也就是说，你在视口中可能有许多不同的内容区域，它们都在不同的时间呈现，而不是一次就全部出现。这可能是可取的，也可能是不可取的，这取决于你是如何设计ATF体验的：你不应该偷懒加载任何ATF，但骨架屏幕可能会对你的SI产生负面影响，尽管最终会有更好的体验。一般来说，我在这里寻找的是任何表明我没有优先考虑折叠以上内容的长尾巴。

更有趣的是，让我们来看看**速度指数**与最大的 内容绘画。这有点难以解释，但在大多数情况下，SI和LCP之间的巨大差距表明，你的最大内容的油漆是_最后的_折叠以上的油漆之一–有一个大的区域失踪了很长时间，它的迟到在巨大的差距中是显而易见的。另一方面，一个小的差距表明，你最大的内容丰富的油漆是相对较早的，但一个较小的ATF油漆把你的SI推了出来–例如，一个晚装的聊天客户端，或一个小的cookie横幅，等等。最终，这个差距可能会告诉我ATF内容的性质是如何形成的：是单一的大区域刷得晚，还是小区域的长尾巴把指标推向了另一边？

这意味着我们可以从图中推断出，PLP上一个大而晚的渲染区域拉低了我们的速度指数，但是SRP上的高SI和低LCP意味着我们可能在处理一个长尾的渲染问题，这与一个大区域的关系不大。

接下来，让我们看看**累积布局转移**和其他里程碑。虽然CLS是一个核心网络要素，但它不是一个以时间来衡量的里程碑。相反，它关注的是布局的稳定性，这实际上与速度根本没有多大关系。话虽如此，我们还是可以把一些点连起来。对我来说，非常明显的是，PLP上巨大的LCP正在推动我们的CLS–无论什么内容迟迟不能呈现，都没有任何占位符或骨架。然而，稍显晦涩的是，SRP上的高CLS并没有被高LCP所连接。这表明有两种可能的情况。

也许搜索结果页面在加载单个图片时没有width 或height 属性，这意味着虽然它们不是一个LCP的一部分，但很多小图片在周围点缀着布局。这证实了我们之前提出的长尾渲染的猜测，当然这也是导致高CLS的一个行为。
这种可能性较小，但请记住，SI只测量折叠以上的完整性，所以有可能是巨大的初始CLS将很多渲染区域推到了屏幕之外，在这个过程中提高了SI的分数。然而，我希望看到这也反映在一个更严重的LCP上。

最后，总阻塞时间不能可靠地或有意义地与其他许多指标进行比较，因为其他里程碑（除了CLS）是受网络限制的，而TBT是受CPU限制的。人们可能得出的唯一关联是TTFB-First Paint之间的巨大差距和TBT指标的提高。记住，TTFB和FP之间的巨大差距表明head中有更多的同步资产–如果TBT也上升，那么这些资产更可能是JS而不是CSS。更多的时候，我会简单地将TBT孤立地看待。