你可以支付吗？：真实的网络性能预算

TL; DR：绩效预算是产品成功和团队健康的重要但不受赞赏的部分。我们合作的大多数合作伙伴都不了解现实世界的运营环境，因此不适当地进行技术选择。我们在<= 5秒的时间内设置预算，首先加载时间到交互，并且<= 2s用于后续加载。我们将自己限制在一个现实的基准设备+网络配置中来衡量进度。默认的全局基线是400Kbps链路上的约200美元的Android设备，具有400ms的往返时间（“RTT”）。这转化为约150-170KB的关键路径资源的预算，具体取决于组合 - 您所包含的JS越多，捆绑包必须越小,这项工作一直很有启发性，有时候是非常意想不到的。最令人意想不到的结果之一是经常发生“埋伏的JavaScript”

绿色发展Progressive Web Apps的企业领导者经常引用以接近零摩擦的新用户为主要动机的能力。同时，团队正在努力实现这一目标的工具不可能。没有人正在努力做一个糟糕的工作，但是“完成”PWA项目的结果通常需要几个星期或几个月的努力才能提供最低限度的可接受的表现。

这种返工延迟发布，反过来延迟收集关于PWA战略的可行性的数据。我们无法直接使用的团队有时候不会遇到这些问题，直到太晚，为大多数潜在用户启动了无法使用的体验。

设定基线

这些属性相互依赖：如果没有重视用户体验和长期业务价值的决策者，很难获得所需的空间来做好事情。具有这种支持的团队可以自由设置绩效预算，在竞争方法之间进行“放弃”，并投资于绩效基础架构。当流行的工具被证明是不恰当的时候，他们也更能反对“行业标准”的粮食。

绩效预算使每个人都保持在同一页面上，并创造出一种共享热情的文化，以改善活跃的用户体验。具有预算的团队也会更容易跟踪和绘制进度。这有助于支持那些然后具有有意义的指标的执行发起人来指出正在进行的投资。

预算设定了一个客观的框架，用于确定代码库的哪些更改代表进度，哪些是用户角度的回归。没有他们，不可能避免滑倒陷阱，假装你可以买得起更多的钱。很少有我们看到一个团队成功，没有设置预算，收集RUM指标，并携带代表性的客户设备。

合作伙伴会议很明亮。我们非常了解基于主要在城市地区使用的高端手机的工程技术负责人，PM和决策者所占比例将如何糟糕的网站性能。

前任团队从未有过这样良好的绩效工具和诊断技术，但结果不佳。这里发生了什么？

JS是你最贵的资产

一个明显的趋势是相信，JavaScript框架和单页架构（SPA）是PWA开发的必需品。这不是真的（更多的是在后续的帖子），并且这样构建的网站隐含地需要在每个文档中更多的脚本（例如，对于路由器组件）。我们经常看到网站加载超过500KB的脚本（压缩）。这很重要，因为所有脚本加载都会延迟我们最重视的度量：交互时间。具有这么多脚本的网站根本无法访问世界各地的用户群; 统计上，用户不会（也不会）等待这些体验加载。那些确实经历了可怕的沉痛。

我们经常被问到“关于大约200KB的JS是什么大问题，我们的一些图像是那个大小？”一个很好的问题！回答它需要了解浏览器如何处理资源（根据类型不同）和关键路径的概念。为了及时介绍，我推荐凯文·沙夫最近的演讲。

延迟加载的JavaScript可能导致“服务器端渲染”页面以令人愤怒的方式失败。这个不可思议的谷底效应是我们关注页面变得可靠交互的原因。

<!DOCTYPE html>
<html>
<head>
<link rel="stylesheet" href="/styles.css">
<script src="/app.js"></script>
</head>
<body>
<my-app>
<picture slot="hero-image">
<source srcset="img@desktop.png, img@desktop-2x.png 2x"
media="(min-width: 990px)">
<source srcset="img@tablet.png, img@tablet-2x.png 2x"
media="(min-width: 750px)">
<img srcset="img@mobile.png, img@mobile-2x.png 2x"
alt="I don‘t know why. It‘s a perfectly cromunlent word!">
</picture>
</my-app>
</body>
</html>

浏览器遇到此文档以响应GET请求。服务器将其作为字节流发送，当浏览器遇到文档中引用的每个子资源时，它会请求它们。https://example.com/

要完成此页面的加载，需要响应用户输入 - “交互时间 ”中的“交互式”。浏览器通过生成应用程序代码侦听的DOM事件来处理用户输入。这种输入处理发生在文档的主线程上，JavaScript运行。

以下是其他线程可能发生的一些操作，允许浏览器保持响应：

如果我们的示例文档不依赖于JavaScript来构造<my-app>自定义元素，则只要足够的CSS和内容可用于有意义地，文档的内容就可能是交互式的。

