前端性能优化01_重要指标和目标

为什么要进行性能优化

性能 - Web网站和应用的支柱

阅读:Amazon发现每100ms延迟导致1%的销量损失

比如电商网站，肯定是希望用户足够的多，客户多浏览商品的人就足够多，下单的人就多。所谓的下单就是转换率，有多少人下单，你的业务才能有多少收益。又例如你做的是一个社交多媒体网站，也肯定希望你的用户足够多，才有人去发布内容，足够有人围观，才能产生一个广告收益。或者和其它平台进行合作进行带货。
现在所有搜索都会对网站进行一个排名，高性能的网站排名靠前，点击的人也会多

寻找性能瓶颈

• 了解性能指标 - 多快才算快：性能提高就是为了把网站做的越来越快，到底多快才算快呢？ 我们得有一个目标，然后朝着目标区努力
• 利用测量工具和APIs：你觉得你的网站慢，到底是多慢呢？ 我们可以借助工具进行量化
• 优化问题，重新测量（迭代）： 优化性能，重新测量，是否达到你的期望。业务不断的发展，规模越来越大，用户越来越多，总就会有新的性能问题暴露出来。优化就要持续的进行

移动端挑战多

我们当下最大的一个挑战就是来自移动端的挑战，互联网大多数用户都是通过移动端进入的，移动端本身的硬件跟不上，再加上用户有时候使用的网络还不好，本省屏幕小，交互方式也与传统不一样。这些 特点对我们来说都是挑战，多数用户缺少耐心，上网时间碎片化。网站加载超过3秒还没有出来，超过一半的用户都不会再用这个网站了

• 设备硬件，网速，屏幕尺寸，交互方式
• 用户更缺少耐心，大于3秒加载导致55%的跳出率（bounce rate）
• 持续增长的移动用户和移动电商业务

性能指标和优化目标

性能指标就是我们进行性能优化的一个标准，这是业界和前人总结出来的一些指导性的东西，我们要做的就是参照这些标准去指导我们的优化。
以淘宝的网页为例

打开调试工具，取消勾选 group by frame
然后，右键左上角选择，清空缓存并硬性进行加载

接下来我们可以发现，淘宝网页一共发了69个请求，总资源量不算太大，才1.7MB左右

而淘宝之前的网页

对于一个电商网站来说，非常希望用户能尽快看到它的产品或者促销活动，会经常使用到颜色丰富的一些图片或者是动画，本身资源大小相对文字就会大一些。这个资源量控制的可以，相对于做了很大的优化。图片相对比较大的资源一半进行了压缩
DOM加载1.8s左右，总的资源加载时间也差不多是1.8s也非常的不错

性能优化–加载

理解加载瀑布图

瀑布图是我们这节重点讲的内容
瀑布图非常直观的把我们网站的加载，用自上而下的方式把它表达出来，就像瀑布一样

瀑布图有两中解读的方法，一种是横向看，一种是竖向看。横向看的是具体的资源，每一行是具体资源的加载，它会有一些色块来表达加载的过程。
一个块又不同的颜色，也就是说资源的下载不是一个单一的过程，实际上经历了很多环节，把鼠标悬浮在色块上，就可以看见一个详情列表，上面记录很很多下载之前的细节，比如说请求之前会有进行排队。它会把高优先级的东西进行请求。我们知道我们每一个资源实际上有一个域名，这个域名最终被翻译到IP，然后找到这个服务器，所以会有一个DNS查找的过程。
我们找到资源之后，服务器会和客户端进行连接，inital connection 橙色的 过程就是我们TCP进行连接的过程。有的网站用的是https，为了保证安全性使用了SSL证书。上来进行一个安全认证，我们管这个过程叫SSL协商，这个过程也会耗时。所以我们看见，在请求这个资源之间，有很多等待请求的时间，之后才是真正的把请求发送出去。但是在请求和请求响应之间还有一个时间。这个也是我们要讲的一个重点，叫做TTFB。它表达的是你请求发出到请求回来到底要经历多久。为什么它重要，因为它能给用户最直观感受。这个网站是快是慢，很大程度上由TTFB来决定。如果TTFB高的话，说明你请求发出要等待很久才能收到响应。用户要等待很久的白屏时间。如果回来很快的话，就可以快速的进行解析渲染，进行下面的步骤了。用户会感觉你的网站非常的快。
TTFB主要取决于两个因素：后台的处理能力，响应速度有多快。一个请求到了后台，后台可能还要查数据库，可能还要对数据进行组织和处理，然后才能把数据返回来。其次是你这条资源回路网络的情况，我发出去请求到回来会不会有延迟。
最后才是下载，如果下载的蓝条越长，代表资源越大。过长代表等待时间也长，肯定不好。有的资源会造成阻塞，一直等他下载，后面的资源等它下载完成之后才能继续，这样的话就会对浏览器加载的总体时间造车一个延误。

