你的站点加载速度应该多快？

原文地址：https://medium.com/firebase-developers/how-fast-should-your-site-load-cfb14be48e8b

去问问谷歌吧。你会发现有很多文章会告诉你，2 到 5 秒就能解决问题。但为什么 2 到 5 秒会被视为标准时间范围呢？你的直觉告诉你，答案肯定要比这复杂得多。

恭喜你说得对。答案远比任何时间段所能涵盖的都要复杂得多。问题出在那个问题本身上。

并非所有的网站和访客都相同

这个问题存在缺陷。它假定在不同情况下存在统一的标准。但网站是各不相同的。用户会在不同的条件下访问网站。

静态博客与图形编辑器不同，而且 4G 网络的速度要比 2G 快得多。静态博客可能完全不需要任何 JavaScript，而图形编辑器则会大量使用它。使用 4G 网络的用户可能只需等待 50 毫秒，而使用 2G 网络的用户每次往返可能要等待整整一秒钟。

上述表格所描述的是在理想条件下所能达到的数据传输速率。身处地下停车场并非理想状态，但这种情形对我们所有人来说都可能发生。这意味着用户访问您网站时所处的网络环境是多变的。

网络状况的多样性

对网络状况进行调整后，页面加载时间会产生显著差异。假设我们有两个用户将通过移动网络访问我的个人网站（davidea.st）。这是一个静态网站，没有会阻塞渲染的 JavaScript 代码。index.html 文件大小为 2.3kb，CSS 文件大小为 1.8kb。第一个用户使用 400kib 的带宽（2G 速度），但有 100ms 的延迟（4G 速度）。第二个访问者也有 400kib 的带宽，但有 1000ms 的延迟（两者均为 2G 速度）。

这其实还是同一个网站，但仅仅调整延迟（当你身处停车场时这很容易做到）就使 index.html 页面的加载速度提高了十倍。所以，如果仅仅延迟就能极大地改变同一个网站的页面加载速度，那么我们是否有必要去问“我的网站应该多快才能加载完成？”

作为开发者，你无法控制用户所使用的网络环境。这意味着网站的性能并非取决于你所设定的某个确切的加载时间数值。而是要了解在不同条件下，你的页面加载时间会呈现出不同的状态范围。要了解这一点，唯一的办法就是进行测量。

RUM：衡量实际使用效果

这就是 RUM 监测所能带来的结果。RUM，即“真实用户指标”，会从页面加载过程中收集重要的性能指标，并将这些指标发送至服务器，用户可以在一个仪表板上查看这些数据。

RUM（性能监测）供应商的种类繁多、规格各异，但出于本文的需要，我将使用 Firebase 性能监测服务。对我来说，Firebase 就像是第三个孩子，而且他们还为我支付薪水。

网络性能是一种分布情况

想象一下，如果你记录了访问你网站的用户的首次加载时间。然后将这些时间汇总在一个柱状图中。其呈现效果大概会是这样。

然而，这并非完全准确的可视化图表。并非所有用户都会在完全相同的时段内加载该网站。对于某位用户来说，网站加载时间为 1.5 秒，而对于另一位用户则为 1.65 秒。因此，我们不能使用柱状图，而应采用面积图。

此面积图展示了加载时间的分布情况。它有助于我们了解加载时间的范围以及最常见的情况。它涵盖了所有类型的加载时间百分位数。

在 Firebase 性能监控中，我们提供了涵盖不同指标的整个仪表板，其中包含了一系列的面积图。

x 轴表示的是更广泛的加载时间范围。y 轴表示的是百分位数。这些百分位数最有趣的地方在于它们的分布形态。

尾部

该图表先是急剧上升，随后又缓慢下降，形成了一个尾部。这表明大多数用户的加载时间在 1.5 到 3.5 秒之间，这可能是好的迹象。但别被这个小幅度的波动所迷惑。那个尾部包含了所有的问题。

