（二）性能优化的指标和工具 (告别前端小白，成为大神的必经之路)

为什么要进行前端性能优化

互联网发展得很快，我们现在做的内容越来越多，功能越来越强大，页面越做越漂亮，内容多了速度会受到影响，用户希望速度越来越快，这对于前端工程师挑战越来越大，我们只有对我们的网站进行持续的优化，才能保证在发展过程中网站速度跟得上用户体验的需求

现在的搜索引擎都会对网站性能进行评估，高性能网站会出现在结果排名中更前的位置

寻找性能瓶颈

了解性能指标-多快才算快

利用测量工具和APIs

优化问题，重新测量（迭代）

移动端挑战多

设备硬件，网速，屏幕尺寸，交互方式

移动端用户更缺少耐心，>3s加载导致53%的跳出率（bounce rate）

持续增长的移动用户和移动电商业务

性能指标和优化目标【了解行业标准】

这边结合淘宝网站的例子

网络加载性能

打开淘宝网站，点击network>network setting,勾选如下三个复选框

进行清空缓存并硬性重新加载

上图红色框选的为概要信息
0 / 63 requests 共63个请求
0 B / 1.2 MB transferred
0 B / 1.9 MB resources 总资源量1.9M
Finish: 2.1 min
DOMContentLoaded: 573 ms DOM完成的加载时间
Load: 770 ms 总资源的加载时间

瀑布图（网站的资源加载以瀑布的形式表达出来）如下

横向看是具体的一个资源的加载，有色块来表达加载的过程，色块有不同的颜色，说明一个资源的加载不是下载一个简单的单一过程，是经历了很多环节，悬浮在色块上可以看到如下详情列表

Queueing 资源需要经过排队才能从浏览器发出去，浏览器会对资源请求进行优先级安排，高优先级的内容先安排进行请求
DNS Lookup 每个资源实际上有个域名，域名最终要被翻译成ip，然后找到这个服务器，所有有这个DNS查找的过程
Initial connection找到资源之后，客户端与服务器要建立链接，这是我们TCP链接建立的过程
SSL 有的网站是https的，为了保证安全性，使用了SSL证书，SSL的工作原理是什么，最上来开始要进行安全性验证，管这个过程叫SSL协商，这个过程也会耗时
Request sent 请求发送出去
Waiting(TTFB) 发送出去请求到资源真正回来中间的等待时间，请求发出到请求回来经历多久的时间，这个参数很重要，能给用户最直观感受网站快慢的参数，如果TTFB高的话，相当于请求发出去了，资源一直没回来，浏览器这边就是白屏，如果很快的话，资源回来之后就可以快速进行解析和渲染及后面的一些步骤，它有两个重要的影响因素：一个是后台的处理能力，服务器响应有多快，这个请求到了后台之后，后台可能还要去查数据库，可能还要对数据进行组织和处理，才把数据返回，最主要的是表达了后台的处理能力，其次是你的资源，这条回路网络的一个情况，我发出去请求，然后回来到底会不会有延时
Content Download下载，如果下载的蓝条越长，说明这个资源越大，过长肯定不好，因为资源下载时间越长，等待的时间就越长，尤其有些资源还会造成堵塞，就是如果它本身一致在下载，它后面的资源都无法加载，只能等它完了之后才能再继续，这样会对我们浏览器的加载过程整体的时间造成延误

纵向看：
1.资源与资源之间的联系：如果发生了堵塞，我们会发现资源是串行的，一个个按顺序加载，如果是并行，就可以加快这个过程，这是我们优化的一个点，期望有些资源可以进行并行加载
2. 关键的时间节点：一根蓝线一根红线，蓝色表示DOM加载完成时间，红色表示页面上所有资源加载完成的时间

network内容比较多，一次分析不完或者后面想再进行分析，可以把结果保存下来，可右键点击空白处，Save all as HAR with content，保存所有的内容为HAR，HAR是web的一个标准格式，主要是将我们性能测试的结果保存起来，以方便我们后续继续使用，或者在其他性能分析工具中继续分析，它是统一的标准

Lighthouse是google给我们集成到chrome里的一个性能测量工具

如上图报告，可以看出
满分100分，这次测试得分82，我们每次测试时网络情况是会变化的，所以你的测试结果不能每次保证一样，所以使用测试工具时，建议多测几次，取一个平均的情况
First Contentful Paint：第一个有内容的绘制出现的时间，内容也包括文字或者图片，主要不再白屏，出现了内容，我们认为这个时间就是我们记录的时间，从白屏到真正出现内容一共2.6s，黄色表示warning，稍微有问题，可以进行改进；红色表示问题比较大的，需要严重优化的东西；绿色是做得非常好

