浏览器的performance

zhaojing

浏览器devtools:

Elements:在 Elements 面板中可以通过 DOM 树的形式查看所有页面元素,同时也能对这些页面元素进行所见即所得的编辑

Console:一方面用来记录页面在执行过程中的信息(一般通过各种 console 语句来实现),另一方面用来当做 shell 窗口来执行脚本以及与页面文档、DevTools等进行交互

Sources:Sources 面板主要用来调试页面中的 JavaScript

Network:在 Network 面板中可以查看通过网络来请求来的资源的详细信息以及请求这些资源的耗时

Performance:在 Performance 面板可以查看页面加载过程中的详细信息,比如在什么时间开始做什么事情,耗时多久等等。有人会问,这个跟上面的 Network 有什么区别呢,上面也能显示耗时信息。在 Performance 面板中,你不仅可以看到通过网络加载资源的信息,还能看到解析 JS、计算样式、重绘等页面加载的方方面面的信息

Memory:Memory 面板主要显示页面 JS 对象和相关联的 DOM 节点的内存分布情况

Application:记录网页加载的所有资源,包括存储信息、缓存信息以及页面用到的图片、字体、脚本、样式等信息

Security:用于检测当面页面的安全性

Audits:审计面板会对页面的加载进行分析,然后给出提高页面性能的建议。

浏览器的 performance
performance.png

页面整体分为4个区域:

1:具体条,包含录制,刷新页面分析,清除结果等操作

2:overview总览图,高度概括随时间线的变动,包括FPS,CPU,NET

FPS(frames per second)是用来分析动画的一个主要性能指标。       绿色竖线越高,FPS 越高。 FPS 图表上的红色块表示长时间帧,       很可能会出现卡顿。能保持在60的FPS的话,那么用户体验就是不       错的。
CPU  cpu 资源, 消耗 CPU
NET  网络请求

3:火焰图,从不同的角度分析框选区域 。例如:Network,Frames, Interactions, Main等

蓝线代表 DOMContentLoaded 事件。 绿线代表首次绘制的时间。 红线代表 load 事件

4:总结区域:精确到毫秒级的分析,以及按调用层级,事件分类的整理

蓝色(Loading):网络通信和HTML解析
黄色(Scripting):JavaScript执行中
紫色(Rendering):样式计算和布局,即重排
绿色(Painting):重绘时间
灰色(other):其它事件花费的时间
白色(Idle):空闲时间

loading事件:

Send Request 发送网络请求时触发

Receive Response 响应头报文到达时触发

Receive Data 请求的响应数据到达事件,如果响应数据很大(拆包),可能会多次触发该事件

Finish Loading 网络请求完毕事件

Parse HTML 浏览器执行HTML解析

scripting事件:

Animation Frame Fired 一个定义好的动画帧发生并开始回调处理时触发

Cancel Animation Frame 取消一个动画帧时触发

GC Event 垃圾回收时触发

DOMContentLoaded 当页面中的DOM内容加载并解析完毕时触发

Evaluate Script A script was evaluated.

Event js事件

Function Call 只有当浏览器进入到js引擎中时触发

Install Timer 创建计时器(调用setTimeout()和setInterval())时触发

Remove Timer 当清除一个计时器时触发

Time 调用console.time()时触发

Time End 调用console.timeEnd()触发

Timer Fired 定时器激活回调后触发

XHR Ready State Change 当一个异步请求为就绪状态后触发

XHR Load 当一个异步请求完成加载后触发

Rendering事件:

Invalidate layout 当DOM更改导致页面布局失效时触发

Layout 页面布局计算执行时触发

Recalculate style Chrome重新计算元素样式时触发

Scroll 内嵌的视窗滚动时触发

Painting事件:

Composite Layers Chrome的渲染引擎完成图片层合并时触发 ,合成层;当渲染树上的节点涂鸦完毕后,便生成位图(bitmap),浏览器把此位图从CPU传输到GPU

Image Decode 一个图片资源完成解码后触发

Image Resize 一个图片被修改尺寸后触发

