深入研究前端性能探索

前端性能优化介绍

你是否经历过以下场景：

• 面试中
  1. 了解性能优化吗？
  2. 输入URL到看到整个页面经历了什么过程？
  3. ...
• 工作中
  1. 页面加载好慢，不知道是前端问题还是后端问题
  2. 页面交互卡顿，不知道具体哪里出了问题
• 如何从一个初级程序员提升为中级、高级甚至更高能力水平程序员？

什么是Web性能

简单来说就是你的网站够不够快

• 打开速度
• 动画效果
• 表单提交
• 列表滚动
• 页面切换

MDN上Web性能定义： Web性能是网站或应用程序的客观度量和可感知的用户

• 减少整体加载时间：减小文件体积、减少HTTP请求、使用预加载
• 让网站尽快可用：仅加载首屏内容，其它内容根据需要进行懒加载
• 平滑和交互性：使用CSS替代JS动画、减少UI重绘
• 感知表现：你的页面可能不能做得更快，但你可以让用户感觉更快。耗时操作要给用户反馈，比如加载动画、进度条、骨架屏等提示信息
• 性能测定：性能指标、性能测试、性能监控持续优化

为什么要关注 Web 性能

• 用户的留存
• 网站的转化率
• 体验与传播
• 搜索排名
• 客户投诉
• 提升工作绩效
• ...

如何进行 Web 性能优化

1. 首先需要了解性能指标-多快才算快？
2. 使用专业的工具可量化地评估出网站或应用的性能表现；
3. 然后立足于网站页面响应的生命周期、分析出造成较差性能表现的原因；
4. 最后进行技术改造、可行性分析等具体的优化实施
5. 迭代优化

性能指标

• RAIL性能模型
• 基于用户体验的核心指标
• 新一代性能指标：Web Vitals

性能测量

如果把对网站的性能优化比作一场旅程，它无疑会是漫长且可能还略带泥泞的，那么在开始之前我们有必要对网站进行性能测量，以知道优化的方向在何处。通常我们会借助一些工具来完成性能测量，本节先简要介绍以下两个操作，后面会有独立章节详细介绍它们的使用方式与生成报告的分析。

• 浏览器 DevTools 调试工具
  1. 网络监控分析
  2. 性能监控分析
• 灯塔（Lighthouse）
  1. 网站整体质量评估，并给出优化建议
• WebPageTest
  1. 多测试地点
  2. 全面的性能报告
• ...

生命周期

网站页面的生命周期，通俗的讲就是我们在浏览器地址栏中输入一个URL后，到整个页面渲染出来的过程。整个过程包括域名解析，建立TCP连接，前后端通过HTTP进行会话，压缩与解压缩，以及前端的关键渲染路径等，把这些阶段拆解 开来看，不仅能容易的获得优化性能的启发，而且也能为今后前端工程师之路构建出完整的知识框架，网站页面加载的生命周期如下图所示：

优化方案

经过对网站页面性能的测量以及渲染过程的了解，相信你对于糟糕性能体验原因已经比较清楚了，那么接下来便是优化性能，这也是本文章所要呈现给读者的大部分篇幅。本节先简单扼要地介绍一些优化方面的思路。

• 从发出请求到收到响应的优化，比如DNS查询、HTTP长连接、HTTP2、HTTP压缩、HTTP缓存等
• 关键渲染路径优化，比如是否存在不必要的重绘和回流
• 加载过程中优化，比如延迟加载，是否有不需要在首屏展示的非关键信息，占用了页面加载的时间
• 资源优化，比如图片、视屏等不同的格式类型会有不同的使用场景，在使用的过程中是否恰当
• 构建优化，比如压缩合并、基于 webpack 构建优化方案
• ...

Web 性能指标

我们已经知道性能的重要性，但当我们讨论性能的时候，让一个网页变得更快，具体是指哪些方面？

RAIL 性能模型

RAIL 是 Response，Animation, Idle, 和 Load的首字母缩写，是一种有Google Chrome团队于2015年提出的性能模型，用于提升浏览器内的用户体验和性能。

RAIL 模型的理念是“以用户为中心，最终目标不是让您的网站在任何特定设备上都能运行很快，而是使用户满意”