另一方面，图像不会阻塞主线程，不要在解析或光栅化时阻止交互，也不要阻止UI的其他部分获取或保持交互。因此，虽然150KB的图像不会明显增加TTI，但是150KB的JS会延迟交互性，达到以下要求：

如果脚本执行时间可能在50ms以下，那么TTI将不会被延迟，但这是不可行的。150KB的gzip压缩JavaScript扩展到大约1MB的代码，而且随着Addy的记录，大部分世界手机的时间将不会超过一秒钟，而不包括获取时间。

JavaScript是任何页面中单一最昂贵的部分，其方式是网络容量和设备速度的函数。对于在快速网络上使用快速手机的开发人员和决策者来说，这是隐藏成本的双重威胁。

全球地面真相

决定用于绩效预算的基准是至关重要的。一些团队和企业密切地了解他们的观众，并且可以对当前和潜在用户所在的设备和网络做出明智的估计。然而，大多数人并没有这么简单的基准。从哪儿开始？

中位数用户在一个缓慢的网络上。一个辩论的问题是多么的缓慢。

我们在Google的指标显示出冲突的图片（我正在努力弄清楚）。一些系统显示3G用户近100ms的中位RTT。其他的显示中位数用户在一些主要市场中不能发送和接收不到400ms的单个数据包。

Google员工可以访问模拟的“退化3G”网络，以帮助在这些条件下验证其应用的行为。它模拟具有400ms RTT和400-600Kbps吞吐量（加上延迟变化性和模拟分组丢失）的链路。鉴于我们在其他系统中看到的数据冲突，这似乎是基准。

然而，模拟丢包和可变延迟可以使基准测试变得非常困难和缓慢。在DNS查找期间丢失的数据包的影响可能是秒的差异，使得在开发时间之前比较之前/之后的比较令人沮丧。因此，我们的基准应该可能会降低吞吐量/更高延迟的数据包丢失。我们在现实世界的忠诚中失去了我们获得的可重复性，并且能够在不同的变化和产品之间进行比较。关于DNS，TLS，网络拓扑等因素的影响还有很多。对于那些想要深入了解的人，我强烈推荐Ilya Grigorik的“高性能浏览器网络”。只有RRC的覆盖才能使您的时间值多久。

回到我们的基线，我们现在对于我们的模拟网络条件应该是什么：400ms RTT，400Kbps带宽。设备本身呢？

从2016年开始，真正的中位数设备售价约为$ 200。今年的中位数设备更便宜，但其性能大致相当。预计未来几年中期业绩继续下滑。这是我去年推荐的Moto G4的一部分原因，并且今年推荐了Moto G5 Plus。

对于大多数技术人员来说，为这种环境建造应用程序也可能在火星上耕作。幸运的是，这个配置可以在webpagetest.org/easy上获得，这意味着我们可以随时在地球上重新创建这些条件。

负担能力计算

在数值上，我们希望在一秒钟内发生每一个页面加载（参见RAIL）。这在现实世界的网络中是不可能的，因此我们已经为合作伙伴设定了以下时间 - 互动（TTI）指标目标：

TTI在5秒钟内进行第一次加载
TTI在2秒内用于后续装载

我们现在有了我们在2017年为产品创建一个球场预算的一切。

第一次加载

从时间，网络条件和关键路径的主要阶段向后退，我们得到了一些有趣的结果。我们可以从5秒的首次预算开始，并开始计算出我们能承受多少转移费用。

首先，我们从我们的DNS查找和TLS握手预算中减去1.6秒，使我们能够使用3.4s。

然后，我们计算在3.4秒内可以通过此链接发送多少数据：400 Kbps = 50KB / s。50KB / s * 3.4 = 170KB。

注意：这个讨论肯定会激怒有能力的网络工程师。本文的以前版本讨论了慢启动，bdp，tcp窗口缩放等。他们相当难以跟随。简化对整个故事的影响相对较小，所以这些细节都被淘汰了。

现代Web应用程序主要由JS组成，这意味着我们还需要减去JS需要解析和评估的时间。JS代码的gzip压缩因子在5x和7x之间。JS的170KB成为?850KB-1MB的JS，根据以前的估计，可能需要一秒钟运行（假设它不做任何昂贵的DOM工作，当然这样做）。使用这些数字一点点，我们可以通过限制自己在电话上传输的130KB的JS下载和评估下面的3.4s。

作品中的最后一个扳手：如果我们的任何关键路径资源来自不同的来源（例如，CDN），我们需要从预算中减去该起点的连接建立时间（约1.6s），进一步限制多少我们5年的时间实际上可以花在网络传输和客户端工作上。

在理想条件下，将关键路径资源（CSS，JS，HTML和数据）的粗略预算放在一起：

170KB的网站没有太多的JS
使用JS框架构建的站点为130KB

这使我们有能力在今天的前端发展中考虑最紧迫的问题：“你能负担得起吗？

