【慕课】前端性能优化企业级解决方案（上）

Panther008 lv-3
·  阅读 71
【慕课】前端性能优化企业级解决方案（上）

最近重新整理 慕课（前端性能优化企业级解决方案 6大角度+大厂视野）。

所以打算从 0 - 1 记录下来如何使用性能优化工具、如何分析前端性能优化，以及主流的前端性能优化方案。

全程采用案例分析的方式，一步一步敲开前端性能分析和优化的大门。

这是 前端性能优化企业级解决方案 的第一篇 性能优化的指标和工具。

性能优化的指标和工具

为什么要进行Web性能优化？

用户体验会更好。

搜索引擎排名更靠前。

用户流量（Amazon发现每100ms延迟导致1%销量损失）。

如何寻找性能瓶颈？

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

利用测量工具和APIs。

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

性能优化指标和优化目标

Waterfall

以taobao 首页性能指标分析为例：

  1. 打开开发者工具 -》Network -》设置勾选 Use large request rows 、Show overview 、 Capture screenshots

image.png

  1. 清除缓存并硬性加载

image.png

  1. 分析底部概要

image.png

  1. 分析Waterfall【重要】
  • 横向看具体资源 的加载

Waterfall -》悬浮到要查看的资源上。 image.png

Queueing        浏览器会对资源的请求做一个优先级的安排，高优先级先请求。
DNSLookup       DNS 查找。
InitIALconnection     客户端与服务器连接，TCP连接的过程。
SSL     https:// 的网站，SSL 协商的时间。
Waitting(TTFB)     请求发出到请求回来的时间。给用户最直观感受，这个网站快还是慢。
                   两个重要的影响因素：后台的处理能力；网络情况。
Content Download 资源下载。时间过长达标资源过大。
复制代码
  • 纵向看资源与资源之间的联系

1）如果发生了阻塞，资源的加载时串行的。所以我们希望有些资源是进行并行的 加载。

2）关键的时间节点

蓝色：DOM 完成加载的时间

红色：资源 完成加载的时间

image.png

  1. 保存 HAR 存储性能信息

HAR 是Web 性能分析的一个统一标准。

Waterfall 右键 -》 Save all as HAR with content。

Lighthouse

  1. FCP 白屏时间

FCP(First Contentful Paint) 第一个有内容的绘制出现的时间，不再是白屏了。从白屏到出现内容的时间。

  1. Speed Index 速度指数

小于4s。

交互响应

  1. 交互动作的反馈时间

足够快，小于100ms。

  1. 画面 足够流畅，达到足够的帧数（1s 60帧）

监控页面帧数。

command + shfit + p -> 输入 frames

image.png

  1. 异步请求足够快

1s内返回。

  • 优化

后端压缩。

1s 完成不了要加loading动画。

总结

我们针对taobao 网站，分析了Waterfall 和 Lighthouse 查看了一些重要指标，现在对这些性能指标做一些汇总。

  • Performance - > Waterfall 显示的指标
Queueing        浏览器会对资源的请求做一个优先级的安排，高优先级先请求。
DNSLookup       DNS 查找。
InitIALconnection     客户端与服务器连接，TCP连接的过程。
SSL     https:// 的网站，SSL 协商的时间。
Waitting(TTFB)     请求发出到请求回来的时间。给用户最直观感受，这个网站快还是慢。
                   两个重要的影响因素：后台的处理能力；网络情况。
Content Download 资源下载。时间过长达标资源过大。
复制代码
  • 以用户为中心的性能指标
-   First Paint 首次绘制（FP）
-   First contentful paint 首次内容绘制 (FCP)
-   Largest contentful paint 最大内容绘制 (LCP)
-   First input delay 首次输入延迟 (FID)
-   Time to Interactive 可交互时间 (TTI)
-   Total blocking time 总阻塞时间 (TBT)
-   Cumulative layout shift 累积布局偏移 (CLS)
复制代码

FP & FCP

首次绘制，FP（First Paint），这个指标用于记录页面第一次绘制像素的时间。

