JavaScript效能最佳化

標籤：省份   互動   事件委託   表資料   負載   需要   sel   服務   換行   

所謂效能最直觀的感覺就是網站在互動的時候響應的速度，也就是一次請求響應周期所花費的時間，這個時間和很多因素有關係

請求發出前：

總體原則：在用戶端應該盡量減少請求發送的數量
第一例：訂單列表中點擊刪除按鈕刪除某條訂單，可以做成點擊時發送ajax給伺服器，用戶端收到響應後直接重新整理頁面，也可以做成在用戶端收到相應後刪除訂單列表DOM中的對應項，後一種方案明顯請求數量少於前一種，效能較好，但對於開發人員要求高，而且有可能由於訂單列表資料的變化可能會導致頁面上其他位置也需要變化，例如訂單總數，但是前端帶有的資料繫結功能的架構幫我們解決了這一問題

第二例：單頁面應用中首屏通常載入很多script標籤，每個script裡面都有一個src，頁面中的圖片也有src，還有每個link標籤都有href，每個src或href就是一個請求，這樣請求數量明顯很多，因此將很多script標籤合并在一起即可減少請求數，從而最佳化效能，進一步的，在發送請求時代碼壓縮與不壓縮明顯佔用的http請求報文的空間不一樣，因此壓縮代碼可以進一步最佳化效能，圖片是同樣的道理，將所有的圖片合成一張圖只發一次請求即可。有時所有的檔案合并在一起回非常大，因此還會考慮按需載入的需求

第三例：省市聯動如果以前端的角度來看，頁面載入完之後可以再發送一個擷取所有省份的ajax，然後在選擇某個省之後在用這個省的id去擷取該省對應的所有的市，但是從請求次數的角度來看，在後台返回html頁面的同時將省份的資料同時帶過來顯然是更好的方式

請求過程中：

從源主機到目標主機，資料幀需要根據路由演算法經過多跳路由器最終抵達，我們希望儘可能減少經過的跳數，因此出現了將靜態檔案部署到CDN上，使用戶端直接存取離自己最近的主機上的資源

請求發出後：

此處主要效能關鍵點在於伺服器處理的過程

首先負載平衡伺服器將會對請求轉寄到不同的web伺服器中分別處理，轉寄的演算法（例如輪尋）對於效能也有一定影響

最為主要的效能瓶頸在於與資料庫伺服器再次建立串連並在資料庫中進行查詢時所消耗（據悉like模糊查詢效能極差）

響應過程中：

與上述請求過程中的效能分析一致，不再贅述

響應收到後：

DOM操作極為昂貴，因此應該盡量減少DOM操作

-- CSS效能最佳化問題 --1. 載入方面   1）慎用 @import：import 會使我們的 link 樣式由原本的並發載入，變成非同步載入；   2）壓縮代碼體積：      a. 壓縮代碼，刪除換行，多餘的空格和注釋；      b. 合并重複代碼，提高代碼的通用性；      c. 精簡包含選擇符，在使用包含選擇的時候，盡量精簡層級；      d. 能使用複合樣式時，盡量使用複合樣式；      e. 多利用繼承，來精簡樣式；2. 最佳化請求   1）使用 css 精靈，減少圖片個數和體積；   2）合理合并檔案，精簡外部檔案個數；   3）對於不需要重複使用的圖片，可適當使用 data Uri；   4）在設計統一的情況下，可使用 FontIcon 的方法，來統一整合頁面上的圖片；3. 渲染方面   1）涉及動畫方面，盡量可以使用位移來解決，努力減少迴流；   2）涉及動畫方面，可以利用 3D，來進行 GPU 加速；   3）避免使用 table，為了減少迴流；   4）避免 text-shadow 和 box-shadow 層級過多；   5）減少浮動和絕對位置的濫用；   6）不濫用 WEB 字型，在部分瀏覽器下會造成渲染阻塞；

-- JS 最佳化問題 --1. 最小化 DOM 訪問次數，儘可能在 JS 端執行；2. 如果需要多次訪問某個 DOM 節點，請使用局部變數儲存對它的引用；3. 小心處理 HTML 集合，因為它即時連繫著底層的文檔，把集合的長度緩衝到一個變數中，並在迭代中使用它，如果需要經常操作集合，建議把它拷貝到一個數組中；4. 如果可能的話，使用速度更快的 API，比如 querySelectorAll 和 firstElementChild；5. 要留意重繪和重排，批量修改樣式時，“離線”操作 DOM 樹。使用緩衝，並減少訪問布局的次數；6. 使用事件委託來減少事件處理器的數量；7. 避免多次訪問對象成員或函數中的全域變數，盡量將它們賦值給局部變數以緩衝；8. 能用 CSS 解決的問題，盡量不用 JS 去解決；

JavaScript效能最佳化