前端性能優化：客戶端從輸入到展現講解

性能優化的根本目的：
　　要思考的是用戶使用網站的體驗如何，而不是咱們能夠節省多少字節，只有準確感知用戶的感覺，咱們纔有必要談毫秒、字節和請求數量等問題。

針對優化注意事項：

• 防止過早優化：不必在剛開始階段就對一個細節進行放大型的優化，由於這樣的成本很高，除了代碼可讀性方面的東西，甚至還可能會引入更多的bug，因此，針對這個問題，咱們能夠在上線和運營的時候進行監控，當快暴露到問題的時候，進行總體優化。
• 本末倒置的關注：網站內容是最重要的，應該查看頁面的每一個部分，看是否知足網站頁面的主要目的，暫時不須要將額外的注意力所有放到一些不關乎本質的東西上。

對於性能的分析：

• 使用瀏覽器的性能分析工具，獲得性能分析圖表，最著名的就是反向火焰圖表，針對瀏覽器的加載和渲染一目瞭然。
• 投入使用以前缺少壓力測試和性能測試

 

性能優化（從用戶輸入網址到客戶端展示，一步一步優化）
　　1.   輸入網址 　　　　　　 　　 ==> 告訴瀏覽器你要去哪裏

　　2.   瀏覽器查找DNS 　　　 　　 ==> 網絡世界是IP地址的世界，DNS就是ip地址的別名。從本地DNS到最頂級DNS一步一步的網上爬，直到命中須要訪問的IP地址
　　　　a.   DNS預解析 使用CDN緩存，加快解析CDN尋找到目標地址（dns-prefetch）

 

　　3. 客戶端和服務器創建鏈接　　 ==>創建TCP的安全通道，3次握手
　　　　a.  CDN加速 使用內容分發網絡，讓用戶更快的獲取到所要內容
　　　　b.  啓用壓縮 在http協議中，使用相似Gzip壓縮的方案（對服務器資源不足的時候進行權衡）
　　　　c.  使用HTTP/2協議 http2.0針對1.0優化了不少東西，包括異步鏈接複用，頭壓縮等等，使傳輸更快

 

　　4.  瀏覽器發送http請求　　　　  ==> 默認長鏈接（複用一個tcp通道，短鏈接：每次鏈接完就銷燬）
　　　　a.  減小http請求 每一個請求從建立到銷燬都會消耗不少資源和時間，減小請求就能夠相對來講更快展現內容
　　　　　　1).  壓縮合並js文件以及css文件
　　　　　　2).  針對圖片，可將圖片進行合併而後下載，經過css Sprites切割展現（控制大小，太大的話反而拔苗助長）
　　　　b.  使用http緩存 緩存原則：越多越好，越久越好。讓客戶端發送更少請求，直接從本地獲取，加快性能。
　　　　c.  減小cookie請求 針對非必要數據（靜態資源）請求，進行跨域隔離，減小傳輸內容大小。
　　　　d.  預加載請求 針對一些業務中場景可預加載的內容，提早加載，在以後的用戶操做中更少的請求，更快的響應
　　　　e.  選擇get和post 在http定義的時候，get本質上就是獲取數據，post是發送數據的。get能夠在一個TCP報文完成請求，可是post先發header，再發送數據。so，考慮好請求選型。
　　　　f.   緩存方案選型 遞進式緩存更新（防止一次性丟失大量緩存，致使負載驟多）

 

　　5.  服務器響應請求 　　　　　　 ==> tomcat、IIS等服務器經過本地映射文件關係找到地址或者經過數據庫查找到數據，處理完成返回給瀏覽器
　　　　a.  後端框架選型 　　 \
　　　　　　　　　　　　　　 ==> 更快的響應，前端更快的操做。
　　　　b.  數據庫選型和優化 /

 

　　6.  瀏覽器接受響應 ==> 瀏覽器根據報文頭裏面的數據進行不一樣的響應處理
　　　　a.  解耦第三方依賴 越多的第三方的不肯定因素，會致使web的不穩定性和不肯定性
　　　　b.  避免404資源 請求資源不到浪費了從請求到接受的全部資源

 

