網(wǎng)絡(luò)加載類
首屏數(shù)據(jù)請(qǐng)求提前,避免JavaScript文件加載后才請(qǐng)求渲染
為了進(jìn)一步提示頁面加載速度嗅战,可以考慮將頁面的數(shù)據(jù)請(qǐng)求盡可能提前衅檀,避免在JavaScript文件加載完成后才去請(qǐng)求數(shù)據(jù)灌闺。通常數(shù)據(jù)請(qǐng)求是頁面內(nèi)容渲染中關(guān)鍵路徑最長的部分,而且不能并行抚官,所以如果數(shù)據(jù)請(qǐng)求能提前的話,可以極大程度上縮短頁面內(nèi)容的渲染完成時(shí)間阶捆。首屏加載和按需加載凌节,非首屏內(nèi)容滾屏加載,保證首屏內(nèi)容最小化
由于移動(dòng)端網(wǎng)絡(luò)相對(duì)較慢洒试,網(wǎng)絡(luò)資源有限倍奢,因此為了保證盡快完成頁面內(nèi)容的加載,需要保證首屏加載資源的最小化儡司,非首屏的內(nèi)容使用滾動(dòng)的方式異步加載娱挨。一般推薦移動(dòng)端頁面首屏數(shù)據(jù)展示延遲不超過3秒。模塊化資源并行下載
主要指模塊化JavaScript資源的異步加載捕犬,例如AMD的異步模塊跷坝,使用并行的加載方式能夠縮短多個(gè)文件資源的加載時(shí)間。inline首屏必備的CSS和JavaScript
通常為了在HTML加載完成時(shí)能使瀏覽器中有基本的樣式碉碉,需要將頁面渲染時(shí)必備的CSS和JS通過script或style的方式內(nèi)聯(lián)到頁面中柴钻,避免頁面HTML載入完成到頁面內(nèi)容展示這段過程中頁面出現(xiàn)空白meta dns prefetch設(shè)置DNS預(yù)解析
設(shè)置文件資源的DNS預(yù)解析,能讓瀏覽器提前解析獲取靜態(tài)資源的主機(jī)IP垢粮,避免等到請(qǐng)求的時(shí)候才發(fā)起DNS解析贴届。
<meta http-equiv='x-dns-prefetch-control' content='on'><link rel="dns-prefetch" >資源預(yù)加載
首屏加載完成后可能會(huì)使用的資源,我們可以用 link標(biāo)簽聲明特定文件的預(yù)加載
<link rel='subresource' href='main.css'><link rel='prefetch' href='secondary.js'>
注意:只有可緩存的資源才進(jìn)行預(yù)加載蜡吧,否則浪費(fèi)資源毫蚓!
Pre render預(yù)渲染
預(yù)渲染意味著我們提前加載好用戶即將訪問的下一個(gè)頁面,否則進(jìn)行預(yù)渲染這個(gè)頁面將浪費(fèi)資源昔善,慎用元潘!
<link rel='prerender' href='//j.autohome.com.cn'>合理利用MTU策略
通常情況下,TCP網(wǎng)絡(luò)傳輸?shù)淖畲髠鬏攩卧∕TU)為1500B君仆,即一個(gè)RTT(Round-Trip Time翩概,網(wǎng)絡(luò)請(qǐng)求返回時(shí)間)內(nèi)可以傳輸?shù)臄?shù)據(jù)量最大為1500字節(jié)(為什么以太網(wǎng)mtu值被設(shè)定為1500 - 知乎)。因此在前后端分離的開發(fā)模式中返咱,盡量保證頁面的HTML內(nèi)容在1KB以內(nèi)钥庇,這樣整個(gè)HTML內(nèi)容的請(qǐng)求就可以在一個(gè)RTT內(nèi)完成,最大限度的提高了HTML載入速度
緩存
- 合理利用瀏覽器緩存
除了上一節(jié)說到的Cache-Control咖摹、Expires评姨、Etag和Last-Modified來設(shè)置HTTP緩存外,在移動(dòng)端還可以使用localstorage等來保存ajax返回的數(shù)據(jù)萤晴,或者使用localstorage保存CSS或JS等靜態(tài)資源参咙,實(shí)現(xiàn)移動(dòng)端的離線應(yīng)用龄广,盡可能的減少網(wǎng)絡(luò)請(qǐng)求,保證靜態(tài)資源內(nèi)容的快速加載蕴侧。 - 靜態(tài)資源離線方案
對(duì)于移動(dòng)端或者混合應(yīng)用择同,可以設(shè)置離線文件或離線包機(jī)制讓靜態(tài)資源請(qǐng)求從本地讀取,加快資源載入速度净宵,并實(shí)現(xiàn)離線更新敲才。這塊推薦葉小釵大神的前端優(yōu)化帶來的思考,淺談前端工程化 可以挑著看择葡。離線資源這塊東西太多了紧武,以后有時(shí)間單獨(dú)拿出來寫 - 嘗試使用 AMP HTML
AMP HTML 可以作為優(yōu)化前端頁面性能的一個(gè)解決方案,使用AMP Component中的元素來代替原始頁面元素進(jìn)行直接渲染 [譯]關(guān)于谷歌的AMP敏储,你需要知道這些阻星。
圖片類
圖片壓縮處理
移動(dòng)端通常要保證頁面中一切用到的圖片都是經(jīng)過壓縮優(yōu)化處理,而不是以原圖的形式直接使用的已添,因?yàn)槟菢雍芟牧髁客谆⑶壹虞d時(shí)間更長。使用較小的圖片更舞,合理使用base64內(nèi)嵌圖片
在頁面使用的背景圖片不多且比較小的情況下畦幢,可以把圖片轉(zhuǎn)成base64編碼嵌入到html頁面或者CSS文件中,這樣可以減少頁面的HTTP請(qǐng)求數(shù)缆蝉。需要注意的是宇葱,要保證圖片較小,一般超過5kb的就不推薦base64嵌入顯示了(前端開發(fā)中刊头,使用base64圖片的弊端是什么黍瞧? - 知乎)-
使用更高壓縮比格式的圖片
使用具有較高壓縮比格式的圖片,如webp等原杂。在同等圖片畫質(zhì)的情況下雷逆,高壓縮比格式的圖片體積更小,能夠更快的完成文件傳輸污尉,節(jié)省網(wǎng)站流量。
圖片懶加載
為了保證頁面內(nèi)容最小化往产,加速頁面渲染被碗,盡可能節(jié)省首屏網(wǎng)絡(luò)流量,頁面中的圖片資源推薦使用懶加載實(shí)現(xiàn)仿村,在頁面滾動(dòng)時(shí)動(dòng)態(tài)載入圖片锐朴。使用Media Query 或者 srcset 根據(jù)不同屏幕加載不同大小的圖片
針對(duì)不同屏幕尺寸和分辨率,輸出不同大小的圖片或者背景圖能保證用戶體驗(yàn)不降低的前提下節(jié)省網(wǎng)絡(luò)流量蔼囊,加快部分機(jī)型圖片載入速度焚志,這在移動(dòng)端非常值得推薦使用iconfont代替圖片圖標(biāo)
iconfont體積較小而且是矢量圖衣迷,因此縮放不會(huì)失真,還可以方便修改圖片大小和呈現(xiàn)的顏色酱酬,但是需要注意iconfont引用不同webfont格式會(huì)有兼容問題壶谒。定義圖片大小限制
加載單張圖片不建議超過30KB,避免大圖片加載時(shí)間過長而阻塞頁面其他資源的下載膳沽。如果用戶上傳的圖片過大汗菜,建議設(shè)置限制。
腳本類
- 盡量使用id選擇器
選擇頁面DOM元素時(shí)盡量使用id選擇器挑社,因?yàn)閕d選擇器速度最快 - 合理的緩存dom對(duì)象
對(duì)于需要重復(fù)使用的dom對(duì)象陨界,要優(yōu)先設(shè)置緩存變量,避免每次使用時(shí)都要從整個(gè)dom樹重新查找痛阻。
// 不推薦$("#mod .active").removeClass('active');$("#mod .not-active").addClass("active");// 推薦const $mod = $("#mod");$mod.find(".active").removeClass("active")$mod.find(".not-active").addClass("active")
jq 上有很多優(yōu)化建議菌瘪,詳情搜索JQ 優(yōu)化
頁面元素盡量使用事件代理,避免事件直接綁定
使用事件代理可以避免對(duì)每個(gè)元素都進(jìn)行綁定阱当。并且可以避免出現(xiàn)內(nèi)存泄漏以及需要?jiǎng)討B(tài)添加元素的事件綁定問題
// 不推薦$(".btn").click( _ => console.log("hello") )// 推薦$(document).on("click", ".btn", _ => console.log("world"))使用touch代理click
由于移動(dòng)端屏幕的設(shè)計(jì)俏扩,touch事件和click事件觸發(fā)之間存在300ms延遲,所以在頁面沒有touchmove實(shí)現(xiàn)滾動(dòng)處理的情況斗这,可以用touchstart代替元素的click事件动猬,加快頁面點(diǎn)擊的響應(yīng)速度,提高用戶體驗(yàn)表箭。但同時(shí)也需要注意頁面重疊元素touch動(dòng)作的點(diǎn)透問題赁咙。
// 不推薦$("body").on("click",".btn",function(){ console.log(this) });// 推薦$("body").on("tap",".btn",function(){ console.log(this) });// tap為zepto用touch事件封裝的避免touchmove,scroll等連續(xù)事件處理
需要對(duì)這類高頻觸發(fā)回調(diào)的事件設(shè)置函數(shù)節(jié)流(throttle | debounce)免钻,避免頻繁的事件調(diào)用導(dǎo)致移動(dòng)端頁面卡頓避免使用eval彼水、with,使用join代替連接符+极舔,推薦使用ES6的模板字符串
基本的安全腳本編寫問題凤覆,盡可能使用高效率的特性來完成這些操作,避免不規(guī)范或者不安全的寫法拆魏。盡量使用ES6+的特性來編程
ES6+在一定程度上更高效盯桦,在chrome59版本對(duì)ES6做了深度優(yōu)化之后,很多特性速度提升了80%左右渤刃,這也是未來規(guī)范的需要拥峦。ES8前段時(shí)間也已經(jīng)落地了,如果你還沒有掌握ES6語法的話卖子,抓緊時(shí)間學(xué)吧...
渲染類
使用viewport固定屏幕渲染略号,可以加速頁面渲染內(nèi)容
一般認(rèn)為,在移動(dòng)端設(shè)置viewport可以加速頁面的渲染,同時(shí)可以避免縮放導(dǎo)致頁面重排重繪玄柠。
// 利用meta標(biāo)簽對(duì)viewport進(jìn)行控制<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0">避免各種形式重排(reflow)重繪(redraw)
頁面的重排重繪很耗性能突梦,所以一定要盡可能減少頁面的重排重繪,例如頁面圖片大小變化羽利、元素位置變化這些情況都會(huì)導(dǎo)致重排與重繪使用CSS3動(dòng)畫宫患,開啟GPU加速
使用CSS3動(dòng)畫可以設(shè)置transform: translateZ(0)來開啟移動(dòng)設(shè)備瀏覽器的GPU圖形處理加速。這里安利一波京東凹凸實(shí)驗(yàn)室铐伴,講的挺好的撮奏,GPU加速是什么合理使用canvas和requestAnimationFrame
選擇canvas或者requestAnimationFrame等更高效的動(dòng)畫實(shí)現(xiàn)方式,避免使用settimeout当宴、setInterval等方式直接處理連續(xù)動(dòng)畫SVG代替圖片
部分情況下可以考慮使用SVG代替圖片實(shí)現(xiàn)動(dòng)畫畜吊,因?yàn)镾VG格式內(nèi)容更小,而且SVG的DOM結(jié)構(gòu)方便調(diào)整不濫用float
在DOM渲染樹生成后的布局渲染階段户矢,使用float的元素布局計(jì)算比較耗性能玲献,所以盡量減少float的使用,推薦使用固定布局或者flex布局的方式來實(shí)現(xiàn)頁面的元素布局不濫用web字體或過多的font-size聲明
過多的font-size聲明會(huì)增加字體的計(jì)算大小梯浪,而且也沒啥必要
架構(gòu)協(xié)議
- 嘗試使用SPDY和HTTP2
在條件允許的情況下可以考慮使用SPDY協(xié)議來進(jìn)行文件資源傳輸捌年,利用連接復(fù)用加快傳輸過程,縮短資源加載時(shí)間挂洛。HTTP2在未來也一定會(huì)成為主流的 - 使用后端數(shù)據(jù)渲染
SSR( Server Side Rendering礼预,服務(wù)端渲染)的方式可以加速頁面內(nèi)容的渲染展示,避免空白頁面的出現(xiàn)虏劲,同時(shí)可以解決頁面SEO的問題托酸。條件允許的話,SSR是一個(gè)很好的實(shí)踐思路柒巫。百度SSP單頁式應(yīng)用性能優(yōu)化實(shí)踐励堡,React 同構(gòu)實(shí)踐與思考 - 使用Native View代替DOM的性能劣勢(shì)
可以嘗試使用Native View的MNV* 開發(fā)模式來避免HTML DOM性能慢的問題,目前使用MNV* 的開發(fā)模式已經(jīng)可以將頁面內(nèi)容渲染體驗(yàn)做到接近客戶端Native應(yīng)用的體驗(yàn)了堡掏。
關(guān)于頁面優(yōu)化的常用技術(shù)手段和思路主要包括以上這些应结,有部分遺漏歡迎補(bǔ)充。大家可以根據(jù)需要將這些方法應(yīng)用到自己的項(xiàng)目中去泉唁,想全部做到幾乎是不可能的鹅龄,但做到用戶可以接受的程度還是很容易的。
軟件工程沒有銀彈亭畜,在我們做到了極致優(yōu)化的同時(shí)也需要付出很大的代價(jià)扮休,這也是前端優(yōu)化的一個(gè)問題。理論上這些優(yōu)化都可以實(shí)現(xiàn)贱案,但是我們也要懂得權(quán)衡,優(yōu)化提升了用戶體驗(yàn),使數(shù)據(jù)加載更快宝踪,但是項(xiàng)目代碼卻可能打亂侨糟,異步內(nèi)容要拆分出來,首屏雪碧圖可能要拆分2個(gè)或更多瘩燥,項(xiàng)目代碼維護(hù)成本成倍增加秕重,項(xiàng)目結(jié)構(gòu)也可能變得混亂。任何一部分優(yōu)化都可以做得很深入厉膀,但不一定都值得溶耘。在優(yōu)化的同時(shí)考慮性價(jià)比,這才是我們作為一名前端工程師處理前端優(yōu)化時(shí)該具有的正確思維服鹅。