我对Web性能社区的挑战

原文地址：My Challenge to the Web Performance Community

原文作者：Philip Walton

译文出自：掘金翻译计划

#我对Web性能社区的挑战(My Challenge to the Web Performance Community)

近年来，我注意到了一种趋势——一种我自己也有的趋势-注重性能的开发人员将重建一个站点，然后发布他们的Lighthouse截图在社交媒体上得分，展示它有多快。

对于许多阅读这篇文章的人来说，可能会感到惊讶的是，我有点希望这种趋势停止，或者至少，我希望它改变。

现在，让我非常清楚：在社交媒体上吹嘘自己的成功绝对没有错，使用Lighthouse或努力获得一个好的Lighthouse分数也没有错。

这种做法让我担心的是，它掩盖了许多重要的细微差别，并使人们永远认为合成或基于实验室的工具（如Lighthouse、WebGetTest和许多其他工具）是对站点实际性能的真实准确评估，而不是它们是什么：用于测试、调试、诊断的工具，在一组受控条件下优化、预测性能或检测回归。

换句话说，在Lighthouse上获得100分肯定是一个非常好的迹象，但这并不能保证你的网站在现实世界中完全没有任何性能问题。

事实上，我的同事布伦丹·肯尼刚刚发表了一些研究这项研究分析了HTTP存档语料库中的所有页面，并研究了Lighthouse分数和核心Web关键信息之间是否存在相关性基于现场数据的得分（也称为真实用户或RUM数据）从Chrome用户体验报告（关键）结果确实发现两者之间存在着强烈的正相关关系，但它也发现了一些令我非常惊讶的事情：

在Lighthouse上获得100分的所有网页中，几乎有一半没有达到推荐的核心网站关键点阈值

我一直都知道Lighthouse100分是有可能的，但现实世界中的问题仍然存在，但我不会猜到这是如此普遍。顺便说一句，数据还显示，反过来也很普遍：许多完全满足所有核心Web关键阈值的页面实际上Lighthouse分数非常低。

现在，仅仅因为一个页面没有满足所有推荐的核心网站关键点阈值并不一定意味着它很糟糕。上面的图表包括一个从黄色到黑色的渐变，表示具有特定灯塔分数的页面与满足所有核心网站关键点“好”的接近程度阈值。Lighthouse分数超过90分的页面出现橙色和红色的数量确实表明，其中许多页面离目标并不遥远。尽管如此，如此多的Lighthouse分数完美的页面仍然存在真实的用户性能问题，这一事实清楚地表明实验室工具存在盲点。

如果您是性能专家，您可能知道这些盲点，以及实验室结果与真实用户数据不同的无数其他原因（例如，实验室工具不考虑滚动或其他用户交互，实验室工具在页面加载后停止测量，以及许多其他原因)，您可能会认为大多数开发人员也理解这些细微差别，但我可以向您保证，事实并非如此。

根据我在Web Vitals工作的经验在谷歌的倡议下，到目前为止，我们从社区听到的第一个问题是，为什么他们在一个工具中看到的数字与在另一个工具中看到的数字不匹配，而在大多数情况下，原因是一个工具报告实验室数据和其他报告现场数据。

当然，性能是一个复杂的话题，存在一些混乱是完全可以理解的。但当我真的退一步思考为什么会有这么多的困惑时，我只是继续回到我上面提到的：人们在公共场合和社交媒体上谈论绩效的方式。

我们如何谈论性能

如果你花了很多时间在网络性能领域，无论是在会议上，阅读案例研究，还是只是浏览推特，你可能会一次又一次地听到以下说法的一些变化：

我的站点在不到1秒的时间内加载
我们的主页在3G上只需不到5秒钟即可实现互动
我们从技术A切换到技术B，我们的LCP提高了40%

人们这样说是因为他们矮、甜，而且听起来真的令人印象深刻。但不幸的是，如果没有额外的上下文，它们也基本上毫无意义。

例如，如果有人对我说“我的站点加载时间不到1秒”，我可能会回答：

**为谁？**是否在不到1秒的时间内为每个访问过它的人加载？
**你说的是什么时候？**它现在是在不到1秒的时间内加载的，还是在整个存在过程中总是在不到1秒的时间内加载的？
**“负载”是什么意思？**你是说字面意义上的负载事件，还是使用其他度量？

现在，通常情况下，如果有人在网上引用了一个毫无意义的统计数据，我不会在意（我尽量不做这个家伙)，但最近，有多少人将性能视为单个数字，而不是值的分布（代表不同的用户访问），这一点开始变得清晰起来每天都在变化和波动。

这些类型的声明的另一个大问题（回到我之前关于灯塔分数吹牛的观点）是，它们通常基于实验室结果，而不是真实的用户数据。