　　7.  瀏覽器渲染順序 ==> a.HTML解析開始構建dom樹
　　　　b. 外部腳本和樣式表加載完畢
　　　　　　a).  儘快加載css，首先將CSSOM對象渲染出來，而後進行頁面渲染，不然致使頁面閃屏，用戶體驗差
　　　　　　b).  css選擇器是從右往左解析的，so相似#test a {color: #444},css解析器會查找全部a標籤的祖先節點，因此效率不是那麼高
　　　　　　c).  在css的媒介查詢中，最好不要直接和任何css規則直接相關。最好寫到link標籤中，告訴瀏覽器，只有在這個媒介下，加載指定這個css
　　　　c. 腳本在文檔內解析並執行
　　　　　　a）.  按需加載腳本，例如如今的webpack就能夠打包和按需加載js腳本
　　　　　　b）.  將腳本標記爲異步，不阻塞頁面渲染，得到最佳啓動，保證無關主要的腳本不會阻塞頁
　　　　　　c). 慎重選型框架和類庫，避免只是用類庫和框架的一個功能或者函數，而引用整個文件。
　　　　d. HTML DOM徹底構造起來
　　　　　　a).  DOM 的多個讀操做（或多個寫操做），應該放在一塊兒。原則：統一讀、統一寫。
　　　　e. 圖片和外部內容加載
　　　　　　a).  對多媒體內容進行適當優化，包括恰當使用文件格式，文件處理、漸進式渲染等
　　　　　　b).  避免空的src，空的src仍然會發送請求到服務器
　　　　　　c).  避免在html內容中縮放圖片，若是你須要使用小圖，則直接使用小圖
　　　　f. 網頁完成加載
　　　　　　a).  服務端渲染，特別針對首屏加載很重要的網站，能夠考慮這個方案。後端渲染結束，前端接管展現。

 

　　　　a） 針對首屏展現優化

　　　　　　1).  圖片懶加載 針對展現只加載第一屏，等用戶進行滾動的時候再進行加載。若是用戶對下面內容不感興趣，那麼節省的請求。

　　　　　　2).  瀏覽器本地緩存模塊   能夠經過按模塊去劃分，將頁面的模塊緩存到localStory中，每次請求覈對模塊版本號，丟失或者版本不一致從新請求，不然直接從本地拿（參考京東）

　　　　b） javascript優化
　　　　　　1).  減小對dom節點的查詢，由於每次都會從新去索引這個集合或者元素。或者查詢一次緩存起來，以待接下來使用
　　　　　　2).  進行js操做DOM的時候，考慮清楚頁面的重繪和重排，由於這些操做相對來講十分損耗性能的。
　　　　　　3).  避免使用eval和Function構造，由於解析器會將這些內容先轉換成可執行代碼，而後再進行接下去的操做。
　　　　　　4).  減小做用域鏈的查找，若是一個閉包函數使用到全局做用域的數據，那麼每次局部做用域都會一層一層爬到最高做用域取得數據。
　　　　　　5).  數據訪問，對非引用類型數據訪問和局部變量的訪問是最快的。因此若是對引用類型的成員（對象的屬性或者數組的成員）訪問超過一次，則緩存
　　　　　　6).  將前端可能會使用的一些算法函數寫的更優化，在時間和空間複雜度上尋找到一個最優方案。
　　　　　　7).  去除重複加載同一模塊腳本
　　　　　　8).  智能事件處理，好比在一個div下有10個按鈕，能夠在冒泡過程當中捕獲這個事件源，而後註冊

　　　　c）  css優化
　　　　　　1).  刪除無用規則
　　　　　　2).  內聯關鍵CSS
　　　　　　3).  避免@imports和Base64
　　　　　　4).  啓用高性價比屬性(如opacity over rgba())
　　　　　　5).  避免重複性工做
　　　　　　6).  不要一條條地改變樣式，而要經過改變class，或者csstext屬性，一次性地改變樣式。
　　　　　　7).  可將元素設爲display: none（須要1次重排和重繪），而後N次操做，最後恢復顯示
　　　　　　8).  position屬性爲absolute或fixed的元素，重排的開銷會比較小，由於不用考慮它對其餘元素的影響。

　　　　d）  圖片優化（網絡請求中80%都是靜態資源的請求）
　　　　　　1).  圖片正確格式的選擇
　　　　　　2).  圖片尺寸的選擇，在低分辨率等情況下考慮降級處理（考慮響應式圖片）
　　　　　　3).  使用正確的工具進行優化（有損壓縮、無損壓縮）
　　　　　　4).  能用css處理和代理的，優先考慮css實現（陰影，濾鏡等）
　　　　　　5).  正確使用data url，好比說多地使用的地方，不建議data url，可考慮緩存
　　　　　　6).  考慮圖片的懶加載和元素可見加載方案
　　　　　　7).  圖片的預加載，在正確的合理的設計節點進行圖片的預加載

全部性能優化總結爲三個層面優化：物理層面的優化，設計層面的優化，代碼層面的優化

注：設計層優化最主要的核心：衡量如何花費最少代價實現頁面功能
注：HTTP/2（超文本傳輸協議第2版，最初命名爲HTTP 2.0），是HTTP協議的的第二個主要版本，HTTP/2的目標包括異步鏈接複用，頭壓縮和請求反饋管線化並保留與HTTP 1.1的徹底語義兼容。Google Chrome、Mozilla Firefox、Microsoft Edge和Opera已支持HTTP/2，並默認啓用。Internet Explorer自IE 11開始支持HTTP/2，但僅限於Windows 10 Beta，並默認狀況激活。

 

github地址：https://github.com/GerryIsWarrior/optimization　　　鄙人厚顏無恥要顆星，這樣纔有動力持續更新

問題補充路徑：

　　1. 博客留言

　　2. gerry.zhong@outlook.com

　　3.github留言