再谈DOMContentLoaded与渲染阻塞—分析html页面事件与资源加载

浏览器的多线程中,有的线程负责加载资源,有的线程负责执行脚本,有的线程负责渲染界面,有的线程负责轮询、监听用户事件。
这些线程,根据浏览器自身特点以及web标准等等,有的会被浏览器特意的阻塞。两个很明显的阻塞就是:脚本执行时对其他线程的阻塞和脚本加载时对其他线程的阻塞。
这两个阻塞发生在HTML页面初次解析时,它们对性能的影响较大,原因是:
document对象绑定了一个事件:DOMContentLoaded。这个事件会在DOM解析完成之后触发。这个事件触发之后(而不是window.load事件),会进入异步事件驱动阶段(另一个线程控制)。也就是说,DOM解析工作不完成,用户与页面的很多(并不是所有)事件交互就无法进行。这时候浏览器的忙指示(那个页面上方的烦人的旋转的圆圈)不会消失。

DOMContentLoaded什么时候触发?
DOMContentLoaded事件本身不会等待CSS文件、图片、iframe加载完成。
DOMContentLoaded的触发时机是:加载完页面,解析完所有标签(不包括执行CSS和JS),但是JS的执行,需要等待位于它前面的CSS加载(如果是外联的话)、执行完成,因为JS可能会依赖位于它前面的CSS计算出来的样式。所以:
  • 如果页面中没有script标签,DOMContentLoaded事件并没有等待CSS文件、图片加载完成。
  • 如果页面中静态的写有script标签,DOMContentLoaded事件需要等待JS执行完才触发。而且script标签中的JS需要等待位于其前面的CSS的加载完成。
注:现代浏览器会并发的预加载CSS、JS、IMG(例如:当 HTML 解析器(HTML Parser)被脚本阻塞时,解析器虽然会停止构建 DOM,但仍会识别该脚本后面的资源,并进行预加载)。但是,执行CSS和JS的顺序还是按原来的依赖顺序(JS的执行要等待位于其前面的CSS和JS加载、执行完)——先加载完成的资源,如果其依赖还没加载、执行完,就只能等着。

再谈DOMContentLoaded与渲染阻塞—分析html页面事件与资源加载_第1张图片

所以就造成外部资源阻塞渲染,如CSS 与 JavaScript
  • 默认情况下,CSS 被视为阻塞渲染的资源,这意味着浏览器将不会渲染任何已处理的内容,直至 CSSOM 构建完毕。
  • JavaScript 不仅可以读取和修改 DOM 属性,还可以读取和修改 CSSOM 属性。
默认情况下,CSS 被视为阻塞渲染的资源,存在阻塞的 CSS 资源时,浏览器会延迟 JavaScript 的执行和 DOM 构建,这意味着浏览器将不会渲染任何已处理的内容,直至 CSSOM 构建完毕。
总结如下:
  • css加载不会阻塞DOM树的解析
  • css加载会阻塞DOM树的渲染
  • css加载会阻塞后面js语句的执行
css会阻塞js,同理,css也会阻塞img解码、paint(浏览器认为你的CSS没有加载完毕,不确定图片的样式到底如何,牵扯到重绘资源问题),js不会阻塞img的解码、paint(估计chrome做了优化,具体本人还不知,希望客官补充)。

css阻塞优化:
  • 还可以用媒体类型(media type)和媒体查询(media query)来解除对渲染的阻塞。media=“print",会加载,但不会阻塞;media="(min-width:320px)",会在符合查询条件下阻塞(适配css会执行)
  • 大css文件拆分成多个小css文件,并发加载
因为渲染线程和js线程与资源进行加载的线程并不互斥,不会互斥意味着:资源的加载可以和UI渲染、重排,事件响应,或者JavaScript代码的执行的并发进行。
所以资源加载器线程会一直进行并发加载。
这里还有一个知识点:下载的最大并行数指的是从一个主机上下载的最大并行数,如果从多个主机下载资源,这个数量会翻倍,但是由于对DNS的解析也是一个性能优化的点,故而一般策略是: 不应设置超过4个主机,最好只设置2个主机。
但是操蛋的就是,如果浏览器解析DOM时需要下载脚本资源,那么下载这个资源的线程就是阻塞其他下载线程以及渲染线程,导致渲染速度变慢。
但是假设该脚本下载的速度较慢,而且多个脚本非并发下载,并且假如多个

你可能感兴趣的:(阻塞渲染,js阻塞,css,css阻塞)