前端資源優化--資源的合併與壓縮

前端優化

資源的合併與壓縮

web前端是bs架構

web訪問是動態增量的過程，經過不斷請求遠程服務器加載資源

優勢：減小http請求，減小請求資源的大小

1.資源合併與壓縮-壓縮

a.html壓縮

方法：

1.使用在線網站進行壓縮

2.nodejs提供了html-minifier工具

3.後端模板引擎渲染壓縮

b.css壓縮

1.無效代碼刪除

2.css語義合併

c.js壓縮與混亂

1.無效字符的刪除

2,剔除註釋

3.代碼語義的縮減和優化

4.代碼保護（代碼壓縮，可讀性底，有利於保護代碼不被看懂或複製）

方法

1.使用在線網站進行壓縮

2.nodejs提供了html-minifier工具

3.使用uglifyjs2對果進行壓縮

資源合併與壓縮-合併

文件合併存在的問題

首屏渲染問題（文件合併成一個文件，首次加載時間會比較長）

緩存失效問題（修改其中一處內容，整個文件變更，在瀏覽器的緩存失效，又要從新加載整個文件）

文件合併建議

公共庫合併

不一樣頁面的合併（vue的異步加載組件）

見機行事，隨機應變

方法

1.使用在線網站進行合併

2.使用nodejs或webpack等框架實現文件合併

2.圖片相關優化

png8/png24/png32之間的區別

png8 -- 256色（2^8） 支持透明--適用於顏色種類較少的png圖片

png24 -- （2^24） 不支持透明

png32 -- （2^24） 支持透明--適用於顏色種類豐富的png圖片

不一樣圖片經常使用的業務場景

jpg有損壓縮，壓縮率高，不支行透明

png支持透明，瀏覽器兼容好

webp壓縮程序更好，在ios webviewe有兼容性問題

svg矢量圖，代碼內嵌，相對較小，圖片樣式相對簡單的場景

進行圖片壓縮

針對真實圖片狀況，捨棄一些相對無關的色彩信息

css雪碧圖

優勢：減小Http請求

缺點：當雪碧圖過大時，加載過慢，在雪碧圖上的全部圖片就會都沒有加載出來

image inline

把圖片轉成base64格式，而後內嵌在html中

優勢：減小http請求

缺點：代碼體量過大

使用矢量圖

使用svg進行矢量圖繪製

使用iconfont解決icon問題

與jpg相比，更小，加載更快

缺點：顏色比較單調，複雜的圖片不適合使用矢量圖

在安卓下使用webp

webp壓縮率更高，大小更小，可是並不全部瀏覽器兼容

圖片壓縮網址圖片壓縮

3. css和js的裝載與執行

html,css,js加載過程

輸入網站，發起請求，服務器返回一段html,瀏覽器html解析器解析，從上到下生成dom樹，在這個過程當中，解析到相應的link,script等外部資源，而後由瀏覽器發起請求，加載到相應的資源並解析，生成對應的css樹，css樹和dom樹結合，生成render tree,而後佈局，重繪，造成html頁面

html渲染過程當中的一些特色

順序執行，併發加載(引入外部資源，併發加載)

是否阻塞（css,js加載是否阻塞後續dom加載）

依賴關係

引入方式

順序執行，併發加載

詞法分析--從上到下

併發加載--引入外部資源，併發加載

併發上限--併發加載資源，有上限

css阻塞

css head中阻塞頁面的渲染

css阻塞js執行--js執行可能影響dom結構和css樣式，執行前要求dom和css已經加載完成，有依賴關係

css不阻塞外部腳本的加載

js阻塞

直接引入的js阻塞頁面的渲染

js不阻塞資源的加載

js順序執行，阻塞後續js邏輯執行

依賴關係

頁面渲染依賴於css加載

js的執行順序的依賴關係

js邏輯對於dom節點的依賴關係

js引入方式

直接引入--會阻塞頁面加載

defer--不會阻塞dom渲染，dom渲染完成後，按照從上到下，同步執行

