Web性能优化——基础篇

引言

软件需求可分为功能性需求和质量需求两部分,其中性能是质量需求中很重要的一部分,其关乎留存、关乎口碑、关乎金钱,本文梳理介绍一下性能优化方面的基础知识。

什么是Web性能?

MDN:Web performance is the objective measurements and the perceived user experience of load time and runtime.

Web性能是包括客观度量和用户主观感受的加载和运行时的体验。

客观度量:如页面加载、渲染帧率、可交互时间等一些测量上的数据

主观感受:感受到的页面加载时间、交互快慢等(跟上面是不一样的,很多优化都是在提升用户的感受)

体验上主要包括加载(Load)和运行时,即交互响应(Response)时间。

Web性能的测量工具有哪些?

1.PerformanceAPIs

浏览器内置的一些最基本的API,属于基础,Lighthouse、WebPageTest 等其他工具均是建立在这些API之上。

Navgation Timing API 

Performance Observe API

更多API>>

2.Chome DevTools

查看网络、加载、帧率、内存等数据

network:瀑布图查看资源加载情况

performance:查看性能火焰图

memory:查看内存信息
其他...

3.Lighthouse

4.WebPageTest

如何来衡量/度量Web性能?

业界主要参考谷歌团队以及w3c性能工作组的一些性能指标

1.以用户为中心的性能指标(通用的性能指标):

整理如下: https://web.dev/metrics/

指标 含义/作用 标准(Lighthouse)
First Contentful Paint(FCP) FCP measures how long it takes the browser to render the first piece of DOM content after a user navigates to your page. ——传统首屏 0–1.8 fast、1.8-3 moderate、> 3 slow
First Meaningful Paint(FMP) FMP measures when the primary content of a page is visible to the user.FMP essentially shows the timing of the paint after which the biggest above-the-fold layout change happens 0–2 fast、2-4 moderate、> 4 slow
Speed Index The Speed Index is the average time at which visible parts of the page are displayed. It is expressed in milliseconds and dependent on size of the view port. 0–3.4 fast、3.4-5.8 moderate、> 5.8 slow
Time to Interactive(TTI) TTI measures how long it takes a page to become fully interactive. 0–3.8 fast、3.9-7.3 moderate、> 7.3 slow
Max Potential First Input Delay Max Potential FID measures the worst-case First Input Delay that your users might experience. First Input Delay measures the time from when a user first interacts with your site, such as clicking a button, to the time when the browser is actually able to respond to that interaction. 0–130ms fast、130-250 moderate、> 250 slow
Total Blocking Time(TBT) TBT 测量页面被阻止响应用户输入(例如鼠标点击、屏幕点击或键盘按下)的总时间,大于 50ms 为长任务,block time 为 longtasktime - 50 0-200ms fast、200-600 moderate、> 600 slow
Cumulative Layout Shift CLS 测量整个页面生命周期内发生的所有意外布局偏移中最大一连串的布局偏移分数。 < 0.1 good、0.1-0.25 needs improvement、>2.05 poor
Interaction to Next Paint (INP) NP aims to represent a page's overall responsiveness by measuring all click, tap, and keyboard interactions made with a page. <200 good、200-500 needs improvement、>500 poor
Largest Contentful Paint(LCP) 最大内容绘制 (LCP) 指标会根据页面首次开始加载的时间点来报告可视区域内可见的最大图像或文本块完成渲染的相对时间。 0–2.5 fast、2.5-4 moderate、> 4 slow
First CPU Idle(FCI) First CPU Idle measures how long it takes a page to become minimally interactive. A page is considered minimally interactive when:Most—but not necessarily all—UI elements on the screen are interactive, andThe page responds, on average, to most user input in a reasonable amount of time. 0–4.7 fast、4.8-6.5 moderate、> 6.5 slow

(最)核心Web性能指标:2020三大指标

ps:如何定义指标是真正了解性能的核心,如有时间和兴趣建议逐项详细阅读!!!

2.RAIL模型,谷歌以用户为中心的性能指标模型

RAIL 是一种以用户为中心的性能模型,它提供了一种考虑性能的结构。该模型将用户体验分解到按键操作(例如,点击、滚动、加载)中,帮助您为每个操作定义性能目标。

Explain:上面的指标主要是反映整体的性能问题,不一定能完全反映用户侧的感受,RAIL模型是直接从用户的角度来定义性能指标的。

RAIL性能模型主要包括四个部分:

Response(响应):在 50ms 内处理事件