这个名字对的由来是有四个英文单字的首字母：

• 响应（Response）：应该尽可能快速的响应用户，应该在100ms以内响应用户输入
• 动画（Animation）：在展示动画的时候，每一帧应该以16ms进行渲染，这样可以保持动画效果的一致性，并且避免卡顿
• 空闲（Idel）：当使用JavaScript主线程的时候，应该把任务划分到执行时间小于50ms的片段中去，这样可以释放线程已进行用户交互
• 加载（Load）：应该在小于1s的时间内加载完成你的网站，并可以进行用户交互

根据网络条件和硬件的不同，用户对性能延迟的理解也有所不同。例如，通过快速的WiFi连接在功能强大的台式机上加载站点通常在1秒内完成，用户对此已经习以为常。在3G连接速度较慢的移动设备上加载网站需要花费更多时间，因此移动用户通常更耐心，在移动设备加载5s是一个更现实的目标。

这四个单词代表与网站或应用的生命周期相关的四个方面，这些方面会以不同方式影响整个网站的性能。

我们将用户作为之后性能优化的中心，首先需要了解用户对于延迟的反应。用户感知延迟的时间窗口，如下表所示

延迟	用户反映
0 ~ 16ms	人眼可以感知每秒 60 帧的动画，即每帧 16 ms，除了浏览器将一帧画面绘制到屏幕上的时间，网站应用大约需要 10ms 来生成一帧
0 ~ 100ms	在该时间范围内响应用户操作，才会是流畅的体验
100 ~ 1000ms	能够感觉到明显的延迟
> 1s	用户的注意力将离开对执行任务的关注
> 10s	用户感到失望，可能会放弃任务

响应

指标：应该尽可能快速响应用户，应该在100ms以内响应用户输入。

网站性能对于响应方面的要求是，在用户感知延迟之前接受到操作的反馈。比如用户进行了文本输入、按钮单击、表单切换及启动动画等操作后，必须在100ms内收到反馈，如果超过100ms的时间窗口，用户就会感知延迟。

看似很基本的用户操作背后，可能会隐藏着复杂业务逻辑处理及网络请求与数据计算。对此我们应当谨慎，将较大开销的工作放在后台异步执行，而即便后台处理要数百毫秒才能完成的操作，也应当给用户提供及时的阶段性反馈

比如在单击按钮向后台发起某项业务处理请求时，首先反馈给用户开始处理的提示，然后在处理完成的回调后反馈完成的提示

动画

指标：在展示动画的时候，每一帧应该以10ms进行渲染，这样可以保持动画效果的一致性，并且避免卡顿

前端所涉及的动画不仅有炫酷的UI特效，还包括滚动和触摸拖动等交互效果，而这一方面的性能要求就是流畅。众所周知，人眼具有视觉暂留特性，就是当光对视网膜所产生的视觉在光停止作用后，扔保留一段时间。

研究表明这是由于视觉神经存在反应速度造成的，其值是1/24s，即当我们所见的物体移除后，该物体在我们眼中并不会立即消失，而会延续存在1/24s的时间，对动画来说，无论动画帧率有多高，最后我们仅能分辨其中的30帧，但越高的帧率会带来更好的流畅体验，因此动画尽力达到60fps的帧率

目前大多数设备屏幕刷新率为60次/秒，那么浏览器渲染动画或页面的每一帧的速率也需要跟设备屏幕的刷新率保持一致。所以根据60fps帧率的计算，每一帧画面的生成都需要经过若干步骤，一帧图像的生成预算为 16ms （1000ms / 60 约等于16.66ms）,除去浏览器绘制帧率的时间，留给代码执行的时间仅 10ms 左右。如果无法符合此预算，帧率将下降，并且内容会在屏幕上抖动。此现象通常成为卡顿，会对用户体验产生负面影响。关于这个维度的具体优化策略，会在后面优化渲染过程的相关章节详细介绍。

• googlechrome.github.io/devtools-sa…

空闲

指标：当使用JavaScript主线程的时候，应该把任务划分到执行时间小于50ms的片段中去，这样可以释放线程以进行用户交互