例如，如果您的JS框架在JS重型站点（由于JS评估时间预算为130KB）而需要大约40KB的传输），则只剩下90KB的“余量”。您的整个应用程序必须适合该空间。从CDN加载的100KB框架预算已经超过20KB。

回想一下：您的选择框架可能是40K，但是该数据系统呢？你添加的路由器？当您还需要包含数据，模板和样式时，突然130KB似乎不是很多。

生活在一个预算意味着不断问自己“我真的可以负担得起吗？

第二负载

在一个理想的世界中，所有的页面加载都会在一秒钟内发生，但是由于许多原因，通常是不可行的。因此，我们将给予自己一点喘气和预算2秒的第二（第三，第四等）负载。

为什么不5 因为我们第一次访问它们，所以我们不需要去网络让我们的应用程序的UI启动。服务工作者和“离线第一”架构使我们能够在屏幕上放置交互式像素，而无需触摸网络。这是实现可靠性能的关键。

在现代CPU方面，两秒钟是永远的，但我们仍然需要明智的花费。我们需要考虑的因素包括：

我看到的每个应用程序，它的初始加载速度达到5s，并且首先实现离线，正确地保持在这个2s的预算之下，sub 1s是可能的！但是，先到先得是许多团队的巨大挑战。架构在本地保存上次看到的用户数据，以可靠和一致的方式缓存应用程序资源，并使用服务工作者生命周期来处理应用程序代码升级可能是一项重大任务。

我期待工具在这一领域不断发展。我今天知道的最全面的引导是聚合物应用工具箱，所以如果你不知道从哪里开始，从那里开始。

130-170KB ...当然你在开玩笑！

我们谈论的很多团队想知道是否有可能提供一些有用的东西，只有130KB。它是！所述PRPL图案示出了通过基于路线的认识，粒状（后续页）资源的服务工缓存和巧妙地利用现代协议增强等的攻击性的代码分割的方式HTTP / 2推。

可悲的是，从一个特定的跟踪来说，很难从页面加载哪些部分是TTI的关键路径资源，但是我并不乐观，但我乐观地看到，工具将快速发展，以帮助我们了解这一关键指标。

无论如何，我们知道这是可能的，即使没有完全放弃框架。双方的Wego和Ele.me与现代工具（内置聚合物和Vue公司，分别），并帮助用户完成实际交易今天。大多数应用程序是少比他们复杂。预算的生活不是饥饿。

预算中的团队工具

获取下预算是很难的，但对企业和用户带来的好处是巨大的。讨论较少的是工程团队及其领导的好处。没有技术主管或PM想要在一个行政人员错误的一边，他们通过电话问道：“为什么我在度假时这么慢？”

我已经看到刚刚完成重建的现代技术团队一小时，因为我们走过他们在现实世界条件下使用他们的“更好”，“更快”的经验的经验。

当产品不符合预期时，每个人都会失去面子。几个计划外的性能消防延迟了新功能的增加，并对队伍士气产生了排水效应。当表现成为危机时，中层管理人员就被抓到是他们的团队所依靠的“狗屎伞”之间，并且对自己的怀疑感到沮丧。更糟糕的是，他们可能会开始怀疑他们的团队。演出危机的另一面是漫长的道路; 组织如何信任团队提供优质的产品？他们是否可以信任TL来推荐新技术或大规模再投资？相反。这是一个糟糕的经历，专门针对开发人员，经常遇到难以置信的压力来解决这个问题 - “ASAP”，而“它”可能是产品建立的核心技术。

在最糟糕的情况下，该产品可能在短时间内无法协助业务。达尔文进程很多，初创公司和小团队投注错误的堆叠，并没有长跑道的好处可能是致命的。更糟糕的是，这可以长时间不诊断。如果整个团队在快速城市网络中携带最新的iOS设备，而产品的经济性则以扩大广泛的观众为前提，那么观众的失败几乎没有得到发挥。

当然，性能不是（整个）产品。许多缓慢或市场限制的产品做得非常好。拥有人们想要的独特服务（并且将脱颖而出）可以覆盖所有这些其他问题。有些人甚至在应用商店中获得成功，摩擦获得的经验是激烈的。但竞争激烈的市场中的产品需要各种优势。

打击膨胀的成功往往意味着将警告转变为严重的错误。具有CI或提交队列系统的团队应强烈地考虑不允许破坏（性能）银行的提交。

对于刚开始的团队，我强烈的建议是从一个堆栈开始，对应用程序结构，代码分割和构建目标有很强的意见。今天最好的是：

无论您的团队选择哪种工具，预算都是至关重要的。没有一个，即使是最先进的“轻量级”框架也可以轻松地产生膨胀的，不可用的应用程序。从全球基线开始，只有根据硬性业务分析增加预算是我知道的最好的方法，以确保您的PWA项目对用户而言也是一样，并且在演示中也是如此。