首次内容绘制，FCP（First Contentful Paint），这个指标用于记录页面首次绘制文本、图片、非空白 Canvas 或 SVG 的时间。

这两个指标看起来大同小异，但是 FP 发生的时间一定小于等于 FCP，如下图是掘金的指标：

image.png

FP 指的是绘制像素，比如说页面的背景色是灰色的，那么在显示灰色背景时就记录下了 FP 指标。但是此时 DOM 内容还没开始绘制，可能需要文件下载、解析等过程，只有当 DOM 内容发生变化才会触发，比如说渲染出了一段文字，此时就会记录下 FCP 指标。因此说我们可以把这两个指标认为是和白屏时间相关的指标，所以肯定是最快越好。

image.png

上图是官方推荐的时间区间，也就是说如果 FP 及 FCP 两指标在 2 秒内完成的话我们的页面就算体验优秀。

LCP

最大内容绘制，LCP（Largest Contentful Paint），用于记录视窗内最大的元素绘制的时间，该时间会随着页面渲染变化而变化，因为页面中的最大元素在渲染过程中可能会发生改变，另外该指标会在用户第一次交互后停止记录。指标变化如下图：

image.png

LCP 其实能比前两个指标更能体现一个页面的性能好坏程度，因为这个指标会持续更新。

举个例子：当页面出现骨架屏或者 Loading 动画时 FCP 其实已经被记录下来了，但是此时用户希望看到的内容其实并未呈现，我们更想知道的是页面主要的内容是何时呈现出来的。

此时 LCP 指标是能够帮助我们实现想要的需求的。

image.png

上图是官方推荐的时间区间，在 2.5 秒内表示体验优秀。

TTI

首次可交互时间，TTI（Time to Interactive）。这个指标计算过程略微复杂，它需要满足以下几个条件：

  1. 从 FCP 指标后开始计算
  2. 持续 5 秒内无长任务（执行时间超过 50 ms）且无两个以上正在进行中的 GET 请求
  3. 往前回溯至 5 秒前的最后一个长任务结束的时间

image.png

FID

首次输入延迟，FID（First Input Delay），记录在 FCP 和 TTI 之间用户首次与页面交互时响应的延迟。

这个指标其实挺好理解，就是看用户交互事件触发到页面响应中间耗时多少，如果其中有长任务发生的话那么势必会造成响应时间变长。

上文我们讲过 Google 推荐响应用户交互在 100ms 以内：

image.png

TBT

阻塞总时间，TBT（Total Blocking Time），记录在 FCP 到 TTI 之间所有长任务的阻塞时间总和。

假如说在 FCP 到 TTI 之间页面总共执行了以下长任务（执行时间大于 50ms）及短任务（执行时间低于 50ms）。

image.png

那么每个长任务的阻塞时间就等于它所执行的总时间减去 50ms。

image.png 所以对于上图的情况来说，TBT 总共等于 345ms。

这个指标的高低其实也影响了 TTI 的高低，或者说和长任务相关的几个指标都有关联性。

CLS

累计位移偏移，CLS（Cumulative Layout Shift），记录了页面上非预期的位移波动。

大家想必遇到过这类情况：页面渲染过程中突然插入一张巨大的图片或者说点击了某个按钮突然动态插入了一块内容等等相当影响用户体验的网站。这个指标就是为这种情况而生的，计算方式为：位移影响的面积 * 位移距离。

image.png

以上图为例，文本移动了 25% 的屏幕高度距离（位移距离），位移前后影响了 75% 的屏幕高度面积（位移影响的面积），那么 CLS 为 0.25 * 0.75 = 0.1875。

image.png

CLS 推荐值为低于 0.1，越低说明页面跳来跳去的情况就越少，用户体验越好。

三大核心指标

Google 在20年五月提出了网站用户体验的三大核心指标，分别为：

  1. LCP