要使网站响应迅速、动画流畅，通常都需要较长的处理时间，但以用户为中心来看待性能问题，就会发现并非所有动作都需要在响应和加载时间段完成，我们完全可以利用浏览器的空闲时间处理可延迟的任务，只要让用户感受不到延迟即可。利用空闲时间处理延迟，可减少预加载的数据大小，以保证网站或应用快速完成加载。

为了更加合理的利用浏览器的空闲时间，最后将处理的任务按50ms 为单位分组，这么做就是保证用户在发生操作后的100ms 内给出响应

加载

指标：首次加载应该在小于5s的时间内加载完成，并可以进行用户交互。对于后续加载，则是建议在2秒内完成

用户感知要求我们尽量在5s内完成页面加载，如果没有完成，用户的注意力就会分散到其他事情上，并对当前处理的任务产生中断感。需要注意的是，这里在5s内完成加载并渲染出页面的 要求，并非要完成所有页面资源的加载，从用户感知体验的角度来说，只要关键渲染路径完成，用户就会认为全部加载已完成

对于其他非关键资源的加载，延迟到浏览器空闲时段再进行，是比较常见的渐进式优化策略。比如图片懒加载，代码拆分等优化手段

关于加载方面具体的优化方案，后续也会分出独立内容进行详细介绍

基于用户体验的性能指标

基于用户体验的性能指标是 Google 在 web.dev 提出的。

First Contentful Paint（FCP）

FCP（First Contentful Paint）首次内容绘制，浏览器首次绘制来自 DOM 的内容的时间，内容必须是文本、图片（包含背景图）、非白色的 canvas 或 SVG，也包括带有正在加载中的 Web 字体的文本

优化方案

• web.dev/fcp/#how-to…

Largest Contentful Paint（LCP）

LCP（Largest Contentful Paint）最大内容绘制，可视区域中最大的内容元素呈现到屏幕上的时间，用以估算页面的主要内容对用户可见时间。

优化方案

• web.dev/optimize-lc…

First Input Delay（FID）

FID（First Input Delay）首次输入延迟，从用户第一次与页面交互（例如单击链接、点击按钮等）到浏览器实际能够响应该交互的时间。

输入延迟是因为浏览器的主线程正忙于做其他事情，所以不能响应用户。发生这种情况的一个常见原因是浏览器正忙于解析和执行应用程序加载的大量计算的 JavaScript。

优化方案

• web.dev/fid/#how-to…
• web.dev/optimize-fi…

Time to Interactive（TTI）

表示网页第一次 完全达到可交互状态 的时间点，浏览器已经可以持续性的响应用户的输入。完全达到可交互状态的时间点是在最后一个长任务（Long Task）完成的时间, 并且在随后的 5 秒内网络和主线程是空闲的。
从定义上来看，中文名称叫可持续交互时间或可流畅交互时间更合适。

优化方案

• web.dev/tti/#how-to…

Total Block Time（TBT）

Total Block Time（TBT）总阻塞时间，度量了 FCP 和 TTI 之间的总时间，在该时间范围内，主线程被阻塞足够长的时间以防止输入响应。

只要存在长任务，该主线程就会被视为“阻塞”，该任务在主线程上运行超过50毫秒（ms）。我们说主线程“被阻止”是因为浏览器无法中断正在进行的任务。因此，如果用户确实在较长的任务中间与页面进行交互，则浏览器必须等待任务完成才能响应。

如果任务足够长（例如，超过50毫秒的任何时间），则用户很可能会注意到延迟并感觉页面缓慢或过时。

给定的长任务的阻止时间是其持续时间超过50毫秒。页面的总阻塞时间是FCP和TTI之间发生的每个长任务的阻塞时间的总和

优化方案

• web.dev/tbt/#how-to…

Cumulative Layout Shift（CLS）

Cumulative Layout Shift（CLS）累计布局偏移，CLS 会测量在页面整个生命周期中发生的每个意外的布局移位的所有单独布局移位分数的总和，它是一种保证页面的视觉稳定性从而提升用户体验的指标方案

