現代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則是把首屏速度再度進行提升，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/169946.html
標籤：JavaScript
上一篇：【微信小程式】動態設定圖片大小
下一篇：判斷變數的資料型別