摘要：本文简单介绍如何生成网站性能分析报告。本文分享自华为云社区《在瀑布下用火焰烤饼：三步法助你快速定位网站性能问题》，原作者：Kagol。导入性能，是个问题。当每个项目发展到一定规模时，几乎不可避免地会遇到性能问题。遇到性能问题的时候，我们是：一脸懵逼，明知道很慢，也不知道为什么能很快理解性能瓶颈，找到有效的优化方案取决于我们对性能的理解以及我们是否有一套好的工具和方法。下面给大家分享一下我在定位业务性能问题时经常使用的三步法。为了方便记忆，我总结成一句话：瀑布下用火焰烤饼话不多说，喝口水开始滚！Performance面板介绍在介绍三步法之前，我们先简单了解一下Chrome开发者工具的Performance面板和性能分析报告的基本构成。生成性能分析报告以DevUI团队掘金个人主页为例，使用Chrome浏览器访问：https://juejin.cn/user/712139...然后按F12打开Chrome的开发者工具，选择性能面板。这时候我们会看到一个简单的向导：向导里面有两个按钮，上面的按钮是手动录音，下面的按钮是自动录音，我们点击傻瓜式的自动录音，自动录音会自动刷新页面，并且页面加载完成后，可以非常方便的生成该页面的性能分析报告，无需人工干预。等待几秒钟以生成报告。一眼望去，五光十色。我不知道从哪里开始？性能报告的构成我们对生成的性能分析报告做了一个简单的面板分类，看起来非常清晰。工具栏性能报告的顶部是一个工具栏（或控制面板），其中包含一堆按钮。前三个我用的比较多，前两个在指南中已经介绍过了，第三个用来清除报表。还有两个隐藏功能也很好用，一个是模拟慢网速，一个是模拟慢CPU，可能用于移动应用的性能优化。概览面板的工具栏下方是一个概览面板，显示了整个页面加载过程中的FPS（FramesPerSecond，每秒的帧数），用于评估页面的流畅度。较大的红色区域表示页面可能被卡住了。FPS下面是CPU处理每个任务所花费的时间，再往下是网络请求所花费的时间。概览面板的底部是每一帧的屏幕截图。线程面板是概览面板下方的线程面板。网络请求瀑布图默认展开，其他线程详情收起。每个线程面板都有性能分析的价值，瀑布图和火焰图是最常用的。后面我会重点分析这两个图表，以及如何利用这两个图表来分析网站的性能瓶颈。内存面板旁边是内存面板。内存面板需要在控制面板中手动打开。它是分类内存使用情况的折线图。每条折线是一个任务随时间的内存使用情况：JS堆栈文档HTML节点事件监控GPU内存详情面板最下面是详情面板，首先看到的是一个饼图，展示了各类任务的占比，这个非常好用，能不能一眼看出什么类型的任务是性能瓶颈。是资源加载还是脚本执行？是页面渲染还是图像绘制？还是空闲时间太多？第一步：看饼图。刚才在介绍Performance面板的构成时，提到了三个非常好用的性能分析工具，分别是详细饼图、请求瀑布图、主线程火焰图。我把这三张图总结成一句话：在瀑布下用火焰烤蛋糕，也是我自己做性能分析优化时屡试不爽的一招。详情面板中的饼图用于展示各类任务的耗时占比。主要有以下几个任务：蓝色是资源加载，黄色是脚本执行，紫色是页面渲染，绿色是图形绘制，白色是空闲时间或者刚才的例子。从饼图可以看出，脚本执行和闲置占比最大。脚本执行时间长，我们大概可以猜到里面可能有一个很长的任务；而空闲率高可能是因为等待服务器响应的时间过长。饼图可以快速形成基本判断，但具体原因需要瀑布图和火焰图分析。第2步：查看瀑布图让我们看一下请求瀑布图。瀑布图和火焰图都是线程面板的一部分。瀑布图的横轴是时间轴。瀑布图上有许多五颜六色的色块。这些色块就是Request块，每种颜色代表一种资源：蓝色是HTML文件，紫色是CSS文件，黄色是JavaScript文件，绿色是图片，灰色是后台界面。我们主要关注那些长色块。长色块意味着需要很长时间，这可能是性能。瓶颈。或者看看掘金个人主页的瀑布图。总结瀑布图的特点，我们先来观察一下这个图的特点和观察图形的能力。相信大家在小学的时候就已经培养过了。我们可以大致总结出以下几个明显的特征：特征一：大瀑布分为三个小瀑布特征二：最左边的小瀑布多为黄色色块，中间的小瀑布多为灰色色块，最右边的小瀑布为多为绿色色块特征3：前两个瀑布之间有距离，中间没有色块特征4：最后两个瀑布由灰色色块的“尾巴”连接在一起但这些特征有什么用告诉我们？能帮我们定位性能瓶颈吗？回答这些问题需要我们对瀑布图和浏览器原理有很多了解。让我们逐步分析它们。分析瀑布图的含义，我们从左到右，从上到下分析。最左边有两个色块，一个灰色色块和一个蓝色色块。面板以查看其详细信息。先看灰色色块。我们注意到这个请求的发起者（Initiator）是一个Chrome插件：chrome://new-tab-page/omnibox.mojom-lite.js，所以我们先不关注，再看蓝色色块前面我们已经介绍过，蓝色色块代表的是HTML文件。我们也可以从详细的MimeType作为text/html来验证这一点。让我们滚动鼠标滚轮，放大瀑布图，查看蓝色请求块的详细信息请求块的组成通过查看详细图，我们有一个新发现：每个请求块由四部分组成：左边line：代表请求发送前的时间（BeforeRequestSent）浅色块：代表请求已经发送（RequestSent），直到服务器返回第一个字节给浏览器（TTFB，TimetoFirstByte）深色块：服务器返回的内容全部下载到浏览器右边一行（ContentDownload）：等待主线程处理（Waitingformainthread）。这个HTML文件是呈现整个网页的起点。只有成功请求并下载此文件后，才会开始下一个故事。这个请求块的浅色部分占了比较大的比例。根据前面的介绍，浅色部分代表服务器的响应速度。浏览器提前发送请求，但服务器响应晚（第一个词节到达浏览器）。可能是网络慢，或者服务器处理速度慢，需要具体排查。毕竟这个HTML文件并不算大，只有111KB，却耗时179ms。对比另一个文件layouts.default.js，体积比它大了124KB，但是请求时间却比它小了一半多，只有74ms。（后来发现是数据不稳定，这个html文件应该不会构成性能瓶颈。）另外，后面的所有请求都依赖这个html，没有它就不会发生其他请求。是阻塞请求，必须保证性能。为了找到可能的性能瓶颈，让我们继续看右边的请求块。顶部的超长灰色块仍然是Chrome插件的请求。我们不在乎。看下面一堆黄色的请求块，都是JavaScript文件。下载HTML文件后，它会开始逐行解析HTML标签。当遇到设置了who和src属性的