您是否曾经在页面上突然发生变化时在没有警告的情况下，文字移动了，并且您失去了位置。甚至更糟：您将要点击一个链接或一个按钮，但是在手指落下的瞬间，链接移动了，您最终单击了其他东西！

页面内容的意外移动通常是由于异步加载资源或将 DOM 元素动态添加到现有内容上方的页面而发生的。罪魁祸首可能是尺寸未知的图像或视频，呈现比其后备更大或更小的字体，或者是动态调整自身大小的第三方广告或小部件。

优化方案

• web.dev/cls/#how-to…
• web.dev/optimize-cl…

Speed Index

Speed Index（速度指数）是一个表示页面可视区域中内容的填充速度的指标，可以通过计算页面可见区域内容显示的平均时间来衡量。

优化方案

• web.dev/speed-index…

Web性能测试

使用灯塔 Lighthouse 测试性能

Lighthouse 直译过来是“灯塔”的意思，它是由 Google 开发并开源的一个 Web 性能测试工具。该性能检测工具以此命名也蕴涵了相同的含义，即通过监控和检测网站应用的各方面性能表现，来为开发者提供优化用户体验和网站性能的指导建议

准备

参考：developer.chrome.com/docs/devtoo…。

git clone https://github.com/lipengzhou/salt-resolute-icecream.git

使用方式

Lighthouse 提供了多种使用方式

• 在 Chrome DevTools 中使用 Lighthouse
• 使用 Chrome 扩展
• 使用 Node CLI 命令行工具
• 使用 Node 包

性能报告

关于性能报告部分的检测结果，Lighthouse 给出的信息包括：检测得分、性能指标、优化建议、诊断结果及已通过的性能，下面来分别进行介绍。

检测得分

经过检测，Lighthouse 会对上述五个维度给出一个 0～100 的评估得分，如果没有分数或得分为 0，则很有可能是检测过程发生了错误，比如网络连接状况异常等；如果得分能达到 90 分以上，则说明网站应用在该方面的评估表现符合最佳实践

关于如何得到这个评估得分，Lighthouse首先会获得关于评估指标的原始性能数据，然后根据指标权重进行加权计算，最后以其数据库中大量的评估结果进行对数正态分布的映射并计算最终得分。

• googlechrome.github.io/lighthouse/…
• web.dev/performance…

性能指标

关于性能指标有以下六个关键的数据。

这六个指标我们已经在“基于用户体验的性能指标”中详细说过了，这里不再赘述

这6种不同的指标数据需要通过加权计算，才能得到关于性能的最终评分，所加的权值越大表示对应指标对性能的影响就越大，如下图所示，列出了目前 Lighthouse 的权重情况。

Audit	Weight
First Contentful Paint	15%
Speed Index	15%
Largest Contentful Paint	25%
Time to Interactive	15%
Total Blocking Time	25%
Cumulative Layout Shift	5%

该权重系统还在不断优化过程中，虽然 Lighthouse 对于其中个别指标给予了较大的权重，也就意味着对该指标的优化能够带来更显著的性能评分提升，但这里还要建议在优化的过程中切勿只关注单个指标的优化，而要从整体性能的提升上来考虑优化策略。

优化建议

为了方便开发者更快地进行性能优化，Lighthouse 在给出关键性能指标评分的同时，还提供了一些切实可行的优化建议，如下图所示为检测报告中的优化建议。

这些建议按照优化后预计能带来的提升效果从高到低进行排列，每一项展开又会有更加详细的优化指导建议，从上到下依次包括以下内容。

（1）移除阻塞渲染的资源，部分JavaScript脚本文件和样式表文件可能会阻塞系统对网站页面的首次渲染，建议可将其以内嵌的方式进行引用，并考虑延迟加载。报告会将涉及需要优化的资源文件排列在下面，每个文件还包括尺寸大小信息和优化后预计提升首屏渲染时间的效果，据此可安排资源文件优化的优先级。

（2）预连接所要请求的源，提前建立与所要访问资源之间的网络连接，或者加快域名的解析速度都能有效地提高页面的访问性能。这里给出了两种方案：一种是设置〈link rel="preconnect"〉的预连接，另一种是设置〈link rel="dns-prefetch"〉的DNS预解析，前面章节对这两种方案都有过讨论，此处就不再赘述了。