尾巴部分代表的是那些遇到最长加载时间的用户。尾巴部分越长，波动性就越大。这意味着您的网站性能将变得难以理解。有些用户加载速度很快，而有些则需要慢慢进入。所以，虽然我们需要努力缩短尾巴部分，但同时也需要理解其含义。

你们的网站什么时候可以使用？

当大多数人提到“页面加载”时，他们所指的其实是网站能够实际使用的那一刻。但这有点容易让人误解，因为网站其实并不需要完全加载完成。

想象一下一个直播博客，它在报道一场重大事件。你访问该博客，会看到随着时间的推移，页面上会神奇地出现各种更新内容。那么，这个页面何时才算“加载完成”呢？是在第一组更新内容出现的时候吗？还是在页面头部加载完成的时候？

这并非是任何人想要进行的辩论。相反，我们会将页面加载时间细化为更具体的指标。

“页面加载”指标

导航是指用户启动网站加载的过程。这可能是通过输入网址并按下回车键，或者点击链接来实现的。此时页面上还没有任何像素内容显示。浏览器正在通过网络获取相关资源。

“首次显示”（FP）是被广泛引用的最常见指标之一。其定义很简单：屏幕上的非零像素数量首次出现的时间是何时？

了解像素何时开始显现非常重要，因为这能让你了解到用户开始看到内容的速度。在某些情况下，这种反馈能帮助用户知道网站正在加载，从而让他们保持耐心等待。

首先，如果您构建的是传统由服务器端渲染的网站（不同于基于服务器端渲染的 JavaScript 应用程序），那么 First Paint 能够准确地反映“页面加载”情况。这是因为所有的 HTML 和 CSS 都已准备就绪，且没有任何会阻塞渲染的 JavaScript 代码。该应用程序看起来和使用起来都很正常。但对于依赖 JavaScript 的网站而言，情况可能会有所不同。

对于许多单页应用程序（SPA）而言，首次渲染通常发生在诸如页眉和页脚等静态元素上。而应用程序的其余部分仍在启动过程中，等待 JavaScript 加载并执行。用户可能会看到一些内容，但应用程序目前还无法使用。

首次内容呈现时间（FCP）关注的是……嗯……页面上内容何时出现。这不仅仅是指屏幕上显示的像素数量。如果您的网站加载速度快，FCP 和 FP 往往会同时触发。但在某些情况下，比如当您为网页字体阻止文本渲染，或者当内容需要通过 JavaScript 加载和执行时，FCP 可能会落后于 FP。

即使您的网站加载速度较慢，FCP（首次渲染时间）和 FP（页面加载时间）也可能相同。这种情况在那些不大量渲染静态 HTML 的大型 JavaScript 应用程序中较为常见。在这些情况下，当 JavaScript 最终加载、执行并完成渲染时，FP 和 FCP 往往会同时触发。

domInteractve 表明，浏览器已根据静态 HTML 构建了 DOM 树。然后，浏览器开始加载其他资源，如样式表、图像和 JavaScript。了解这一点很有用，因为它能告知我们 DOM 树何时已构建完成，以及浏览器何时将开始加载其他所有内容。我们何时知道像 JavaScript 和样式表这样的重要资源已加载完成呢？这就是 domContentLoadedEventEnd 的作用。当 domContentLoadedEventEnd 触发时，您就知道不再有任何样式表阻碍任何 JavaScript 的执行了。

这些指标结合起来使用非常有用，因为“domInteractive”能告诉你样式表加载何时开始，而“domContentLoadedEventEnd”则能告诉你加载何时结束。

“加载事件结束”并非总是最实用的衡量指标，但有时它能提供不少有用的信息。当文档的加载完成时，“loadEventEnd”事件就会触发。这意味着该事件会在 DOM 树中的所有资源（包括链接的样式表、脚本和图像等）都加载完毕时触发。由于这些资源（如图像）可能会拖慢这一指标的运行速度。如果你不小心在网站上上传了一个 100MB 的 GIF 图像，那么你会看到“loadEventEnd”事件的触发时间相当缓慢。我这么说也是基于自己的经验之谈。

