關(guān)于web性能一些特性匯總

DOMContentLoaded & load

load事件是window對(duì)象上的事件。指的是網(wǎng)頁(yè)資源已經(jīng)加載完畢（包括但不限于DOM、圖片、音頻、腳本、插件資源以及CSS）。

DOMContentLoaded事件是document對(duì)象上的事件。指的是DOM已經(jīng)加載完畢。IE中有個(gè)私有的事件onreadystatechange事件跟這個(gè)標(biāo)準(zhǔn)事件類似。

因此DOMContentLoaded事件都會(huì)比load事件提前觸發(fā)(jQuery重點(diǎn)ready event 就是兼容各種情況的DOMContentLoaded實(shí)現(xiàn)，感覺DOMContentLoaded時(shí)JS腳步也跑完了，畢竟放在body前）。

event.target & event.currentTarget & event.delegateTarget

在事件冒泡過程中的當(dāng)前DOM元素。

觸發(fā)事件的DOM元素。

綁定了當(dāng)前正在調(diào)用jQuery 事件處理器的元素。

async & defer （script TAG)

async 異步下載，下載后立即執(zhí)行

defer 異步下載，按順序執(zhí)行,執(zhí)行區(qū)間大致在DOMContentLoaded 和window.load 之間

FPS（Frames Per Second）：每秒傳輸幀數(shù)

正如Andrey Kosyakov Chromium 的博客中提到的，即使你的程序沒有很多動(dòng)畫，幀的概念也是有用的，因?yàn)闉g覽器在處理輸入事件時(shí)會(huì)生成重復(fù)動(dòng)作的序列。如果你在一幀中留有足夠的時(shí)間處理這些事件，就會(huì)使你的程序看上去有更好的響應(yīng)性，這意味著更好的用戶體驗(yàn)。

如果我們的目標(biāo)是60fps, 那么最多有 16.66ms 去做所有的事情。這個(gè)時(shí)間并不多，所以盡可能從動(dòng)畫中擠出時(shí)間來提高性能還是很重要的。

CSS阻塞與JS阻塞

• JS阻塞

所有瀏覽器在下載JS的時(shí)候，會(huì)阻止一切其他活動(dòng)，比如其他資源的下載，內(nèi)容的呈現(xiàn)等等。
直到JS下載、解析、執(zhí)行完畢后才開始繼續(xù)并行下載其他資源并呈現(xiàn)內(nèi)容。
為了提高用戶體驗(yàn)，新一代瀏覽器都支持并行下載JS，但是JS下載仍然會(huì)阻塞其它資源的下載（例如.圖片，css文件等）。

由于瀏覽器為了防止出現(xiàn)JS修改DOM樹，需要重新構(gòu)建DOM樹的情況，所以就會(huì)阻塞其他的下載和呈現(xiàn)。

嵌入JS會(huì)阻塞所有內(nèi)容的呈現(xiàn)，而外部JS只會(huì)阻塞其后內(nèi)容的顯示，

2種方式都會(huì)阻塞其后資源的下載。也就是說外部樣式不會(huì)阻塞外部腳本的加載，但會(huì)阻塞外部腳本的執(zhí)行。

• CSS阻塞

CSS本來是可以并行下載的，在什么情況下會(huì)出現(xiàn)阻塞加載了(在測(cè)試觀察中，IE6下CSS都是阻塞加載）

當(dāng)CSS后面跟著嵌入的JS的時(shí)候，該CSS就會(huì)出現(xiàn)阻塞后面資源下載的情況。而當(dāng)把嵌入JS放到CSS前面，就不會(huì)出現(xiàn)阻塞的情況了。

根本原因：因?yàn)闉g覽器會(huì)維持html中css和js的順序，樣式表必須在嵌入的JS執(zhí)行前先加載、解析完。而嵌入的JS會(huì)阻塞后面的資源加載，所以就會(huì)出現(xiàn)上面CSS阻塞下載的情況。

CSS匹配規(guī)則

• HTML 經(jīng)過解析生成 DOM Tree（這個(gè)我們比較熟悉）；而在 CSS 解析完畢后，需要將解析的結(jié)果與 DOM Tree 的內(nèi)容一起進(jìn)行分析建立一棵 Render Tree，最終用來進(jìn)行繪圖。Render Tree 中的元素（WebKit 中稱為「renderers」，Firefox 下為「frames」）與 DOM 元素相對(duì)應(yīng)，但非一一對(duì)應(yīng)：一個(gè) DOM 元素可能會(huì)對(duì)應(yīng)多個(gè) renderer，如文本折行后，不同的「行」會(huì)成為 render tree 種不同的 renderer。也有的 DOM 元素被 Render Tree 完全無視，比如 display:none 的元素。
• 在建立 Render Tree 時(shí)（WebKit 中的「Attachment」過程），瀏覽器就要為每個(gè) DOM Tree 中的元素根據(jù) CSS 的解析結(jié)果（Style Rules）來確定生成怎樣的 renderer。對(duì)于每個(gè) DOM 元素，必須在所有 Style Rules 中找到符合的 selector 并將對(duì)應(yīng)的規(guī)則進(jìn)行合并。選擇器的「解析」實(shí)際是在這里執(zhí)行的，在遍歷 DOM Tree 時(shí)，從 Style Rules 中去尋找對(duì)應(yīng)的 selector。
• 因?yàn)樗袠邮揭?guī)則可能數(shù)量很大，而且絕大多數(shù)不會(huì)匹配到當(dāng)前的 DOM 元素（因?yàn)閿?shù)量很大所以一般會(huì)建立規(guī)則索引樹），所以有一個(gè)快速的方法來判斷「這個(gè) selector 不匹配當(dāng)前元素」就是極其重要的。
• 如果正向解析，例如「div div p em」，我們首先就要檢查當(dāng)前元素到 html 的整條路徑，找到最上層的 div，再往下找，如果遇到不匹配就必須回到最上層那個(gè) div，往下再去匹配選擇器中的第一個(gè) div，回溯若干次才能確定匹配與否，效率很低。
• 逆向匹配則不同，如果當(dāng)前的 DOM 元素是 div，而不是 selector 最后的 em，那只要一步就能排除。只有在匹配時(shí)，才會(huì)不斷向上找父節(jié)點(diǎn)進(jìn)行驗(yàn)證。
• 但因?yàn)槠ヅ涞那闆r遠(yuǎn)遠(yuǎn)低于不匹配的情況，所以逆向匹配帶來的優(yōu)勢(shì)是巨大的。同時(shí)我們也能夠看出，在選擇器結(jié)尾加上「*」就大大降低了這種優(yōu)勢(shì)，這也就是很多優(yōu)化原則提到的盡量避免在選擇器末尾添加通配符的原因。

文檔說明

此文檔的所有資源都是來源網(wǎng)絡(luò)僅在此做了分類整理備忘持續(xù)更新,所有精華之處并非原創(chuàng)，所有原創(chuàng)之處并不優(yōu)秀。

參考鏈接

• js中的window.onload和jquery中的load區(qū)別的講解
• CSS阻塞與JS阻塞
• script之defer&async
• 使用Chrome DevTools的Timeline和Profiles提高Web應(yīng)用程序的性能
• Sizzle引擎
• markdown

轉(zhuǎn)載于:https://www.cnblogs.com/advence-liz/p/6101551.html

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的关于web性能一些特性汇总的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。