上一篇講了PC端的部分:前端性能優化(PC端),此次繼續說移動端的。相對於PC端的,移動web瀏覽器上有一些明顯的特色:設備的屏幕小、新特性兼容性較好、支持一些比較新的HTML5和CSS三、須要與Native應用交互等。但移動端可用的CPU資源和網絡資源極爲有限,所以要作好移動端web上的優化每每須要考慮作更多的事情。首先在移動web的前端頁面渲染中,PC的優化規則一樣適用,此外針對瀏覽器也要作一些更細節的優化達到更好的效果。須要注意的是,並非移動端的優化在PC端不適用,而是因爲兼容性的緣由,一些優化規則在移動端更具備表明性,因此也是爲何我把DNS預解析,離線緩存,HTTP2協議,GPU加速等東西放到這部分來說...javascript
爲了進一步提示頁面加載速度,能夠考慮將頁面的數據請求儘量提早,避免在JavaScript文件加載完成後纔去請求數據。一般數據請求是頁面內容渲染中關鍵路徑最長的部分,並且不能並行,因此若是數據請求能提早的話,能夠極大程度上縮短頁面內容的渲染完成時間。css
因爲移動端網絡相對較慢,網絡資源有限,所以爲了保證儘快完成頁面內容的加載,須要保證首屏加載資源的最小化,非首屏的內容使用滾動的方式異步加載。通常推薦移動端頁面首屏數據展現延遲不超過3秒。html
主要指模塊化JavaScript資源的異步加載,例如AMD的異步模塊,使用並行的加載方式可以縮短多個文件資源的加載時間。前端
一般爲了在HTML加載完成時能使瀏覽器中有基本的樣式,須要將頁面渲染時必備的CSS和JS經過script或style的方式內聯到頁面中,避免頁面HTML載入完成到頁面內容展現這段過程當中頁面出現空白java
設置文件資源的DNS預解析,能讓瀏覽器提早解析獲取靜態資源的主機IP,避免等到請求的時候才發起DNS解析。web
<!-- cdn域名預解析 --> <meta http-equiv='x-dns-prefetch-control' content='on'> <link rel="dns-prefetch" href="//x.autoimg.cn">
首屏加載完成後可能會使用的資源,咱們能夠用 link標籤聲明特定文件的預加載ajax
<link rel='subresource' href='main.css'> <link rel='prefetch' href='secondary.js'>
注意:只有可緩存的資源才進行預加載,不然浪費資源!chrome
預渲染意味着咱們提早加載好用戶即將訪問的下一個頁面,不然進行預渲染這個頁面將浪費資源,慎用!編程
<link rel='prerender' href='//j.autohome.com.cn'>
一般狀況下,TCP網絡傳輸的最大傳輸單元(MTU)爲1500B,即一個RTT(Round-Trip Time,網絡請求返回時間)內能夠傳輸的數據量最大爲1500字節(爲何以太網mtu值被設定爲1500 - 知乎)。所以在先後端分離的開發模式中,儘可能保證頁面的HTML內容在1KB之內,這樣整個HTML內容的請求就能夠在一個RTT內完成,最大限度的提升了HTML載入速度canvas
除了上一節說到的Cache-Control、Expires、Etag和Last-Modified來設置HTTP緩存外,在移動端還可使用localstorage等來保存ajax返回的數據,或者使用localstorage保存CSS或JS等靜態資源,實現移動端的離線應用,儘量的減小網絡請求,保證靜態資源內容的快速加載。
對於移動端或者混合應用,能夠設置離線文件或離線包機制讓靜態資源請求從本地讀取,加快資源載入速度,並實現離線更新。這塊推薦葉小釵大神的前端優化帶來的思考,淺談前端工程化 能夠挑着看。離線資源這塊東西太多了,之後有時間單獨拿出來寫
AMP HTML 能夠做爲優化前端頁面性能的一個解決方案,使用AMP Component中的元素來代替原始頁面元素進行直接渲染 [譯]關於谷歌的AMP,你須要知道這些。
移動端一般要保證頁面中一切用到的圖片都是通過壓縮優化處理,而不是以原圖的形式直接使用的,由於那樣很消耗流量,而且加載時間更長。
在頁面使用的背景圖片很少且比較小的狀況下,能夠把圖片轉成base64編碼嵌入到html頁面或者CSS文件中,這樣能夠減小頁面的HTTP請求數。須要注意的是,要保證圖片較小,通常超過5kb的就不推薦base64嵌入顯示了(前端開發中,使用base64圖片的弊端是什麼? - 知乎)
使用具備較高壓縮比格式的圖片,如webp等。在同等圖片畫質的狀況下,高壓縮比格式的圖片體積更小,可以更快的完成文件傳輸,節省網站流量。
![](//x.autoimg.cn/path/photo.webp)
爲了保證頁面內容最小化,加速頁面渲染,儘量節省首屏網絡流量,頁面中的圖片資源推薦使用懶加載實現,在頁面滾動時動態載入圖片。
針對不一樣屏幕尺寸和分辨率,輸出不一樣大小的圖片或者背景圖能保證用戶體驗不下降的前提下節省網絡流量,加快部分機型圖片載入速度,這在移動端很是值得推薦
iconfont體積較小並且是矢量圖,所以縮放不會失真,還能夠方便修改圖片大小和呈現的顏色,可是須要注意iconfont引用不一樣webfont格式會有兼容問題。
加載單張圖片不建議超過30KB,避免大圖片加載時間過長而阻塞頁面其餘資源的下載。若是用戶上傳的圖片過大,建議設置限制。
選擇頁面DOM元素時儘可能使用id選擇器,由於id選擇器速度最快
對於須要重複使用的dom對象,要優先設置緩存變量,避免每次使用時都要從整個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 上有不少優化建議,詳情搜索JQ 優化
使用事件代理能夠避免對每一個元素都進行綁定。而且能夠避免出現內存泄漏以及須要動態添加元素的事件綁定問題
// 不推薦 $(".btn").click( _ => console.log("hello") ) // 推薦 $(document).on("click", ".btn", _ => console.log("world"))
因爲移動端屏幕的設計,touch事件和click事件觸發之間存在300ms延遲,因此在頁面沒有touchmove實現滾動處理的狀況,能夠用touchstart代替元素的click事件,加快頁面點擊的響應速度,提升用戶體驗。但同時也須要注意頁面重疊元素touch動做的點透問題。
// 不推薦 $("body").on("click",".btn",function(){ console.log(this) }); // 推薦 $("body").on("tap",".btn",function(){ console.log(this) }); // tap爲zepto用touch事件封裝的
須要對這類高頻觸發回調的事件設置函數節流(throttle | debounce),避免頻繁的事件調用致使移動端頁面卡頓
基本的安全腳本編寫問題,儘量使用高效率的特性來完成這些操做,避免不規範或者不安全的寫法。
ES6+在必定程度上更高效,在chrome59版本對ES6作了深度優化以後,不少特性速度提高了80%左右,這也是將來規範的須要。ES8前段時間也已經落地了,若是你尚未掌握ES6語法的話,抓緊時間學吧...
通常認爲,在移動端設置viewport能夠加速頁面的渲染,同時能夠避免縮放致使頁面重排重繪。
// 利用meta標籤對viewport進行控制
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0">
頁面的重排重繪很耗性能,因此必定要儘量減小頁面的重排重繪,例如頁面圖片大小變化、元素位置變化這些狀況都會致使重排與重繪
使用CSS3動畫能夠設置transform: translateZ(0)來開啓移動設備瀏覽器的GPU圖形處理加速。這裏安利一波京東凹凸實驗室,講的挺好的,GPU加速是什麼
選擇canvas或者requestAnimationFrame等更高效的動畫實現方式,避免使用settimeout、setInterval等方式直接處理連續動畫
部分狀況下能夠考慮使用SVG代替圖片實現動畫,由於SVG格式內容更小,並且SVG的DOM結構方便調整
在DOM渲染樹生成後的佈局渲染階段,使用float的元素佈局計算比較耗性能,因此儘可能減小float的使用,推薦使用固定佈局或者flex佈局的方式來實現頁面的元素佈局
過多的font-size聲明會增長字體的計算大小,並且也沒啥必要
在條件容許的狀況下能夠考慮使用SPDY協議來進行文件資源傳輸,利用鏈接複用加快傳輸過程,縮短資源加載時間。HTTP2在將來也必定會成爲主流的
SSR( Server Side Rendering,服務端渲染)的方式能夠加速頁面內容的渲染展現,避免空白頁面的出現,同時能夠解決頁面SEO的問題。條件容許的話,SSR是一個很好的實踐思路。百度SSP單頁式應用性能優化實踐,React 同構實踐與思考
能夠嘗試使用Native View的MNV* 開發模式來避免HTML DOM性能慢的問題,目前使用MNV* 的開發模式已經能夠將頁面內容渲染體驗作到接近客戶端Native應用的體驗了。
關於頁面優化的經常使用技術手段和思路主要包括以上這些,有部分遺漏歡迎補充。你們能夠根據須要將這些方法應用到本身的項目中去,想所有作到幾乎是不可能的,但作到用戶能夠接受的程度仍是很容易的。
軟件工程沒有銀彈,在咱們作到了極致優化的同時也須要付出很大的代價,這也是前端優化的一個問題。理論上這些優化均可以實現,可是咱們也要懂得權衡,優化提高了用戶體驗,使數據加載更快,可是項目代碼卻可能打亂,異步內容要拆分出來,首屏雪碧圖可能要拆分2個或更多,項目代碼維護成本成倍增長,項目結構也可能變得混亂。任何一部分優化均可以作得很深刻,但不必定都值得。在優化的同時考慮性價比,這纔是咱們做爲一名前端工程師處理前端優化時該具備的正確思惟。
PS:另外身位一個coder,雖然晚睡是常態了,但每次寫東西都是熬到半夜二、3點身體也吃不消啊.... o(╥﹏╥)o !!