web前端性能優化

前端性能優化點，涉及的功能 1）網絡層面。2）構建層面。3）服務端層面。4）瀏覽器渲染層面。 資源的合併與壓縮，圖片編解碼原理和類型選擇，瀏覽器渲染機制。 掌握前端性能優化的原理，這些優化點如何與業務相互結合，業務優化點有哪些能夠優化的點。 瞭解當前大公司在性能優化上所作的實踐，學會分析自身業務，選擇合適的性能優化方式。

---

資源的合併與壓縮

掌握知識要點：

理解減小http請求數量和減小請求資源大小兩個優化要點；

掌握壓縮與合併的原理；

掌握經過在線網站和fis3兩種實現壓縮與合併的方法。

CS架構：

BS架構：開發人員將前端代碼發

布到遠程服務器webserver以及遠程CDN上,用戶打開瀏覽器輸入相應網址，這是瀏覽器向遠程服務器發送請求，動態增量式的去加載靜態資源，因次web前端去訪問過程是一個動態增量地加載靜態資源過程，經過http請求，經過瀏覽器發出到server而且返回，最終拿到資源，這個過程當中咱們拿到資源接口返回數據更快，那麼對咱們web前端來說體驗會更好。

瀏覽器的一個請求從發送到返回都經歷了什麼？

 

 

請求過程當中一些潛在的性能優化點：

• dns是否能夠經過緩存減小dns查詢時間？
• 網絡請求的過程走最近的網絡環境？
• 相同的靜態資源是否能夠緩存？
• 可否減小請求http請求大小？
• 減小http請求
• 服務端渲染

深刻理解http請求的過程是前端性能優化的核心，基於對業務更深刻的理解，及對業務技術棧更深刻的理解。

資源的合併與壓縮包含哪兩種知識點？

減小http請求數量合併；減小請求資源的大小（壓縮）；

 

html壓縮：

html代碼壓縮就是壓縮這些在文本文件中有意義，可是在html中不顯示的字符，包括空格，製表符，換行符等，還有一些其餘有意義的字符，如html註釋也能夠被壓縮。

如何進行html壓縮：

1）使用在線網站進行壓縮（如今不多使用這種方式進行，大多數公司使用webpack構建工具進行壓縮）；

2）nodejs提供了html-minifier工具；

3）後端模板引擎渲染壓縮；

css壓縮：

無效代碼刪除；css語義合併；

如何進行css壓縮：

1）使用在線網站進行壓縮；

2）使用html-minifier對html中的css進行壓縮；

3）使用clean-css對css進行壓縮；

js壓縮與混亂：

無效字符的刪除，剔除註釋，代碼語義的縮減和優化；代碼保護層面 ；

如何進行js壓縮和混亂：

1）使用在線網站進行壓縮；

2）使用html-minifier對html中的js進行壓縮；

3）使用uglifyjs2對js進行壓縮；

文件合併存在的問題：

1）首屏渲染問題（React、Vue ）；2）緩存失效問題；

針對上面2個問題如何解決？

1）公共庫合併；在真實的業務場景中，將公共庫打包成一個文件，將業務代碼（頻繁改變）打包成一個文件，就算咱們改動業務代碼的時候，也不會影響到業務層代碼的狀況

2）不一樣頁面的合併；針對常常單頁應用，單頁面應用在渲染的時候會請求當前頁面對應的js，而不是把全部js都打成一個包，請求回來是不合理的。在真實的業務場景中，咱們指望的是單頁面中某一個頁面被路由到的時候，纔去加載那個頁面的組件，請求那個頁面的js。把不一樣頁面的js分別打包，當前端路由路由到哪一個頁面的時候纔去加載那個頁面的組件（對應js文件）。這種方式在webpack中是能夠實現，異步加載組件結合如今的框架。

3）見機行事，隨機應變；

如何進行文件合併：

使用在線網站進行文件合併；使用nodejs實現文件合併；

進行文件合併有些狀況下還有一個緣由就是：受限於咱們瀏覽器所支持一個域名的併發狀況。好比說

瀏覽器能夠並行加載100個js文件，其實它會發100個請求，是實際上瀏覽器自己由於受限它起的線程數量，因此瀏覽器針對每個域名併發請求js的數量（靜態資源數量）是有限的，好比。。100個js經過<script>標籤引入的話，其實並不能對它同時發起請求。瀏覽器支持對同一個域名下併發請求數量是有限的，具體數據每一個瀏覽器是不同的。

web前端的核心概念和web前端性能優化的意義所在；

http請求的過程及其中潛在的性能優化點；

壓縮與合併的理念和使用；

---

 圖片相關的優化

須要掌握：理解圖片相關的優化的核心概念；結合大廠網站案例分析；掌握經過在線網站和fis3兩種實現圖片相關的一些優化。

png8/png24/png32之間的區別：

png8--256色+支持透明；png24——2的24方色+不支持透明；png32——2的24方色+ 支持透明；文件大小，色彩富豐程度。

每種圖片格式都有本身的特色，針對不一樣的業務場景選擇不一樣的圖片格式很重要。

不一樣格式圖片經常使用的業務場景（及特色）：