该指标能帮助您大致了解文档中的资源加载所需的时间。在该指标生效之前，您的网站就已经可以正常使用了。利用此指标，您可以大致判断页面上是否有大量资源需要加载。

首次输入延迟（FID）用于衡量用户首次操作触发所需的时间。您可能曾遇到过这样的情况：页面看起来已经准备好使用了，但实际上却处于停滞状态。无论您如何愤怒地滑动或点击，该网站都无法正常运行。首次输入延迟就是为了衡量这类问题而存在的。

如果你的博客是静态的，那么它可能就没那么有用了，因为 FID（用户与网站交互的时间）这一指标是衡量用户能够与你的网站进行交互的时间的。这通常是在事件监听器触发之后才会开始的。而对于那些使用大量 JavaScript 的应用程序来说，这个指标可能是至关重要的。使用大量 JavaScript 的应用程序必须先加载、解析和执行代码，然后才能运行，这可能会推迟网站的首次交互时刻。

网页关键性能指标

如果你是一位注重性能表现的资深开发者（或者如果你是 阿迪·奥斯曼尼 的追随者），那么你很可能听说过“网页关键性能指标”这一倡议。

“Web Vitals”是谷歌发起的一项举措，旨在为对实现良好网络用户体验至关重要的质量指标提供统一的指导。

目标是提升加载性能、交互性和稳定性。构成“网页关键指标”的核心指标有：

• 最大内容渲染时间（LCP）（用于衡量加载性能）
• 首次输入延迟（用于衡量交互性）
• 累积布局偏移（CLS）（用于衡量稳定性）

我不会对每一项进行详细说明（因为我们已经讨论过很多指标了），但您可以查看 web.dev/vitals 页面上的描述。每个指标都是通过谷歌网络团队提供的库来获取的。

import { getCLS, getFID, getLCP } from 'web-vitals';
getCLS(console.log);
getFID(console.log);
getLCP(console.log);

Firebase 性能监测仅将首次输入延迟作为一类主要指标予以支持。在其他指标能够自动收集之前，您可以使用自定义跟踪功能来记录最大内容完整呈现时间和累积布局偏移量。

监控自定义属性

借助性能监控功能，您可以利用属性对性能数据进行分类，并专注于分析您的应用程序的性能情况…… firebase

##指标过多

网络性能中包含了大量的指标，并非所有指标都适用于您的网站和情况。我建议您仔细阅读每一项指标，看看它是否适合您的网站类型。不必担心逐一追踪每个指标。要了解哪些指标最适合您的网站。

那么，您的网站加载速度应该达到怎样的水平呢？

对于这些指标，我们该如何处理呢？既然您已经了解了这些指标，我们就可以利用它们来了解网站的运行情况，并提出更恰当的问题。

这里有一个具体的问题需要提出：“我们的内容何时首次面向 3G 用户推出？” 在实际环境中追踪这些指标能够帮助您了解哪些用户群体受到了影响，以及随着时间的推移趋势如何。

通过 Firebase 性能监测功能，您可以深入查看诸如“首次内容呈现”等指标，以了解哪些因素会影响该指标。在此例中，我们可以按照“有效连接类型”（网络速度）对其进行细分。

该仪表盘显示，大多数用户使用的网络连接至少为 4G 或更高速度。但有 5.88% 的用户使用的网络速度为 3G，并且页面加载时间为 2.24 秒。这比问“我的网站应该加载多快？”要好得多。

开始测量

希望在开始阅读这篇文章之前，您对页面加载速度已经有了一定的了解。如果您能从中获得一条建议的话，那就是：开始进行测量吧。

请查阅 Firebase 文档，开始使用 Firebase 性能监测功能。只需几行代码即可完成。测量能够帮助您提出更恰当的问题并获得更准确的答案。并且永远要记住，页面加载时间并非一个固定的数值。网络性能本身就是一个分布情况。