Speed Index 速度指数，速度指数标准是4s，如果你比4s小，你的网站是快的，如果比4s大，那是要进行优化的，这也要根据网站的性质来看，比如google、百度搜索引擎的首页，页面上内容比较少，性能测试出来会很好，但是淘宝首页内容比较多，电商网站想要在首页展示更多的内容，更多的商品，会用很多图片，网页速度会受到影响，所以不能一概追求指标，指标对我们来说是指导性的作用，它是我们的一个目标，我们只能不断地去优化，并不一定能够真正达到它给我们指定的这个最优的结果

交互体验

网站加载完成之后，用户真正开始使用网站，在这个过程中的交互体验，记住三点
1.交互响应做到足够快，比如点击一级菜单是否能马上列举出二级菜单的内容，搜索结果响应快
2.画面要足够流畅，内容往下滚动画面卡卡的，网页动画卡卡的，这是因为做的内容没有达到一定的帧数，比较流畅的帧数标准是60帧/s，如果低于这个标准就会觉得卡，f12里command+shift+p，输入frame，选择下图红框

会出现如下监控，我们可以用它来看我们画面上的帧数

3.所有的异步请求都能足够快，多快算快，1s，希望所有的异步请求能在一秒之内把数据返回回来，如果返回不回来怎么办？可以做压缩，如果压缩完了还是返回不回来，就可以考虑前端交互上的一些优化，比如加loading动画

总结

性能优化-加载
1.理解加载瀑布图
2.基于HAR存储与重建性能信息
3.速度指数（Speed Index）
4.重要测量指标：Speed Index，TTFB，页面加载时间，首次渲染时间

性能优化-响应
1.交互动作的反馈时间
2.帧率FPS
3.异步请求的完成时间

RAIL测量模型【黄金指南】

RAIL是google提出来的可以进行量化测量的标准，通过这个模型可以指导我们性能优化的一个目标

什么是RAIL

Response 响应，网站给用户响应的一个体验
Animation 动画，动画流畅度
Idle空闲，要让浏览器有足够的空闲时间，实际上这个第一点Response是相呼应的，交互及时被响应的前提是你要有足够的空闲时间，当浏览器进行交互时，突然觉得特别卡，或者卡死动不了，说明浏览器主线程非常忙，已经没有时间处理你的响应了，这时候就要考虑怎么加大Idle空闲时间，不能让主线程始终处于繁忙状态，这样没有足够时间来处理用户交互

如上图可以看到主线程每时每刻都在做什么，它有没有足够的空闲，还可以打开详细，去查看它在做什么的时候具体做的一些事情
Load加载，资源网络加载的时间

RAIL的目标

让良好的用户体验成为性能优化的目标

RAIL评估标准

响应：处理事件应在50ms以内完成，50ms这个数是怎么得出来的？实际上google有非常广的用户基础，会像这些用户发起调查，对延时的体会和感受，把用户反馈分成几个组，形成不同的区间段，发现用户能接受的最高延时是100ms，所以所有的用户操作，我们必须在100ms内反馈，这里说的100ms是当用户进入交互进行输入之后一直到给出反馈所经历的时间，但我们能真正做输入处理的时间没有100ms，浏览器还要对输入进行处理，这个要留个保守的时间，大概50ms

动画：每10ms产生一帧，60帧/s换算后一帧是1/60，大概是16ms，中间差了6ms，浏览器去获取这一帧，实际上也要些时间，大概6ms左右，这个也要考虑进去，所以我们产生一帧要保证在10ms之内
空闲：尽可能增加空闲时间，与响应是相呼应的，只有空闲足够多，当响应来的时候，我们才有足够的时间去进行处理，不能让我们的处理时间太长，多长是长，50ms，如果前置时间50ms，处理时间50ms，那用户的交互栏根本没时间去处理，用户点击后就会感觉卡住了，后面要用到的内容利用空闲时间慢慢加载可以，一些业务逻辑计算放在前端做是不合理的，大量业务相关运算相关的内容，应放在后台做
加载：在5s内完成内容加载并可以交互，其实这5s是非常高的要求，分两个层面开看，第一个层面，要完成内容的加载，这5s不光是加载这么简单，加载完了还要解析，解析完了还要进行渲染，所有这些时间都要算在内，这样才能达到用户可以进行交互的目的；第二个层面我们要看的是，使用的移动设备，网络环境有可能非常差

