現代WEB前端的性能優化

現代WEB前端的性能優化

前言：這只是一份學習筆記。

 

什麼是WEB前端

 

潛在的優化點：

DNS是否能夠經過緩存減小DNS查詢時間？

網絡請求的過程走最近的網絡環境？

相同的靜態資源是否能夠緩存？

可否減小http請求的大小？

減小http請求數

服務端渲染

 

涉及層面

網絡層面

構建層面

服務端層面

瀏覽器渲染層面

 

基礎優化：圖片的編碼原理、選擇圖片的格式、資源的合併與壓縮。

進階優化：瀏覽器渲染層面的優化、重繪與迴流層面的優化、瀏覽器存儲的選擇與使用、瀏覽器端結合服務端的緩存機制。

結合服務端的優化：基於nodejs的Vue-SSR解決首屏渲染的問題。

 

知識點

資源的合併與壓縮

目的：減小http請求數量、減小請求資源大小、減小帶寬消費。

原理：經過一個入口文件（依賴的頂層），分析全部依賴，獲得依賴樹，最後按照依賴樹，對文件進行壓縮、混淆、合併、語法轉換。

 

a)  html壓縮

在前端的源代碼裏，有些東西，只在代碼裏有意義，可是對於瀏覽器卻毫無心義的。

例如：代碼對齊的回車、空格、tab，代碼註釋。

這些東西在發佈的時候能夠去掉。

 

b)  css壓縮

刪除回車、空格、tab，刪除代碼註釋，css語義合併。

 

c)   js壓縮與混淆（必須）

刪除回車、空格、tab，刪除代碼註釋，代碼命名和語義的縮減與優化，達到代碼保護。

 

d)  文件合併

· 公共庫合併（合併成爲vendor.js）

· 分頁面合併（按路由合併）

· 按實際狀況合併

 

e)  開啓gzip

將js和css文件壓縮爲gzip。

 

圖一爲普通模式的請求情況

「傳輸」：http請求大小 + 文件傳輸過程大小

「大小」：文件的實際大小

 

 

圖二爲gzip模式的請求情況，gzip的壓縮閾值爲10K

「傳輸」：http請求大小 + 文件傳輸過程大小（即gzip壓縮後大小）

「大小」：文件的實際大小（瀏覽器收到gzip，解壓以後的大小）

 

 

舉個例子，vendor.js，原大小6.5M（echarts的源碼太大了），

通過代碼壓縮後，成果是770K，

最後部署到nginx，啓用nginx的gzip功能，瀏覽器請求時變成200K

6.5M->770K->200K

 

圖片壓縮

小圖片轉換爲base64嵌入到代碼裏。

大圖片將肉眼沒法識別的色彩去除，達到壓縮。

 

瀏覽器渲染

 

本質就是：js和css的加載順序問題，把css放在head，js按實際須要放（儘量放底部），並且，訪問對應路由的時候才加載須要的js和css。

 

懶加載與預加載

懶加載：在沒有進入可視區域的時候，img的src是一個很小的佔位圖片或者直接是空的，進入可視區域的時候，才變成有效的src。

 

 

 

上面代碼是手工實現的，另有開源的zepto.lazyload.js，vue-cli架構下也有專門的庫。

 

預加載：在最開頭的部分，使用隱藏的img加載須要的圖片，後面須要使用的時候，其它的img就會從緩存讀圖片。直接在js裏面new一個Image對象，也能實現預加載。用ajax的get方法去加載也行，可是ajax有跨域問題。

開源的有PreloadJS

 

 

 

 

 

重繪與迴流

瀏覽器渲染的時候，css的運行會阻塞js的運行。

頻繁觸發重繪與迴流，會致使UI頻繁渲染，最終致使js變慢。

儘可能少觸發重繪與迴流能夠提高性能。

重繪的代價比迴流要小的多，因此，儘量只觸發重繪，而減小觸發迴流，就能提升性能。

在瀏覽器的開發者工具欄裏面，性能（performance）那一項，有重繪與迴流的記錄。

若是沒法避免重繪與迴流，則儘可能把重繪迴流的範圍限制在一個圖層以內，例如video、canvas、有特定樣式的div。（在谷歌瀏覽器的開發者工具欄的layers裏面，有代表哪些元素是圖層，以及那些元素之因此是圖層的緣由）

 

重繪（代價比較小）：

 

 

迴流（即重佈局，代價比較大）：

 

 

上面兩個圖看不懂不要緊，能夠直接看下面這個圖：

 

 

.class1 { margin-left : 10px; padding-left: 10px;}

.class2 { margin-left : 20px; padding-left: 20px;}

關於第三點，修改元素樣式的時候，用class的話，只回流1次，可是若是直接改style，則迴流2次

 

關於第四點，先把元素隱藏起來，而後修改各類樣式，改完再顯示出去，就只回流兩次。

若是直接是顯示狀態下改n種樣式，就會迴流n次。

（PS：若是用了第三點，就能夠忽略第四點）

 

關於第五點，不要在循環裏面取值，要在循環外面事先取出來

舉個反例：

 

 

正確例子：

 

 

瀏覽器存儲

在現代WEB前端，

Cookie用於標識用戶，如今的人都再也不用於存儲數據

LocalStorage，僅用於存儲數據，永久性的

SessionStorage，僅用於存儲數據，生命週期跟session有關

IndexDB，前端的NOSQL數據庫，永久性的，大量數據時候會用到

ServiceWorker，控制瀏覽器的離線緩存，經過編寫ServiceWorker的js代碼，能夠直接控制瀏覽器去讀緩存裏的js、css、html文件，並且是徹底離線的，也就是說，即便斷網了，也同樣能夠訪問網站。（若是緩存裏面沒有該文件，纔會發請求出去拿文件）

 

關於cookie的一個優化點：

Cookie是做用於一個域的，請求裏面攜帶cookie會有必定的損耗，可是通常只有調接口的時候才須要cookie，調js和css是不須要cookie的，因此，通常把前端靜態文件放在CDN（即另外一個域），這樣子訪問js和css就不會攜帶cookie了。對於京東來講，這樣子每一年能夠節省上億元的帶寬消費。

 

緩存策略

區別於上一節，http、https自身也有緩存策略：經過控制cache-control、last-modified、Etag，能夠達到自由控制緩存。

 

狀態對比：

（200）> （304） > （200已緩存）

舉個例子 10ms > 5ms > 0ms

 

PWA

PWA（Progressive Web App）是一種全新的網頁技術，讓網站的離線體驗變得更好，特別適用於斷斷續續的網絡。如今很是火，對於前端性能的優化，效果很顯著。它的本質就是用了ServiceWorker。

 

先後端分開部署

前端，只要有html、css、js、圖片就是完整的了。

後端，則有PHP、Java等語言。

PHP依賴於Apache，Java依賴於Tomcat，而前端能夠放在任意的web服務容器上運行。

前端放在Tomcat、Apache、Nginx的性能比是 1：5：15。

 

Vue-SSR

vue-cli跟vue-ssr作出來的都是單頁面應用，因爲用了vue-router來實現各個tab，因此每一個tab的性能都是超乎想象的優越。

而vue-ssr則是把首屏速度再度進行提高。