目标:在 100ms 内完成由用户输入发起的转换,让用户感觉交互是即时的。

Animation(动画):在 10ms 内生成一帧

目标:在 10ms 或更短的时间内生成动画的每一帧。从技术上来讲,每帧的最大预算为 16ms(1000 ms/ 60 ≈ 16 ms),但是,浏览器需要大约 6 毫秒来渲染一帧。

Idle(空闲):最大限度增加空闲时间

最大限度增加空闲时间以提高页面在 50 ms内响应用户输入的几率。

Load(加载):在5s内交付并实现可交互——按现在的网速来说有点过时了,大体应该在3s内,下面附一个用户对叫体验的感受

目前,对于,在使用速度较慢 3G 连接的中端移动设备上,理想的目标是在 5s 或更短的事件内实现交互
对于后续加载,理想的目标是在 2s 内加载页面。

用户对交互体验的感受:

Time Exprience
0 to 16 ms Users are exceptionally good at tracking motion, and they dislike it when animations aren't smooth. They perceive animations as smooth so long as 60 new frames are rendered every second. That's 16 ms per frame, including the time it takes for the browser to paint the new frame to the screen, leaving an app about 10 ms to produce a frame.
0 to 100 ms Respond to user actions within this time window and users feel like the result is immediate. Any longer, and the connection between action and reaction is broken.
100 to 1000 ms Within this window, things feel part of a natural and continuous progression of tasks. For most users on the web, loading pages or changing views represents a task.
1000 ms or more Beyond 1000 milliseconds (1 second), users lose focus on the task they are performing.
10000 ms or more Beyond 10000 milliseconds (10 seconds), users are frustrated and are likely to abandon tasks. They may or may not come back later.

3.性能指标归纳

用户交互响应要在100ms内给出,用户从操作到数据加载要在2000ms内完成

Web性能优化基本原理和方法

1.chromium多进程模型

说明:

  • Browser进程:浏览器的主进程,负责浏览器界面的显示,各个页面的管理,其他各种进程的管理;

  • Render进程:页面的渲染进程,负责页面的渲染工作,WebKit的工作主要在这个进程中完成;

  • NPAPI插件进程:每种类型的插件只会有一个进程,每个插件进程可以被多个Render进程共享;

  • GPU进程:最多只有一个,当且仅当GPU硬件加速打开的时候才会被创建,主要用于对3D加速调用的实现;

  • Pepper插件进程:同NPAPI插件进程,不同的是为Pepper插件而创建的进程

好处:

  • 避免单个page crash影响整个浏览器

  • 避免第三方插件crash影响整个浏览器

  • 方便使用沙盒模型隔离插件等进程,提高浏览器稳定性

  • 多进程充分利用多核优势

2.chromium多线程模型

3.浏览器执行过程

分为导航、响应、解析、渲染、交互几个过程:

4.进一步理解渲染

60FPS与设备刷新率

目前大多数设备的屏幕刷新率为 60 次/秒。因此,如果在页面中有一个动画或渐变效果,或者用户正在滚动页面,那么浏览器渲

染动画或页面的每一帧的速率也需要跟设备屏幕的刷新率保持一致。其中每个帧的预算时间仅比 16 毫秒多一点 (1 秒/ 60 =

16.66 毫秒)。但实际上,浏览器有整理工作要做,因此您的所有工作需要在 10 毫秒内完成。如果无法符合此预算,帧率将下

降,并且内容会在屏幕上抖动。 此现象通常称为卡顿,会对用户体验产生负面影响。

像素管道:像素绘制到屏幕中的关键点,任何一个阶段都可能产生卡顿

JavaScript(代码变动):
一般来说,我们会使用 JavaScript 来实现一些视觉变化的效果。比如用 jQuery 的 animate 函数做一个动画、对一个数据集进

行排序或者往页面里添加一些 DOM 元素等。当然,除了 JavaScript,还有其他一些常用方法也可以实现视觉变化效果,比如:

CSS Animations、Transitions 和 Web Animation API。

Style(样式计算):

此过程是根据匹配选择器(例如 .headline 或 .nav > .nav__item)计算出哪些元素应用哪些 CSS 规则的过程。从中知道规则之

后,将应用规则并计算每个元素的最终样式。

Layout(布局):

在知道对一个元素应用哪些规则之后,浏览器即可开始计算它要占据的空间大小及其在屏幕的位置。网页的布局模式意味着一个