性能测量工具

Chrome DevTools开发调试、性能评测
Lighthouse网站整体质量评估，不光可以看网站性能，还能看seu，网站可访问性如何，是不是做了渐进式的网络应用开发等等，还能提出一些建议，告诉你怎么进行相关的改进
WebPageTest多测试站点、全面性能报告，可以在很多位置发起这个测试，来了解你在全球不同位置的用户访问你的网站性能体验是怎么样的

使用WebPageTest评估Web网站性能【快捷好用的在线分析工具】

访问https://webpagetest.org/，输入测试网站地址
Test Location选择测试地点
Browser选择浏览器
Connection配置网络连接的情况
Number of Tests to Run表示测试轮数
Repeat View结果视图，通常选择First View and Repeat View，用户首次访问页面和第二次访问，可以对静态资源做缓存，第二次访问肯定比第一次快，所以通过这两个视图的对比，可以看出缓存的工作做得好不好；Capture Video，捕捉视频，如果你选的是Chrome，这个可以勾选上，测试完成后会给你录一个截屏，是一段视频，你可以非常直观的通过这段视频了解到你的用户在这指定的设备上访问的一个体验
开始测试后，结果如下

上面是一个总结，下面是每一轮测试的具体详情
First Byte 发出去的第一个请求，它得到响应的时间是多久，反应了后台的处理能力和网络回路的一个情况
Start Render首屏渲染，这是体验的第一步，我要看到内容，而不是一直白屏
Speed Index 速度指数
Total Blocking Time 页面被阻塞住了，用户不能进行交互，这个时间累积有多长，绿色代表是达标的
下图是第一轮的详情，从图中可以看出First view的时间是4.892s

点击瀑布图可以查看详细信息，拉到最后面有页面可交互的时间（Page is Interactive），这是非常有用的信息，可以看出在整个加载过程中大部分页面都是可以交互的，只有个别阻塞的时候

Browser Main Thread主线程占用情况，什么时候比较忙，整体还可以，大部分空闲还是比较多的
CPU Utilization 带宽、CPU的占用使用情况

上图图片资源有并行同时进行加载，极大的节约了时间，这块消耗时间由最大的图片加载时间决定

上图黄色背景，后面标了302，重定向，也就是我们这个资源不在原来你请求的位置了，需要进行重定向才能找到真实的位置，这就提示我们这个地方可以做个优化，可以直接去访问重定向的那个地址，这样可以省出这个请求的时间

解读WebPageTest的报告

waterfall chart请求瀑布图
first view首次访问
repeat view二次访问

WebPageTest

在线进行网站性能分析
如何本地部署WebPageTest工具
安装docker
docker pull webpagetest/server
docker pull webpagetest/agent
docker run -d -p 4000:80 webpagetest/server
docker run -d -p 4001:80 --network=“host” -e “SERVER_URL=http://localhost:4000/work/” -e “LOCATION=Test” webpagetest/agent
制作一个自定义镜像，方便日后再次进行部署或者安装
mkdir wpt-mac-server
cd wpt-mac-server
vim Dockerfile

vim locations.ini

docker build -t wpt-mac-server .
cd …/
mkdir wpt-mac-agent
cd wpt-mac-agent
vim Dockerfile

vim script.sh

chmod u+x script.sh
docker build -t wpt-mac-agent .

使用LightHouse分析性能【一站式全面呈现性能指标】

LightHouse是google开源的项目，之所以会使用很多的性能测量工具，是因为每个工具都有自身的特点，LightHouse除了会帮我们生成完整的性能测试报告之外，还会给我们提供很多有针对性优化的建议

使用

npm install lighthouse -g
lighthouse url
会出现如下页面

当看到如下地址内容时，说明测试报告已经生成

把地址拷贝到浏览器里就可以看到测试报告内容

Performance：性能
Accessibility：可访问性
Best Practices：最佳实践
SEO：对搜索引擎有没有做优化
Progressive Web App（PWA）：google一直在推的概念，渐进式应用的加载，包括离线也能给客户进行访问的体验
这些是对网站整体质量的评估
下面先看看网站的性能

First Contentful Paint：第一个有内容的绘制时间，6.2秒有点长，资源考虑压缩