（3）降低服务器端响应时间，通常引起服务器响应缓慢的原因有很多，因此也有许多改进方法：比如升级服务器硬件以拥有更多的内存或CPU，优化服务器应用程序逻辑以更快地构建出所需的页面或资源，以及优化服务器查询数据库等，不要以为这些可能并非属于前端工程师的工作范围就不去关注，通常node服务器转发层就需要前端工程师进行相应的优化。

（4）适当调整图片大小，使用大小合适的图片可节省网络带宽并缩短加载用时，此处的优化建议通常对于本应使用较小尺寸的图片就可满足需求，但却使用了高分辨率的大图，对此进行适当压缩即可。

（5）移除未使用的CSS，这部分列出了未使用但却被引入的 CSS 文件列表，可以将其删除来降低对网络带宽的消耗，若需要对资源文件的内部代码使用率进行进一步精简删除，则可以使用 Chrome 开发者工具的Coverage面板进行分析。

诊断结果

这部分 Lighthouse 分别从影响网站页面性能的多个主要维度，进行详细检测和分析得到的一些数据，下面我们来对其进行介绍

（1）对静态资源文件使用高效的缓存策略，这里列出了所有静态资源的文件大小及缓存过期时间，开发者可以根据具体情况进行缓存策略的调整，比如延迟一些静态资源的缓存期限来加快二次访问时的速度。

（2）减少主线程的工作，浏览器渲染进程的主线程通常要处理大量的工作：如解析 HTML 构建 DOM，解析 CSS 样式表文件并应用指定的样式，以及解析和执行 JavaScript 文件，同时还需要处理交互事件，因此渲染进程的主线程过忙很容易导致用户响应延迟的不良体验，Lighthouse 给我们提供了这一环节网站页面主线程对各个任务的执行耗时，让开发者可针对异常处理过程进行有目标的优化

（3）降低JavaScript脚本执行时间，前端项目的逻辑基本都是依托于JavaScript执行的，所以JavaScript执行效率与耗时也会对页面性能产生不小的影响，通过对这个维度的检测可以发现执行耗时过长的JavaScript文件，进而针对性的优化JavaScript解析、编译和执行的耗时

（4）避免存在较大尺寸网络资源的请求，因为如果一个资源文件尺寸较大，那么浏览器就需要等待其完全加载好后，才能进行后续的渲染操作，这就意味着单个文件的尺寸越大其阻塞渲染流程的时间就可能越长，并且网络传输过程中存在丢包的风险，一旦大文件传输失败，重新传输的成本也会很高，所以应当尽量将较大尺寸的资源进行优化，通常一个尺寸较大的代码文件可以通过构建工具打包成多个尺寸较小的代码包；对于图片文件如非必要还是建议在符合视觉要求的前提下尽量进行压缩。可以看出该检测维度列出的大尺寸资源文件，基本都是图片文件

（5）缩短请求深度，浏览器通常会对同一域名下的并发请求进行限制，超过限制的请求会被暂时挂起，如果请求链的深度过长，则需要加载资源的总尺寸也会越大，这都会对页面渲染性能造成很大影响。因此建议在进行性能检测时，对该维度进行关注和及时优化

使用 Chrome DevTools 测试性能

通过 Chrome 任务管理器我们可以查看当前 Chrome 浏览器中，所有进程关于 GPU、网络和内存空间的使用情况，这些进程包括当前打开的各个页签，安装的各种扩展插件，以及 GPU、网络、渲染等浏览器的默认进程，通过监控这些数据，我们可以在有异于其他进程的大幅开销出现时，去定位到可能存在内存泄漏或网络资源加载异常的问题进程。

Network 网络分析

Network 面板是 Chrome 开发者工具中一个经常会被用到的工具面板，通过它可以查看到网站所有资源的请求情况，包括加载时间、尺寸大小、优先级设置及 HTTP 缓存触发情况等信息，从而帮助我们发现可能由于未进行有效压缩而导致资源尺寸过大的问题，或者未合理配置缓存策略导致二次请求加载时间过长的问题等。