元素可能影响其他元素,例如 元素的宽度一般会影响其子元素的宽度以及树中各处的节点,因此对于浏览器来说,布

局过程是经常发生的。

Paint(绘制):

绘制是填充像素的过程。它涉及绘出文本、颜色、图像、边框和阴影,基本上包括元素的每个可视部分。绘制一般是在多个表面

(通常称为层)上完成的。

Composite(合成):

由于页面的各部分可能被绘制到多层,由此它们需要按正确顺序绘制到屏幕上,以便正确渲染页面。对于与另一元素重叠的元素

来说,这点特别重要,因为一个错误可能使一个元素错误地出现在另一个元素的上层。

5.渲染阶段基础优化手段

Javascript:

1.使用 requestAnimationFrame 来实现视觉变化

requestAnimationFrame 采用系统时间间隔(一般系统为60FPS),保持最佳绘制效率。不会因为间隔时间过短,造成过度绘制,增加开销;也不会因为间隔时间过长,使动画卡顿。

requestAnimationFrame VS setTimeout/setInterval

a. 提升性能,防止掉帧

b.节约资源,节省电源 ——page hidden 后自动停止

2.降低复杂性或使用 Web Worker

JavaScript 在浏览器的主线程上运行,恰好与样式计算、布局以及许多情况下的绘制一起运行。如果 JavaScript 运行时间过

长,就会阻塞这些其他工作,可能导致帧丢失。因此,要尽控制 JavaScript 的运行时机以及运行时间。例如,如果在滚动之类

的动画中,最好是想办法使 JavaScript的执行 保持在 3-4ms 范围内。

在许多情况下,可以将纯计算工作移到 Web Worker,例如,如果它不需要 DOM 访问权限。数据操作或遍历(例如排序或搜

索)往往很适合这种模型,加载和模型生成也是如此。并非所有工作都适合此模型: Web Worker 没有 DOM 访问权限。

如果您的工作必须在主线程上执行,请考虑一种批量方法,将大型任务分割为微任务,每个微任务所占时间不超过几毫秒,并且

在每帧的 requestAnimationFrame 处理程序内运行。

3.避免JavaScript微优化:

从性价比的角度出发,JavaScript微优化投入产出比较低,特殊场景再考虑(JavaScript优化也有很多手段,可以自行查找下)

Style->Layout->Paint->Composit:

概念:

重绘:由于节点的几何属性发生改变或者由于样式发生改变并且不会影响布局的,称为重绘 —— Paint及之后

回流:回流是布局或者几何属性需要改变就称为回流

优化手段:

1.尽量避免大型布局,降低复杂度

2.使用性能较高的一些布局方法,如 flex 等

3.CSSOM阶段优化,降低选择器复杂度

4.避免重绘(Repaint)、重排

a.减少改动: 内存换操作——虚拟DOM

b. 避免不必要的重绘重排操作

5.复合图层:

will-change: transform,will-change会将元素直接提升至单独的合成层,交由GPU渲染原则:该拆的拆,不必

要的不要拆,避免内存暴涨

6.传输加载基础优化手段

资源Gzip压缩

设置keep-alive,避免频繁重建TCP链接

http-cache 加速非首次访问速度

serviceWorker:需要 https,tsl证书(离线缓存、加速重复访问)

http2 协议:建立在https基础上,适用于访问量较大场景(二进制分帧、多路复用、服务端推送)

CDN加速

7.资源基础优化手段

Html 压缩

CSS 压缩

JS 压缩

CSS、JS 合并

图片优化

字体资源优化

8.后端的基础优化手段

使用缓存

按需拉取

串行转并行

内存IO换网路IO

其他:就近部署、如http使用http2.0、Mysql优化等,不详述

9.一些业务应用上的优化思路

主路径优先原则——最基本的一条,按照“道法术器”来说,这个就是“道”

合理利用缓存:localStorage、IndexDB、Redis ———离线化“应用”

预加载、懒加载、按需加载

前端的一些虚拟列表、服务端渲染等

10.基于Vue的优化手段

使用Vue的项目可以看看:https://www.cnblogs.com/DevinnZ/p/17732217.html

最后

搞Web性能优化不是搞科学,不需要很高的门槛,主要是:基础 + 思路,如果性能优化方面有要求的在这两点上下功夫就可以了,如果没有时间去研究,记住一条原则 “主路径优先”——性能优化之道。

posted @ 2023-10-26 16:03  今年十六岁  阅读(183)  评论(0编辑  收藏  举报