深入了解JavaScript阻塞渲染
作者:卡颂
前言:
在中文社区,这么多年一直流传一个说法:JS
线程负责执行JS
,GUI
渲染线程负责渲染,这两者是互斥的,所以JS
执行时会阻塞渲染。但随着Dev Tools
使用的增多,逐渐开始怀疑以上说法。本文会以实际案例来解释为什么JS
阻塞渲染。
到底几个线程
在讲解JS
线程与GUI
线程互斥的文章中,通常会列出渲染进程包含的线程,比如:
GUI
渲染线程JS
引擎线程- 事件触发线程
- 定时触发器线程
HTTP
请求线程
但是,我们以百度的搜索页举例,打开Performance
面板开启录制:
上图录制结果中:
Chrome_ChildIOThread
对应IO
线程的任务记录,用户输入、网络、设备相关事件都与他相关Raster
记录光栅化线程池任务、GPU
记录GPU
合成位图的任务、Compositor
记录合成线程的任务执行,以上三者都与浏览器渲染相关Main
记录渲染进程的主线程中的任务
从这个角度看,浏览器实际的线程情况与那些GUI
线程相关的文章描述的并不相同。
主线程的任务
接下来,让我们进入Main
。红线框内长短不一的灰色块,就是主线程中执行的任务。
注意看红框内的绿色块FP
,代表First Paint
(首次绘制):
那么在首次绘制前都要执行什么任务呢?可以看到主要有3个Task
(任务):
第一个任务是请求HTML
数据:
Parse HTML
当请求回HTML
字节流后,开始第二个任务,将HTML
字节流解析为DOM
,这个任务的名字就是图中的蓝色块Parse HTML
:
注意其中有些执行时长不一的Evaluate Script
,这些是解析DOM
树过程中遇到的JS
代码。
从DOM
树中可以看到这些阻塞DOM
树生成的JS
脚本:
他们的存在显著拉长了Parse HTML
的用时。
Recaculate Style
解析完DOM
树(蓝色Parse HTML
)后,下一个任务是紫色Recaculate Style
:
他负责将HTML
中的CSS
样式(外联、内联)输出为styleSheets
,styleSheets
有两个作用:
- 可以与
DOM
树结合为页面带来样式 JS
可以操作styleSheets
改变页面样式
我们可以从控制台打印document.styleSheets
直观感受他的存在:
Layout
有了DOM
树与styleSheets
,接下来需要为视图中可见部分生成一棵树(比如display: none
部分就不需要在这棵树中显示)。
这个任务是紫色Layout
:
Update Layer Tree
用户看到的页面实际是由多层页面重叠后的结果,开发者可以用很多手段(比如z-index
)改变某部分的层级。
比如滚动条就会形成自己独立的层级:
既然是多层结构,那么就需要更新每层的信息,这个任务是紫色的Update Layer Tree
:
Paint
我们可以发现,在FP
之前,Update Layer Tree
之后只剩下Paint
这一任务了:
从字面意义讲,这就是绘制么?并不是。
Paint
的任务是整理每一层页面的绘制信息,构成绘制列表,这些数据会交给合成线程负责后续绘制操作。
可以发现,具体的绘制操作是交由合成线程完成,他与JS
所在线程(主线程)并不是互斥的。
JS为啥阻塞渲染
我们现在知道,JS
执行与Paint
任务都发生在主线程。
渲染被阻塞的原因很明显:因为Paint
任务没有及时执行,即绘制列表没有及时提交给合成线程。
之所以没有及时执行,可能是因为JS
执行时间过长,导致这一帧没有时间执行Paint
。
比如,我们打开B站,记录下主线程的任务。
可以看到,有个JS
执行时长达到231.88ms,超过了一帧的时间,在此期间主线程就没时间执行Paint
了:
总结
JS
之所以阻塞渲染,是因为JS
执行与渲染相关任务都在争夺主线程有限的资源。当JS
执行时间过长,渲染相关任务就没时间执行了。
到此这篇关于深入了解JavaScript阻塞渲染的文章就介绍到这了,更多相关JS阻塞渲染 内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!