async--不會阻塞dom渲染，dom渲染完成後，異步加載執行，不存在依賴關係

異步動態引入js

加載和執行的一些優化點

css樣式表置頂

用link代替import--外部引用css樣式完成後，再解析import，在css樣式表內部執行,不會併發執行

js腳本置底

合理使用js的異步加載能力

4. 懶加載與預加載

原理

什麼是懶加載：圖片進入可視區域以後請求圖片資源，若是網站圖片不少，可是用戶只看了幾張就退出，後面的圖片也沒有必要加載，這時就是用到懶加載了，並且過多資源加載，會影響後面js的加載

1,監聽scoll整件，當圖片進入可視區域後，圖片開始加載

什麼是預加載：圖片等靜態資源使用前，提早加載，資源使用到時能從緩存中加載，提高用戶體驗

預加載的三種方法

1.直接在頁面內經過img標籤引入，默認隱藏

2.在js裏文件new image對象，須要的時候直接引用

3.使用XMLHttpRequest對象加載圖片，這個方法返回狀態和回調函數，監聽函數，更好控制整個過程，可是不一樣域名下的資源有跨域問題

4.使用preloadJS庫

重繪與迴流

css性能讓javascript變慢？是的，這是由於ui是一個線程，js渲染也是一個線程，但這兩個線程是互斥，當其中一個線程進行時，另外一個是凍結的。頻繁觸發重繪與迴流，會致使ui頻繁渲染，最終致使js變慢

迴流

當render tree中的一部分或所有，由於元素的規模尺寸，佈局，隱藏等改變而須要從新構建。這就稱爲迴流。當頁面佈局和幾何屬性（大小長寬）改變時須要迴流

重繪

當render tree中的一些元素須要更新屬性，在，而這些屬性只是影響元素的外觀，風格，而不影響佈局的，好比背景，字體顏色，則稱爲重繪。

迴流必將引發重繪，而重繪不必定會引發迴流

觸發頁面重佈局的屬性

盒子模型相關屬性會觸發重佈局

定位屬性及浮動也會觸發得佈局

改變節點內部文字結構也會觸發重佈局

只觸發重繪屬性

瀏覽器存儲

多種瀏覽器存儲方式並存，如何選擇？

cookie

由於HTTP請求無狀態，因此須要cookie去維護客戶端狀態

cookier的生成方式

http response header 中的set-cookie,當客戶端接收到http response header 中的set-cookie信息時，會自動在客戶端生成相應的cookie,客戶端再次發起請求時，這些cookie信息將被攜帶在request header中帶給服務端，服務端能夠從這些信息中判斷用戶的相關信息--用於瀏覽器端和服務端的交互

cookie屬性httponly(服務端設置), 若是您在cookie中設置了HttpOnly屬性，那麼經過js腳本將沒法讀取到cookie信息，這樣能有效的防止XSS攻擊

js中能夠經過document.cookie能夠讀寫cookie--客戶端自身存儲信息

cookie存儲的限制

做爲瀏覽器存儲，大小4kb左右

需在設置過時時間 expire

瀏覽器存儲儘可能用localstorage

Localstorage

HTML5設計出來專門用於瀏覽器存儲

大小爲5M左右

僅在客戶端使用，不和服務端進行通訊

接口封閉較好，有專門的api進行設置刪除操做

瀏覽器本地緩存方案

sessionstorage

會話級別的瀏覽器存儲（瀏覽器關閉，sessionstorage刪除）

大小爲5M左右

僅在客戶端使用，不和服務端進行通訊

接口封閉較好，有專門的api進行設置刪除操做

對於表單信息的維護

IndexedDB

IndexedDB 就是瀏覽器提供的本地數據庫，它能夠被網頁腳本建立和操做。IndexedDB 容許儲存大量數據，提供查找接口，還能創建索引。這些都是 LocalStorage 所不具有的。就數據庫類型而言，IndexedDB 不屬於關係型數據庫（不支持 SQL 查詢語句），更接近 NoSQL 數據庫。

service workers 產生的意義

大規模,多線程運行js

PWA