Speed Index 速度指数，页面上所有可见内容多久让用户看到，9.8s太长

Largest Contentful Paint：所有可见资源里最大的那个花了多久看到

Time to Interative：什么时候用户可以和你的网站进行交互，这是很重要的用户体验，上图中有10个截屏，这10个截屏表现了用户最开始访问一直到整个页面出来经历的过程，10张里有7张是白的，这说明没有做很好的渐进式优化，首屏不是逐步加载出来的，而是突然出来的，这体验很不好
下图

Opportunities部分

会提供一些优化建议，会告诉你应该做什么，做了这项大概能提升多少

Remove unused Javascript，移除没有用到的js，可以提升2.21s，有可能这些是后面使用的资源，可以考虑首屏先不加载，后面再加载
Eliminate render-blocking resources：减少渲染阻塞资源，要看下这个js是不是可以延迟加载，有没有必要在第一时间加载，因为它阻塞了，后面没办法继续，整体加载时间会因它延长，下面测试看它是不是必须的
下图中的log-reporter刚在评估报告中显示会阻塞渲染资源，它在head部分，会第一时间加载和解析，势必会阻塞后面资源的加载

如何确认它是不是必须的，command+shift+p调出窗口，选择第一个

增加log*.js都不让加载的规则，再重新进行加载，把名字为log的文件过滤出来，发现log*.js无法进行加载

再去看看首屏内容有没有受到影响，没有影响说明不是必须的
调试工具里也有lighthouse，如下图，可以勾选设备及测试项（如性能）

Diagnostics

诊断，这里面每一项也是很好的建议

Passed audits

会把测的网站没有问题的项列出来，也可以看看网站哪些地方做得比较好

Lighthouse的安装和使用

本地npm安装Lighthouse
chrome Devtools中使用
通过chrome web store安装插件

使用Chrome DevTools分析性能【最大法宝】

分析自己的一个网站

一共发起了7个请求，请求到的资源总量是2.1兆，dom加载完成时间是1.9s，总的资源加载完成时间3.65s，这两个时间都比较长，因为我们的网站很简单

每个资源都有一些属性：资源名称 大小 总的耗时，总的资源量高达2.1兆，可以点击size大小排序，把资源从大到小进行排序，从图上可以看出第一个资源bundle.js高达1.4兆，因为我们使用webpack进行打包，所有js都打到这里面，相对较大些，可以做些优化和精简，size里上下列出了两个1.4兆，这两个是不同的含义，上面的1.4兆是指这个资源通过网络过来总的实际的大小，下面是指资源本身的大小，网络传输的大小和资源的实际大小可能不相同，怎么才能不相同？在后台把这个资源返回给前端之前可以对资源进行压缩，在网络上经过时这个资源的实际大小会变小，通过这样的方式可以节约资源在网络上的消耗

如上代码对所有的请求资源进行压缩，然后再返回给前端

再次刷新看到，实际大小虽然是1.4兆，但在网络传输时只有429kb，大大减少了通过网络传输的资源大小，可以看到相应的其他所有的资源在网络传输时都被进行了压缩

dom加载时间过长分析

点击performance，可以点击实习圆开始记录，在这个过程中页面所发生的一切包括你的交互，都会被记录下来，至到你点击停止之后，这段过程中发生的一切都会出一个详细的性能报告；还有一种方式是点击刷新按钮，就会刷新我们的页面，记录页面从开始刷新一直到整个所有资源加载完成这个过程所发生的一切，然后进行性能分析，这就是我们关心的网络加载性能，我们点击刷新按钮，经过一段时间就得到我们的性能分析报告

找到Main主线程，可以看到随着时间推移，我们的主线程都做了哪些任务，可以通过滚轮进行放大缩小，点击住拖动画面进行移动，我们看下这个主线程都做了哪些任务，它是自上而下类似堆栈的结构列举的，也就是把我们整个调用关系都很清晰的表示出来，比如说我们做了个Task，Task做了什么事呢，首先分析了脚本，脚本里会有一些相关的调用，一层一层会把我们的调用关系全部都列出来，一直到最后，这非常清晰，有助于我们做具体的一个分析

这边还有个Timings，关键的时间节点，DCL就是dom加载完成时间，它什么时候发生的，发生之前都做了什么，从图中可以看出主线程的任务恰巧是发生在这之前的，这个执行时间很长，很有可能是这个导致DCL来得过于晚，所以了解下主线程到底做了什么