参考：developer.chrome.com/docs/devtoo…。

缓存测试

网络吞吐测试

网络请求阻止

Coverage 面板

我们可以通过 Coverage 面板监控并统计出网站应用运行过程中代码执行的覆盖率情况。该面板统计的对象是 JavaScript 脚本文件与 CSS 样式表文件，统计结果主要包括：每个文件的字节大小、执行过程中已覆盖的代码字节数，以及可视化的覆盖率条形图。

根据执行结果我们能够发现，在启动录制的过程中到底有哪些尺寸较大的代码文件执行覆盖率较低，这就意味着有些代码文件中可能存在较多的无用代码，更准确地说是暂时没用到的代码。这些信息对性能优化来说是非常有用的，开发者可以据此将执行覆盖率较低的代码文件进行拆分，将首屏渲染阶段暂时不会执行到的代码部分单独打包，仅在需要的时候再去加载。

同时对规模较大且迭代周期较长的项目来说，工程代码中会包含一些永远都不会执行到的代码，而使用 webpack 的 Tree Shaking 仅能根据 export 进行无关联引用，那么此时 Coverage 面板就为优化提供了一条可以尝试的途径。

Memory 面板

前端主要使用 JavaScript 代码来处理业务逻辑，所以保证代码在执行过程中内存的良性开销对用户的性能体验来说尤为重要，如果出现内存泄漏，那么就可能会带来网站应用卡顿或崩溃的后果。

为了更细致和准确地监控网站应用当前的内存使用情况，Chrome 浏览器开发者工具提供了 Memory 面板，通过它可以快速生成当前的堆内存快照，或者查看内存随时间的变化情况。据此我们可以查看并发现可能出现内存泄漏的环节，下图是使用 Memory 面板查看堆内存使用快照的情况。

Performance 面板

使用 Performance 面板主要对网站应用的运行时性能表现进行检测与分析，其可检测的内容不仅包括页面的每秒帧数（FPS）、CPU 的消耗情况和各种请求的时间花费，还能查看页面在前 1ms 与后 1ms 之间网络任务的执行情况等内容。

使用方式

使用方式非常简单，只需要在进行性能检测的网站页面中打开 Chrome 开发者工具的 Performance 面板即可，这里建议在Chrome 浏览器的匿名模式下使用该工具，因为在匿名模式下不会受到既有缓存或其他插件程序等因素的影响，能够给性能检测提供一个相对干净的运行环境。

Performance 面板中常用的是图中标出的三个按钮。通常当我们需要检测一段时间内的性能状况时，可单击两次“启动/停止检测”按钮来设置起止时间点，当单击第二次按钮停止检测后，相应的检测信息便出现在控制面板下方的区域。

图中的“启动检测并刷新页面”按钮用来检测页面刷新过程中的性能表现，单击它会首先清空目前已有的检测记录，然后启动检测刷新页面，当页面全部加载完成后自动停止检测。

打开测试示例：googlechrome.github.io/devtools-sa…。

面板信息

Performance 的评估结果页，其中的面板信息大致可分为四大类：控制面板、概览面板、线程面板及统计面板，下面进行逐一介绍

控制面板

（1）Screenshots：表示是否截取每一帧的屏幕截图，默认会勾选，并且在概览面板中展示随时间变化的每帧截屏画面，如果取消勾选，则不会在概览面板中展示这部分内容。 （2）Memory：表示是否记录内存消耗，默认不会勾选，如果勾选则会在线程面板与统计面板之间展示出各种类型资源的内存消耗曲线。 （3）网页指标：表示是否展示性能指标信息，默认不会勾选，如果勾选则会在网络和Frames之间展示出核心指标的节点状态。 （4）Disable javaScript samples：如果勾选则表示关闭 JavaScript 示例，减少在手机端运行时的开销，若要模拟手机端的运行环境时则需要勾选。 （5）Enable advanced paint instrumentation（slow）：如果选中则表示开启加速渲染工具，用来记录渲染事件的相关细节。因为该功能比较消耗性能，所以开启后重新生成检测报告的速度会变慢。 （6）Network：在性能检测时，用以切换模拟网络环境。 （7）CPU：限制 CPU 处理速度，主要用于模拟低速 CPU 运行时的性能。