基于HAR存储与重建性能信息
横着看完了，我们竖着看，

1. 看资源于资源之间的联系：我们上面说了，如果发生阻塞，有些资源是串行的，按顺序一个一个加载，如果是并行的，我们就可以加快这个过程，这也是我们优化的一个点。
2. 看关键的时间节点：在chrome调试工具上面主要可以看到两根线，蓝色是DOM加载完成的时间，红色是页面所有资源加载完成的时间
   
   network中的信息很多。我们一次分析不完，我们像以后拿出来再看一下，我们可以把这个结果保存下来，右键空白处选择Save all as HAR with content HAR是 web的一种标准格式，主要用于将性能测试结果保存起来，以方便后期继续使用或者导入到其它的一些性能分析工具中进行分析

Lighthouse

重要的测量指标
lighthouse是google集成到chrome的一个性能测量工具，我们后面也会详细的介绍怎么去用，怎么去解读给出的报告，我们当前的重点是解读性能指标。
满分是100分，淘宝网页的得分是81分还算可以。以为每次测量的时候网络情况可能会有变化，所以一般建议多测量几次
我们今天只讲两个我们最关心的数据 一个是 First Contentful Paint 一个是 Speed Index
绿色：好。黄色：警告 。红色：需要优化。

First Contentful Paint ：从白屏到第一次出现内容的时间，

下面有一些加载过程的一些截图，10屏里面有8屏是白屏，白屏肯定是约少越好，但是淘宝这个白屏时间非常短。用户虽然要经历8个白屏的时间，但是非常短，感觉不到。就出现了画面

Speed Index ：速度指数，我们不许关注它是怎么得出来了，背后涉及一套很复杂的公式，我们只需关注这个数值。Speed Index标准为4秒，我们测得的speed index是4.2s，稍微慢了一点，但还是不错的。我们要结合网站本身的性质来看。并不是分数高的性能一定高，有的网站如百度，页面上基本没有什么内容，测出来的分数肯定很完美。而淘宝是一个电商的网站，需要展示很多东西给用户看，指标只是一个指导作用，并不一定能够达到最优的结果

上面谈到的一切都是关于网络加载的性能，但除了性能，我们还关心另外一大块就是网站加载完之后，用户真正开始使用的过程中，交互的体验

1. 交互响应，要做到足够快：例如淘宝鼠标移动到一级菜单立刻显示出二级菜单的内容。电商最重要的搜索，决定了用户流量的转换率，输入的内容，很快给出结果并带有分类，所以说淘宝的网站做的非常好，对我来说优化到了极致

2. 页面足够的流畅：有的开发网站做的页面动画并不流畅，因为做的效果并没有达到一定的帧数，人眼能够接收的比较流畅的帧数要求是1秒60帧，如果低于这个标准就会觉得有点卡。
我们用另外一种工具:command + shift + p
输入 frames

然后我们发现网站的左上角就多了一个东西，实时监控页面的帧数变化

进行测试： https://googlechrome.github.io/devtools-samples/jank/
Chrome性能调优技巧

3. 页面足够的流畅：所有的异步请求都足够快：1s。优化所有的异步请求能在1秒之内把数据返回回来，如果返回不回来，进行压缩。如果压缩完了之后一秒钟之内还是返回不了。这个时候就可以考虑前端交互上的一些优化。 因为我们最终最重要的一点是：及时给用户反馈。加一点loading动画，进度条这些前端最基本的东西。这些如果不做，显得网站很low而且性能和体验都非常差。

总结：
性能优化-加载

• 理解加载瀑布图
• HAM存储与重建性能信息
• 速度指数（Speed Index）
• 重要测量指标
• TTFB
• 页面加载时间
• 首次渲染

性能优化-响应

• 交互动作的返回时间
• 帧率FPS
• 异步请求的完成时间