1）jpg有損壓縮，壓縮率高，不支持透明；——大部分不須要透明的業務場景

2）png支持透明，瀏覽器兼容好；——大部分須要透明圖片的業務場景

3）webp壓縮程度更好，在ios webviews有兼容性問題（ios支持不是很好）；——安卓所有

4）svg矢量圖，代碼內嵌，相對較小，圖片樣式相對簡單的場景；——圖片樣式相對簡單的業務場景

圖片壓縮：針對真是圖片狀況，捨棄一些相對可有可無的色彩信息。

CSS雪碧圖：把網站上用到的一些圖片整合到一張單獨的圖片中

優勢：減小你的網站的http請求數量；缺點：整合圖片比較大時，一次加載比較慢。

Image inline： 在構建階段將圖片內嵌到html上，與html同時存在的狀況，不是發送http請求去得到一張圖片，而是以base64格式將它文件的信息都inline到，減小網站http請求的數量。

使用矢量圖：使用SVG進行矢量圖的繪製，使用iconfont解決icon問題。

在安卓下使用webp：Webp的優點體如今它具備更優的圖像數據壓縮算法，能帶來更小的圖片體積，並且擁有肉眼識別無差別的圖像質量；同時具有了無損和有損的壓縮模式、Alpha透明以及動畫的特性，在JQED和png上的轉化效果都很是優秀、穩定和統一。

圖片壓縮經常使用網站：https：//tinypng.com

png壓縮webp的兩種方式：1）在線網站2）fis3壓縮。

image-inline：須要根據具體業務場景來確實是否使用，會致使圖片變大，總體資源所須要size變大，但會減小http請求，尋找合適的業務場景。小的icon自己只有1kb那麼變大也就1.幾kb，這樣在size變化不大。可是減小一次http請求，更多減小10次http請求對於咱們網絡上傳輸損耗是優化是很是大的。

在業務場景中會有一個標準，小於4kb或者小於8kb的圖片，都會使用構建工具inline進來。

---

css和js的加載與執行

最早拿到html從上到下解析，瀏覽器在解析的過程會發現它會使用其它外部資源，進一步請求外部資源，再對這些外部資源進行解析，從而進行頁面最終的渲染，這是html頁面加載渲染的過程。

css加載生成css樹最終和DOM樹整合成爲RenderTree以後纔會進行頁面渲染，帶有樣式。

HTML渲染過程的一些特色：

1）順序執行，併發加載；

從上倒下詞法分析html標籤狀況進行加載，html中引入cssjs外部資源是併發加載的，這個併發度是受瀏覽器限制的。

2）是否阻塞；

css加載是否阻塞js的加載？css加載是否會阻塞js的執行？css加載是否會阻塞頁面渲染？

3）依賴關係；

4）引入方式；

CSS阻塞（重要）

1）css head中阻塞頁面的渲染；css若是在head中經過link的方式引入，會阻塞頁面渲染。

2）css阻塞js的執行；

3）css不阻塞外部腳本的加載；

js阻塞

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

2）js不阻塞資源的加載；

3）js順序執行，阻塞後續js邏輯的執行；

---

懶加載與預加載

預加載：

---

重繪與迴流

css性能讓javascript變慢？

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

css的核心會影響頁面的樣式展現，渲染流程頻繁觸發，重繪與迴流機制頻繁觸發的話，實際上那麼ui線程會比較頻繁的進行頁面相關的渲染。這個時候再進行渲染的時候，因爲阻塞了JavaScript線程，因此JavaScript腳本代碼沒辦法執行，那麼css會讓頁面一些JavaScript代碼執行變慢。

嘗試優化css寫法和一些性能，從而讓咱們頁面ui線程渲染次數和渲染難度下降，從而加快渲染速度，性能提高。

迴流

1）當render tree中的一部分（或所有）由於元素的規模尺寸，佈局，隱藏等改變而須要從新構建。這就成爲迴流。

2）當頁面佈局和幾何屬性改變時就須要迴流。

重繪

1)當render tree中的一些元素須要更新屬性，而這些屬性只是影響元素的外觀，風格，而不會影響佈局的，好比backgroud-color。則就叫重繪。

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

觸發頁面重佈局的屬性--觸發重繪

只觸發重繪的屬性，不會觸發迴流

---

瀏覽器存儲

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

Cookie

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

cookie的生成方式：

1）http response header 中的set-cookie。

2）js中能夠經過document.cookie能夠經過讀寫cookie

由服務端生成的，由客戶端存儲和維護的。每次請求客戶端都攜帶cookie這個標示到服務端的。

cookie做用：

1）用於瀏覽器端和服務器的交互。

2）客戶端自身數據的存儲。

過時時間expire。

cookie存儲的限制：

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

2）須要設置過時時間expire。

httponly：當前這個cookie不支持js讀寫的，若是這個cookie支持讀寫，可能會有安全隱患。

cookie中在相關域名（Domain）下面-cdn的流量損耗。域名維度下面的概念，只要這個域名下全部請求都會攜帶cookie，並非這個域名下全部請求都須要用cookie。在http-request-header中攜帶cookie。

