摘要:關(guān)于網(wǎng)頁性能網(wǎng)頁性能管理是一個(gè)很大的話題,最近在復(fù)習(xí)相關(guān)的知識(shí),小結(jié)一下。這兩個(gè)規(guī)則的實(shí)質(zhì)都是提高頁面的性能,避免發(fā)生不必要的重新渲染。頁面性能優(yōu)化重排和重繪會(huì)不斷觸發(fā),這是不可避免的。但是,它們非常耗費(fèi)資源,是導(dǎo)致網(wǎng)頁性能低下的根本原因。
關(guān)于網(wǎng)頁性能
頁面加載順序網(wǎng)頁性能管理是一個(gè)很大的話題,最近在復(fù)習(xí)相關(guān)的知識(shí),小結(jié)一下。
網(wǎng)頁生成的過程大致如下:
HTML代碼轉(zhuǎn)化成DOM
CSS代碼轉(zhuǎn)化成CSSOM(CSS Object Model)
結(jié)合DOM和CSSOM,生成一棵渲染樹(包含每個(gè)節(jié)點(diǎn)的視覺信息)
生成布局(layout),即將所有渲染樹的所有節(jié)點(diǎn)進(jìn)行平面合成
將布局繪制(paint)在屏幕上
CSS加載、JS加載是否阻塞DOM樹的解析和渲染由上面的過程我們可以看出,在渲染之前,CSSOM 和 DOM 已經(jīng)生成。
實(shí)際上,css的加載不會(huì)阻塞DOM樹解析,但是會(huì)阻塞DOM樹渲染。要在樣式加載好了之后,才開始渲染頁面。這是合理的。
而JS執(zhí)行會(huì)阻塞DOM樹的解析和渲染。當(dāng)引用了JS的時(shí)候,瀏覽器發(fā)送1個(gè)JS request就會(huì)一直等待該request的返回。因?yàn)闉g覽器需要1個(gè)穩(wěn)定的DOM樹結(jié)構(gòu),而JS中很有可能有代碼直接改變了DOM樹結(jié)構(gòu),比如使用 document.write 或 appendChild,甚至是直接使用的location.href進(jìn)行跳轉(zhuǎn),瀏覽器為了防止出現(xiàn)JS修改DOM樹,需要重新構(gòu)建DOM樹的情況,所以,JS執(zhí)行會(huì)阻塞DOM樹的解析和渲染。
這兩個(gè)規(guī)則的實(shí)質(zhì)都是提高頁面的性能,避免發(fā)生不必要的重新渲染。
頁面性能優(yōu)化以下三種情況,會(huì)導(dǎo)致網(wǎng)頁重新渲染。重排和重繪會(huì)不斷觸發(fā),這是不可避免的。但是,它們非常耗費(fèi)資源,是導(dǎo)致網(wǎng)頁性能低下的根本原因。
修改DOM
修改樣式表
用戶事件(比如鼠標(biāo)懸停、頁面滾動(dòng)、輸入框鍵入文字、改變窗口大小等等)
有一些技巧,可以降低瀏覽器重新渲染的頻率和成本。重新渲染,就需要重新生成布局和重新繪制。前者叫做"重排"(reflow),后者叫做"重繪"(repaint)需要注意的是,"重繪"不一定需要"重排",比如改變某個(gè)網(wǎng)頁元素的顏色,就只會(huì)觸發(fā)"重繪",不會(huì)觸發(fā)"重排",因?yàn)椴季譀]有改變。但是,"重排"必然導(dǎo)致"重繪",比如改變一個(gè)網(wǎng)頁元素的位置,就會(huì)同時(shí)觸發(fā)"重排"和"重繪",因?yàn)椴季指淖兞?/p>
DOM 的多個(gè)讀操作(或多個(gè)寫操作),應(yīng)該放在一起。不要兩個(gè)讀操作之間,加入一個(gè)寫操作。
不要一條條地改變樣式,而要通過改變class,或者csstext屬性,一次性地改變樣式。
先將元素設(shè)為display: none(需要1次重排和重繪),然后對(duì)這個(gè)節(jié)點(diǎn)進(jìn)行100次操作,最后再恢復(fù)顯示(需要1次重排和重繪)。這樣一來,你就用兩次重新渲染,取代了可能高達(dá)100次的重新渲染。
position屬性為absolute或fixed的元素,重排的開銷會(huì)比較小,因?yàn)椴挥每紤]它對(duì)其他元素的影響。
只在必要的時(shí)候,才將元素的display屬性為可見,因?yàn)椴豢梢姷脑夭挥绊懼嘏藕椭乩L。另外,visibility : hidden的元素只對(duì)重繪有影響,不影響重排.
獲取某些屬性瀏覽器引擎可能會(huì)針對(duì)重排做了優(yōu)化。比如Opera,它會(huì)等到有足夠數(shù)量的變化發(fā)生,或者等到一定的時(shí)間,或者等一個(gè)線程結(jié)束,再一起處理,這樣就只發(fā)生一次重排。但除了渲染樹的直接變化,當(dāng)獲取一些屬性時(shí),瀏覽器為取得正確的值也會(huì)觸發(fā)重排。這樣就使得瀏覽器的優(yōu)化失效了。這些屬性包括:offsetTop、offsetLeft、offsetWidth、offsetHeight、scrollTop、scrollLeft、scrollWidth、scrollHeight、clientTop、clientLeft、clientWidth、clientHeight、getComputedStyle() (currentStyle in IE)。所以,在多次使用這些值時(shí)應(yīng)進(jìn)行緩存。
參看文獻(xiàn)
網(wǎng)頁性能管理詳解
瀏覽器加載和渲染html的順序
重繪(repaints) 重排(reflows)
css加載會(huì)阻塞DOM樹的解析渲染嗎?
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://specialneedsforspecialkids.com/yun/84182.html
摘要:放在中減少引起和接下來我們?cè)賮碛懻撘幌聢D片與雪碧圖或精靈,在網(wǎng)頁中我們會(huì)用到很多圖標(biāo),如果每一個(gè)圖標(biāo)是單獨(dú)的一張圖片,那網(wǎng)頁加載的時(shí)候,就會(huì)有多個(gè)請(qǐng)求去請(qǐng)求圖片,顯而易見會(huì)影響網(wǎng)頁性能,所以要采取方法對(duì)網(wǎng)頁中圖標(biāo)使用進(jìn)行優(yōu)化處理。 ???????我們都知道性能對(duì)于一個(gè)網(wǎng)站來說相當(dāng)重要,以至于很多公司都會(huì)專門招聘人員優(yōu)化網(wǎng)站性能,網(wǎng)上關(guān)于探討網(wǎng)站性能優(yōu)化的文章也非常多。性能是什么呢?簡單...
摘要:放在中減少引起和接下來我們?cè)賮碛懻撘幌聢D片與雪碧圖或精靈,在網(wǎng)頁中我們會(huì)用到很多圖標(biāo),如果每一個(gè)圖標(biāo)是單獨(dú)的一張圖片,那網(wǎng)頁加載的時(shí)候,就會(huì)有多個(gè)請(qǐng)求去請(qǐng)求圖片,顯而易見會(huì)影響網(wǎng)頁性能,所以要采取方法對(duì)網(wǎng)頁中圖標(biāo)使用進(jìn)行優(yōu)化處理。 ???????我們都知道性能對(duì)于一個(gè)網(wǎng)站來說相當(dāng)重要,以至于很多公司都會(huì)專門招聘人員優(yōu)化網(wǎng)站性能,網(wǎng)上關(guān)于探討網(wǎng)站性能優(yōu)化的文章也非常多。性能是什么呢?簡單...
摘要:端優(yōu)談?wù)勱P(guān)于前端的緩存的問題我們都知道對(duì)頁面進(jìn)行緩存能夠有利于減少請(qǐng)求發(fā)送,從而達(dá)到對(duì)頁面的優(yōu)化。而作為一名有追求的前端,勢必要力所能及地優(yōu)化我們前端頁面的性能。這種方式主要解決了淺談前端中的過早優(yōu)化問題過早優(yōu)化是萬惡之源。 優(yōu)化向:單頁應(yīng)用多路由預(yù)渲染指南 Ajax 技術(shù)的出現(xiàn),讓我們的 Web 應(yīng)用能夠在不刷新的狀態(tài)下顯示不同頁面的內(nèi)容,這就是單頁應(yīng)用。在一個(gè)單頁應(yīng)用中,往往只有一...
摘要:如何理解是由性能小組提出的用于精確計(jì)算網(wǎng)頁性能數(shù)據(jù)的特性,它返一個(gè)對(duì)象,支持以上的所有瀏覽器,這里給出對(duì)象的原型返回對(duì)象,包含延遲相關(guān)的性能信息。返回對(duì)象,該對(duì)象表示在當(dāng)前給定瀏覽上下文中網(wǎng)頁導(dǎo)航的類型,,,以及次數(shù)。 如何理解 window.performance window.performance 是由 W3C 性能小組提出的用于精確計(jì)算網(wǎng)頁性能數(shù)據(jù)的特性,它返一個(gè) Perfor...
閱讀 3677·2021-09-22 15:34
閱讀 1186·2019-08-29 17:25
閱讀 3399·2019-08-29 11:18
閱讀 1371·2019-08-26 17:15
閱讀 1740·2019-08-23 17:19
閱讀 1228·2019-08-23 16:15
閱讀 718·2019-08-23 16:02
閱讀 1335·2019-08-23 15:19