前端优化的方法有哪些方法(前端常用的性能优化方法)

TL;DR: 当我们在做性能优化的时候,我们究竟在优化什么?做性能优化需不需要了解底层的东西?需要了解到什么程度?浏览器底层是一个什么架构?浏览器渲染的本质究竟是什么?哪些方面对用户的体验影响才是最大的?有没有业内一些通用的标准或标杆参考?都1202年了,雅虎军规还有没有用?性能分析工具都有哪些?我们从哪方面进行分析才是合适的?

本文为你一一解答这些问题。了解了这些问题,可能你在做性能优化的时候才能更加得心应手。

1. 性能优化的本质1.1 展示更快,响应更快

性能优化的目的,就是为了提供给用户更好的体验,这些体验包含这几个方面:展示更快、交互响应快、页面无卡顿情况。

更详细的说,就是指,在用户输入url到站点完整把整个页面展示出来的过程中,通过各种优化策略和方法,让页面加载更快;在用户使用过程中,让用户的操作响应更及时,有更好的用户体验。

对于前端工程师来说,要做好性能优化,需要理解浏览器加载和渲染的本质。理解了本质原理,才能更好的去做优化。所以我们先来看看浏览器架构是怎样的。

1.2 理解浏览器多进程架构

从大的方面来说,浏览器是一个多进程架构。

它可以是一个进程包含多个线程,也可以是多个进程中,每个进程有多个线程,线程之间通过IPC通讯。每个浏览器有不同的实现细节,并没有标准规定浏览器必须如何去实现。

这里我们只谈论chrome架构。

下面这张图是目前chrome的多进程架构图。

前端优化的方法有哪些方法(前端常用的性能优化方法) (图片引自Mariko Kosaka的《Inside look at modern web browser》)

我们来看看这些进程分别对应浏览器窗口中的哪一部分:

(图片引自Mariko Kosaka的《Inside look at modern web browser》)

那么,怎么看浏览器对应启动了什么进程呢?chrome中,我们可以通过更多->More Tools->Task Manager看到启动的进程。

从chrome官网和源码,我们也可以得知,多进程架构中包含这些进程:

Browser进程:打开浏览器后,始终只有一个。该进程有UI线程、Network线程、Storage线程等。用户输入url后,首先是Browser进程进行响应和请求服务器获取数据。然后传递给Renderer进程。Renderer进程:每一个tab一个,负责html、css、js执行的整个过程。前端性能优化也与这个进程有关 。Plugin进程:与浏览器插件相关,例如flash等。GPU进程:浏览器共用一个。主要负责把Renderer进程中绘制好的tile位图作为纹理上传到GPU,并调用GPU相关方法把纹理draw到屏幕上。

这里的话只是简单介绍一下浏览器的多进程架构,让大家对浏览器整体架构有个初步认识,其实背后的细节还有很多,这里就不一一展开。有兴趣可以细看这一系列文章[1]和chrome官网[2]介绍。

1.3 理解页面渲染相关进程1.3.1 Renderer Process & GPU Process

从以上的多架构,我们了解到,与前端渲染、性能优化相关的,其实主要是Renderer进程和GPU进程。那么,它们又是什么架构呢?

来看一下这张我们再熟悉不过的图。

(图片引自Paul的《The Anatomy of a Frame》[3])

Renderer进程:包括3个线程。合成线程(Compositor Thread)、主线程(Main Thread)、Compositor Tile Worker。GPU进程:只有GPU线程,负责接收从Renderer进程中的Compositor Thread传过来的纹理,显示到屏幕上。1.3.2 Renderer Process详解

Renderer进程中3个线程的作用为:

Compositor Thread:首先接收vsync信号(vsync信号是指操作系统指示浏览器去绘制新的帧),任何事件都会先到达Compositor线程。如果主线程没有绑定事件,那么Compositor线程将避免进入主线程,并尝试将输入转换为屏幕上的移动。它将更新的图层位置信息作为帧通过GPU线程传递给GPU进行绘制。

当用户在快速滑动过程中,如果主线程没有绑定事件,Compositor线程是可以快速响应并绘制的 ,这是浏览器做的一个优化。

Service Workers和Web Workers可以暂时理解也在Renderer进程中,这里不展开讨论。

1.3.2.1 Main Thread

main-thread.png

主线程需要重点讲下。因为这是我们的代码真实存在的环境。

从上一小节Render进程和GPU进程的图中,我们可以看到有个红色的箭头,从Recal Styles和Layout指向了requestAnimationFrame,这意味着有Forced Synchronous Layout (or Styles)(强制回流和重绘)发生,这一点在性能方面特别要注意。

在Main Thread中,有这几个需要注意一下:

requestAnimationFrame:因为布局和样式计算是在rAF之后,所以在rAF是进行元素变更的理想时机。如果在这里对一个元素变更100个类,不会进行100次计算,它们会分批以后处理。需要注意的是,不能在rAF中查询任何计算样式和布局的属性(例如:el.style.backgroundImage或el.style.offsetWidth),因为这样会导致重绘和回流。Layout:布局的计算通常是针对整个文档的,并且与DOM元素的大小成正比!(这点特别要注意,如果一个页面DOM元素太多,也会导致性能问题)

主线程的顺序始终都是:Input Event Handler->requestAnimationFrame->ParseHtml->ReculateStyles->Layout->Update Layer Tree->Paint->Composite->commit->requestIdleCallback,只能从前往后,例如,必须先是ReculateStyles,然后Layout、然后Paint。但是,如果它只需要做最后一步Paint,那么这就是它全部要做的事情,不会再发生前面的ReculateStyles和Layout。

这里其实给了我们一个启示:如果要让fps保持60,即每帧的js执行时间少于16.66ms,那么让这个主线程执行的过程尽可能地少,是我们的性能优化目标 。

根据主线程的这些步骤,理想的情况下,我们只希望浏览器只发生最后一个步骤:Composite(合成)。

2. 看看经典:雅虎军规

多年前雅虎的Nicolas C. Zakas提出7个类别35条军规,至今为止很多前端优化准则都是围绕着这个展开。如果严格按照这些规则去做,其实我们有很多优化工作可以做,只要认真践行,性能提升不是问题。

yahoo-35.png

我们来看看它7个分类都是围绕哪些方面展开:

Server:与页面发起请求的相关;Cookie:与页面发起请求相关;Mobile:与页面请求相关;Content:与页面渲染相关;Image:与页面渲染相关;CSS:与页面渲染相关;Javascript:与页面渲染和交互相关。

从上面的描述可以看到,其实雅虎军规,是围绕页面发起请求那一刻,到页面渲染完成,页面开始交互这几个方面来展开,提出的一些原则。

减少DOM节点数量

为什么要减少DOM节点的数量?当遍历查询500和5000个DOM节点,进行事件绑定时,会有所差别。当一个页面DOM节点过多,应该考虑使用无限滚动方案来使视窗节点可控。可以看看google提的方案[6]。

减少cookie大小

cookie 传输会造成带宽浪费,影响响应时间,可以这样做:消除不必要的cookies;静态资源不需要 cookie,可以采用其他的域名,不会主动带上 cookie。

避免图片src为空

图片src为空时,不同浏览器会有不同的副作用,会重新发起一起请求。

3. 性能指标3.1 什么样的性能指标才能真正代表用户体验?思考点详细内容Is it happening?导航是否成功,服务器是否响应了Is it useful?是否已经渲染了足够的内容,让用户可以开始参与其中Is it usable?用户是否可以与页面交互,页面是否处于繁忙状态Is it delightful?交互是否流畅、自然、没有滞后反映或卡顿

通常有2种途径来衡量性能。

本地实验衡量:本地模拟用户的网络、设备等情况进行测试。通常在开发新功能的时候,实验测量是很重要的,因为我们不知道这个功能发布到线上会有什么性能问题,所以提前进行性能测试,可以进行预防。线上衡量:实验测量固然可以反映一些问题,但无法反映在用户那里真实的情况。同样的,在用户那里,性能问题会和用户的设备、网络情况有关,而且还跟用户如何与页面进行交互有关。

有这几个类型与用户感知性能相关。

页面加载时间:页面以多快的速度加载和渲染元素到页面上。加载后响应时间:页面加载和执行js代码后多久能响应用户交互。运行时响应:页面加载完成后,对用户的交互响应时间。视觉稳定性:页面元素是否会以用户不期望的方式移动,并干扰用户的交互。流畅度:过渡和动画是否以一致的帧率渲染,并从一种状态流畅地过渡到另一种状态。

对应上面几种分类,Google和W3C性能工作组提供了对应这几种性能指标:

这些指标能从一定程度上衡量页面性能,但不一定都是有效的。举个例子。LCP指标主要用户衡量页面的主要内容是否完成加载,但会有这样的情况,最大的元素并不是主要内容,那么这个时候LCP指标并不是那么重要。每个不同的站点有自己的特殊性,可以参考以上角度进行衡量,也需要因地制宜。

3.2 Core Web Vitals

在以上列出的指标中,Google定义了3个最核心的指标,作为Core Web Vitals。它们分别代表着:加载、交互、视觉稳定性。