優化方案：cdn的域名（不攜帶cookie）和主站的域名要分開。cdn域名下存放css、js請求不須要攜帶cookie的，減小流量的損耗。

LocalStorage

1）html5設計出來專門用於瀏覽器存儲的

2）大小爲5m左右

3）盡在客戶端使用，不和服務端進行通訊

4）接口封裝較好

5）瀏覽器本地緩存方案

SessionStorage（會話維度）

1）回話級別的瀏覽器存儲。——瀏覽器的type就是一個回話，chrome標籤關閉後，存儲的數據清空。

2）大小爲5m左右。

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

4）接口封裝較好。

5）對於表單信息的維護。

對SessionStorage方面的優化：

（1）對於想註冊相關頁面，用戶會填寫相關信息，當刷新頁面後信息會丟失，能夠用sessionStorage實時存儲用戶輸入的信息即便用戶刷新頁面數據還在，只有在用戶關閉標籤以後信息纔會消失，提高用戶交互體驗。

（2）另一種狀況就是用戶填寫信息是以分頁形式展現，點擊下一頁填寫信息，也可使用這個方式去存儲相關信息。 sessionStorage去維護一個表單在進行多頁切換的時候數據傳遞能夠存儲。

IndexedDB（瀏覽器端數據庫）

1）IndexedDB是一種低級api，用於客戶端存儲大量結構化數據。該api使用索引來實現對該數據的高性能搜索。雖然web Storage對於存儲較少許的數據頗有用，可是對於存儲大量的結構化數據來講，中方方式不太有用。IndexedDB提供了一個解決方案。

2）爲應用建立離線版本。

相關性能優化的案例：

1）localStorage做爲緩存優化的應用場景：百度是將BMap這個庫js全都存到了localStorage中，包括了css文件，這些文件請求一次就不會改變了。若是僅僅經過服務端緩存機制設置過時時間，終究會有資源浪費。可是存到localstorage中設置不會過時的話，那麼就很是方便。

2）手淘將不少小icon存到localstorage中，或商鋪相關信息等。

---

緩存

httpheader(Response、Request)

Cache-Control

1）max-age:指定緩存最大有效時間

　　

從請求這個資源到max-age這段時間內，瀏覽器再次請求這個資源的時候不會向服務端發起請求的。max-age會讓瀏覽器在請求資源的時候不向服務端發起請求。服務端會告訴瀏覽器在這段時間內，這個資源是有效的不會過時的，瀏覽器會從緩存中直接讀取。

2）s-maxage（返回304）

指定一個緩存的有效時間，只能設置對於public設備（cdn）的緩存，cdn公共緩存區域。

優先級高於max-age，只能去public緩存區域讀取相關信息，不是從瀏覽器拿資源而是去cdn上讀取，返回304狀態及資源。s-maxage的意義是對於cdn公共的區域在s-maxage設置的過時時間以內緩存是不會過時的，超過這個時間纔回去原服務器（cdn）更新資源。

3）private：私人緩存設備，當前用戶本身訪問的緩存，用戶在瀏覽器緩存的信息，只有當前用戶使用。

4）public：

好比cdn緩存設備，能被不少用戶訪問讀取信息的。

5）no-cache：

搭配max-age=0使用，當前文件都會向瀏覽器發起請求詢問當前文件是否在緩存策略中過時，不會不發請求直接向瀏覽器緩存讀。先發請求到服務端根據返回信息判斷瀏覽器端緩存是否過時。

6）no-store：

不適用緩存策略。

Expires

1）緩存過時時間，用來指定資源到期的時間，是服務器端的具體的時間點。

2）告訴瀏覽器在過時時間前瀏覽器能夠直接從瀏覽器存取數據，而無需再次請求。

max-age優先級高於expires的，強的瀏覽器端緩存，屬性生效不會觸發向服務端發起請求的過程，直接在瀏覽器中讀取相應緩存數據，在瀏覽器層面控制。那麼服務端某資源發生變化，瀏覽器端是沒法感知的，由於瀏覽器直接從瀏覽器端緩存中讀取資源。

Last-Modified/IF-Modified-Since

1）基於客戶端和服務端協商的緩存機制。

2）last-modified---response header。

3）if-modified-since---request header。

4)須要與cache-control共同使用。

當從客戶端發起請求到服務端，服務端會在response-header中帶Last-Modified，客戶端會將資源存到緩存區域當中，Last-Modified做爲一個標識。那麼每次客戶端在請求這個資源時，會在Request-Headers中帶if-modified-since這個字段，告訴服務端這個時間點。那麼客戶端在這個時間點過時以後，若是這個資源沒有更新返回304狀態以及Last-Modified情況；若是有更新，則返回最新Last-Modified的時間點及200狀態碼。

但last-modified有什麼缺點？

1.某些服務器不能獲取精確的修改時間

2.文件修改時間改了，但文件內容卻沒有變。

Etag/If-None-Match

1）文件內容的hash值

2）etag-response header

3）if-none-match-request header

4）須要與cache-control共同使用

當文件內容改變，這個哈希值會改變，更加精確。