其他分享
首页 > 其他分享> > 在瀑布下用火焰烤饼：三步法助你快速定位网站性能问题（超详细）

在瀑布下用火焰烤饼：三步法助你快速定位网站性能问题（超详细）

作者：互联网

DevUI是一支兼具设计视角和工程视角的团队，服务于华为云DevCloud平台和华为内部数个中后台系统，服务于设计师和前端工程师。

官方网站：devui.design

Ng组件库：ng-devui（欢迎Star）

官方交流：添加DevUI小助手（devui-official）

DevUIHelper插件：DevUIHelper-LSP（欢迎Star）

引言

性能，是一个问题。

每个项目成长到一定的规模，都几乎必然要遇到性能问题，当遇到性能问题时，我们是：

一脸懵逼，就知道很卡、很慢，不知道为什么

还是

能够快速洞察性能瓶颈，找到行之有效的优化方案

取决于我们对性能的理解深浅，以及是否有一套好的工具和方法。

接下来给大家分享我自己在定位业务性能问题时常用的三步法，为了方便记忆，我把它总结为一句话：

在瀑布下用火焰烤饼

话不多说，喝口水直接开撸！

Performance面板简介

介绍三步法之前，先来简单了解下Chrome开发者工具的Performance性能面板，以及性能分析报告的基本组成。

生成性能分析报告

以DevUI团队的掘金个人主页为例，使用Chrome浏览器访问：https://juejin.cn/user/712139267650141

然后按F12打开Chrome的开发者工具，选择Performance性能面板。

这时我们会看到一个简单的指引：

指引里面有两个按钮，上面的按钮是手动录制，下面的是自动录制，我们点击傻瓜式的自动录制，自动录制会自动刷新页面，在页面加载完成之后，生成该页面的性能分析报告，无需人工干预，非常方便。

等个几秒钟报告就生成好了，一眼看去，花花绿绿的，不知道从何看起？

性能报告的组成

我们对生成的性能分析报告做一个简单的面板分类，看起来就很清晰了。

工具栏

性能报告的顶部是一个工具栏（或者叫控制面板），里面有一堆按钮，我这边用得比较多的是前面三个，其中前两个在指引里已经介绍过了，第三个是用来清除报告的。

还有两个隐藏的功能也很有用，一个是模拟慢网速的，另一个是模拟慢CPU的，对移动端应用做性能优化可能会用到。

概览面板

工具栏下面是一个概览面板，显示了整个页面加载过程中的FPS（Frames Per Second，每秒传输帧数），用来评估页面的流畅度，有大片红色说明页面可能存在卡顿。

FPS下面是CPU处理各个任务花费的时间，再往下是网络请求的耗时，概览面板最下面是每一帧的截图。

线程面板

概览面板往下是线程面板，默认展开的是网络请求瀑布图，其他线程的详情都是收起的。

每个线程面板对性能分析都有价值，而我最常用的是瀑布图和火焰图，后面会重点分析这两个图，如何利用这两张图来分析网站的性能瓶颈。

内存面板

再往下是内存面板，内存面板需要在控制面板中手动打开，它是一个分类的内存占用折线图。

每条折线是一种任务随时间推移的内存占用：

详情面板

最下面是详情面板，首先看到的是一个饼图，这个饼图显示了各种类型任务的占比，这个非常有用，能否一眼看出什么类型的任务是性能瓶颈。

是资源加载还是脚本执行？是页面渲染还是图像绘制？又或者是空闲时间太长？

第一步：看饼图

刚才介绍Performance面板的组成时，提到了3个非常有用的性能分析利器，分别是详情饼图、请求瀑布图和主线程火焰图。

我把这三张图总结成一句话：

在瀑布下用火焰烤饼

这句话也是我自己在做性能分析和优化时，屡试不爽的小技巧。

详情面板中的饼图用于展示各种类型任务的耗时占比。

主要有以下几种任务：

还是举刚才的例子。

从饼图可以看出占比最多的是脚本执行和空闲。

脚本执行时间长，我们大概可以猜测里面可能存在长任务（Long task）;