Paint 合并后的层被绘制到对应显示区域后触发 确定渲染树上的节点的大小和位置后,便可以对节点进行涂鸦(paint)

Send Request 发送网络请求

根据url,先去本地DNS缓存列表里寻找对应的服务器的ip地址和端口号,若没有找到,继续寻找系统缓存和路由缓存,若找到则跳转第三步

还没找到的话则请求本地DNS服务器,没有就将域名发送给其他服务器,递归寻找,从根域名服务器开始不断向下递归,直到返回对应的IP地址和端口号,并将其缓存

根据ip地址和端口号,与目标服务器建立TCP连接(三次握手)

这三步并没有被我们看见,然后接下来的事就被我们观察到了

浏览器向服务器发送http请求,并接收返回的响应头和响应体

Receive Data

服务器在发送数据的时候,可能会进行拆包,分几次发送

下面就是解析html 解析js解析css了

html: HTML Parser的任务是将HTML标记,解析成DOM Tree,这是一个深度遍历的过程,只有Dom下的子节点都被遍历完成,才遍历下一个同级Dom节点

js:

不管是内联的还是外部的,都会阻塞后续dom的解析和渲染,

所以一般将<script>标签放在<body>后面

如果是外部的,还可以在<script>标签上加上defer或async属性

defer可以让js的下载不影响html的后续解析,且在html解析完了再执行js文件,且按照原来的下载顺序

async也是让js的下载不影响html的后续解析,但一旦下载完了就立即执行,因此也无法保证按照下载顺序执行

css:外部和内部的css文件都不会阻塞dom的解析,但是会阻塞dom的渲染

渲染布局与绘制

在有了Dom Tree和CSSOM之后
浏览器就会构建Render Tree(渲染树)Render Tree实际上就是一个计算好了样式,同时不包含display:none之类,不占据空间的元素的的渲染树。

把DOM Tree和CSSOM进行附加

重排和重绘:

完成了第一次绘制之后,浏览器会继续收到服务器发来的数据
图片,css文件,js文件
其中可能会有导致页面布局更改或样式更改的内容,都会添加到我们的Render Tree上去
引起重排(Layout)或重绘(Paint)

引起重排的操作:

页面首次渲染
浏览器窗口大小发生改变
元素尺寸或位置发生改变
元素内容变化(文字数量或图片大小等等)
元素字体大小变化
添加或者删除可见的DOM元素
激活CSS伪类(例如::hover)
设置style属性
重绘 :

引起重绘的一般都是修改元素的属性

性能优化

从性能优化的角度,我们要尽量减少浏览器的重排和重绘,尤其是重排

尽量不要在布局信息改变时做查询(会导致渲染队列强制刷新)

减少DOM操作,同一个DOM的多个属性改变可以写在一起,在一个局部方法中需要多次访问同一个Dom,则先暂存它的引用。批量添加DOM,可以先让元素脱离文档流,操作完后再带入文档流,这样只会触发一次重排(应用fragment元素)

将需要多次重排的元素,position属性设为absolute或fixed,例如有动画效果的元素

采用更优的API替代消费高的API,转换优化消费高的集合,如用querySelectorAll()替代getElementByXX()。

开启动画的GPU加速

少用HTML集合(类数组)来遍历,因为集合遍历比真数组遍历耗费更高。

用事件委托来减少事件处理器的数量。

避免设置大量的style属性,因为通过每一次设置都会触发一次reflow,所以最好是使用class属性

动画实现的速度太精细平滑,会导致reflow过于频繁

不要使用table布局,因为table中某个元素旦触发了reflow,那么整个表格都会reflow。

减少通过JavaScript代码修改元素样式,尽量使用修改class名方式操作样式或动画;

隐藏在屏幕外,或在页面滚动时,尽量停止动画;

window.performance这个API可以告诉我们一下当前页面中与性能相关的信息。

资料:https://developer.mozilla.org/zh-CN/docs/Web/API/Performance

阅读 1.2k
0 声望
1 粉丝
0 条评论
0 声望
1 粉丝
宣传栏