概览面板

在概览面板的时间轴上，可以通过选择一个起始时间点，然后按住鼠标左键滑动选择面板中的局部范围，来进行更小范围内的性能观察。

这部分可观察的性能信息包括：FPS、CPU 开销和网络请求时间。对每秒帧数而言，尽量保持在60FPS才能让动画有比较流畅的视觉体验。

对CPU开销而言，不仅可以在整个检测时间轴上以曲线的形式观察CPU处理任务所花费时间的变化情况，同时还可以在统计面板中查看当前选中时间区域里各个任务花费时间的占比，其中占比较大的部分就有可能存在性能问题，可以进一步检测与分析。

对网络请求时间而言，概览面板提供的信息可能不够清晰，这里建议在线程面板的Network部分中具体查看，比如时间轴上每个请求的耗时及起止时间点都会更加清楚，从而方便开发者发现响应过长的网络请求并进行优化。

线程面板

这部分最主要的信息即为主线程执行过程的火焰图，主线程在解析 HTML 和 CSS、页面绘制及执行 JavaScript 的过程中，每个事件调用堆栈和耗时的情况都会反映在这张图上，其中每一个长条都代表了一个事件，将鼠标悬浮其上的时候可以查看到相应事件的执行耗时与事件名。

这个火焰图的横轴表示执行时间，纵轴表示调用栈的情况，上面的事件会调用下面的事件，越往下事件数量越少，所以火焰图是倒立的形式。

火焰图中的事件会以不同颜色进行标注，常见的事件类型有以下几种：HTML 解析、JavaScript 事件（例如鼠标单击、滚动等）、页面布局更改、元素样式重新计算及页面图层的绘制。了解并熟知这些事件的执行情况，有助于发现潜在的性能问题。

统计面板

统计面板会根据在概览面板中选择时间区域的不同，绘制出不同类型任务执行耗时的可视化图标。统计面板中包含四个页签。

其中 Summary 页签中会展示各类任务事件耗时的环形图；

Bottom-Up 页签中可以查看各个事件耗费时间的排序列表，列表会包含两个维度：去除子事件后该事件本身的耗时和包含子事件从开始到结束的总耗时。

Call Tree页签中可以查看全部或指定火焰图中某个事件的调用栈，如下图所示。

Event Log 页签中可查看关于每个事件的详细日志信息，如图下图所示。

保存测试记录

FPS 计数器

另一个非常方便的工具是 FPS 计数，可在页面运行时提供对 FPS 的实时估计。

1、选择 Control+Shift+P (Windows、Linux) 或 Command+Shift+P (macOS) 打开命令菜单。 2、在命令菜单中开始键入Rendering，然后选择显示渲染. 3、在呈现工具 中，打开 FPS 指示器。 新的叠加层将显示在视线的右上角。 4、关闭 FPS 计数并选择 Escape 来关闭呈现工具。

Performance monitor

虽然使用 Performance 面板来进行检测能够得到较为全面的性能数据，但依然存在两个使用上的问题，即面板信息不够直观和数据的实时性不够强。

为了弥补这两方面的不足，Chrome 从 64 版本开始便在开发者工具中引入了 Performance monitor 面板，通过它让我们可以实时监控网站应用运行过程中，诸如 CPU 占用率、JavaScript 内存使用大小、内存中挂的 DOM 节点数、JavaScript 事件监听次数及页面发生重绘与重排的处理时间等信息。

据此如果我们发现，当与页面的交互过程中出现某项指标有较为陡峭的增长，就意味着可能有影响性能体验的风险存在

如图所示为 Performance monitor 面板，图中出现的明显波动是执行刷新页面操作所产生的，可观察到 JavaScript 堆内存大小与 DOM 节点数的指标都有一个明显的断崖式下跌，这正是刷新操作清除了原有 DOM 节点后，还未重新渲染出新节点的时间点。

参考链接

• developer.chrome.com/docs/devtoo…
• developer.chrome.com/docs/devtoo…
• docs.microsoft.com/zh-cn/micro…