性能指标和优化目标之：加载
性能指标：我们在性能优化过程中可以参考的标准。这些标准都是业界或者前人总结出来的指导性经验。我们可以参考这些指标，去指导我们自己的优化。
瀑布图 Waterfall
瀑布图可以非常直观地把网站的加载过程，用自上而下的方式表达出来，就像瀑布一样。
瀑布图有两中解读方式：一种是横向看，一种是纵向看。
1、横向看：
横向看的是具体的资源，每一行代表某个资源的加载信息。里面有一些色块来表达加载的过程，每个块的颜色不同。也就是说资源的下载不是单一的过程，而是经历了很多环节。
为了了解资源的具体加载过程，我们把鼠标悬浮在第一个资源的色块上，可以看见一个详情列表： 1）等待：
- Queueing：排队。浏览器会对资源的请求做优先级排序。
（2）连接：
- DNS Lookup：DNS域名解析。每个资源都有域名，对域名做DNS解析，然后找到对应服务器的IP地址。
- initial connection：客户端和服务器之间建立TCP连接。
- SSL证书：该网站为了保证安全性，使用了 https 协议，启用了SSL证书。启用之后，需要做安全认证（SSL协商），这个过程也会耗时。到这里位置，我们可以看到，在请求资源之前，有很多的前置步骤。
（3）请求和响应：
- Request sent：到这一步，真正开始请求资源。
- Waiting（TTFB）：资源从请求到响应，有一个等待的时间。
- Content Download：收到响应后，资源的下载时间。如果值越大，表明下载时间越长。有些同步加载的资源会造成阻塞，导致网页的整体加载时间过长，让用户等待太久。
TTFB 是一个很重要的指标，它表示的是：请求发出到响应，到底要经历多久。TTFB 可以给我们一个很直观的感受，我们网站的请求和响应到底是快还是慢，很大程度上是由 TTFB 决定。
影响 TTFB 的因素是什么呢？比如：
- 后台的处理能力的响应速度。
- 网络状况：是否有网络延迟。
2、纵向看：（主要看两点）
（1）看资源与资源之间的联系：如果发生阻塞，说明资源可能是串行地按顺序加载。可以按需要适当调整为并行。
（2）看关键的时间节点。Waterfall 中有两根时间线：蓝色的线是 DOM 加载完成的时间，红色的线是所有资源加载完成的时间。
性能指标和优化目标之：交互
上面的内容讲的是加载的性能，还有一个需要关注的性能指标是交互。也就是网站加载完成后，用户真正开始使用这个网站过程中的的交互体验。
关于交互体验的性能，我们需要关注的是：
- 交互动作的响应时间要短：比如点击按钮后的弹窗、在搜索框里输入关键字后的搜索结果。
- 页面滚动要流畅：可以查看 FPS 帧率。
- 异步请求接口的完成时间要短：比如关注/取关主播的响应、领取红包的操作。
FPS帧率、FRS
这里首先科普两个概念：
- 刷新率：显示器每秒有多少帧画面。大多数显示器的刷新率是60帧/秒（即60hz）。
- 帧率（FPS：frames per second）：视频或者动画的内容本身，每秒有多少帧。由显卡输出帧率。
上面的两个参数中，不要把「刷新率」和「帧率」弄混了。「刷新率」是屏幕的参数，「帧率」是图像、视频等内容的参数。人眼最终看到的效果，是以最低的参数为准的。
目前，市场主流手机和电脑屏幕的刷新率基本都是60Hz，即每秒显示60帧画面。也就是说，当我们在使用手机的时候，本质上是手机在连续播放一张张静态图片，每秒播放60张，让肉眼误认为眼前的画面在动。 持续滑动的过程中，如果页面输出到显示器的帧率低于60帧/秒，则人眼会感觉卡顿。
那么，在浏览器中如何实时显示内容的 FPS 参数呢？打开浏览器的控制台后，按住快捷键「Cmd + Shift + P」，然后输入 frame，选择Show frames per second（FPS） meter。
温馨提示：
从 2020年7月起，chrome 官方已经取消了 fps参数的显示，改为了 FRS
用 RAIL 模型测量性能
RAIL 模型是Google提出的可以量化性能的测量标准。我们做性能优化时，要尽可能到这个标准。
在做性能优化的时候，我们需要有人告诉我们：做到多好才算好？有没有一些通用的标准？而 RAIL 模型 可以给我们带来量化的指标。
RAIL 模型包括四个方面：
-
Response：响应
-
Animation：动画
-
Idle：空闲时间
-
load：加载
-
RAIL 的目标：
-
让良好的用户体验成为性能优化的目标
接下来，我们再看看看 RAIL 的评估标准。
1、响应
目标：处理用户发起的响应，应该在 50ms 内完成。
准则：
- 在50毫秒内处理用户输入事件。这适用于大多数输入，如点击按钮、切换表单控件或启动动画。这不适用于触摸拖动或滚动。
- 对于需要超过50毫秒才能完成的操作，需要提供反馈。
-
2、动画
目标：在10毫秒或更短的时间内制作出动画中的每一帧。（即：100帧/秒。）
我们知道，当动画的帧率是 >= 60帧/秒 的时候，人眼才不会觉得卡顿。此时的理论值为 1000毫秒/60帧 = 16.6 毫秒/帧。
10毫秒和16毫秒之间，隔了6秒。这6秒是什么呢？因为浏览器需要大约6毫秒的时间来渲染每一帧，所以，每一帧的准则建议是10毫秒，而不是 16.6毫秒。
假设动画本身是60帧/秒，那么，最终渲染出来的效果可能只有 45帧/秒。
广义的动画：
动画不仅仅是花哨的UI效果。每一种交互都被认为是动画。比如：
- 视觉动画
- 滚动
- 拖动、平移元素、放大图片等。
3、空闲时间
目标：最大化闲置时间，增加页面在50毫秒内响应用户输入的几率。
这个空闲时间，是和上面的第一点“响应”是结合在一起的。只有空闲足够多，当用户的交互来的时候，我们才能有足够的时间进行处理。
准则：
- 利用空闲时间做延迟加载。例如，页面在初始化的时候，尽可能少的加载数据，然后利用空闲时间加载其余部分。
- 在空闲时间内处理任务，时间不能超过50毫秒。否则，就阻塞了用户做其他的输入请求，导致卡顿。
- 如果用户在闲置时间工作期间与页面进行交互，那么这个交互应始终处于最高优先级，并中断闲置时间工作。
4、加载
目标：在5秒或更短的时间内加载页面并可以交互。
准则：
- 这里的5秒包括：加载、解析、渲染，并确保用户可以交互。
- 加载的过程中，可以使用loading框、进度条、骨架屏等方式缓解用户焦虑。
使用Chrome DevTools 分析性能
现在主流的性能测量工具：
- Chrome DevTools：开发调试、分析性能。
- Lighthouse 网站整体质量评估。
- WebPageTest：给网站提供多个地点的测试，以及全面的性能报告。
这一段，我们先来讲一讲 Chrome DevTools 。
大家平时在用 Chrome DevTools 的时候，一般使用来开发调试、查看 DOM、css、接口请求等，但其实，这个工具非常强大。
size：文件大小分析
可以把size从到小排序，看看哪个资源的文件较大。
另外，上图中的横线处说明：该文件在网络传输的时候会做压缩（125kb），拿到资源之后再解压还原（526kb）。
performance：性能表现
preformance的两个作用：
- Record button：记录页面加载、用户交互等全过程，直到我们手动点击停止按钮。
- Reload button：记录页面从刷新到资源加载完成的过程。会自动停止记录。
参数解读：
- Timing：关键的时间节点。
- Main：主线程做了哪些任务，以及调用关系。
Timing参数中，尤其注意看DCL（DOMContentLoaded），即DOM加载完成的时间节点。我们可以通过Main参数看看DOM在加载完成之前，都做了些什么事情。很有可能就是这些事情导致 DCL的时间过晚。
我们可以翻到Main里的最后一行（即最终调用的位置），往往这个位置就是我们自己写的代码。
Diable cache
上图中的Diable cache是一个很重要的设置选项。
勾选Diable cache：
- 不走缓存，相当于页面初次访问。
- 如果你希望改的代码立即生效，就一定要勾选上。
不勾选Diable cache：
- 走缓存，相当于页面二次、三次访问。
- 很多时候，我们需要关心用户在第二次、第三次访问时候，他的访问速度如何、性能如何、我们设置的缓存有没有生效。此时就不要勾选上。
