摘要:前言瀏覽器的內(nèi)核是指支持瀏覽器運(yùn)行的最核心的程序,分為兩個(gè)部分的,一是渲染引擎,另一個(gè)是引擎。渲染引擎在不同的瀏覽器中也不是都相同的。接下來(lái)就是瀏覽器的渲染過(guò)程。布局完成后,瀏覽器會(huì)立即發(fā)出和事件,將渲染樹轉(zhuǎn)換成屏幕上的像素。
前言
瀏覽器的內(nèi)核是指支持瀏覽器運(yùn)行的最核心的程序,分為兩個(gè)部分的,一是渲染引擎,另一個(gè)是JS引擎。渲染引擎在不同的瀏覽器中也不是都相同的。目前市面上常見(jiàn)的瀏覽器內(nèi)核可以分為這四種:Trident(IE)、Gecko(火狐)、Blink(Chrome、Opera)、Webkit(Safari)。這里面大家最耳熟能詳?shù)目赡芫褪?Webkit 內(nèi)核了,Webkit 內(nèi)核是當(dāng)下瀏覽器世界真正的霸主。本文我們就以 Webkit 為例,對(duì)現(xiàn)代瀏覽器的渲染過(guò)程進(jìn)行一個(gè)深度的剖析。
想閱讀更多優(yōu)質(zhì)文章請(qǐng)猛戳GitHub博客,一年五十篇優(yōu)質(zhì)文章等著你!
頁(yè)面加載過(guò)程在介紹瀏覽器渲染過(guò)程之前,我們簡(jiǎn)明扼要介紹下頁(yè)面的加載過(guò)程,有助于更好理解后續(xù)渲染過(guò)程。
要點(diǎn)如下:
瀏覽器根據(jù) DNS 服務(wù)器得到域名的 IP 地址
向這個(gè) IP 的機(jī)器發(fā)送 HTTP 請(qǐng)求
服務(wù)器收到、處理并返回 HTTP 請(qǐng)求
瀏覽器得到返回內(nèi)容
例如在瀏覽器輸入https://juejin.im/timeline,然后經(jīng)過(guò) DNS 解析,juejin.im對(duì)應(yīng)的 IP 是36.248.217.149(不同時(shí)間、地點(diǎn)對(duì)應(yīng)的 IP 可能會(huì)不同)。然后瀏覽器向該 IP 發(fā)送 HTTP 請(qǐng)求。
服務(wù)端接收到 HTTP 請(qǐng)求,然后經(jīng)過(guò)計(jì)算(向不同的用戶推送不同的內(nèi)容),返回 HTTP 請(qǐng)求,返回的內(nèi)容如下:
其實(shí)就是一堆 HMTL 格式的字符串,因?yàn)橹挥?HTML 格式瀏覽器才能正確解析,這是 W3C 標(biāo)準(zhǔn)的要求。接下來(lái)就是瀏覽器的渲染過(guò)程。
瀏覽器渲染過(guò)程瀏覽器渲染過(guò)程大體分為如下三部分:
1)瀏覽器會(huì)解析三個(gè)東西:一是HTML/SVG/XHTML,HTML字符串描述了一個(gè)頁(yè)面的結(jié)構(gòu),瀏覽器會(huì)把HTML結(jié)構(gòu)字符串解析轉(zhuǎn)換DOM樹形結(jié)構(gòu)。
二是CSS,解析CSS會(huì)產(chǎn)生CSS規(guī)則樹,它和DOM結(jié)構(gòu)比較像。
三是Javascript腳本,等到Javascript 腳本文件加載后, 通過(guò) DOM API 和 CSSOM API 來(lái)操作 DOM Tree 和 CSS Rule Tree。
2)解析完成后,瀏覽器引擎會(huì)通過(guò)DOM Tree 和 CSS Rule Tree 來(lái)構(gòu)造 Rendering Tree。Rendering Tree 渲染樹并不等同于DOM樹,渲染樹只會(huì)包括需要顯示的節(jié)點(diǎn)和這些節(jié)點(diǎn)的樣式信息。
CSS 的 Rule Tree主要是為了完成匹配并把CSS Rule附加上Rendering Tree上的每個(gè)Element(也就是每個(gè)Frame)。
然后,計(jì)算每個(gè)Frame 的位置,這又叫l(wèi)ayout和reflow過(guò)程。
3)最后通過(guò)調(diào)用操作系統(tǒng)Native GUI的API繪制。接下來(lái)我們針對(duì)這其中所經(jīng)歷的重要步驟詳細(xì)闡述構(gòu)建DOM
瀏覽器會(huì)遵守一套步驟將HTML 文件轉(zhuǎn)換為 DOM 樹。宏觀上,可以分為幾個(gè)步驟:
瀏覽器從磁盤或網(wǎng)絡(luò)讀取HTML的原始字節(jié),并根據(jù)文件的指定編碼(例如 UTF-8)將它們轉(zhuǎn)換成字符串。
在網(wǎng)絡(luò)中傳輸?shù)膬?nèi)容其實(shí)都是 0 和 1 這些字節(jié)數(shù)據(jù)。當(dāng)瀏覽器接收到這些字節(jié)數(shù)據(jù)以后,它會(huì)將這些字節(jié)數(shù)據(jù)轉(zhuǎn)換為字符串,也就是我們寫的代碼。
將字符串轉(zhuǎn)換成Token,例如:、等。Token中會(huì)標(biāo)識(shí)出當(dāng)前Token是“開始標(biāo)簽”或是“結(jié)束標(biāo)簽”亦或是“文本”等信息。
這時(shí)候你一定會(huì)有疑問(wèn),節(jié)點(diǎn)與節(jié)點(diǎn)之間的關(guān)系如何維護(hù)?
事實(shí)上,這就是Token要標(biāo)識(shí)“起始標(biāo)簽”和“結(jié)束標(biāo)簽”等標(biāo)識(shí)的作用。例如“title”Token的起始標(biāo)簽和結(jié)束標(biāo)簽之間的節(jié)點(diǎn)肯定是屬于“head”的子節(jié)點(diǎn)。
上圖給出了節(jié)點(diǎn)之間的關(guān)系,例如:“Hello”Token位于“title”開始標(biāo)簽與“title”結(jié)束標(biāo)簽之間,表明“Hello”Token是“title”Token的子節(jié)點(diǎn)。同理“title”Token是“head”Token的子節(jié)點(diǎn)。
生成節(jié)點(diǎn)對(duì)象并構(gòu)建DOM
事實(shí)上,構(gòu)建DOM的過(guò)程中,不是等所有Token都轉(zhuǎn)換完成后再去生成節(jié)點(diǎn)對(duì)象,而是一邊生成Token一邊消耗Token來(lái)生成節(jié)點(diǎn)對(duì)象。換句話說(shuō),每個(gè)Token被生成后,會(huì)立刻消耗這個(gè)Token創(chuàng)建出節(jié)點(diǎn)對(duì)象。注意:帶有結(jié)束標(biāo)簽標(biāo)識(shí)的Token不會(huì)創(chuàng)建節(jié)點(diǎn)對(duì)象。
接下來(lái)我們舉個(gè)例子,假設(shè)有段HTML文本:
Web page parsing Web page parsing
This is an example Web page.
上面這段HTML會(huì)解析成這樣:
構(gòu)建CSSOMDOM會(huì)捕獲頁(yè)面的內(nèi)容,但瀏覽器還需要知道頁(yè)面如何展示,所以需要構(gòu)建CSSOM。
構(gòu)建CSSOM的過(guò)程與構(gòu)建DOM的過(guò)程非常相似,當(dāng)瀏覽器接收到一段CSS,瀏覽器首先要做的是識(shí)別出Token,然后構(gòu)建節(jié)點(diǎn)并生成CSSOM。
在這一過(guò)程中,瀏覽器會(huì)確定下每一個(gè)節(jié)點(diǎn)的樣式到底是什么,并且這一過(guò)程其實(shí)是很消耗資源的。因?yàn)闃邮侥憧梢宰孕性O(shè)置給某個(gè)節(jié)點(diǎn),也可以通過(guò)繼承獲得。在這一過(guò)程中,瀏覽器得遞歸 CSSOM 樹,然后確定具體的元素到底是什么樣式。
注意:CSS匹配HTML元素是一個(gè)相當(dāng)復(fù)雜和有性能問(wèn)題的事情。所以,DOM樹要小,CSS盡量用id和class,千萬(wàn)不要過(guò)渡層疊下去。
構(gòu)建渲染樹當(dāng)我們生成 DOM 樹和 CSSOM 樹以后,就需要將這兩棵樹組合為渲染樹。
在這一過(guò)程中,不是簡(jiǎn)單的將兩者合并就行了。渲染樹只會(huì)包括需要顯示的節(jié)點(diǎn)和這些節(jié)點(diǎn)的樣式信息,如果某個(gè)節(jié)點(diǎn)是 display: none 的,那么就不會(huì)在渲染樹中顯示。
我們或許有個(gè)疑惑:瀏覽器如果渲染過(guò)程中遇到JS文件怎么處理?
渲染過(guò)程中,如果遇到就停止渲染,執(zhí)行 JS 代碼。因?yàn)闉g覽器有GUI渲染線程與JS引擎線程,為了防止渲染出現(xiàn)不可預(yù)期的結(jié)果,這兩個(gè)線程是互斥的關(guān)系。JavaScript的加載、解析與執(zhí)行會(huì)阻塞DOM的構(gòu)建,也就是說(shuō),在構(gòu)建DOM時(shí),HTML解析器若遇到了JavaScript,那么它會(huì)暫停構(gòu)建DOM,將控制權(quán)移交給JavaScript引擎,等JavaScript引擎運(yùn)行完畢,瀏覽器再?gòu)闹袛嗟牡胤交謴?fù)DOM構(gòu)建。
也就是說(shuō),如果你想首屏渲染的越快,就越不應(yīng)該在首屏就加載 JS 文件,這也是都建議將 script 標(biāo)簽放在 body 標(biāo)簽底部的原因。當(dāng)然在當(dāng)下,并不是說(shuō) script 標(biāo)簽必須放在底部,因?yàn)槟憧梢越o script 標(biāo)簽添加 defer 或者 async 屬性(下文會(huì)介紹這兩者的區(qū)別)。
JS文件不只是阻塞DOM的構(gòu)建,它會(huì)導(dǎo)致CSSOM也阻塞DOM的構(gòu)建。
原本DOM和CSSOM的構(gòu)建是互不影響,井水不犯河水,但是一旦引入了JavaScript,CSSOM也開始阻塞DOM的構(gòu)建,只有CSSOM構(gòu)建完畢后,DOM再恢復(fù)DOM構(gòu)建。
這是什么情況?
這是因?yàn)镴avaScript不只是可以改DOM,它還可以更改樣式,也就是它可以更改CSSOM。因?yàn)椴煌暾腃SSOM是無(wú)法使用的,如果JavaScript想訪問(wèn)CSSOM并更改它,那么在執(zhí)行JavaScript時(shí),必須要能拿到完整的CSSOM。所以就導(dǎo)致了一個(gè)現(xiàn)象,如果瀏覽器尚未完成CSSOM的下載和構(gòu)建,而我們卻想在此時(shí)運(yùn)行腳本,那么瀏覽器將延遲腳本執(zhí)行和DOM構(gòu)建,直至其完成CSSOM的下載和構(gòu)建。也就是說(shuō),在這種情況下,瀏覽器會(huì)先下載和構(gòu)建CSSOM,然后再執(zhí)行JavaScript,最后在繼續(xù)構(gòu)建DOM。
布局與繪制當(dāng)瀏覽器生成渲染樹以后,就會(huì)根據(jù)渲染樹來(lái)進(jìn)行布局(也可以叫做回流)。這一階段瀏覽器要做的事情是要弄清楚各個(gè)節(jié)點(diǎn)在頁(yè)面中的確切位置和大小。通常這一行為也被稱為“自動(dòng)重排”。
布局流程的輸出是一個(gè)“盒模型”,它會(huì)精確地捕獲每個(gè)元素在視口內(nèi)的確切位置和尺寸,所有相對(duì)測(cè)量值都將轉(zhuǎn)換為屏幕上的絕對(duì)像素。
布局完成后,瀏覽器會(huì)立即發(fā)出“Paint Setup”和“Paint”事件,將渲染樹轉(zhuǎn)換成屏幕上的像素。
以上我們?cè)敿?xì)介紹了瀏覽器工作流程中的重要步驟,接下來(lái)我們討論幾個(gè)相關(guān)的問(wèn)題:幾點(diǎn)補(bǔ)充說(shuō)明 1.async和defer的作用是什么?有什么區(qū)別?
接下來(lái)我們對(duì)比下 defer 和 async 屬性的區(qū)別:
其中藍(lán)色線代表JavaScript加載;紅色線代表JavaScript執(zhí)行;綠色線代表 HTML 解析。
1)情況1沒(méi)有 defer 或 async,瀏覽器會(huì)立即加載并執(zhí)行指定的腳本,也就是說(shuō)不等待后續(xù)載入的文檔元素,讀到就加載并執(zhí)行。
2)情況2 (異步下載)async 屬性表示異步執(zhí)行引入的 JavaScript,與 defer 的區(qū)別在于,如果已經(jīng)加載好,就會(huì)開始執(zhí)行——無(wú)論此刻是 HTML 解析階段還是 DOMContentLoaded 觸發(fā)之后。需要注意的是,這種方式加載的 JavaScript 依然會(huì)阻塞 load 事件。換句話說(shuō),async-script 可能在 DOMContentLoaded 觸發(fā)之前或之后執(zhí)行,但一定在 load 觸發(fā)之前執(zhí)行。
3)情況3 (延遲執(zhí)行)defer 屬性表示延遲執(zhí)行引入的 JavaScript,即這段 JavaScript 加載時(shí) HTML 并未停止解析,這兩個(gè)過(guò)程是并行的。整個(gè) document 解析完畢且 defer-script 也加載完成之后(這兩件事情的順序無(wú)關(guān)),會(huì)執(zhí)行所有由 defer-script 加載的 JavaScript 代碼,然后觸發(fā) DOMContentLoaded 事件。
defer 與相比普通 script,有兩點(diǎn)區(qū)別:**載入 JavaScript 文件時(shí)不阻塞 HTML 的解析,執(zhí)行階段被放到 HTML 標(biāo)簽解析完成之后。
在加載多個(gè)JS腳本的時(shí)候,async是無(wú)順序的加載,而defer是有順序的加載。**
把 DOM 和 JavaScript 各自想象成一個(gè)島嶼,它們之間用收費(fèi)橋梁連接。——《高性能 JavaScript》
JS 是很快的,在 JS 中修改 DOM 對(duì)象也是很快的。在JS的世界里,一切是簡(jiǎn)單的、迅速的。但 DOM 操作并非 JS 一個(gè)人的獨(dú)舞,而是兩個(gè)模塊之間的協(xié)作。
因?yàn)?DOM 是屬于渲染引擎中的東西,而 JS 又是 JS 引擎中的東西。當(dāng)我們用 JS 去操作 DOM 時(shí),本質(zhì)上是 JS 引擎和渲染引擎之間進(jìn)行了“跨界交流”。這個(gè)“跨界交流”的實(shí)現(xiàn)并不簡(jiǎn)單,它依賴了橋接接口作為“橋梁”(如下圖)。
過(guò)“橋”要收費(fèi)——這個(gè)開銷本身就是不可忽略的。我們每操作一次 DOM(不管是為了修改還是僅僅為了訪問(wèn)其值),都要過(guò)一次“橋”。過(guò)“橋”的次數(shù)一多,就會(huì)產(chǎn)生比較明顯的性能問(wèn)題。因此“減少 DOM 操作”的建議,并非空穴來(lái)風(fēng)。
3.你真的了解回流和重繪嗎渲染的流程基本上是這樣(如下圖黃色的四個(gè)步驟):1.計(jì)算CSS樣式 2.構(gòu)建Render Tree 3.Layout – 定位坐標(biāo)和大小 4.正式開畫
注意:上圖流程中有很多連接線,這表示了Javascript動(dòng)態(tài)修改了DOM屬性或是CSS屬性會(huì)導(dǎo)致重新Layout,但有些改變不會(huì)重新Layout,就是上圖中那些指到天上的箭頭,比如修改后的CSS rule沒(méi)有被匹配到元素。
這里重要要說(shuō)兩個(gè)概念,一個(gè)是Reflow,另一個(gè)是Repaint
重繪:當(dāng)我們對(duì) DOM 的修改導(dǎo)致了樣式的變化、卻并未影響其幾何屬性(比如修改了顏色或背景色)時(shí),瀏覽器不需重新計(jì)算元素的幾何屬性、直接為該元素繪制新的樣式(跳過(guò)了上圖所示的回流環(huán)節(jié))。
回流:當(dāng)我們對(duì) DOM 的修改引發(fā)了 DOM 幾何尺寸的變化(比如修改元素的寬、高或隱藏元素等)時(shí),瀏覽器需要重新計(jì)算元素的幾何屬性(其他元素的幾何屬性和位置也會(huì)因此受到影響),然后再將計(jì)算的結(jié)果繪制出來(lái)。這個(gè)過(guò)程就是回流(也叫重排)
我們知道,當(dāng)網(wǎng)頁(yè)生成的時(shí)候,至少會(huì)渲染一次。在用戶訪問(wèn)的過(guò)程中,還會(huì)不斷重新渲染。重新渲染會(huì)重復(fù)回流+重繪或者只有重繪。
回流必定會(huì)發(fā)生重繪,重繪不一定會(huì)引發(fā)回流。重繪和回流會(huì)在我們?cè)O(shè)置節(jié)點(diǎn)樣式時(shí)頻繁出現(xiàn),同時(shí)也會(huì)很大程度上影響性能。回流所需的成本比重繪高的多,改變父節(jié)點(diǎn)里的子節(jié)點(diǎn)很可能會(huì)導(dǎo)致父節(jié)點(diǎn)的一系列回流。
任何會(huì)改變?cè)貛缀涡畔?元素的位置和尺寸大小)的操作,都會(huì)觸發(fā)回流,
添加或者刪除可見(jiàn)的DOM元素;
元素尺寸改變——邊距、填充、邊框、寬度和高度
內(nèi)容變化,比如用戶在input框中輸入文字
瀏覽器窗口尺寸改變——resize事件發(fā)生時(shí)
計(jì)算 offsetWidth 和 offsetHeight 屬性
設(shè)置 style 屬性的值
2)常見(jiàn)引起重繪屬性和方法 3)如何減少回流、重繪使用 transform 替代 top
使用 visibility 替換 display: none ,因?yàn)榍罢咧粫?huì)引起重繪,后者會(huì)引發(fā)回流(改變了布局)
不要把節(jié)點(diǎn)的屬性值放在一個(gè)循環(huán)里當(dāng)成循環(huán)里的變量。
for(let i = 0; i < 1000; i++) { // 獲取 offsetTop 會(huì)導(dǎo)致回流,因?yàn)樾枰カ@取正確的值 console.log(document.querySelector(".test").style.offsetTop) }
不要使用 table 布局,可能很小的一個(gè)小改動(dòng)會(huì)造成整個(gè) table 的重新布局
動(dòng)畫實(shí)現(xiàn)的速度的選擇,動(dòng)畫速度越快,回流次數(shù)越多,也可以選擇使用 requestAnimationFrame
CSS 選擇符從右往左匹配查找,避免節(jié)點(diǎn)層級(jí)過(guò)多
將頻繁重繪或者回流的節(jié)點(diǎn)設(shè)置為圖層,圖層能夠阻止該節(jié)點(diǎn)的渲染行為影響別的節(jié)點(diǎn)。比如對(duì)于 video 標(biāo)簽來(lái)說(shuō),瀏覽器會(huì)自動(dòng)將該節(jié)點(diǎn)變?yōu)閳D層。
性能優(yōu)化策略基于上面介紹的瀏覽器渲染原理,DOM 和 CSSOM 結(jié)構(gòu)構(gòu)建順序,初始化可以對(duì)頁(yè)面渲染做些優(yōu)化,提升頁(yè)面性能。
JS優(yōu)化: 標(biāo)簽加上 defer屬性 和 async屬性 用于在不阻塞頁(yè)面文檔解析的前提下,控制腳本的下載和執(zhí)行。
defer屬性: 用于開啟新的線程下載腳本文件,并使腳本在文檔解析完成后執(zhí)行。
async屬性: HTML5新增屬性,用于異步下載腳本文件,下載完畢立即解釋執(zhí)行代碼。
CSS優(yōu)化: 標(biāo)簽的 rel屬性 中的屬性值設(shè)置為 preload 能夠讓你在你的HTML頁(yè)面中可以指明哪些資源是在頁(yè)面加載完成后即刻需要的,最優(yōu)的配置加載順序,提高渲染性能
總結(jié)綜上所述,我們得出這樣的結(jié)論:
瀏覽器工作流程:構(gòu)建DOM -> 構(gòu)建CSSOM -> 構(gòu)建渲染樹 -> 布局 -> 繪制。
CSSOM會(huì)阻塞渲染,只有當(dāng)CSSOM構(gòu)建完畢后才會(huì)進(jìn)入下一個(gè)階段構(gòu)建渲染樹。
通常情況下DOM和CSSOM是并行構(gòu)建的,但是當(dāng)瀏覽器遇到一個(gè)不帶defer或async屬性的script標(biāo)簽時(shí),DOM構(gòu)建將暫停,如果此時(shí)又恰巧瀏覽器尚未完成CSSOM的下載和構(gòu)建,由于JavaScript可以修改CSSOM,所以需要等CSSOM構(gòu)建完畢后再執(zhí)行JS,最后才重新DOM構(gòu)建。
給大家推薦一個(gè)好用的BUG監(jiān)控工具Fundebug,歡迎免費(fèi)試用!
歡迎關(guān)注公眾號(hào):前端工匠,你的成長(zhǎng)我們一起見(jiàn)證!
async 和 defer 的區(qū)別 | SegmentFault
瀏覽器的渲染原理簡(jiǎn)介
前端面試之道
關(guān)鍵渲染路徑
前端性能優(yōu)化原理與實(shí)踐
由入門到專家:前端全鏈路開發(fā)實(shí)踐手冊(cè)
Web 前端面試指南與高頻考題解析
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://specialneedsforspecialkids.com/yun/77512.html
摘要:前言瀏覽器的內(nèi)核是指支持瀏覽器運(yùn)行的最核心的程序,分為兩個(gè)部分的,一是渲染引擎,另一個(gè)是引擎。渲染引擎在不同的瀏覽器中也不是都相同的。接下來(lái)就是瀏覽器的渲染過(guò)程。布局完成后,瀏覽器會(huì)立即發(fā)出和事件,將渲染樹轉(zhuǎn)換成屏幕上的像素。 前言 瀏覽器的內(nèi)核是指支持瀏覽器運(yùn)行的最核心的程序,分為兩個(gè)部分的,一是渲染引擎,另一個(gè)是JS引擎。渲染引擎在不同的瀏覽器中也不是都相同的。目前市面上常見(jiàn)的瀏覽...
摘要:不同的框架對(duì)這三個(gè)屬性的命名會(huì)有點(diǎn)差別,但表達(dá)的意思是一致的。它們分別是標(biāo)簽名屬性和子元素對(duì)象。我們先來(lái)看下頁(yè)面的更新一般會(huì)經(jīng)過(guò)幾個(gè)階段。元素有可能是數(shù)組的形式,需要將數(shù)組解構(gòu)一層。 歡迎關(guān)注我的公眾號(hào)睿Talk,獲取我最新的文章:showImg(https://segmentfault.com/img/bVbmYjo); 一、前言 目前最流行的兩大前端框架,React和Vue,都不約...
摘要:歡迎來(lái)我的個(gè)人站點(diǎn)性能優(yōu)化其他優(yōu)化瀏覽器關(guān)鍵渲染路徑開啟性能優(yōu)化之旅高性能滾動(dòng)及頁(yè)面渲染優(yōu)化理論寫法對(duì)壓縮率的影響唯快不破應(yīng)用的個(gè)優(yōu)化步驟進(jìn)階鵝廠大神用直出實(shí)現(xiàn)網(wǎng)頁(yè)瞬開緩存網(wǎng)頁(yè)性能管理詳解寫給后端程序員的緩存原理介紹年底補(bǔ)課緩存機(jī)制優(yōu)化動(dòng) 歡迎來(lái)我的個(gè)人站點(diǎn) 性能優(yōu)化 其他 優(yōu)化瀏覽器關(guān)鍵渲染路徑 - 開啟性能優(yōu)化之旅 高性能滾動(dòng) scroll 及頁(yè)面渲染優(yōu)化 理論 | HTML寫法...
摘要:歡迎來(lái)我的個(gè)人站點(diǎn)性能優(yōu)化其他優(yōu)化瀏覽器關(guān)鍵渲染路徑開啟性能優(yōu)化之旅高性能滾動(dòng)及頁(yè)面渲染優(yōu)化理論寫法對(duì)壓縮率的影響唯快不破應(yīng)用的個(gè)優(yōu)化步驟進(jìn)階鵝廠大神用直出實(shí)現(xiàn)網(wǎng)頁(yè)瞬開緩存網(wǎng)頁(yè)性能管理詳解寫給后端程序員的緩存原理介紹年底補(bǔ)課緩存機(jī)制優(yōu)化動(dòng) 歡迎來(lái)我的個(gè)人站點(diǎn) 性能優(yōu)化 其他 優(yōu)化瀏覽器關(guān)鍵渲染路徑 - 開啟性能優(yōu)化之旅 高性能滾動(dòng) scroll 及頁(yè)面渲染優(yōu)化 理論 | HTML寫法...
摘要:歡迎來(lái)我的個(gè)人站點(diǎn)性能優(yōu)化其他優(yōu)化瀏覽器關(guān)鍵渲染路徑開啟性能優(yōu)化之旅高性能滾動(dòng)及頁(yè)面渲染優(yōu)化理論寫法對(duì)壓縮率的影響唯快不破應(yīng)用的個(gè)優(yōu)化步驟進(jìn)階鵝廠大神用直出實(shí)現(xiàn)網(wǎng)頁(yè)瞬開緩存網(wǎng)頁(yè)性能管理詳解寫給后端程序員的緩存原理介紹年底補(bǔ)課緩存機(jī)制優(yōu)化動(dòng) 歡迎來(lái)我的個(gè)人站點(diǎn) 性能優(yōu)化 其他 優(yōu)化瀏覽器關(guān)鍵渲染路徑 - 開啟性能優(yōu)化之旅 高性能滾動(dòng) scroll 及頁(yè)面渲染優(yōu)化 理論 | HTML寫法...
閱讀 2562·2021-09-02 15:40
閱讀 1565·2019-08-30 15:54
閱讀 1079·2019-08-30 12:48
閱讀 3398·2019-08-29 17:23
閱讀 1046·2019-08-28 18:04
閱讀 3664·2019-08-26 13:54
閱讀 606·2019-08-26 11:40
閱讀 2390·2019-08-26 10:15