重要的分析

我一直对引用全球浏览器使用率百分比来证明使用浏览器功能的合理性持怀疑态度。除了在鸡尾酒会上作为闲聊话题之外，浏览器的全球使用率并不重要。真正重要的是您网站用户使用的浏览器，而这可能在不同网站之间差异很大。

最近几天，我一直思考着 **跟踪您实际网站的真实使用情况** 的概念。这不仅是“我无法使用 CSS 网格，因为 IE 11 仍然占全球使用率的 1.42%” 之类的事情，还涉及衡量对您的网站重要的指标，无论它们是什么。

性能指标是一个重要的方面。当您进行性能测试时，其中大部分是所谓的 **合成测试**。自动浏览器会加载您的网站，并在加载过程中跟踪它找到的内容，例如某项操作的计时、资产大小、资产数量等。当我花费大量时间在性能上时，这种合成信息会进入我的脑海。“我相信我可以删除这个额外的请求，”我想。“我相信我可以进一步优化这个资产。” 我们使用的性能工具会方便地向我们报告这种类型的数据。我们的 JavaScript 包有多大？我们的“最大内容绘制”是多少？我们的 Lighthouse 性能得分是多少？所有这些都与性能相关，但 **并未衡量实际用户的体验**。

请先思考一下这一点。

我们可以从网站上收集其他分析，例如使用情况分析。例如，我们可能会在网站上安装 Google Analytics，除了安装通用代码段外不做任何事情。这将告诉我们诸如哪些页面最受欢迎、人们在网站上停留了多长时间以及哪些国家提供了最多流量之类的信息。这些是真实的用户分析，但它们是十分通用的分析信息。

如果您希望在您的网站上获得更有用的分析数据，您需要事先多加考虑。您想了解什么？也许您想知道人们使用功能 X 的频率。或者您想知道他们本周上传了多少文件。或者他们发送了多少条消息。或者他们点击了多少次星标按钮。这些信息可以告诉您您的网站运行情况如何。通用的分析跟踪无法做到这一点；您需要编写一些 JavaScript 代码来捕获和报告这些信息。为了获得您真正关心的分析，您需要付出一些努力。

现在将此应用于性能工具。

与其进行通用的合成测试，为什么不 **衡量对您的特定网站真正重要的内容**？这方面的一个方法是 RUM，即“真实用户监控”。因此，与其让一个合成测试成为您网站所有性能测试的来源，不如跟踪实际用户在自己的设备上实际使用网站的情况。在我看来，这很有意义，但除了逻辑之外，它还能解锁一些重要的数据。

例如，谷歌的 网页核心指标（很快将影响我们页面的 SEO）中包含一个称为首次输入延迟 (FID) 的指标，您 *必须* 通过页面上的 JavaScript¹ 收集数据才能使用它。

另一个网页核心指标是“最大内容绘制”，这是对更具意义的性能指标的迷人尝试。想象一下像“开始渲染”或首次页面绘制这样的指标。这有趣吗？有点吧。至少它向用户发出信号，表明正在发生某些事情（可能）。然而，首次渲染可能并非真正有用的内容，例如新闻文章的标题和正文。因此，此指标会猜测可能的有用内容是什么，并对它进行衡量。非常聪明。

但是，*为什么要猜测？*我明白 *谷歌* 为什么需要猜测。他们必须在一百万个网站上测量 LCP 并提供通用有用的测量结果。但在您自己的网站上（再次强调，重点分析实际上很重要），**我们可以 *告诉* 性能工具哪些元素对我们很重要，并记录它们何时渲染**。就我个人而言，我会关心这篇文章本身何时在这篇文章中渲染。通过 SpeedCurve 的英雄渲染时间，我可以做类似的事情

<main elementtiming="article"></main>

<!-- or focus on the top of the page, like the "hero" timing suggests -->
<header elementtiming="hero"></header>

现在我正在衡量对 *我* 的网站重要的内容，而不仅仅是通用数字。

同样，FID 很酷，但为什么不触发一个 JavaScript 事件，告诉性能工具何时发生对 *您的网站* 重要的事件。例如，在 CodePen 上，当编辑器可以使用时，我们会这样做。这被称为 用户计时，并且它是一个 W3C 规范！

Editors.init();
performance.mark("Editors are initialized.");

这些需要一些努力的分析肯定比标准分析要好。当然，当 JavaScript 超过 200KB 时发出警告的性能预算很棒，但当您的应用程序的核心功能在 1.4 秒后才准备好，而您的预算只有 1.1 秒时，发出警告的性能预算就更加重要。