core-web-vitals.pngLargest Contentful Paint (LCP): 测量加载性能。为了能提供较好的用户体验,LCP指标建议页面首次加载要在2.5s内完成。First Input Delay (FID): 测量交互性能。为了提供较好用户体验,交互时间建议在100ms或以内。Cumulative Layout Shift (CLS): 测量视觉稳定性。为了提供较好用户体验,页面应该维持CLS在0.1或以内。

当页面访问量有75%的数据达到了以上以上Good的标准,则认为性能是不错的了。

Core Web Vitals是作为核心性能指标,但是其他指标也同样在重要,是做为核心指标的一个辅助。例如,TTFB和FCP都可以用来衡量加载性能(服务器响应时间和渲染时间),它们作为LCP的一个问题手段辅助。同样的,TBT和TTI对于衡量交互性能也很重要,是FID的一个辅助,但是它们无法在线上进行测量,也无法反映以用户为中心的结果。

Google官方提供了一个web-vitals[7]库,线上或本地都可以测量上面提到的3个指标:

import{getCLS,getFID,getLCP}from’web-vitals’;functionsendToAnalytics(metric){constbody=JSON.stringify(metric);//Use`navigator.sendBeacon()`ifavailable,fallingbackto`fetch()`.(navigator.sendBeacon&&navigator.sendBeacon(‘/analytics’,body))||fetch(‘/analytics’,{body,method:’POST’,keepalive:true});}getCLS(sendToAnalytics);getFID(sendToAnalytics);getLCP(sendToAnalytics);

下面,分别讲讲这3个指标定义的原因、如何测量、如何优化。

3.2.1 Largest Contentful Paint (LCP)3.2.1.1 LCP如何定义

(图片来自LCP[8])

LCP是指页面开始加载到最大文本块内容或图片显示在页面中的时间。那么哪些元素可以被定义为最大元素呢?

<img>标签<image> 在svg中的image标签<video> video标签CSS background url()加载的图片包含内联或文本的块级元素3.2.1.2 如何测量LCP

线上测量工具

Chrome User Experience ReportPageSpeed InsightsSearch Console (Core Web Vitals report)web-vitals JavaScript library

实验室工具

Chrome DevToolsLighthouseWebPageTest

原生的JS API测量 LCP还可以用JS API进行测量,主要使用PerformanceObserver接口,目前除了IE不支持,其他浏览器基本都支持了。

newPerformanceObserver((entryList)=>{for(constentryofentryList.getEntries()){console.log(‘LCPcandidate:’,entry.startTime,entry);}}).observe({type:’largest-contentful-paint’,buffered:true});

我们看一下结果是怎样的:

LCP-example.png

Google官方web-vitals库 Google官方也提供了一个web-vitals[9]库,底层还是使用这个API,只是帮我们处理了一些需要测量和不需测量的场景、以及一些细节问题。

3.2.1.3 如何优化LCP

LCP可能被这四个因素影响:

服务端响应时间Javascript和CSS引起的渲染卡顿资源加载时间客户端渲染

更加详细的优化建议就不展开了,可以参考这里[10]。

3.2.2 First Input Delay (FID)3.2.2.1 FID如何定义

(图片来自FID[11])

我们都知道第一印象的重要性,比如初次遇到某人形成的印象,会在后续交往中起重要的影响。对于一个网站也是如此。

网站以多快的速度加载完成是其中一项指标,加载后以多快的速度对用户进行响应也同样重要。FID就是指后者。

可以通过下面的图来更详细了解FID处于哪个位置:

(图片来自FID[12])

从上图可以看出,当主线程处于繁忙的时候,FID是指从浏览器接收到了用户输入,到浏览器对用户的输入进行响应的延迟时间。

通常,**当我们在写代码的时候,会认为只要用户输入信息,我们的事件回调就会立刻响应,但实际上并不是这样。这是主线程可能处于繁忙,浏览器正忙着解析和执行其他js。**如上图所示的FID时间,主线程正在处理其他任务。

当FID的时间为100ms或以内,则为Good。

上面的例子中,用户刚好在主线程最繁忙的时刻进行了交互,但是如果用户在主线程空闲的时候交互,那么浏览器可以立刻响应。所以FID的值需要重点查看它的分布情况。

FID实际上测量的是输入事件被感知到到主线程空闲的这段时间。这意味着即使没有输入事件被注册,FID也可以测量。因为用户的输入相应并不一定需要事件被执行,但一定需要主线程是空闲的。例如,下面这些HTML元素都需要在交互响应之前等待主线程上的正在执行的任务完成:

输入框,例如<input>、<textarea>、<radio>、<checkbox>下拉框,例如<select>链接,例如<a>

为什么要考虑测量第一次的输入延迟?有如下原因:

因为第一次输入延迟是用户对你的网站形成的第一个印象,网站是否有质量且可靠;在今天,web中最大的交互问题第一次加载之后;对于网站应该如何解决较高的首次输入延迟(例如代码分割、减少JavaScript的预加载)的建议解决方案(TTI是指衡量这一块),不一定与在页面加载后解决输入延迟(FID是指衡量这一块)的解决方案相同。所以FID是在TTI的基础上更精确的细分。

为什么FID只是包含从用户输入到主线程开始相应的时间?而没有包含事件处理到浏览器绘制UI的时间?

尽管主线程处理和绘制的这段时间也很重要,但是如果FID把这段时间也包含进来,开发者可能会使用异步API(例如setTimeout、requestAnimationFrame)来把这个task拆分到下一帧,以较少FID的时间,这样不仅没有提高用户体验,反而使用户体验降低。

3.2.2.2 如何测量FID

FID可以在实验环境也可以在线上环境测量。

线上测量工具

Chrome User Experience ReportPageSpeed InsightsSearch Console (Core Web Vitals report)web-vitals JavaScript library

原生的JS API测量

newPerformanceObserver((entryList)=>{for(constentryofentryList.getEntries()){constdelay=entry.processingStart-entry.startTime;console.log(‘FIDcandidate:’,delay,entry);}}).observe({type:’first-input’,buffered:true});

PerformanceObserver目前除了在IE上没有兼容,其他浏览器基本都兼容了。

我们看一下结果是怎样的:

FID-example.png

Google官方web-vitals库 Google官方也提供了一个web-vitals[13]库,底层还是使用这个API,只是帮我们处理了一些需要测量和不需测量的场景、以及一些细节问题。

3.2.2.3 如何优化FID

FID可能被这四个因素影响:

减少第三方代码的影响减少Javascript的执行时间最小化主线程工作减小请求数量和请求文件大小

更加详细的优化建议可以参考这里[14]。

3.2.3 Cumulative Layout Shift (CLS)3.2.3.1 CLS如何定义

(图片来自CLS[15])

CLS是一个非常重要的、以用户为中心的测量指标。它能衡量页面是否排版稳定。

页面移动会经常发生在资源异步加载、或者DOM元素动态添加到已存在的页面元素上面。这些元素有可能是图片、视频、第三方广告或小图标等。

但是我们开发过程中可能不会察觉到这些问题,因为调试过程中刷新页面,图片都已经缓存在本地。调试接口的时候我们使用的是mock或者在局域网,接口速度都很快,这些延迟都可能被我们忽略。

CLS就是帮我们去发现这些真实发生在用户端的问题的指标。

CLS是测量页面生命周期中,每个发生意外布局移动的分数。当一个可视元素在下一帧移动到另外一个位置,就是指布局移动。

CLS的分数在0.1或以下,则为Good。

那么意外布局移动的分数如何计算?

浏览器会监控两桢之间发生移动的不稳定元素。布局移动分数由2个元素决定:impact fraction和distance fraction。

layoutshiftscore=impactfraction*distancefraction

可视区域内,在前一帧到下一帧之间所有不稳定的元素的并集,会影响当前帧的布局移动分数。

举个例子,下面这张图中,左边是当前帧的一个元素,下一帧中,元素下移了可视区域内25%的高度。红色虚线框标出了两桢中当前元素的并集,占适口的75%,所以这个时候,impact faction是0.75。

另外一个影响布局移动分数的是distance fraction,指这个元素相对视口移动的距离。不管是横向还是竖向,取最大值。

下面例子中,竖向距离更大,该元素相对适口移动了25%的距离,所以distance fraction是0.25。所以布局移动分数是 0.75 * 0.25 = 0.1875.

impact-fraction-example.png

但是要注意的是,并不是所有的布局移动都是不好的,很多web网站都会改变元素的开始位置。只有当布局移动是非用户预期的,才是不好的。

3.2.3.2 如何测量CLS

线上测量工具

Chrome User Experience ReportPageSpeed InsightsSearch Console (Core Web Vitals report)web-vitals JavaScript library

实验室工具

Chrome DevToolsLighthouseWebPageTest

原生的JS API测量

letcls=0;newPerformanceObserver((entryList)=>{for(constentryofentryList.getEntries()){if(!entry.hadRecentInput){cls =entry.value;console.log(‘CurrentCLSvalue:’,cls,entry);}}}).observe({type:’layout-shift’,buffered:true});

我们看一下结果是怎样的:

CLS-example.png

Google官方web-vitals库 Google官方也提供了一个web-vitals[16]库,底层还是使用这个API,只是帮我们处理了一些需要测量和不需测量的场景、以及一些细节问题。

3.2.3.3 如何优化CLS

我们可以根据这些原则来避免非预期布局移动:

图片或视屏元素有大小属性,或者给他们保留一个空间大小,设置width、height,或者使用unsized-media feature policy[17]。不要在一个已存在的元素上面插入内容,除了相应用户输入。使用animation或transition而不是直接触发布局改变。

更详细的内容可以看这里[18]。

4. 性能工具:工欲善其事,必先利其器

Google开发的所有工具[19]都支持Core Web Vitals的测量。工具如下:

LighthousePageSpeed InsightsChrome DevToolsSearch Consoleweb.dev’s提供的测量工具Web Vitals扩展Chrome UX Report API

tools-all.png

这些工具对Core Web Vitals的支持如下:

tools.png4.1 Lighthouse

lighthouse.png

Lighthhouse是一个实验室工具,本地模拟移动端和PC端对这几个方面进行测试。同时lighthouse还会针对这几个方面提出建议,在产品上线前值得一测。

lighthouse-func.png

Lighthouse还提供了Lighthouse CI[20],把Lighthouse集成到CI流水线中。举个例子,每次在上线之前,跑50次流水线对Lighthouse的各项指标进行测试取平均值,一旦发现异常,立刻进行排查。把性能问题排查提前到发布之前。这块后面会细讲。

4.2 PageSpeed Insights

PageSpeed Insights(PSI)是一个可以分析线上和实验室数据的工具。它是根据线上环境用户真实的数据(在Chrome UX 报告中)和Lighthouse结合出一份报告。和Lighthouse类似,它也会给出一些分析建议,可以知道页面的Core Web Vitals是否达标。

PageSpeed-demo.png

PageSpeed只是提供对单个页面的性能测试,而Search Console是正对整个网站的性能测试。

PageSpeed Insights也提供了API[21]供我们使用。同样的,我们也可以把它集成到CI中。

4.3 CrUX

Chrome UX Report (CrUX)是指汇聚了成千上万条用户体验数据的数据报告集,它是经过用户同意才进行上报的,目前存储在Google BigQuery上,可以使用账号登陆进行查询。它测量了所有的Core Web Vitals指标。

上面提到的PageSpeed Insights工具就是结合CrUX的数据进行分析给出的结论。

当然CrUX现在也提供了API共我们进行查询,可以查询的数据包括:

Largest Contentful PaintCumulative Layout ShiftFirst Input DelayFirst Contentful Paint

原理如下:

CrUX.png

通过API的查询的数据每日都更新,并汇集了过去28天的数据。

具体的使用方式可以参考官方给出的demo[22]。

4.4 Chrome DevTools Performance面板

Performance是我们最常用的本地性能分析工具。

devtools-panel.png

4.4.1 Frame

我们把鼠标移上去看看:

frame-58.png

这种体验顺畅的情况。

再比如:

提示这一帧耗时了30.9ms,当前是32fps并且是掉帧状态。

4.4.2 Timings

这里可以看到几个关键指标的时间点。

FP:First Paint;FCP:First Contentful Paint;LCP:Largest Contenful Paint;DCL:DOMContentLoaded EventL:OnLoad Event。

timings.png4.4.3 Main

Main是DevTools中最常用也是最重要的功能。

main.png

通过record,我们可以查看页面上所有操作在主线程中的执行过程。也就是我们常说的流程:

main-thread.png

一旦有任何一个流程时间过长或频繁发生,比如Update Layer Tree时间过长、频繁出现RecalcStyles、Layout(重绘回流),那么需要引起注意。后面会举一个例子。

4.4.4 Layers

Layers是浏览器在绘制过程中生成的一个层。因为浏览器底层渲染的本质是纵向分层、横向分块。这一块的知识点是发生在Renderer Process进程中。后面会以一个例子展开讲。

这里想提Layers的原因是,Layer的渲染也会影响性能问题,而且有时候还不容易被发现!

layers-panel.png

layer-detail.png

选中某个层,可以查看该层生成的原因。

layer-reason.png

Chrome的Blink内核给出了54种会生成合成层的原因:

constexprCompositingReasonStringMapkCompositingReasonsStringMap[]={{CompositingReason::k3DTransform,”transform3D”,”Hasa3dtransform”},{CompositingReason::kTrivial3DTransform,”trivialTransform3D”,”Hasatrivial3dtransform”},{CompositingReason::kVideo,”video”,”Isanacceleratedvideo”},{CompositingReason::kCanvas,”canvas”,”Isanacceleratedcanvas,orisadisplaylistbackedcanvasthatwas””promotedtoalayerbasedonaperformanceheuristic.”},{CompositingReason::kPlugin,”plugin”,”Isanacceleratedplugin”},{CompositingReason::kIFrame,”iFrame”,”IsanacceleratediFrame”},{CompositingReason::kSVGRoot,”SVGRoot”,”IsanacceleratedSVGroot”},{CompositingReason::kBackfaceVisibilityHidden,”backfaceVisibilityHidden”,”Hasbackface-visibility:hidden”},{CompositingReason::kActiveTransformAnimation,”activeTransformAnimation”,”Hasanactiveacceleratedtransformanimationortransition”},{CompositingReason::kActiveOpacityAnimation,”activeOpacityAnimation”,”Hasanactiveacceleratedopacityanimationortransition”},{CompositingReason::kActiveFilterAnimation,”activeFilterAnimation”,”Hasanactiveacceleratedfilteranimationortransition”},{CompositingReason::kActiveBackdropFilterAnimation,”activeBackdropFilterAnimation”,”Hasanactiveacceleratedbackdropfilteranimationortransition”},{CompositingReason::kXrOverlay,”xrOverlay”,”IsDOMoverlayforWebXRimmersive-armode”},{CompositingReason::kScrollDependentPosition,”scrollDependentPosition”,”Isfixedorstickyposition”},{CompositingReason::kOverflowScrolling,”overflowScrolling”,”Isascrollableoverflowelement”},{CompositingReason::kOverflowScrollingParent,”overflowScrollingParent”,”Scrollparentisnotanancestor”},{CompositingReason::kOutOfFlowClipping,”outOfFlowClipping”,”Hasclippingancestor”},{CompositingReason::kVideoOverlay,”videoOverlay”,”Isoverlaycontrolsforvideo”},{CompositingReason::kWillChangeTransform,”willChangeTransform”,”Hasawill-change:transformcompositinghint”},{CompositingReason::kWillChangeOpacity,”willChangeOpacity”,”Hasawill-change:opacitycompositinghint”},{CompositingReason::kWillChangeFilter,”willChangeFilter”,”Hasawill-change:filtercompositinghint”},{CompositingReason::kWillChangeBackdropFilter,”willChangeBackdropFilter”,”Hasawill-change:backdrop-filtercompositinghint”},{CompositingReason::kWillChangeOther,”willChangeOther”,”Hasawill-changecompositinghintotherthantransformandopacity”},{CompositingReason::kBackdropFilter,”backdropFilter”,”Hasabackdropfilter”},{CompositingReason::kBackdropFilterMask,”backdropFilterMask”,”Isamaskforbackdropfilter”},{CompositingReason::kRootScroller,”rootScroller”,”Isthedocument.rootScroller”},{CompositingReason::kAssumedOverlap,”assumedOverlap”,”Mightoverlapothercompositedcontent”},{CompositingReason::kOverlap,”overlap”,”Overlapsothercompositedcontent”},{CompositingReason::kNegativeZIndexChildren,”negativeZIndexChildren”,”Parentwithcompositednegativez-indexcontent”},{CompositingReason::kSquashingDisallowed,”squashingDisallowed”,”Layerwasseparatelycompositedbecauseitcouldnotbesquashed.”},{CompositingReason::kOpacityWithCompositedDescendants,”opacityWithCompositedDescendants”,”Hasopacitythatneedstobeappliedbycompositorbecauseofcomposited””descendants”},{CompositingReason::kMaskWithCompositedDescendants,”maskWithCompositedDescendants”,”Hasamaskthatneedstobeknownbycompositorbecauseofcomposited””descendants”},{CompositingReason::kReflectionWithCompositedDescendants,”reflectionWithCompositedDescendants”,”Hasareflectionthatneedstobeknownbycompositorbecauseof””compositeddescendants”},{CompositingReason::kFilterWithCompositedDescendants,”filterWithCompositedDescendants”,”Hasafiltereffectthatneedstobeknownbycompositorbecauseof””compositeddescendants”},{CompositingReason::kBlendingWithCompositedDescendants,”blendingWithCompositedDescendants”,”Hasablendingeffectthatneedstobeknownbycompositorbecauseof””compositeddescendants”},{CompositingReason::kPerspectiveWith3DDescendants,”perspectiveWith3DDescendants”,”Hasaperspectivetransformthatneedstobeknownbycompositorbecause””of3ddescendants”},{CompositingReason::kPreserve3DWith3DDescendants,”preserve3DWith3DDescendants”,”Hasapreserves-3dpropertythatneedstobeknownbycompositorbecause””of3ddescendants”},{CompositingReason::kIsolateCompositedDescendants,”isolateCompositedDescendants”,”Shouldisolatedescendantstoapplyablendeffect”},{CompositingReason::kFullscreenVideoWithCompositedDescendants,”fullscreenVideoWithCompositedDescendants”,”Isafullscreenvideoelementwithcompositeddescendants”},{CompositingReason::kRoot,”root”,”Istherootlayer”},{CompositingReason::kLayerForHorizontalScrollbar,”layerForHorizontalScrollbar”,”Secondarylayer,thehorizontalscrollbarlayer”},{CompositingReason::kLayerForVerticalScrollbar,”layerForVerticalScrollbar”,”Secondarylayer,theverticalscrollbarlayer”},{CompositingReason::kLayerForScrollCorner,”layerForScrollCorner”,”Secondarylayer,thescrollcornerlayer”},{CompositingReason::kLayerForScrollingContents,”layerForScrollingContents”,”Secondarylayer,tohousecontentsthatcanbescrolled”},{CompositingReason::kLayerForSquashingContents,”layerForSquashingContents”,”Secondarylayer,homeforagroupofsquashablecontent”},{CompositingReason::kLayerForForeground,”layerForForeground”,”Secondarylayer,tocontainanynormalflowandpositivez-index””contentsontopofanegativez-indexlayer”},{CompositingReason::kLayerForMask,”layerForMask”,”Secondarylayer,tocontainthemaskcontents”},{CompositingReason::kLayerForDecoration,”layerForDecoration”,”Layerpaintedontopofotherlayersasdecoration”},{CompositingReason::kLayerForOther,”layerForOther”,”Layerforlinkhighlight,frameoverlay,etc.”},{CompositingReason::kBackfaceInvisibility3DAncestor,”BackfaceInvisibility3DAncestor”,”Ancestorinsame3Drenderingcontexthasahiddenbackface”},};4.4.5 Rendering

Rendering面板也隐藏了很多好用的功能。

4.4.5.1 Paint flashing

勾选了Paint flashing后,我们就会看到页面上有哪些内容被重绘了:

paint-flashing.png4.4.5.2 Layout Shift Regions

勾选了Layout Shift Regions后,进行交互,就可以看到哪些元素进行了布局移动:

layout-shift-regions.png4.4.5.3 Frame Rendering Stats

这个工具有一个小插曲。

Frame Rendering Stats的前身是FPS meter,在Google版本85.0.4181.0[23]改成了Frame Rendering Stats,但是迫于用户抱怨[24],在90版本的时候又改回来了。

Frame Rendering Stats主要显示不掉帧率。而FPS侧重于显示每秒的刷新率fps。

Chrome为什么要改成不掉帧率,是因为认为不掉帧率更能反映页面的顺畅度。而FPS显示每一秒渲染的帧数虽然能一定程度反映页面顺畅度,但是在一些特殊情况例如没有激活或空闲的页面,fps会比较低,这样并不能反映真实情况。

(图片引自blink dev论坛讨论[25])

4.4.6 Memory

在大型项目中,内存问题也是有发生。DevTools也提供了内存分析工具供我们使用。

memory.png

memory-snapshot.png4.5 Search Console

它会展示3个 Core Web Vitals metrics: LCP, FID, CLS。如果发现有问题,可以配合PageSpeed一起使用,分析问题。

(图片引自vital-tools)

4.6 web.dev

web.dev/measure[26]是google官方提供的测量性能工具,也会提供类似PageSpeed Insight的指标,还会提供一些具体代码更改建议。

4.7 Web Vitals extension

Google也提供了扩展工具去测量Core Web Vitals。可以从Store[27]中进行安装。

web-vitals-extension.png4.8 工具:思考与总结

当我们了解了这么多工具之后,琳琅满目,我们该如何选择?如何使用好这些工具进行分析?

首先我们可以使用Lighthouse,在本地进行测量,根据报告给出的一些建议进行优化;发布之后,我们可以使用PageSpeed Insights去看下线上的性能情况;接着,我们可以使用Chrome User Experience Report API去捞取线上过去28天的数据;发现数据有异常,我们可以使用DevTools工具进行具体代码定位分析;使用Search Console’s Core Web Vitals report查看网站功能整体情况;使用Web Vitals扩展方便的看页面核心指标情况;5. 谈谈监控

最后一个章节想来谈谈监控。

我们在做性能优化的时候,常常会通过各种线上打点,来收集用户数据,进行性能分析。没错,这是一种监控手段,更精确的说,这是一种”事后”监控手段。

**”事后”监控固然重要,但我们也应该考虑”事前”监控,否则,每次发布一个需求后,去线上看数据。咦,发现数据下降了,然后我们去查代码,去查数据,去查原因。这样性能优化的同学永远处于”追赶者”的角色,永远跟在屁股后面查问题。

举个例子,我们可以这样去做”事前”监控。

建立流水线机制。流水线上如何做呢?

Lighthouse CI[28] 或 PageSpeed Insights API[29]:把Lighthouse或PageSpeed Insights API集成到CI流水线中,输出报告分析。

(图片来自Flo Sloot的Jank: You can measure what your users can feel.)

输出报告。定义异常临界值。如果异常过多,考虑是否卡发布流程。6. 总结

终于到了我们的总结部分。我们来回顾一下前面的内容:

第一部分,讲了浏览器整体架构和渲染相关进程,为什么把这个章节也放到这篇性能优化的文章中?浏览器对于我们前端开发来说,是一个sandbox或者darkbox。我们知道js、html、css结合起来就能实现我们的需求,但如果知道它是如何去渲染、执行、处理我们的代码,不管是对做需求还是性能优化,都能更知其然和所以然。

第二部分,雅虎军规是多年前提出的非常经典的优化建议。至今对于我们依然有很强的指导作用。你会发现它是从页面加载、页面渲染、到页面交互全面的一个指导建议。与今天Chrome和W3c提出的Web Vitals思路依然类似。

第三部分,性能指标,参考标准与业内标杆的建议,能更好地指导我们进行优化。

第四部分,性能工具。工欲善其事,必先利其器。这个道理大家都懂,运用好工具,才能让我们更加事半功倍。

第五部分,监控在性能优化中占很重要的部分,”事前”监控更重要,防患于未然。让性能优化成为一个预防者而不是追赶者。

没有困难的工作.jpg参考资料[1]

这一系列文章: https://developers.google.com/web/updates/2018/09/inside-browser-part1

[2]

chrome官网: https://www.chromium.org/developers/how-tos/getting-around-the-chrome-source-code

[3]

《The Anatomy of a Frame》: https://aerotwist.com/blog/the-anatomy-of-a-frame/

[4]

CSS属性: https://csstriggers.com/

[5]

[6]

google提的方案: https://developers.google.com/web/updates/2016/07/infinite-scroller

[7]

web-vitals: https://github.com/GoogleChrome/web-vitals

[8]

LCP: https://web.dev/lcp/

[9]

web-vitals: https://github.com/GoogleChrome/web-vitals

[10]

这里: https://web.dev/optimize-lcp/

[11]

FID: https://web.dev/fid/

[12]

FID: https://web.dev/fid/

[13]

web-vitals: https://github.com/GoogleChrome/web-vitals

[14]

这里: https://web.dev/optimize-fid/

[15]

CLS: https://web.dev/cls/

[16]

web-vitals: https://github.com/GoogleChrome/web-vitals

[17]

unsized-media feature policy: https://github.com/w3c/webappsec-feature-policy/blob/master/policies/unsized-media.md

[18]

这里: https://web.dev/optimize-cls/

[19]

所有工具: https://web.dev/vitals-tools/

[20]

Lighthouse CI: https://github.com/GoogleChrome/lighthouse-ci

[21]

API: https://developers.google.com/speed/docs/insights/v5/get-started

[22]

demo: https://developers.google.com/web/tools/chrome-user-experience-report/api/guides/getting-started

[23]

85.0.4181.0: https://chromium.googlesource.com/chromium/src/ log/85.0.4180.0..85.0.4181.0?pretty=fuller&n=10000

[24]

[25]

blink dev论坛讨论: https://groups.google.com/a/chromium.org/g/blink-dev/c/iHULoSyUxOQ?pli=1

[26]

web.dev/measure: https://web.dev/measure/

[27]

Store: https://chrome.google.com/webstore/detail/web-vitals/ahfhijdlegdabablpippeagghigmibma?hl=en

[28]

Lighthouse CI: https://github.com/GoogleChrome/lighthouse-ci

[29]

PageSpeed Insights API: https://developers.google.com/speed/docs/insights/v5/get-started

[30]

Puppeteer: https://github.com/puppeteer/puppeteer/blob/main/docs/api.md#class-tracing

[31]

Playwright: https://playwright.dev/docs/api/class-browser?_highlight=tracing#browserstarttracingpage-options

[32]

Chrome DevTools Protocol: https://chromedevtools.github.io/devtools-protocol/

[33]

规则: https://docs.google.com/document/d/1CvAClvFfyA5R-PhYUmn5OOQtYMH4h6I0nSsKchNAySU/edit

– EOF –

1、超全整理!Linux 性能分析工具汇总

2、从 10 多秒到 1.05 秒!前端性能优化实践

3、前端性能优化 24 条建议

发表评论

登录后才能评论