共计 5903 个字符，预计需要花费 15 分钟才能阅读完成。
作者：莫力全 Kyle Mo
译者：前端小智
起源：medium
提到 Web 前端的效力优化，有许多的技巧是聚焦在如何缩小页面的“载入工夫 Loading Time”，例如 Code Splitting 透过缩小须要载入的 Bundle Size 来放慢载入效力。也有些技巧是针对执行期间 (Runtime) 的优化与调教，例如 Virtualized List 透过管制渲染的 DOM 元素数量来放弃页面的流畅性，又或者是页面的 Repaint、Reflow、Composite 等渲染流程所破费的工夫，不过这些 runtime 指标又该如何 debug 呢？什麽样的情况又代表者页面的效力可能呈现了一些瓶颈呢？在现今网页中动画佔了非常重要的局部，那动画的性能又该怎麽观测呢？
明天想透过这篇文章与各位分享如何透过 Chrome Devtool 的 Performance Tab 来检测网页在执行时的各种性能指标，让网页的 Runtime Performance 不再成为你 debug 时的瓶颈！
Chrome Devtool Performance Tab 的根本介绍
有应用过 Chrome Devtool Performance Tab 的读者可能已经也和我一样被丰盛的图表与複杂的资讯给吓到了，齐全不晓得要从何开始看起。确实 Chrome 的 Performance Tab 提供了相当丰盛的信息，要在一篇文章就整顿透彻简直能够说是不可能的工作，所以明天只会介绍最根本的信息与图表，但我认为也曾经足够面对平时 Debug 时的需要。那咱们就废话不多说，间接开始吧！
开始 Debug
首先开启一个无痕视窗并拜访这个网站，应用无痕视窗的起因是能够确保 chrome 是运行在 “clean state” 下的，不然 performance 的测量后果有可能被 extensions 等正在运行的其余利用影响，造成不够精确的情况。
接着在键盘输入 Command+Option+I (Mac) 或是 Control+Shift+I (Windows, Linux) 关上 Devtool 并点选 Performance Tab。
左上角会有两个按钮（红色框框区块），点选第一个即会开始纪录，这时候你能够开始操作网页，Devtool 会纪录操作网页时的 CPU、记忆体、Frame Rate 等使用量与指标，这种形式适宜监测页面上的某些特定行为与性能。
第二颗按钮“Start profiling and reload page”，会开始 profiling 并重新整理页面，并在浏览器认为页面互动告一段落后主动进行 profiling。
因为我想要检测的是使用者手动触发的页面动画，所以应用第一种形式会比拟适宜。另外如果你的网站也有手机版的需要，一般来说有些 Mobile Devices 的性能会比拟差，为了检测利用在 low-level 的 Mobile Devices 是否也可能晦涩的运作，能够抉择 CPU 选项（图中橘色区块）并调整 CPU 的性能，这边我抉择 6x slower 来模仿在性能低的设施运作的情况。点选开始检测后，操作一下想要检测的性能，点选 stop profiling，一段时间后 Devtool 就会出现 Profiling 的后果。
剖析一下 Profiling 的后果吧！
让咱们一步一步拆解，首先来看看纪录 FPS、CPU、NET 的图表区域。
FPS
提到测量网页动画的性能，最直觉的形式就是察看 FPS (Frame Per Second)，也就是经常听到的 Frame Rate。当在进行动画时，会心愿 Frame Rate 能够达到 60 FPS 左右，使用者看到的动画才不易产生卡顿。（有时候 FPS 很低也不肯定不好，也有可能是页面真的没有任何的动静）
在上图的 FPS 栏位能够看到粉红色与红色组成的 bar，这代表这页面可能会有掉帧的情况，这会导致页面动画不平顺甚至卡顿，重大影响使用者体验，是咱们应该要尽量避免的。
CPU
从上图能够看到 CPU 图表是有时段性的，有些区段看起来非常沉闷，有先区段看起来却简直没有在运作。滑鼠在 FPS、CPU、NET 上 hover 都能够看到 profiling 过程残缺的 Screenshot，这种技术也叫做 scrubbing，能够让咱们以渐进式的形式追踪页面动画。
从下面的 Screenshot 能够得悉在使用者点击重新排列触发动画始终到动画实现之间的工夫都会让 CPU 的使用量进步。
而 CPU 图表有分很多不同的色彩，这代表著不同品种的工作，如果想要更容易懂且统整指定工夫区段的图表，能够在 Performance Tab 底下 Summary 看到统整后的图表，色彩的对应与下面的 CPU section 是一样的。
- 灰色 (System)— 浏览器外部的工作 (对于哪些工作被归类在这能够参考这个 stackoverflow 的问题)
- 红色 (Idle)— Idle Time
- 黄色 (Scripting) — 执行 JavaScript 与事件处理
- 绿色 (Painting) — 图像处理、画面绘制
- 紫色 (Rendering)— 页面的款式计算
- 蓝色 (Loading) — 载入与解决 HTML（因为我是在页面载入后才开始 profiling，因而没有显示这个阶段）
如果你发现你的网页的 CPU 长时间都是放弃 maxed out (图表中看起来很忙碌很多工作要做) 的状态，就要留神一下是不是有机会透过 Code Refactor 或是拔除不必要的性能来加重 CPU 的 Workload。
当然不代表 CPU 长时间都在运作就是不好的，举例来说 asana 的官网有一些会有限轮迴的动画
这样 CPU 势必会得始终解决一些工作，如果需要是这样，也未必不好
不过能够看得出来掉帧的情况蛮重大的，还有 JavaScript 的执行佔了 CPU 的少数工夫，这时候能够更近一步去思考如何改善掉帧的问题，或是动画能不能尽量用 CSS 就达到一样的成果（起因在于 CSS 架构的动画通常是由浏览器“主执行绪”的另外一个独立的执行绪解决，详情能够参考这篇文章）。
接下来往下看到 Performance Tab 两头区段的更多具体资讯局部。因为本人的 demo site 在这边显示的资讯太少，所以抉择应用刚刚提到的 asana 官网来解释这个区块，而碍于篇幅我只会提到几个我认为比拟常会用到的指标 — Memory、Frames、Timing、Main、Network、Experience。
Memory
点选红色区块的 Memory 选项，下不便会显示这段 profiling 期间网页的内存用量，例如说观测蓝色 JS Heap 使用量的变动咱们大抵能够察看出网页有没有 Memory Leak 的问题，也能够得悉大略是哪些操作会导致内存用量飙升。
橘色区块的垃圾桶则是能够强制浏览器做 GC (Garbage Collection)，因为 GC 在 JavaScript 裡是不可控的，所以很难只看代码就找出可能产生 Memory Leak 的情况。藉由强制 GC，咱们能够观测出执行一个函式前后的内存用量差异。例如在执行某个函式后就强制 GC，如果内存使用量还是在高点甚至越来越高，兴许就是遇到 Memory Leak 的情况了。
如果察看到 GC 是高频率被触发的也不要快乐得太早，尽管可能能够解决 Memory Leak 的问题，但也代表著网站内存的用量有点太多了，GC 有一个个性是“Stop The World”，因为 GC 同样是在 Main Thread 执行，太过频繁可能会导致网站效力呈现瓶颈。
Frames
两头区块的 Frames Section 显示了页面中每一次 UI update 的 Screenshot，而每一次 UI update 又能够被称作一个“frame”。当 UI 长时间被卡住无奈更新时就称作是一个“long frame”。
点击 Frames 中显示的其中一个 frame，下方的 summary tab 会显示该 frame 的具体资讯，包含 Duration、FPS 与 CPU Time。
如果点击 summary 中的 Screenshot 还能一步步按照工夫程序浏览被捕捉到的 frames。
Timing
Timing Section 能够看到网页载入性能一些重要指标产生的工夫线，这些指标别离有：
- DCL (DOM Content Loaded): HTML 被载入且解析（Parse）结束的工夫点。
- FP (First Paint) : 任何一个 pixel（像素）被浏览器绘制到页面上的工夫，例如页面的 background color。
- FCP (First Contentful Paint): 中文为“首次内容绘制”，当浏览者达到网站之后，首次显示网站内容须要的工夫，也是指浏览器第一次显示文字或图片的工夫，测试第一次显示起因是第二次再显示网站的时候，浏览器曾经有快取文件了，因而会没有那麽精确。
- LCP (Largest Contentful Paint): 是计算网页可视区 (viewport) 中最大元件的载入工夫，也就是页面的次要内容被使用者看到的工夫，是速度的指标。
- L (onload) : 代表解析 HTML 后申请的资源都载入实现的工夫点
在 Performance Tab 的最下方也会显示 Total Blocking Time (TBT)，代表在 Profiling 的过程中，浏览器 Main Thread 被阻塞的工夫总和，当然咱们会心愿这个工夫能够越短越好。
Experience
从 Experience 能够看出哪裡会产生 Layout Shift，也就是 Core Web Vital 中大家非常在意的 CLS。
Network
依照程序显示抓取各个资源破费的工夫和资源间的依赖关係，如果点击任一资源能够在下方 summary tab 看到更具体的材料，例如 URL、Duration、Priority、Mime Type、Encoded Data 大小、Decoded Body 大小。
不过笔者通常在 debug networking 相干的资源时还是比拟常间接应用 Devtool 的 Network Tab，整体信息更为具体且直觉。
Main (CPU Flame Chart)
Main Section 出现的是 Main Thread 的 CPU task，并且採用倒转的火焰图（flame chart）的模式出现，意思是在上面的 function 或 task 是由上一层的 task 所触发的，咱们能够利用这点追踪各个 task 与 function 的依赖与触发关係。
如果 Task 的右上角呈现红色的三角形，代表这是一个 long task，同时这也是一个通知咱们这裡可能有呈现一些问题导致 task 执行工夫过长的正告。
点选有红色三角形的 task 后，会呈现如上图的详细信息，有时候它会指出这个 task 在程式码中的地位，让咱们能够更疾速的 debug 找出潜在的问题，例如咱们点击下面显示的 content.js：
会间接切换到 Sources Tab 并显示对应的行数，对于 Debug 来说十分不便。
有时候你会发现除了 Main，还多了其余的 Frame 与 Worker，这些 Frame 指的不是刚刚提到能够观测 FPS 的 Frames，而是指网页中有嵌入的 iframe，而 Worker 指的是 Web Workers 等除了 Main Thread 以外的执行绪，Performance Tab 连这些都能够 debug，真的十分令人惊艳。
一些遗憾
碍于篇幅，其实 Performance Tab 上还有很多丰盛的信息没有介绍到，例如对于 Layer 相干的信息、Advanced Paint Instrumentation，还有 Summary Tab 底下对于 Call Tree、Bottom-Up 等能够更细粒度的察看 CPU 流动的区块，蛮倡议有趣味与有须要的读者能够自行钻研一下。
所以说，网站动画通过 refactor 后到底对效力产生多少影响？
了解了 Performance Tab 根本的操作形式后，回过头来看看用来 Demo 的网站在 Performance Tab 的剖析情况。
能够看出在动画触发时基本上会重大掉帧，CPU 的工作量也会变得很大，次要在做的事是 Rendering（紫色）与 Painting（绿色），Idle（红色）的工夫并不多，有可能会导致没方法解决使用者的 input 行为。
依照刚刚介绍的形式，也能够进一步去看在 Main Section 标示为 long task 的工作，发现大部分的工夫都花在 painting 上了，且破费的工夫十分久，按照 RAIL Model 的规范，这样的工夫破费会让使用者感触到页面的卡顿，甚至使用者互动所触发的事件浏览器也会没方法及时处理，使用者体验十分不好。
到这裡大抵上能够确定这个版本的动画有很大的问题，既然确定了问题，咱们就来看看动画的 code
发现这段 code 是间接扭转 element 的 top 来达成动画，这会造成页面每次都须要通过 Reflow 从新计算 Layout。但咱们应该有更好的形式能够达成一样的动画成果的，于是我试著将 code 改成以下这样：
并且应用 will-change CSS 属性在 transform 上：
接著咱们间接对新版的网站进行 Performance Profiling：
能够发现 frame rate 与 CPU 使用量都优化十分多，从 summary tab 也能够发现同样是差不多一秒左右的工夫，新版网页的 Idle Time 变多了，代表更有机会能够解决使用者的 input，防止使用者感触到整个网站是失去响应的。
尽管改版后还是有些失帧的情况，应该还能再更加改良，但比起上一版曾经改善十分多。
透过这个简略的范例，各位读者将来在遇到页面不晦涩或是卡顿等问题时应该就比拟晓得怎麽 debug，在修改写法后也晓得如何比对是不是真的有改善。
事例地址：https://github.com/kylemocode…
总结
当初的网站非常依赖与看重像 Lighthouse 这种性能检测工具所算出的分数，但笔者就已经遇过明明 Lighthouse Performance 分数是满分，在应用时却有显著卡顿与不晦涩的情况。这代表咱们不能齐全置信与依赖这些分数，当使用者亲自遇到性能体验不佳的情况时，Runtime Performance 的 Debugging 就变得非常重要。尽管明天只有介绍到皮毛，但心愿这篇文章可能让各位在将来须要应用 Performance Tab 时不再被目迷五色的 Dashboard 震慑住，而能够分明地晓得要如何去找出问题的瓶颈。
代码部署后可能存在的 BUG 没法实时晓得，预先为了解决这些 BUG，花了大量的工夫进行 log 调试，这边顺便给大家举荐一个好用的 BUG 监控工具 Fundebug。
原文：https://medium.com/starbugs/%…
交换
有幻想，有干货，微信搜寻 【大迁世界】 关注这个在凌晨还在刷碗的刷碗智。
本文 GitHub https://github.com/qq44924588… 已收录，有一线大厂面试残缺考点、材料以及我的系列文章。