同样，使用基于实验室的工具优化性能绝对没有错。在将更改部署到生产环境之前，我一直使用Lighthouse和WebGetTest。但我确实认为，暗示（特别是公开）基于实验室的性能结果实际上等同于真实世界的性能结果是有问题的。我这么说不仅仅是为了吹毛求疵的技术细节，我这么说是因为每一天我都会看到人们感到困惑。他们是这个行业的新手，他们并不完全理解实验室和现场测量之间的区别，但根据他们看到人们在网上谈论灯塔的程度，他们认为这是行业专家使用的，但这并不完全正确。

通过我在谷歌的工作以及作为W3C Web性能工作组的成员，我了解了世界上一些最先进的公司的工程师如何衡量和优化绩效，基本上所有这些公司都优先考虑真实世界的数据，他们根据实际用户结果做出性能决策。明确地说，这些公司还使用基于实验室的工具来测试、调试、诊断和优化性能，但任何基于实验室测试的决定都会在现实世界中得到验证，通常是通过一个仅对一小部分用户启用的实验，然后在实验证明成功后才逐步向所有用户推出。

我知道许多公司没有资源来构建自己的性能监控和实验基础设施，但真正的用户性能监控不是你必须自己构建的。市场上有许多奇妙的朗姆酒分析解决方案（其中一些甚至是免费的），因此我有点惊讶有多少公司仍然只看实验室数据。

我认为，作为一个行业，我们面临的问题不是获取真实用户数据，而是意识到实验室数据和现场数据是不同的。它们服务于不同的目的，而这些差异实际上是有用的和互补的。

但当我们谈论实验室数据时，就好像它等同于（或替代）真实的用户数据，我认为我们只是加剧了误解，在某些情况下给人们一种错误的安全感。

我的挑战

我希望这篇文章能让你相信，我们谈论绩效的方式确实很重要。在初学者面前，我们越是简化和掩盖细微差别，我们就越会混淆他们，使我上面讨论的神话和误解永久化。

因此，本着帮助提高web开发社区对性能复杂性的认识的精神，我想向任何公开谈论、写作、博客或吹嘘性能的人提出这个挑战：

如果您要谈论生产站点的性能，请使用真实的用户数据

如果你还没有检测你的站点来收集真实的用户数据，我已经包括了下面的一些链接来帮助你开始。对于在CrUX数据集中有足够流量的站点，可以使用PageSpeed Insights field data report等工具或关键仪表板查看基于Chrome遥测的真实用户性能指标。

如果要使用单个数字引用性能结果，请指定该数字在分布中的位置

例如，服务器响应时间中位数为XX毫秒，第75百分位的FCP为X秒。

在讨论实际用户性能时，请具体说明时间段

例如：“在过去7天中，我的TTFB中值比前7天提高了25%。”。指定一个时间段有助于强调性能不是一个单一的数字（它可以改变）。

如果你真的想吹嘘你的灯塔成绩或其他实验室结果，请结合更大的绩效故事来吹嘘

例如：“我们将登台服务器上的Lighthouse分数从62提高到95，部署后，我们的第75百分位LCP从5秒降至2.2！”或者，如果您没有现场数据，至少可以这样说：“这项技术在实验室测试中将图像加载性能提高了40%。我们希望在下周将其部署到实际用户时看到良好的结果！”

无可否认，上述指导方针是微妙的，但如果有足够多的人遵循它们，我确实认为它会产生很大的影响。性能优化应该是让用户满意，而不是让工具满意。如果我们真的相信这一点，我们应该以身作则。

最后，我只想说，我肯定地认识到，真正的用户性能度量比实验室性能度量困难得多。我知道它的设置更复杂，需要更长的时间才能得到结果（几小时或几天而不是几秒钟），而且大多数朗姆酒分析产品的使用都要花钱。

当我与开发人员交谈并问他们为什么不使用RUM时，我经常得到的一个回答是：\我认为我们不需要它。我们的表现真的很好。我们监控CI的几个关键指标，并进行自动化测试，以确保PRs不会导致回归_

如果这是真的，那就太棒了！这正是基于实验室的工具的用途，也是它们提供最大价值的地方。但请记住我在本文开头引用的统计数据：在Lighthouse上得分为100分的HTTP存档数据集中，几乎有一半的页面没有达到基于真实用户数据的推荐核心Web关键阈值。

所以当你说你不需要现场数据，因为你的表现已经非常好了，你应该问自己：你怎么知道这是真的

附加资料

RUM分析提供商和服务

以下公司都提供朗姆酒分析服务。虽然我没有亲自使用所有这些工具，但我见过所有这些团队，并且我与使用他们服务的公司合作过。

测量现场性能的一般指南

我最近写的一个资源列表旨在帮助人们使用通用分析工具或他们自己构建的工具来衡量绩效。虽然所有这些都主要讨论网络的重要信息，但这些概念也适用于一般的绩效衡量。