而空闲占比多可能是等待服务器的响应时间太长。

饼图可以快速形成基本的判断，而具体原因则需要分析瀑布图和火焰图。

第二步：看瀑布图

我们来看下请求瀑布图，瀑布图和火焰图都是线程面板的一部分，瀑布图的横轴是时间轴，瀑布图上有很多五颜六色的色块，这些色块就是请求块，每种颜色代表一类资源：

我们主要关注那些长色块，长色块意味着耗时长，可能是性能瓶颈。

还是看下掘金个人主页的瀑布图。

总结瀑布图的特点

我们先观察这张图有什么特点，图形观察能力，相信大家小学就已经培养起来了，大致我们可以总结出以下比较明显的特点：

类似的特点我们还可以总结出很多来，但是这些特点说明了什么呢？能否帮助我们定位性能瓶颈呢？

回答这些问题需要我们对瀑布图以及浏览器原理有很多的认识，我们一步步来分析吧。

分析瀑布图的含义

我们按从左到右，从上到下的顺序进行分析，最左边有两个色块，一个灰色色块，一个蓝色色块，我们分别点击这两个色块，在详情面板看下它们的详情信息。

先看灰色色块

我们有注意到这个请求的启动器（Initiator）是一个Chrome插件：chrome://new-tab-page/omnibox.mojom-lite.js

因此我们不关注，接着看蓝色色块

前面我们已经介绍了，蓝色色块代表HTML文件，我们从详情的Mime Type为text/html也可以验证这一点。

我们滚动鼠标滚轮，把这个瀑布图放大，看这个蓝色请求块的细节

请求块的组成

通过查看细节图，我们有了新的发现：

每个请求块都由四部分组成：

  1. 左侧线：代表请求发送之前的时间（Before Request Sent）
  2. 浅色块：代表请求已经发送（Request Sent），直到服务器返回第一个字节给浏览器（TTFB, Time to First Byte）
  3. 深色块：服务器返回的内容全部下载到浏览器（Content Download）
  4. 右侧线：等待主线程处理（Waiting for main thread）

这个HTML文件是整个网页渲染的起点，成功请求并下载这个文件，才会有接下来的故事。

这个请求块的浅色块部分占比比较大，根据前面的介绍，浅色部分代表的是服务器的响应速度，浏览器已经早早地发出了请求，服务器却迟迟才给回应（第一个字节到达浏览器）。

中间可能是网络慢，也可能是服务器处理速度慢，需要具体排查，毕竟这个HTML文件不算大，才111KBb，却花了179ms。

对比另外一个文件layouts.default.js，体积比它大124KB，请求耗时却比它小一半多，才74ms。（后来发现这个数据不稳定，这个HTML文件应该不至于构成性能瓶颈）

另外所有后续的请求都依赖于这个HTML，没有它其他请求都不会发生，它是一个阻塞请求，性能必须要有保障。

发现可能的性能瓶颈

我们继续看右边的请求块，顶部那个超长的灰色块依然是Chrome插件的请求，我们不管，看下面那一堆黄色的请求块，这些都是JavaScript文件。

HTML文件下载完了之后，就会开始一行一行解析其中的HTML标签，遇到设置了谁、src属性的<script>标签，就会去下载src指定的JavaScript脚本文件。

从瀑布图可以看出，一共并行下载了8个JavaScript文件，它们的域名都是一样的：sf1-scmcdn2-tos.pstatp.com

不是说Chrome浏览器对同一个域名，并行的请求数最大是6个吗？

不仅仅是JavaScript文件，下面还有3个同域名的图片资源，也是在并行请求的，也就是说几乎同时发起了11个请求。

这说明

掘金的静态资源服务器升级到了HTTP/2

HTTP/2的多路复用可以实现一个TCP连接同时传输多个资源。

我们到Network面板里去看下这些JavaScript的请求详情，果然和我们猜测的一致，这一点必须给掘金点个赞

标签：色块,请求,性能,下用,烤饼,耗时,瀑布,火焰,法助
来源： https://www.cnblogs.com/kagol/p/14127876.html