关于web:什么是-Web-应用性能评测领域的-RAIL-模型

46次阅读

共计 3723 个字符,预计需要花费 10 分钟才能阅读完成。

Measure performance with the RAIL model

RAIL 是一种以用户为核心的性能模型,它提供了一种思考性能的构造。该模型将用户体验合成为要害操作(例如,点击、滚动、加载)并帮忙您为每个操作定义性能指标。

RAIL 代表 Web 应用程序生命周期的四个不同方面:响应、动画、闲暇和加载,即 response, animation, idle 和 load 的缩写。用户对这些上下文中的每一个都有不同的性能冀望,因而性能指标是依据上下文和用户如何感知提早的 UX 钻研来定义的。

Focus on the user

让用户成为性能工作的焦点。下表形容了用户如何感知性能提早的要害指标:

用户对性能提早的认识

  • 0 到 16 毫秒 用户十分善于跟踪静止,并且不喜爱动画不晦涩时的跟踪。只有每秒渲染 60 个新帧,他们就会认为动画很晦涩。这是每帧 16 毫秒,包含浏览器将新帧绘制到屏幕所需的工夫,让应用程序生成一个帧大概须要 10 毫秒。
  • 0 到 100 ms 在此工夫窗口内响应用户操作,用户感觉后果是空谷传声的。如果超过这个时延,口头和反馈之间的分割就被突破了。
  • 100 到 1000 ms 在这个窗口内,事件感觉是工作天然和间断停顿的一部分。对于网络上的大多数用户来说,加载页面或更改视图是一项工作。
  • 1000 毫秒或更多 超过 1000 毫秒(1 秒),用户会失去对他们正在执行的工作的注意力。
  • 10000 毫秒或更多 超过 10000 毫秒(10 秒),用户感到丧气并可能放弃工作。他们当前可能会也可能不会回来。

Goals and guidelines

在 RAIL 的上下文中,术语指标 (goals) 和指南 (guidelines) 具备特定含意:

指标: 与用户体验相干的要害性能指标。例如,点击即可在 100 毫秒内渲染。因为人类的感知是绝对恒定的,这些指标不太可能很快扭转。

准则: 帮忙您实现目标的倡议。这些可能特定于以后的硬件和网络连接条件,因而可能会随着工夫而扭转。

Response: process events in under 50ms

指标:在 100 毫秒内实现由用户输出启动的转换,让用户感觉交互是即时的。

准则:

为确保 100 毫秒内的可见响应,请在 50 毫秒内解决用户输出事件。这实用于大多数输出,例如单击按钮、切换表单控件或启动动画。这不适用于触摸拖动或滚动。

只管这听起来有悖常理,但立刻响应用户输出并不总是正确的做法。您能够应用这个 100 毫秒的窗口来做其余低廉的工作,但要留神不要阻塞用户。如果可能,请在后盾工作。

对于须要 50 毫秒以上能力实现的操作,请始终提供反馈。

50 ms 还是 100 ms?

指标是在 100 毫秒内响应输出,那么为什么咱们的估算只有 50 毫秒?这是因为除了输出解决之外,通常还有其余工作要做,并且这些工作占用了可承受的输出响应的局部可用工夫。如果应用程序在闲暇工夫在举荐的 50 毫秒块中执行工作,这意味着如果输出在这些工作块之一期间产生,则它能够排队最多 50 毫秒。思考到这一点,能够平安地假如只有残余的 50 毫秒可用于理论输出解决。下图显示了这种成果,该图显示了在闲暇工作期间收到的输出如何排队,从而缩小了可用的解决工夫:

Animation: produce a frame in 10 ms

指标:

在 10 毫秒或更短的工夫内生成动画中的每一帧。从技术上讲,每帧的最大估算为 16 毫秒(1000 毫秒 / 每秒 60 帧≈16 毫秒),但浏览器须要大概 6 毫秒来渲染每帧,因而每帧 10 毫秒的准则。

以视觉平滑为指标。用户会留神到帧速率何时发生变化。

准则:

在像动画这样的低压点中,要害是在你能做的中央什么都不做,在你不能做的中央相对起码。尽可能利用 100 毫秒响应事后计算低廉的工作,以便最大限度地进步达到 60 fps 的机会。

无关各种动画优化策略,请参阅渲染性能。

意识所有类型的动画。动画不仅仅是花哨的 UI 成果。这些交互中的每一个都被视为动画:

  • 视觉动画,例如入口和进口、补间和加载指示器。
  • 滚动。这包含甩动,即用户开始滚动,而后撒手,页面持续滚动。
  • 拖拽操作。动画通常遵循用户交互,例如平移地图或捏合缩放。

Idle: maximize idle time

指标:最大化闲暇工夫以减少页面在 50 毫秒内响应用户输出的几率。

准则:

利用闲暇工夫实现延期工作。例如,对于初始页面加载,加载尽可能少的数据,而后应用闲暇工夫加载其余的数据。

在 50 毫秒或更短的闲暇工夫内执行工作。再这样上来,您就有可能烦扰应用程序在 50 毫秒内响应用户输出的能力。