可以将主线程拉到最后面，看看最终调用是什么，因为往往最后调用用到的是我们自己的代码，前面很多可能都是框架本身的一些内容，可以看到最后一直在忙碌的做calculatePi这个函数，这是我们故意在代码里埋下的长任务
打开代码看下

看到这个组件在构建的时候调用了calculatePi函数，制造了1.5s的延迟，这个函数就导致了加载的过程被堵塞，有1.5s的延迟
通过performance这个工具，可以很好的定位出导致这些产生长任务甚至堵塞的一些任务的发生原因及具体的函数位置

Disable cache，开发过程中要修改很多代码，如果有缓存，修改的代码不能立即生效，看到的还是缓存效果，所以通常开发时会把这个勾选上；但当我们进行性能评测时，要把这个勾选去掉，因为我们更关心用户在第二次第三次访问时设置的缓存有没有生效，因为这些缓存会提高再次访问的速度

网络吞吐：可以调整我们现在网络的状态，模拟用户网络情况，比较快的3g，比较慢的3g，离线，也可以自定义添加网络吞吐情况，比如添加自定义4g，4g大概下载速度在5-12兆，所以设置Download为5120，上行速度一般是2-5兆，所以设置Upload为下限2048，Latency延迟，考虑到用户所在位置信号不是很好，延迟比较高，设置800ms

常用的功能点击esc会列举出来，相当于另外一个功能菜单，把我们之前经常用的功能都列在这，例如Request blocking让一些资源不能进行加载，之后对我们网站有什么影响，会不会导致性能提升还是网站功能异常了

Rendering渲染也是我们关心的一块，比如FPS刷新频率，Paint flashing当我们页面滚动时可以标记出哪些地方发生重绘，因为重绘制是对性能影响比较大的一块内容，要避免重绘事件的发生，提高网站性能

Performance monitor：性能监测，可以看到cpu使用情况，js堆占用情况，当前页面dom节点数，dom节点数也是影响比较大的，dom节点数越多，层级越深，对性能影响越大，还有布局、样式的重新计算，这些都可以通过monitor进行监测

使用Chrome DevTools进行性能测试

Audit(Lighthouse)
Throttling调整网络吞吐
Performance性能分析
Network网络加载分析

常用的性能测量APIs

经常需要真正实时获取用户在真实使用过程中性能的数据，这时候就需要用web提供的标准api进行动态测量

Web标准APIs

关键时间节点（Navigation Timing，Resource Timing）
网络状态（Network APIs）
客户端服务端协商（HTTP Client Hints）& 网络显示状态（UI APIs）
之前的性能测量工具都有一些关键的时间节点，比如TTFB、首屏等，这些时间节点是通过浏览器按照标准实现的特定的api获取的

拿到这个数据后可以发送给后台，这样就可以上报实时的性能数据信息

DNS 解析耗时: domainLookupEnd - domainLookupStart
TCP 连接耗时: connectEnd - connectStart
SSL 安全连接耗时: connectEnd - secureConnectionStart
网络请求耗时 (TTFB): responseStart - requestStart
数据传输耗时: responseEnd - responseStart
DOM 解析耗时: domInteractive - responseEnd
资源加载耗时: loadEventStart - domContentLoadedEventEnd
First Byte时间: responseStart - domainLookupStart
白屏时间: responseEnd - fetchStart
首次可交互时间: domInteractive - fetchStart
DOM Ready 时间: domContentLoadEventEnd - fetchStart
页面完全加载时间: loadEventStart - fetchStart
http 头部大小： transferSize - encodedBodySize
重定向次数：performance.navigation.redirectCount
重定向耗时: redirectEnd - redirectStart

通过api发现长任务，这样可以实时监测和上报


你做的是视频网站，如果用户不再看你这个页面了，这时候需要考虑节流，不再进行视频内容的加载

let vEvent = 'visibilitychange'
if(document.webkitHidden != undefined) {
	// webkit事件名称
	vEvent = 'webkitvisibilitychange'
}
function visibilityChanged () {
	// 页面不可见
	if (document.hidden || document.webkitHidden) {
		console.log('Web page is hidden')
	} else {// 页面可见
		console.log('Web page is visible')
	}
}
document.addEventListener(vEvent, visibilityChanged, false);

然后在页面上切换tab进行测试

判断当前的网络状态进行有针对性资源的加载，网络状态不好时使用稍微模糊的图片