瀏覽器的多線程中,有的線程負責加載資源,有的線程負責執(zhí)行腳本,有的線程負責渲染界面,有的線程負責輪詢、監(jiān)聽用戶事件。
成都創(chuàng)新互聯(lián)公司始終堅持【策劃先行,效果至上】的經(jīng)營理念,通過多達十多年累計超上千家客戶的網(wǎng)站建設總結了一套系統(tǒng)有效的全網(wǎng)推廣解決方案,現(xiàn)已廣泛運用于各行各業(yè)的客戶,其中包括:宣傳片制作等企業(yè),備受客戶表揚。
這些線程,根據(jù)瀏覽器自身特點以及web標準等等,有的會被瀏覽器特意的阻塞。兩個很明顯的阻塞就是:腳本執(zhí)行時對其他線程的阻塞和腳本加載時對其他線程的阻塞。
這兩個阻塞發(fā)生在HTML頁面初次解析時,它們對性能的影響較大,原因是:
document對象綁定了一個事件:DOMContentLoaded。這個事件會在DOM解析完成之后觸發(fā)。這個事件觸發(fā)之后(而不是window.load事件),會進入異步事件驅動階段(另一個線程控制)。也就是說,DOM解析工作不完成,用戶與頁面的很多(并不是所有)事件交互就無法進行。這時候瀏覽器的忙指示(那個頁面上方的煩人的旋轉的圓圈)不會消失。
DOMContentLoaded事件本身不會等待CSS文件、圖片、iframe加載完成。
DOMContentLoaded的觸發(fā)時機是:加載完頁面,解析完所有標簽(不包括執(zhí)行CSS和JS),但是JS的執(zhí)行,需要等待位于它前面的CSS加載(如果是外聯(lián)的話)、執(zhí)行完成,因為JS可能會依賴位于它前面的CSS計算出來的樣式。所以:
如果頁面中沒有script標簽,DOMContentLoaded事件并沒有等待CSS文件、圖片加載完成。
如果頁面中靜態(tài)的寫有script標簽,DOMContentLoaded事件需要等待JS執(zhí)行完才觸發(fā)。而且script標簽中的JS需要等待位于其前面的CSS的加載完成。
注:現(xiàn)代瀏覽器會并發(fā)的預加載CSS、JS、IMG(例如:當 HTML 解析器(HTML Parser)被腳本阻塞時,解析器雖然會停止構建 DOM,但仍會識別該腳本后面的資源,并進行預加載)。但是,執(zhí)行CSS和JS的順序還是按原來的依賴順序(JS的執(zhí)行要等待位于其前面的CSS和JS加載、執(zhí)行完)——先加載完成的資源,如果其依賴還沒加載、執(zhí)行完,就只能等著。
所以就造成外部資源阻塞渲染,如CSS 與 JavaScript
默認情況下,CSS 被視為阻塞渲染的資源,這意味著瀏覽器將不會渲染任何已處理的內(nèi)容,直至 CSSOM 構建完畢。
JavaScript 不僅可以讀取和修改 DOM 屬性,還可以讀取和修改 CSSOM 屬性。
默認情況下,CSS 被視為阻塞渲染的資源,存在阻塞的 CSS 資源時,瀏覽器會延遲 JavaScript 的執(zhí)行和 DOM 構建,這意味著瀏覽器將不會渲染任何已處理的內(nèi)容,直至 CSSOM 構建完畢。
總結如下:
css加載不會阻塞DOM樹的解析
css加載會阻塞DOM樹的渲染
css加載會阻塞后面js語句的執(zhí)行
css會阻塞js,同理,css也會阻塞img解碼、paint(瀏覽器認為你的CSS沒有加載完畢,不確定圖片的樣式到底如何,牽扯到重繪資源問題),js不會阻塞img的解碼、paint(估計chrome做了優(yōu)化,具體本人還不知,希望客官補充)。
還可以用媒體類型(media type)和媒體查詢(media query)來解除對渲染的阻塞。
media=“print",會加載,但不會阻塞;media="(min-width:320px)",會在符合查詢條件下阻塞(適配css會執(zhí)行)
大css文件拆分成多個小css文件,并發(fā)加載
因為渲染線程和js線程與資源進行加載的線程并不互斥,不會互斥意味著:資源的加載可以和UI渲染、重排,事件響應,或者JavaScript代碼的執(zhí)行的并發(fā)進行。
所以資源加載器線程會一直進行并發(fā)加載。
這里還有一個知識點:下載的最大并行數(shù)指的是從一個主機上下載的最大并行數(shù),如果從多個主機下載資源,這個數(shù)量會翻倍,但是由于對DNS的解析也是一個性能優(yōu)化的點,故而一般策略是:不應設置超過4個主機,最好只設置2個主機。
但是操蛋的就是,如果瀏覽器解析DOM時需要下載腳本資源,那么下載這個資源的線程就是阻塞其他下載線程以及渲染線程,導致渲染速度變慢。
但是假設該腳本下載的速度較慢,而且多個腳本非并發(fā)下載,并且假如多個<script>內(nèi)腳本執(zhí)行時間較長的話,DOM解析工作還是會一直完不成。
故而我們需要無阻塞加載腳本的技術。
因為:腳本執(zhí)行和渲染DOM的并發(fā)可能會引發(fā)嚴重的沖突(腳本可以修改DOM)
所以:JavaScript引擎和渲染引擎所在的兩個線程被設計為互斥的!
這就意味著:在執(zhí)行<script>中內(nèi)容時,瀏覽器會切換到JavaScript引擎所在的線程,此時渲染引擎所在的線程會阻塞,故其后元素的解析和渲染會暫停。這時候如果腳本執(zhí)行時間太長的話,不僅后面的元素會一直看不到,對DOM的解析工作也會一直完不成。用戶會陷入焦急的等待中。
為了防止javascript阻塞,我們會
1、把<script>放到緊跟</body>之前的位置
這樣就不會影響需要放到頁面上的UI元素的解析了。這樣的好處就是,用戶能即使看到頁面上的UI元素,而防止出現(xiàn)了瀏覽器白屏等現(xiàn)象。
2、動態(tài)腳本元素-不重要的js動態(tài)插入。
因為document.createElement("script")的async屬性默認為true,而document.head.appendChild代碼之后,由于沒有觸發(fā)渲染樹的重繪,切換回的渲染線程會將剩下的DOM解析并渲染完畢。同時新插入的<script>中的資源也會并發(fā)的下載。
var script=document.createElement("script"); console.log(script.async);//true
同理:用XHR對象下載代碼,并注入到頁面也可以達到同樣的效果
如果需要同步執(zhí)行,需要將async屬性設置為fasle
3、h6時代,script添加defer或asyn兩個屬性(html4.0中定義了defer;html5.0中定義了async)
如果 script 標簽中包含 defer,那么這一塊腳本將不會影響 HTML 文檔的解析,而是等到 HTML 解析完成后才會執(zhí)行。而 DOMContentLoaded 只有在 defer 腳本執(zhí)行結束后才會被觸發(fā)。即:整個 document 解析完畢且 defer-script 也加載完成之后(這兩件事情的順序無關),會執(zhí)行所有由 defer-script 加載的 JavaScript 代碼,然后觸發(fā) DOMContentLoaded 事件。defer不會改變script中代碼執(zhí)行順序
如果 script 標簽中包含 async,則 HTML 文檔構建不受影響,不需要等待 async-script 執(zhí)行。但是,async-script 加載完成后,就會立即執(zhí)行!如果頁面還是沒有解析完成,就會停下來(阻塞頁面)等此腳本執(zhí)行完畢再繼續(xù)解析。async-script 可能在 DOMContentLoaded 觸發(fā)之前或之后執(zhí)行,但一定在 load 觸發(fā)之前執(zhí)行。而且:多個 async-script 的執(zhí)行順序是不確定的。
說道DOMContentLoaded,不得不提readystatechange,通過document.readyState值來更進一步來判斷文檔狀態(tài):
uninitiated:xml 對象被產(chǎn)生,但沒有任何文件被加載。
loading:document正在下載,文件尚未開始解析。
loaded:部分的文件已經(jīng)加載且進行解析,但對象模型尚未生效。
interactive:document完成了解析,但是資源還在下載,對象模型是有效但只讀的。
complete:代表加載成功,文檔加載完成,并且所有resource都加載完畢
通過下面代碼驗證,在chrome上貌似只有 interactive和complete。
document.addEventListener("DOMContentLoaded",function () { console.log("DOMContentLoaded"+new Date()) }); document.addEventListener("readystatechange",function () { console.log("B_____"+new Date()); console.log(document.readyState) // switch (document.readyState){ // case "loading": // console.log("LOADING"+new Date()); // break; // case "loaded": // console.log("loaded"+new Date()); // break; // case "interactive": // console.log("interactive"+new Date()); // break; // case "complete": // console.log("complete"+new Date()); // break; // } }); console.time("A")
A: 5.89208984375ms
B_____Thu May 17 2018 10:23:36 GMT+0800 (CST)
interactive
DOMContentLoadedThu May 17 2018 10:23:36 GMT+0800 (CST)
B_____Thu May 17 2018 10:23:36 GMT+0800 (CST)
complete
但是,今天看了:你不知道的 DOMContentLoaded
這里又有疑問:interactive DOMContentLoaded complete onload三個先后順序是什么呢?
DOMContentLoaded和interactive:表示文檔解析完成,且資源未完全加載完成。區(qū)別呢?執(zhí)行順序呢?
驗證表明:interactive 》DOMContentLoaded 》 complete 》 onload
但是,DOMContentLoaded觸發(fā)時候,document.readyState一般是interactive,也有可能complete。而當頁面有大量的二進制文件(頁面加載的時長大于阻塞的時長的時候),document.readyState=complete 可能反而在 onload 事件之后才能觸發(fā)(這個我未完成驗證出這種情況)
我覺得onreadystatechange這個不是很靠譜,一般用DOMContentLoaded判斷頁面解析完全。希望哪位大牛提供這方面的補充,感激不盡!
在圖片上,也有onload跟complete
document.getElementById('load').onclick = function() { var img = new Image(); if(img.complete) { console.log('dd'); } img.onload = function() { console.log('ff') } img.src="images/1-logo.png"; }
這里順帶提下img加載相關 屬性
onload:表示加載好,換言之,沒有加載好不會執(zhí)行;
onAbort:圖片加載的時候,用戶通過點擊停止加載時出發(fā)
onerror:如果圖片不存在(網(wǎng)絡很不通暢,也可能觸發(fā) onerror事件)
complete:圖片顯示出來以后為true,
參考文章:
你不知道的 DOMContentLoaded
JS、CSS以及img對DOMContentLoaded事件的影響
瀏覽器線程阻塞和無阻塞加載腳本的理解
css加載會造成阻塞嗎?
轉載請注明來源:再談DOMContentLoaded與渲染阻塞—分析html頁面事件與資源加載
網(wǎng)頁標題:再談DOMContentLoaded與渲染阻塞—分析html頁面事件與資源加載
網(wǎng)站網(wǎng)址:http://jinyejixie.com/article4/ghhiie.html
成都網(wǎng)站建設公司_創(chuàng)新互聯(lián),為您提供定制網(wǎng)站、軟件開發(fā)、營銷型網(wǎng)站建設、手機網(wǎng)站建設、關鍵詞優(yōu)化、網(wǎng)站內(nèi)鏈
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉載內(nèi)容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉載,或轉載時需注明來源: 創(chuàng)新互聯(lián)