如果用户在闲暇工夫工作期间与页面交互,则用户交互应始终具备最高优先级并中断闲暇工夫工作。

Load: deliver content and become interactive in under 5 seconds

当页面加载迟缓时,用户注意力会游移,用户会认为工作已损坏。加载速度快的网站具备更长的均匀会话、更低的跳出率和更高的广告可见度。

指标:

优化与用户的设施和网络性能相干的疾速加载性能。目前,首次加载的一个很好的指标是加载页面并在 5 秒或更短的工夫外在 3G 连贯速度较慢的中端挪动设施上进行交互。

对于后续加载,一个好的指标是在 2 秒内加载页面。

指南:

在您的用户中常见的挪动设施和网络连接上测试您的负载性能。您能够应用 Chrome 用户体验报告来理解您用户的连贯散布。如果数据不适用于您的站点,挪动经济 2019 倡议良好的寰球基线是中端 Android 手机,例如 Moto G4 和慢速 3G 网络(定义为 400 ms RTT 和 400 kbps 传输速度)。此组合在 WebPageTest 上可用。

请记住,只管您的典型移动用户的设施可能宣称它应用的是 2G、3G 或 4G 连贯,但实际上,因为数据包失落和网络差别,无效连贯速度通常要慢得多。

打消渲染阻塞资源。

您不用在 5 秒内加载所有内容即可产生残缺加载的感觉。思考提早加载图像、代码拆分 JavaScript 包以及 web.dev 上倡议的其余优化。

意识影响页面加载性能的因素:

  • 网络速度和提早
  • 硬件(例如,较慢的 CPU)
  • 缓存驱赶(cache eviction)
  • L2/L3 缓存的差别
  • 解析 JavaScript

Tools for measuring RAIL

有一些工具能够帮忙您主动执行 RAIL 测量。您应用哪一种取决于您须要什么类型的信息,以及您喜爱什么类型的工作流程。

Chrome DevTools

以下 DevTools 性能特地相干:

限度 CPU 以模仿性能较弱的设施

限度网络以模仿较慢的连贯

查看主线程流动以查看录制时主线程上产生的每个事件

应用 Main 局部查看页面主线程上产生的流动。

查看表中的主线程流动,以依据占用工夫最多的流动对流动进行排序。

记录页面后,您无需仅依赖 Main 局部来剖析流动。DevTools 还提供了三个用于剖析流动的表格视图。每个视图都让您对流动有不同的认识:

  • 如果要查看导致最多工作的根流动,请应用“调用树”选项卡。
  • 如果要查看间接破费工夫最多的流动,请应用自下而上 (Bottom-Up) 选项卡。
  • 如果要按记录期间流动的产生程序查看流动,请应用“事件日志”选项卡。

剖析每秒帧数 (FPS) 以掂量您的动画是否真正流畅地运行

使用性能监视器实时监控 CPU 使用率、JS 堆大小、DOM 节点、每秒布局等

应用“网络”局部可视化录制时产生的网络申请

在录制时捕捉屏幕截图以精确回放页面加载时页面的外观,或动画触发等。

查看交互以疾速辨认用户与其交互后页面上产生的状况

应用交互局部查找和剖析录制期间产生的用户交互。

通过在潜在问题侦听器触发时突出显示页面来实时查找滚动性能问题。

实时查看绘制事件以辨认可能侵害动画性能的代价昂扬的绘制事件。

Lighthouse

Lighthouse 可在 Chrome DevTools、web.dev/measure、Chrome 扩大、Node.js 模块和 WebPageTest 中应用。你给它一个 URL,它模仿一个 3G 连贯速度较慢的中端设施,在页面上运行一系列审计,而后给你一份负载性能报告,以及如何改良的倡议。

以下审核尤其相干:

response

  • Max Potential First Input Delay:依据主线程闲暇工夫预计您的利用响应用户输出所需的工夫。
  • 不应用被动侦听器来进步滚动性能。
  • 总阻塞工夫。测量页面被阻止响应用户输出(例如鼠标点击、屏幕点击或键盘按下)的总工夫。
  • Time To Interactive:掂量用户何时能够始终如一地与所有页面元素进行交互。

Load

不注册管制 page 和 start_url 的 service worker。Service Worker 能够缓存用户设施上的公共资源,从而缩小通过网络获取资源所破费的工夫。

挪动网络上的页面加载速度不够快。

打消渲染阻塞资源。

推延屏幕外图像(offscreen images). 推延加载屏幕外图像,直到须要它们。

适当大小的图像。不要提供显著大于挪动视口中出现的尺寸的图像。

防止链接要害申请。

不对其所有资源应用 HTTP/2。

无效地编码图像。

启用文本压缩。

防止微小的网络负载。

防止过大的 DOM 大小。通过仅传送出现页面所需的 DOM 节点来缩小网络字节。

总结

  • 以用户为核心。
  • 在 100 毫秒内响应用户输出。
  • 动画或滚动时,在 10 毫秒内生成一帧。
  • 最大化主线程闲暇工夫。
  • 在 5000 毫秒内加载交互式内容。

更多 Jerry 的原创文章,尽在:” 汪子熙 ”:

正文完
 0