持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第 30 天，点击查看活动详情
RAIL 模型是 Google 提出来的一个可以量化的测量标准，我们通过这个模型来指导我们的性能优化的目标。
在做网页性能优化的时候，我们做到程度多好才算好，没有一个量化的结果，此时需要有人告诉我们，做到什么程度才算好，RAIL 测量模型告诉我们需要优化到怎样的程度才算好。
它不光有这种指导性的作用，并且它也是我们很多优化的知识点的必备的基础。先了解我们为什么要往这个目标做，然后再看我们怎么去做。
Web 已经出现了有20、30 年的时间。在过去很长的一段的时间里，我们的技术工程师不断的去追求，怎么让我们的 Web 网站或者是 Web 应用变得更快。
我们始终觉得网站不够快，我们终极的理想是什么？我们就希望用户把地址输到浏览器地址栏并回车之后，网站瞬间就能出来。
但是受制于我们的技术、硬件以及物理的原理，我们实际上是做不到这一点的。但是我们现在跟过去 10 年相比，已经有了非常飞速的进步，这也是为什么现在有了这么多 Web 用户。
但是用户多了，随之问题也不断的暴露出来了。以前大家在使用 Web 可能就是一些研究机构或者院校的老师，用户群非常的小，如果性能不好，影响了用户群非常的小。但是现在每天大家都在使用 Web，如果性能不好，这个影响就非常的大。
这个时候 Google 制定一个标准的模型，即 RAIL 模型，告诉大家应该怎么做，做到什么样子才算可以，性能才是好。
什么是 RAIL
RAIL 是 Response、Animation、Idle 和 Load 的首字母缩写，是一种由 Google Chrome 团队与 2015 年提出的性能模型, 用于提升浏览器内的用户体验和性能.。
RAIL模型的理念是以用户为中心；最终目标不是让您的网站在任何特定设备上都能运行很快，而是使用户满意。
RAIL 实际上就是一个标准，它告诉了我们要做到什么样子，怎么去做。
**Response（响应）： **应该尽可能快的响应用户。对于用户而言，当它和我们的网站去进行交互的时候，比如点击按钮或者输入内容之后，网站有没有及时的给出反馈。所以这里的响应并不是请求的那个响应，而是网站给用户的一个响应的体验。应该在100ms内响应用户的操作，虽说是100ms，但预算只有 50ms，因为浏览器内部还有很多工作需要预留时间。
**Animation（动画）： **在展示动画的时候，每一帧应该以16ms进行渲染，这样可以保持动画效果的一致性，并且避免卡顿。我们为了让我们的网站变得更漂亮，给用户体验更好，我们会添加很多的动画。但是动画给用户加的是不是足够的流畅呢？网站如果让用户用起来感觉很卡顿，这肯定就不好。我们添加动画本身出发点是好的，想要给用户体验好，本身它是一件好事，但是没有把它做成好事。因此这个是我们要认真考虑的问题。
**Idle（空闲）： **当使用 JavaScript 主线程的时候，应该把任务划分到执行时间小于 50ms 的片段中去，这样可以释放线程以进行用户交互。我们要让我们的浏览器有足够的空闲时间，这一点和 Response 是相呼应的，能够让用户的交互能够及时的被响应的前提就是要有足够的空闲时间。大家可能都有这样的体验，有时候跟浏览器进行交互的时候，忽然就觉得特别的卡或者根本就动不了，这个时候就说明浏览器主线程非常的忙，已经没有时间来处理这个响应了。这个时候就必须要认真的考虑一下怎么来加大 Idle 的时间，不能让主线程始终是处于一个繁忙的状态。我们可以通过浏览器调试工具的 performance 选项卡，查看一些性能指标。查看主线程情况，每时每刻都在做什么，而且还可以详细去查看它在做什么的时候，具体做的事情，有没有足够的空闲。
**Load（加载）： **网络加载资源的时间。应该在小于 1s 的时间内加载完成你的网站，并可以进行用户交互。用户访问网站的时候，可能就一直看着一个白屏在那里等待。初级的前端工程师，可能就觉得这个网站功能做全了，不报错就已经可以了，对这个不重视。但是用户和开发人员的出发点是不一样的。需要我们换位思考，一开始访问一个陌生的网站，并不知道网站的内容是什么，最直观的感受是网站加载够不够快，如果特别慢，可能就会觉得这个网站可能不是特别的好。
RAIL 评估标准
**响应： **对于 Response，Google 给出的指标是希望我们所有的处理事件能够在 50ms 之内可以去完成。50ms 这个数它是怎么得出来的， Google 有一个非常广的用户基础，向这些用户去发起一个调查，问用户对延时的体会和感受是什么呢？然后把用户的反馈去分成几个组，形成不同的这个区间段。然后通过研究发现用户能够接受的最高的延时是 100ms。所以所有的用户的操作，我们都必须在100ms 之内给出反馈。到这里，有人就会觉得有点矛盾，前面说要 50ms，现在怎么又说 100ms。
我们一起来看一下这张图，相信大家就会非常的清楚了。
我们说的这个 100ms 指的是当用户开始进行交互，或者是进行了输入之后，一直到我们能够给出反馈所经历的时间要在 100ms 之内，但是真正能够做输入处理的时间实际上没有 100ms。当用户去进行输入之后，浏览器还要有时间对输入进行处理，大概是 50ms。保险起见，真正能够用来做事件处理的时间只有 50ms。
**动画： **每10ms 产生一帧。关于动画前面也提到了动画要做的尽可能的流畅。流畅的标准是什么？这个动画呀只有达到 60 帧，也就是 1s要有 60 帧，动画才给人眼的感觉是非常流畅的。是每 10ms 产生 1 帧，是简单的换算。因为希望是 1s 钟 60 帧，大概是 16ms 1 帧 。16ms 和 10ms 的差异是什么？浏览器要去绘制 1 帧，也要消耗一定的时间，大概是 6 ms，因此我们要把这个考虑进去。真正要产生 1 帧动画，要保证在 10ms 之内。
**空闲： **尽可能增加空闲时间。和我们这个第一个响应是相呼应的。我们要尽可能去增加我们的空闲，只有空闲足够多。当用户的交互来的时候，我们才能有足够的时间去进行处理。我们不能让我们的处理时间太长，多长合适。如果前置时间需要 50ms，然后处理时间又是 50ms，那用户的交互来了，你根本就没有时间去进行处理。用户点了页面之后感觉马上卡住了。
此时人可能就说了，那要是这样的话，是不是我们的前端尽可能就什么都不要去做了，加载完了之后，就尽量让页面就摆着即可。
并不是，还是要分下情况，要看到底要做什么，什么是合理的，什么是不合理的。
举个例子，比如为了前端去进行了一些推迟加载的优化。首次加载完之后，后面要用到的内容又利用空闲时间把它慢慢的加载过来，这样做是没有问题的。但是什么是不对，比如一些业务逻辑的计算，把它放在了前端去实现，这就是不合理的了。像一些大量的业务上相关的或者运算相关的实现，我们应该在后台去实现。
**加载： **在 5s 内完成内容加载并可以交互。我们希望能在 5s 之内完成所有内容的加载，并且可以开始进行交互。这个指标是一个非常高的一个要求。这里面分两个层面来介绍：
第一，要完成内容的加载，这 5s 不光是加载这么简单，加载完了还有解析，解析完了之后还要进行渲染。所有的这些时间都要算在内，要在 5s 钟之内完成，这样才能达到让用户可以去进行交互这样的目的。
第二，要考虑到所有的用户不一定都是在使用电脑，有可能他们在使用一些移动设备，还有就是他们所使用的网络环境有可能非常的差。比如有可能还在使用 3G 网络或者所在的位置信号特别的不好，这个加载就会受到影响。
这 4 个指标其实都是我们的一个终极目标。如果真的能把这 4 点全都做到的话，那你的这个网站堪称就是完美了。
但是往往我们还是在优化的路上，我们只能逐步的去发现一些问题，然后去解决这些问题。
性能测量工具
介绍完 RAIL 模型和它相关的指标之后，相当于我们的优化目标已经明确了。我们接下来就要看一下，我们可以利用什么样的性能测量工具，可以帮我们来确定现在所处的一个阶段，距离目标到底还有多大的差距。
Chrome DevTools：开发调试和性能评测。对于这个工具，相信大家都非常熟悉。但是大家可能没有特别多的用过它性能评测相关的功能，大家可能平时用它做什么呀，查看 JS、CSS 以及网络等等。查看网络就已经涉及性能相关的功能。实际上，这个工具非常的强大，它所包含的功能远远不止这些，后面我们在详细介绍该工具。
Lighthouse：它是 Google 推出的。它跟其他的性能测试工具不太相同，它提供了一站式的一个质量评估。利用它不光是能看网站的性能如何，它还能测试其他工能，比如网站的 SEO 如何，网站的可访问性如何，网站是否是做了渐进式的网络应用的开发等等，都可以以做出很好的评估。而且还能给我们提出很多很好的建议，告诉我们如何去进行性能相关的改进。
WebPageTest：这个工具非常的好用，可以直接通过它的网站就可以对我们网站来进行性能的评估。而且它最大的优势在于它提供了很多的测试地点。可以在很多的位置去发起测试，了解在全球不同位置的用户访问我们的网站的时候，它性能体验如何。
