你可以支付吗？：真实的网络性能预算
TL; DR：绩效预算是产品成功和团队健康的重要但不受赞赏的部分。我们合作的大多数合作伙伴都不了解现实世界的运营环境，因此不适当地进行技术选择。我们在<= 5秒的时间内设置预算，首先加载时间到交互，并且<= 2s用于后续加载。我们将自己限制在一个现实的基准设备+网络配置中来衡量进度。默认的全局基线是400Kbps链路上的约200美元的Android设备，具有400ms的往返时间（“RTT”）。这转化为约150-170KB的关键路径资源的预算，具体取决于组合 - 您所包含的JS越多，捆绑包必须越小,这项工作一直很有启发性，有时候是非常意想不到的。最令人意想不到的结果之一是经常发生“埋伏的JavaScript”
绿色发展Progressive Web Apps的企业领导者经常引用以接近零摩擦的新用户为主要动机的能力。同时，团队正在努力实现这一目标的工具不可能。没有人正在努力做一个糟糕的工作，但是“完成”PWA项目的结果通常需要几个星期或几个月的努力才能提供最低限度的可接受的表现。
这种返工延迟发布，反过来延迟收集关于PWA战略的可行性的数据。我们无法直接使用的团队有时候不会遇到这些问题，直到太晚，为大多数潜在用户启动了无法使用的体验。
设定基线
避免令人不快的惊喜的团队往往分享一些特点：
- 执行赞助人热情洋溢。他们使用“做所需”的语言来描述获得和保持快速的努力
- 绩效预算是在项目生命的早期设定的
- 预算将缩放到基准网络和设备
- 工具和CI系统帮助他们监控进度并防止回归
这些属性相互依赖：如果没有重视用户体验和长期业务价值的决策者，很难获得所需的空间来做好事情。具有这种支持的团队可以自由设置绩效预算，在竞争方法之间进行“放弃”，并投资于绩效基础架构。当流行的工具被证明是不恰当的时候，他们也更能反对“行业标准”的粮食。
绩效预算使每个人都保持在同一页面上，并创造出一种共享热情的文化，以改善活跃的用户体验。具有预算的团队也会更容易跟踪和绘制进度。这有助于支持那些然后具有有意义的指标的执行发起人来指出正在进行的投资。
预算设定了一个客观的框架，用于确定代码库的哪些更改代表进度，哪些是用户角度的回归。没有他们，不可能避免滑倒陷阱，假装你可以买得起更多的钱。很少有我们看到一个团队成功，没有设置预算，收集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运行。
以下是其他线程可能发生的一些操作，允许浏览器保持响应：
- 解析HTML
- 解析CSS
- 解析和编译JavaScript（有时）
- 一些JS垃圾收集任务
- 解析和光栅化图像
- GPU加速的CSS转换和动画
- 主文件滚动（假设没有主动触摸监听器）
但是，这些操作必须发生在主线程上：
- 执行JavaScript
- DOM的构建
- 布局
- 处理输入（包括带有主动触摸监听器的滚动）
如果我们的示例文档不依赖于JavaScript来构造<my-app>自定义元素，则只要足够的CSS和内容可用于有意义地，文档的内容就可能是交互式的。
脚本执行以几种方式延迟交互性：
- 如果脚本执行超过50ms，则交互时间将延迟整个下载，编译和执行JS所需的时间
- 任何在JS中创建的DOM或UI都不可用，直到脚本运行
另一方面，图像不会阻塞主线程，不要在解析或光栅化时阻止交互，也不要阻止UI的其他部分获取或保持交互。因此，虽然150KB的图像不会明显增加TTI，但是150KB的JS会延迟交互性，达到以下要求：
- 请求代码，包括DNS，TCP，HTTP和解压缩开销
- 解析并编译JS的顶级功能
- 执行脚本
这些步骤大部分是序列化的。
如果脚本执行时间可能在50ms以下，那么TTI将不会被延迟，但这是不可行的。150KB的gzip压缩JavaScript扩展到大约1MB的代码，而且随着Addy的 记录，大部分世界手机的时间将不会超过一秒钟，而不包括获取时间。
JavaScript是任何页面中单一最昂贵的部分，其方式是网络容量和设备速度的函数。对于在快速网络上使用快速手机的开发人员和决策者来说，这是隐藏成本的双重威胁。
全球地面真相
决定用于绩效预算的基准是至关重要的。一些团队和企业密切地了解他们的观众，并且可以对当前和潜在用户所在的设备和网络做出明智的估计。然而，大多数人并没有这么简单的基准。从哪儿开始？
两个数字设定了舞台：
- 45％的移动连接发生超过2G全球
- 75％的连接发生在2G或3G上
中位数用户在一个缓慢的网络上。一个辩论的问题是多么的缓慢。
我们在Google的指标显示出冲突的图片（我正在努力弄清楚）。一些系统显示3G用户近100ms的中位RTT。其他的显示中位数用户在一些主要市场中不能发送和接收不到400ms的单个数据包。
我建议我们应该保守。有争议的是，超订购的单元格可以使“快速”网络变得非常缓慢，运输差异可能使TCP效率降低，网络流量的突发性对我们起作用。
Google员工可以访问模拟的“退化3G”网络，以帮助在这些条件下验证其应用的行为。它模拟具有400ms RTT和400-600Kbps吞吐量（加上延迟变化性和模拟分组丢失）的链路。鉴于我们在其他系统中看到的数据冲突，这似乎是基准。
然而，模拟丢包和可变延迟可以使基准测试变得非常困难和缓慢。在DNS查找期间丢失的数据包的影响可能是秒的差异，使得在开发时间之前比较之前/之后的比较令人沮丧。因此，我们的基准应该可能会降低吞吐量/更高延迟的数据包丢失。我们在现实世界的忠诚中失去了我们获得的可重复性，并且能够在不同的变化和产品之间进行比较。关于DNS，TLS，网络拓扑等因素的影响还有很多。对于那些想要深入了解的人，我强烈推荐Ilya Grigorik的“高性能浏览器网络”。只有RRC的覆盖才能使您的时间值多久。
回到我们的基线，我们现在对于我们的模拟网络条件应该是什么：400ms RTT，400Kbps带宽。设备本身呢？
在去年的Chrome Dev Summit上，我讨论了一些热和功率限制因素，从而在台式机和移动设备性能之间产生巨大差异。通过像高速缓存大小这样的芯片设计因素，增加了低端和高端设备性能之间的打呵欠的鸿沟，并且很难知道设置设备基准的位置。幸运的是，这比网络速度更容易：超过一半的美国移动用户在Android设备上。在国外看来，全球的智能手机出货量（和过去5年来一直是）绝大多数是基于Android的。这些设备的平均销售价格在大多数地区都在下降由Android的无处不在和在该生态系统内无情的价格下降驱动。这反过来，驱动一个最重要的趋势，在制定全球网站绩效预算的硬件基础：下一个十亿用户将在很大程度上联机时，他们可以负担得起。这将在可预见的未来推动新兴市场的智能手机平均售价（“ASP”）下滑。这反过来意味着晶体管每美元的所有改进将转化为较低的售价，而不是更快的设备（平均）。
从2016年开始，真正的中位数设备售价约为$ 200。今年的中位数设备更便宜，但其性能大致相当。预计未来几年中期业绩继续下滑。这是我去年推荐的Moto G4的一部分原因，并且今年推荐了Moto G5 Plus。
总而言之，我们的绩效基准测试的全球基准是：
- 〜$ 200（新，解锁）Android手机
- 在一个缓慢的3G网络，仿效于：
- 400ms RTT
- 400Kbps传输
对于大多数技术人员来说，为这种环境建造应用程序也可能在火星上耕作。幸运的是，这个配置可以在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方面，两秒钟是永远的，但我们仍然需要明智的花费。我们需要考虑的因素包括：
- 流程创建时间（Android相对于其他操作系统相对较慢）
- 从磁盘读取字节所需的时间（即使在基于闪存的存储上也不是零）！
- 执行和运行代码的时间
我看到的每个应用程序，它的初始加载速度达到5s，并且首先实现离线，正确地保持在这个2s的预算之下，sub 1s是可能的！但是，先到先得是许多团队的巨大挑战。架构在本地保存上次看到的用户数据，以可靠和一致的方式缓存应用程序资源，并使用服务工作者生命周期来处理应用程序代码升级可能是一项重大任务。
我期待工具在这一领域不断发展。我今天知道的最全面的引导是聚合物应用工具箱，所以如果你不知道从哪里开始，从那里开始。
130-170KB ...当然你在开玩笑！
我们谈论的很多团队想知道是否有可能提供一些有用的东西，只有130KB。它是！所述PRPL图案示出了通过基于路线的认识，粒状（后续页）资源的服务工缓存和巧妙地利用现代协议增强等的攻击性的代码分割的方式HTTP / 2推。
总而言之，这些工具使我们能够在100KB以下的关键路径上提供实用的现代体验。
可悲的是，从一个特定的跟踪来说，很难从页面加载哪些部分是TTI的关键路径资源，但是我并不乐观，但我乐观地看到，工具将快速发展，以帮助我们了解这一关键指标。
无论如何，我们知道这是可能的，即使没有完全放弃框架。双方的Wego和Ele.me与现代工具（内置聚合物和Vue公司，分别），并帮助用户完成实际交易今天。大多数应用程序是少比他们复杂。预算的生活不是饥饿。
预算中的团队工具
获取下预算是很难的，但对企业和用户带来的好处是巨大的。讨论较少的是工程团队及其领导的好处。没有技术主管或PM想要在一个行政人员错误的一边，他们通过电话问道：“为什么我在度假时这么慢？”
这不是理论上的。
我已经看到刚刚完成重建的现代技术团队一小时，因为我们走过他们在现实世界条件下使用他们的“更好”，“更快”的经验的经验。
当产品不符合预期时，每个人都会失去面子。几个计划外的性能消防延迟了新功能的增加，并对队伍士气产生了排水效应。当表现成为危机时，中层管理人员就被抓到是他们的团队所依靠的“狗屎伞”之间，并且对自己的怀疑感到沮丧。更糟糕的是，他们可能会开始怀疑他们的团队。演出危机的另一面是漫长的道路; 组织如何信任团队提供优质的产品？他们是否可以信任TL来推荐新技术或大规模再投资？相反。这是一个糟糕的经历，专门针对开发人员，经常遇到难以置信的压力来解决这个问题 - “ASAP”，而“它”可能是产品建立的核心技术。
在最糟糕的情况下，该产品可能在短时间内无法协助业务。达尔文进程很多，初创公司和小团队投注错误的堆叠，并没有长跑道的好处可能是致命的。更糟糕的是，这可以长时间不诊断。如果整个团队在快速城市网络中携带最新的iOS设备，而产品的经济性则以扩大广泛的观众为前提，那么观众的失败几乎没有得到发挥。
当然，性能不是（整个）产品。许多缓慢或市场限制的产品做得非常好。拥有人们想要的独特服务（并且将脱颖而出）可以覆盖所有这些其他问题。有些人甚至在应用商店中获得成功，摩擦获得的经验是激烈的。但竞争激烈的市场中的产品需要各种优势。
一些具体的工具和技术可以帮助那些采用绩效预算的团队：
- webpagetest.org/easy：这是我们的一次性分析工具。
- WPT脚本：对于不想设置自定义WPT实例并为其WIP应用程序设置公用URL的团队，与WPT脚本集的集成可以成为获取常规“检查”的好方法，
- WPT私有实例：要将WPT直接集成到其CI或提交队列系统中的团队应调查设置私有WPT服务器和硬件
- 脚本灯塔：没有准备好一个完整的WPT实例？脚本灯塔可以帮助您的CI自动分析您的网站和捕获回归
grunt-perfbudget是一个更容易，自动化的WPT测试您的CI。用它！- Speedcurve和Calibre：这些托管服务会随着时间的推移自动跟踪效果，提供卓越的现实世界肠道检查
- Webpack性能预算：对于在构建步骤中使用webpack的团队，启用此配置可为超出预算的资源提供极好的开发时间警告。
- bundlesize和pr-bot允许您设置每个脚本预算，这些预算可以作为您的拉取请求过程的一部分自动执行。推荐的！
打击膨胀的成功往往意味着将警告转变为严重的错误。具有CI或提交队列系统的团队应强烈地考虑不允许破坏（性能）银行的提交。
对于刚开始的团队，我强烈的建议是从一个堆栈开始，对应用程序结构，代码分割和构建目标有很强的意见。今天最好的是：
无论您的团队选择哪种工具，预算都是至关重要的。没有一个，即使是最先进的“轻量级”框架也可以轻松地产生膨胀的，不可用的应用程序。从全球基线开始，只有根据硬性业务分析增加预算是我知道的最好的方法，以确保您的PWA项目对用户而言也是一样，并且在演示中也是如此。