代表了页面的速度指标，虽然还存在其他的一些体现速度的指标，但是上文也说过 LCP 能体现的东西更多一些。一是指标实时更新，数据更精确，二是代表着页面最大元素的渲染时间，通常来说页面中最大元素的快速载入能让用户感觉性能还挺好。

  1. FID

代表了页面的交互体验指标，毕竟没有一个用户希望触发交互以后页面的反馈很迟缓，交互响应的快会让用户觉得网页挺流畅。

  1. CLS

代表了页面的稳定指标，尤其在手机上这个指标更为重要。因为手机屏幕挺小，CLS 值一大的话会让用户觉得页面体验做的很差。

RAIL 测量模型

谷歌提出的一个可以量化的标准（量化指标）。

通过这个模型，可以指导我们性能优化的目标。

image.png

  • RAIL的目标 让良好的用户体验称为性能优化的目标。

什么是RAIL？

  1. Response 响应，指用户和网站交互的反馈响应的体验。

  2. Animation 动画。

  3. Idle 空闲。浏览器要有足够的空闲时间。

Performance 主线程的性能【重要】 查看主线程每时每刻都在做什么，有没有足够的空闲。

image.png

  1. Load 资源的网络加载时间。

响应

给用户的响应。

处理事件应在50ms 以内完成。

image.png

对于用户交互（比如点击事件），推荐的响应时间是 100ms 以内。 那么为了达成这个目标，推荐在空闲时间里执行任务不超过 50ms（W3C 也有这样的标准规定），这样能在用户无感知的情况下响应用户的交互，否则就会造成延迟感。

动画

每10ms 产生一帧。

动画需要达到60FPS（帧/秒），1s 60 帧。一帧的时间1/60 = 16.6ms。

浏览器要去绘制这一帧大概需要6ms 左右。所以要保证在10ms 之内产生一帧。

空闲

浏览器有足够的空闲时间。主线程是否有足够的空闲。

  • 优化

大量的计算放到后端。

加载

在5s内完成内容加载并可以交互。

性能测量工具

Chrome DevTools

开发调试、性能评测。

  1. Throttling 调整网络吞吐

image.png

  1. Performance 性能分析 image.png

  2. Network 网络加载分析

  3. 开发者模式下，按Esc

image.png

Network request bloking 禁用某些资源，对网站有什么影响。
Rendering 
    FPS
    Paint flashIng     页面滚动时页面哪些地方发生重绘。
Performance monitor     性能检测，如：CPU等。
复制代码

LightHouse

谷歌推出的一站式网站整体质量评估。 提供优化的建议。

  1. 本地安装
$ npm install -g lighthouse
$ lighthouse http://www.bilibili.com
复制代码
  1. Chrome DevTools

image.png

  • Performance
First Contentfurl Paint 首屏开始绘制的时间
SpeedIndex 速度指数，页面上所有内容多久能让用户看到
Largest Contentful Paint 最大资源的绘制时间
Time to Interactive 可交互的时间
复制代码

image.png

WebPageTest【非常好用】

全球性的节点多测试disdain、全面性能报告。

webpagetest.org/ 需翻墙访问。

分析报告地址： taobao.com : Chrome...irginia USA - EC2 - WebPageTest Result

  1. 解读WebPageTest 报告

waterfall chart 请求瀑布图

first view 首次访问

repeat view 二次访问

  1. 本地部署
$ 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
复制代码

image.png

常用的性能测量APIs

计算TTI

实时监测长任务

页面可见性的状态监听

通过切换浏览器访问页面 触发页面change。

判断当前的网络状态

Network -> 模拟网络环境。 image.png

其他计算公式

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
复制代码

Web 标准APIs

  1. 关键时间节点（Navigation Timing ， Resource Timing ）

  2. 网络状态（Network APIs）

  3. 客户端服务端协商（HTTP Client Hints）

  4. 网页显示状态（UI APIs)

参考

我的前端性能优化知识体系 - 掘金 (juejin.cn)

分类：
前端
标签：
前端

友情链接：

前端开发
私信
获得点赞  101
文章被阅读  7,710
收藏成功！
已添加到「」， 点击更改