摘要:緩存優(yōu)化性能優(yōu)化第一步,便是管理好頁面的緩存,避免重復下載資源。加載時優(yōu)化消滅不必要的下載最好的優(yōu)化,便是根本不下載資源。所以,在網(wǎng)頁中隨意擺放和極有可能造成各種阻塞,必須精心安排。不要高頻率調(diào)用函數(shù),事件連續(xù)觸發(fā)時,只調(diào)用一次函數(shù)。
本文提供一個優(yōu)化網(wǎng)頁性能的大概思路,具體操作網(wǎng)上資料很多。
緩存優(yōu)化性能優(yōu)化第一步,便是管理好頁面的緩存,避免重復下載資源。否則,即增加服務(wù)器壓力,又折磨用戶的錢包。
瀏覽器緩存機制訪問頁面,請求各種資源,瀏覽器檢查本地是否有緩存。
如果有,檢查資源是否過期。沒過期,直接使用緩存。過期了,便向服務(wù)器發(fā)出請求。
發(fā)出的請求中會帶上etag和last-modified首部字段。
服務(wù)器會通過Etag和last-modified來判斷瀏覽器緩存的資源是否已經(jīng)不可用。
如果資源仍然有效,便返回304告知瀏覽器使用緩存。否則返回更新后的資源。
按照這一套邏輯,便可規(guī)劃好網(wǎng)站的緩存。
如果資源提前過期,如何通知瀏覽器更新資源?通常無法做到這一點,因為瀏覽器發(fā)現(xiàn)資源沒過期,根本不會發(fā)出請求。
但是可以通過修改資源的網(wǎng)址來實現(xiàn)。所以需要給資源文件名加上版本號或者隨機標記。例如 style.1234.css。
也就是說,不要讓瀏覽器緩存html文件,否則,過期之前,瀏覽器都不會請求服務(wù)器。
最好的優(yōu)化,便是根本不下載資源。所以要盡量減少比不要的資源。
評估所有依賴是否必要,權(quán)衡利弊。
依賴的下載路徑是否可靠,不可用時候是否會阻礙整個頁面。
產(chǎn)品設(shè)計時候就需要拋棄浪費帶寬的設(shè)計。
壓縮所有可以壓縮的資源 代碼自不用說,都是文本,全部壓縮。 優(yōu)化圖片去掉不必要的圖片
多使用css3來代替圖片
使用壓縮率更高的圖片。特別是gif動圖,一些視頻格式(H.264或WebM)的體積比gif小很多。
用藝術(shù)字字體,不要用圖片
仔細權(quán)衡圖片和文字的關(guān)系。要表達一個意思,可能一圖勝千言。多了一張圖片,反而節(jié)省了大量文字。
使用progressive jpeg。相比隨著數(shù)據(jù)下載從上到下顯示的baseline jpeg,progressive jpeg是由模糊到清晰,用戶體驗好,也不會導致reflow。
圖片分辨率要盡可能小,避免圖片分辨率大于顯示分辨率。
為使用更新瀏覽器的用戶提供更現(xiàn)代的圖片格式。
多種分辨率的位圖供不同頁面大小使用。
要給標簽指明寬高,否則會導致reflow。
使用HTTP/2。比如,精靈圖是由很多小圖片組成的一張大圖片,可以減少http請求。但是卻難以緩存,修改一個小圖片,導致所有小圖片緩存失效。HTTP/2,一個鏈接內(nèi)可以發(fā)起多個請求,便無需使用精靈圖。
優(yōu)化字體@font-face 中unicode-range可以制定字符范圍,用來避免下載不需要的語言的字符。
確保字體都被壓縮過。
用@font-face的display屬性和FontFace對象管理好字體加載時的邏輯。
關(guān)鍵渲染路徑瀏覽器渲染一張網(wǎng)頁通過以下步驟。
處理 HTML 標記并構(gòu)建 DOM 樹。
處理 CSS 標記并構(gòu)建 CSSOM 樹。
將 DOM 與 CSSOM 合并成一個渲染樹。
根據(jù)渲染樹來布局,以計算每個節(jié)點的幾何信息。
將各個節(jié)點繪制到屏幕上。
說人話:瀏覽器先解析HTML,發(fā)現(xiàn)就去請求CSS文件,發(fā)現(xiàn)
js修改元素樣式
瀏覽器重新計算CSSOM樹
如果布局發(fā)生變化,則計算出新的布局
按不同的layer來計算出繪制元素所需的每個像素。
按順序合并不同的layer
優(yōu)化動畫便是優(yōu)化以上步驟使動畫達到60幀。
CSS選擇器要簡單,避免瀏覽器遍歷DOM樹來尋找元素。
js修改的元素要避免牽連過多導致布局發(fā)生變化。
要減少需要重繪的元素。重繪時,同一個layer的元素都會被重繪。重繪也是非常耗費性能的一步。
選擇器越復雜,瀏覽器計算得越久。最糟情況下,瀏覽器需要遍歷整個DOM-tree,計算量等于元素總個數(shù)乘以選擇器個數(shù)。
盡量不要使選擇器太復雜,事先給需要被操作的元素加上類名。
reflow, layout即布局發(fā)生變化。Chrome, Opera, Safari, Internet Explorer中叫l(wèi)ayout. 火狐稱之為Reflow。
reflow, repaint次數(shù)越少越好,牽連的元素越少越好。
reflow總是牽涉整個文檔流。
千萬不能修改元素css后立刻讀取css計算值。因為瀏覽器必須重新計算布局,才能知道所需值。而js中相關(guān)API都是同步的,所以這將導致瀏覽器同步reflow,阻塞js線程。
Paint(重繪)因為動畫一直在運動,所以要避免使用會導致布局發(fā)生變化,和導致必須重新計算元素像素(重繪)的CSS屬性制作動畫。而transform和opacity兩個CSS屬性正是我們所需的。
因為瀏覽器渲染網(wǎng)頁時,會將網(wǎng)頁分層(layer),最后將不同層合并,然后完成渲染。
同一層中,哪怕只有一個小小的元素發(fā)生變化,整個層都會被repaint。
開發(fā)者工具的Paint Profiler界面中觀察到每一層的繪制過程創(chuàng)建新layer
所以,可以考慮將動畫放在多帶帶的layer中。
CSS的will-change和 transform: translateZ(0)可以用來創(chuàng)建新layer;
再搭配transform和opacity,用CSS3制作動畫。根據(jù)我的實驗,可以完全避免reflow和重繪。
但是過多l(xiāng)ayer也消耗內(nèi)存和性能,用開發(fā)者工具中的Performance判斷新layer是否帶來優(yōu)化,否則不要創(chuàng)建新layer。優(yōu)化交互
開發(fā)者工具的layer界面中可以觀察網(wǎng)頁有多少個layer,每個layer包含哪些元素。
網(wǎng)頁時給人用的,所以最惱人的是鼠標或手指操作頁面時,頁面卡卡的。
而響應(yīng)用戶操作的JS都是異步的。如果JS線程太繁忙,遲遲不能進入下一個事件循環(huán),就會導致響應(yīng)用戶操作不及時。
盡量增加線程空閑時間,讓事件循環(huán)可以及時取出回調(diào)函數(shù)。提高響應(yīng)的優(yōu)先級,用戶交互時,停下其他耗時的JS。
但響應(yīng)不必過于及時,在100ms內(nèi)得到反饋,人類都不會察覺到卡頓,可以把一些耗時的工作分解成很多步,利用這個時間差去執(zhí)行它們。
活用requestAnimationFrame方法。
requestAnimationFrame在下一幀開始前調(diào)用函數(shù)。優(yōu)于setInterval的地方是每一幀只會調(diào)用一次,而setInterval則不一定。監(jiān)聽函數(shù)
交互事件的監(jiān)聽函數(shù)的執(zhí)行時間不能太長,否則會阻塞頁面滾動。
監(jiān)聽函數(shù)可能會調(diào)用preventDefault, 導致瀏覽器必須等待監(jiān)聽函數(shù)執(zhí)行完成。
不過新擴展的addEventListener方法第三個參數(shù)可以是一個對象,對象的passive屬性用來事先承諾不會調(diào)用preventDefault方法,瀏覽器則不會等待監(jiān)聽函數(shù)。
不要再交互事件的監(jiān)聽函數(shù)中修改樣式,會導致強制同步reflow,阻塞js執(zhí)行。
因為監(jiān)聽函數(shù)會在requestAnimationFrame之前執(zhí)行,如果監(jiān)聽函數(shù)中修改了樣式,又用到requestAnimationFrame來制作動畫,便會導致強制同步reflow。
某些交互事件觸發(fā)極頻繁,注意要debounce。
debounce:不要高頻率調(diào)用函數(shù),事件連續(xù)觸發(fā)時,只調(diào)用一次函數(shù)。
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://specialneedsforspecialkids.com/yun/107468.html
摘要:前言對于前端的性能話題,從來都沒有斷絕過。作為一個前端開發(fā)者,性能是我們關(guān)注的指標。前端發(fā)展以來,優(yōu)化方式,琳瑯滿目,有雅虎軍規(guī)等。所以,接下來我會從三個方面就前端性能進行總結(jié)網(wǎng)絡(luò)方面操作及渲染方面數(shù)據(jù)方面。 前言 對于前端的性能話題,從來都沒有斷絕過。因為這個東西沒有最好,只有更好。而且往往也是業(yè)務(wù)的繁雜程度去決定優(yōu)化程度的。作為一個前端開發(fā)者,性能是我們關(guān)注的指標。它直接影響著我們...
摘要:前言對于前端的性能話題,從來都沒有斷絕過。作為一個前端開發(fā)者,性能是我們關(guān)注的指標。前端發(fā)展以來,優(yōu)化方式,琳瑯滿目,有雅虎軍規(guī)等。所以,接下來我會從三個方面就前端性能進行總結(jié)網(wǎng)絡(luò)方面操作及渲染方面數(shù)據(jù)方面。 前言 對于前端的性能話題,從來都沒有斷絕過。因為這個東西沒有最好,只有更好。而且往往也是業(yè)務(wù)的繁雜程度去決定優(yōu)化程度的。作為一個前端開發(fā)者,性能是我們關(guān)注的指標。它直接影響著我們...
摘要:前言對于前端的性能話題,從來都沒有斷絕過。作為一個前端開發(fā)者,性能是我們關(guān)注的指標。前端發(fā)展以來,優(yōu)化方式,琳瑯滿目,有雅虎軍規(guī)等。所以,接下來我會從三個方面就前端性能進行總結(jié)網(wǎng)絡(luò)方面操作及渲染方面數(shù)據(jù)方面。 前言 對于前端的性能話題,從來都沒有斷絕過。因為這個東西沒有最好,只有更好。而且往往也是業(yè)務(wù)的繁雜程度去決定優(yōu)化程度的。作為一個前端開發(fā)者,性能是我們關(guān)注的指標。它直接影響著我們...
摘要:端優(yōu)談?wù)勱P(guān)于前端的緩存的問題我們都知道對頁面進行緩存能夠有利于減少請求發(fā)送,從而達到對頁面的優(yōu)化。而作為一名有追求的前端,勢必要力所能及地優(yōu)化我們前端頁面的性能。這種方式主要解決了淺談前端中的過早優(yōu)化問題過早優(yōu)化是萬惡之源。 優(yōu)化向:單頁應(yīng)用多路由預渲染指南 Ajax 技術(shù)的出現(xiàn),讓我們的 Web 應(yīng)用能夠在不刷新的狀態(tài)下顯示不同頁面的內(nèi)容,這就是單頁應(yīng)用。在一個單頁應(yīng)用中,往往只有一...
閱讀 3213·2021-11-24 09:39
閱讀 2942·2021-11-23 09:51
閱讀 899·2021-11-18 10:07
閱讀 3549·2021-10-11 10:57
閱讀 2752·2021-10-08 10:04
閱讀 3008·2021-09-26 10:11
閱讀 1054·2021-09-23 11:21
閱讀 2797·2019-08-29 17:28