什么是Web应用的性能?
Web应用的性能体现在哪些方面?
怎么样来评价一个Web应用性能的好坏?
这几个看起来是个很傻的问题。
对的,这几个问题的确很傻,Web应用的性能好差不就是根据用户用起来爽不爽来评价么是的。性能主要是满足用户的需求，让用户满意。
我们在开发的过程中,由于自己对应用业务的熟悉程度和用户不一样,所以,我们自己在使用我们自己的应用时间,体验可能会跟用户的体验不一样。因此,需要一些具体的评价指标和工具来帮助我看在开发的过程中更好的检验我们开发的应用的性能。下面介绍下RAIL模型来评估应用性能。
Web应用性能概述
RAIL是一种以用户为中心的性能模型。 每个网络应用均具有与其生命周期有关的四个不同方面，且这些方面以不同的方式影响着性能：
- 以用户为中心；最终目标不是让您的应用在任何特定设备上都能运行很快， 而是使用用户满意。
- 立即响应用户； 在100毫秒以内确认用户输入。
- 设置动画或滚动时， 在10毫秒以内生成帧。
- 最大程度增加主线程的空闲时间。
- 持续吸引用户，在1000毫秒以内程现内容。
使用RAIL模型评估应用性能
关注用户感知，把用户体验当作为你努力的焦点。
下表描述了用户感变化与性能延时的关系：
用户对性能的感知
| 时间 | 用户感知 |
|---|---|
| 0 - 16ms | 用户特别擅长跟踪动作，他们不喜欢不流畅的动画。用户感知到动画，因为每秒都有60个新帧渲染出来。 也就是每16ms秒1帧，包生成帧和浏览器把帧渲染到屏幕的时间，也就是说，应用可以有大约10毫秒的时间来生成一帧。 |
| 0 - 100ms | 当咋就用户操作在100ms以内时， 用户感知是立即响应。 如果超出了这个范围，用户就感觉到操作和响应不是连续的。 |
| 100 - 100ms | 用户会感觉到轻微的延时。 |
| 300 - 1000ms | 在这个窗口中，事物感觉是任务的自然和持续进展的一部分。 对于网络上的大多数用户来说，加载页面或更改视图代表了一项任务。 |
| 1000ms 以上 | 超过1秒， 用户关注的焦点会从他们正在执行的活动中转移。 |
| 10000ms 以上 | 超过10秒， 用户会感到扫兴，或许会终止他们正当前的活动，也许再也不回来了。 |
要根据 RAIL 指标评估您的网站，请使用 Chrome DevTools Timeline 工具记录用户操作。然后根据这些关键RAIL指标检查Timeline中的记录时间。
Response
在100ms以内完成响应用户操作的过渡动画。 用户花费的时间大部分应该待应用响应他们的输入，而不是等待网站加载。
- 在50ms以内响应用户操作
- 虽然， 看起来有点不合常理，并不在所有情况的可以立即响应用户输入。有的时候可以在100ms以来执行其它比较耗时的操作。但是需要注意的不要中断用户操作，在后台执行异步操作。
- 大于50ms的操作，需要提供提示。
Animation
需要在10ms以内生成帧。技术角度上，每帧最大限度上允许有16ms,但是浏览器需要大约6ms的时间来渲染一帧，因此，建议10ms每帧。
保证视觉上流畅， 用户能察觉到帧率的变化 。 - 在如动画等压力大的情况下，尽可能少的执行计算和操作。在允许的情况下，
预先计算和缓存花费时间的工作，以保证有机会达到60fps。 - 在不同场景下优化动画。
- 意识到所有的动画类别。 动画不仅是花俏的用户界面效果。以下每一种交互都被当作动画。
- 使用空闲时间执行延迟任务。例如， 在页面初始化的时候，尽可能减少加载的数据，然后在空闲的时间去加载剩余的。
- 在空闲时间执行任务在50ms以内，否则，有可以会引起应用响应用户输入超出50ms的风险。
- 在空闲时间执行任务时，如果有用户交互操作，用户交互应用有更高的优先级，并且中断当前空闲执行任务。
Load
当页面加载慢时，用户的注意力会转移，用户会感觉到操作被中断。加载快的网站，会有更长的会话，更低的跳失率，以及更高的广告可见性。
- 根据用户使用的设备和网络情况优化加载性能。
- 渐进性的加载，尽可能在2s内完成页面加载。
