用RAIL模型测量性能RAIL是一个以用户为中心的性能模型，它提供了一个考虑性能的结构。该模型将用户体验分解为关键操作（例如，单击、滚动、加载）并帮助您定义每个操作的性能目标。RAIL代表Web应用程序生命周期的四个不同方面：响应、动画、空闲和负载，响应、动画、空闲和负载的缩写。用户对这些上下文中的每一个都有不同的性能期望，因此性能目标是根据用户如何感知延迟的上下文和UX研究来定义的。以用户为中心使得用户成为绩效工作的重点。下表描述了用户如何感知性能延迟的关键指标：用户对性能延迟的感知0到16毫秒用户非常擅长跟踪运动并且不喜欢在动画不稳定时进行跟踪。只要他们每秒渲染60个新帧，他们就会认为动画是流畅的。这是每帧16毫秒，包括浏览器将新帧绘制到屏幕所花费的时间，应用程序生成一个帧大约需要10毫秒。0到100毫秒在此时间窗口内响应用户操作，用户感觉结果立竿见影。如果超过这个延迟，动作和反应之间的联系就会被打破。100到1000毫秒在此窗口内，事情感觉像是任务的自然和连续进展。加载页面或更改视图是网络上大多数用户的任务。1000毫秒或更多超过1000毫秒（1秒），用户就会失去对他们正在执行的任务的关注。10000毫秒或更多超过10000毫秒（10秒），用户会感到沮丧并可能放弃任务。他们以后可能会也可能不会回来。目标和指南在RAIL的上下文中，术语目标和指南具有特定含义：目标：与用户体验相关的关键性能指标。例如，单击会在100毫秒内呈现。由于人类的感知相对稳定，这些目标不太可能很快改变。指南：帮助您实现目标的建议。这些可能特定于当前的硬件和网络连接条件，因此可能会随着时间的推移而改变。响应：在50毫秒内处理事件目标：在100毫秒内完成由用户输入启动的转换，让用户感觉交互是即时的。指导原则：要保证100ms以内可见响应，在50ms以内处理用户输入事件。这适用于大多数输入，例如单击按钮、切换表单控件或启动动画。这不适用于触摸拖动或滚动。虽然这听起来违反直觉，但立即响应用户输入并不总是正确的做法。您可以将这100毫秒的窗口用于其他昂贵的工作，但要注意不要阻塞用户。如果可能，请在后台工作。始终为完成时间超过50毫秒的操作提供反馈。50毫秒还是100毫秒？目标是在100ms内响应输入，那为什么我们的预算只有50ms呢？这是因为除了输入处理之外，通常还有其他工作要做，并且该工作会占用一部分可用时间来接受可接受的输入响应。如果应用程序在其空闲时间内按建议的50毫秒块执行工作，这意味着如果在这些工作块之一期间发生输入，则它最多可以排队50毫秒。考虑到这一点，可以安全地假设只有剩余的50毫秒可用于实际输入处理。效果如下图所示，它显示了空闲任务期间接收到的输入如何排队，从而减少了可用的处理时间：动画：在10毫秒内生成一帧目标：在10毫秒或更短时间内生成动画中的每一帧。从技术上讲，每帧的最大预算是16毫秒（1000毫秒/每秒60帧≈16毫秒），但浏览器大约需要6毫秒来渲染每一帧，因此每帧10毫秒是指导原则。以视觉流畅为目标。用户会注意到帧率何时发生变化。指导方针：在动画这样的高压点，关键是能做的什么都不做，不能做的绝对最少。尽可能以100毫秒的响应预先计算昂贵的工作，以最大限度地提高达到60fps的机会。有关各种动画优化策略，请参阅渲染性能。了解所有类型的动画。动画不仅仅是花哨的UI效果。这些交互中的每一个都被视为动画：视觉动画，例如进入和退出、补间和加载指示器。滚动。这包括jerks，用户开始滚动，然后放手，页面继续滚动。拖放操作。动画通常遵循用户交互，例如平移地图或双指缩放。空闲：最大化空闲时间目标：最大化空闲时间以增加页面在50毫秒内响应用户输入的机会。指导方针：利用空闲时间完成延期的工作。例如，对于初始页面加载，加载尽可能少的数据，然后使用空闲时间加载其余部分。在50毫秒或更短的空闲时间内完成工作。再进一步，您可能会干扰应用程序在50毫秒内响应用户输入的能力。如果用户在空闲时间工作期间与页面交互，则用户交互应始终具有最高优先级并中断空闲时间工作。加载：交付内容并在5秒内变为交互当页面加载缓慢时，用户的注意力会分散，用户会认为任务中断了。加载速度快的网站平均会话时间更长、跳出率更低、广告可见度更高。目标：优化与用户设备和网络功能相关的快速加载性能。目前，首次加载的一个很好的目标是在3G连接速度较慢的中端移动设备上加载页面并在5秒或更短时间内与其交互。对于后续加载，一个好的目标是在2秒内加载页面。指南：测试您在用户常用的移动设备和网络连接上的负载性能。您可以使用Chrome用户体验报告了解用户的连接分布。如果您的站点没有可用数据，MobileEconomy2019建议良好的全球基准是中端Android手机，例如MotoG4和慢速3G网络（定义为400msRTT和400kbps传输速度）。此组合在WebPageTest上可用。请记住，虽然您的典型移动用户的设备可能声称它正在使用2G、3G或4G连接，但实际上，由于数据包丢失和网络差异，有效连接速度通常要慢得多。消除渲染阻塞资源。您不必在5秒内加载所有内容即可感觉??已满载。考虑延迟加载图像、代码拆分JavaScript包以及web.dev上建议的其他优化。识别影响页面加载性能的因素：网络速度和延迟硬件（例如较慢的CPU）缓存逐出（cacheeviction）L2/L3缓存分辨率差异用于测量RAIL的JavaScriptTools有一些工具可以帮助您自动化RAIL测量。您使用哪一个取决于您需要什么类型的信息，以及您喜欢什么类型的工作流程。ChromeDevTools以下DevTools功能特别相关：节流CPU以模拟功能较弱的设备节流网络以模拟较慢的连接查看主线程活动以查看记录时主线程上发生的每个事件使用主部分查看发生了什么在页面活动的主线程上。查看表中的主线程活动，根据花费时间最多的活动对活动进行排序。记录页面后，您无需仅依靠Main部分来分析活动。DevTools还为分析活动提供了三个表格视图。每个视图都为您提供不同的活动视图：如果您想查看导致最多工作的根活动，请使用“调用树”选项卡。如果您想查看直接花费最多时间的活动，请使用自下而上选项卡。如果您想按记录期间发生的顺序查看活动，请使用“事件日志”选项卡。分析每秒帧数(FPS)以衡量您的动画是否真正流畅地运行使用性能监视器实时监控CPU使用率、JS堆大小、DOM节点、每秒布局等使用网络部分可视化录制时发生的网络请求在录制时捕获屏幕截图以准确重放页面在加载时或动画触发时的外观等。查看交互以快速识别用户与其交互后页面上发生的情况使用“交互”部分查找和分析录制期间发生的用户交互。通过在潜在问题侦听器触发时突出显示页面来实时查找滚动性能问题。实时查看绘制事件以识别可能损害动画性能的代价高昂的绘制事件。LighthouseLighthouse在ChromeDevTools、web.dev/measure、Chrome扩展、Node.js模块和WebPageTest中可用。您给它一个URL，它会模拟一个具有慢速3G连接的中档设备，在页面上运行一系列审核，然后给您一个负载性能报告，以及如何改进的建议。以下评论尤其相关：responseMaxPotentialFirstInputDelay：根据主线程空闲时间估计您的应用需要多长时间来响应用户输入。通过不使用被动侦听器来提高滚动性能。总阻塞时间。测量页面被阻止响应用户输入（例如鼠标点击、屏幕点击或键盘按下）的总时间。交互时间：衡量用户何时可以与所有页面元素持续交互。Load没有注册控制页面和start_url的serviceworker。ServiceWorker可以在用户设备上缓存公共资源，减少通过网络获取资源所需的时间。移动网络上的页面加载速度不够快。消除渲染阻塞资源。推迟屏幕外图像。推迟加载屏幕外图像，直到需要它们为止。适当大小的图像。不要提供比移动视口中呈现的尺寸大得多的图像。避免链接关键请求。不要对其所有资源使用HTTP/2。高效编码图像。启用文本压缩。避免巨大的网络负载。避免过大的DOM大小。通过仅提供呈现页面所需的DOM节点来减少网络字节数。摘要以用户为中心。在100毫秒内响应用户输入。动画或滚动时，在10毫秒内生成一帧。最大化主线程空闲时间。在5000毫秒内加载交互式内容。更多Jerry原创文章在这里：《王子熙》：
