前端性能優化（九）

時間 2019-11-12

原文原文鏈接

優化基於文本的資產的編碼和傳輸大小

咱們的網絡應用在範圍、目標和功能上都在不斷增加。這是件好事！可是向着更豐富的網絡無情進軍的過程也推進了另外一種趨勢：每一個應用所需下載的數據量也在持續穩步增加。爲了提供卓越的性能，咱們須要優化每個字節數據的交付！html

數據壓縮 101

在咱們消除了任何沒必要要的資源以後，下一步就是將瀏覽器必須下載的剩餘資源的總大小減至最小，即，對其進行壓縮。根據資源類型（文本、圖片、字體等），咱們有許多不一樣的技術供咱們使用：能夠在服務器上啓用的通用工具，適用於特定內容類型的預處理優化，以及須要開發人員輸入的特定於資源的優化。算法

要實現最佳的性能須要結合全部這些技術。瀏覽器

減少數據大小的過程稱爲’數據壓縮’，而這自己就是一個須要深刻研究的領域：許多人終其一輩子致力於算法、技術和優化以提升各類壓縮工具的壓縮比率、速度和內存要求。勿需多言，對本主題進行全面討論超出了咱們的範圍，可是，在一個較高的水平上了解壓縮的工做方式以及用於減少網頁所需的各類資源的大小所能使用的技術，這還是很重要的。服務器

爲了說明這些要推廣的技術的核心原則，讓咱們看看如何可以優化一個簡單的短信格式（此格式僅僅是咱們爲此示例所編造的）：網絡




# 下面是一條祕密消息，它由一組標題組成
# 這組標題採用後面跟着一個新行和加密消息的鍵-值格式。
format: secret-cipher
date: 04/04/14
AAAZZBBBBEEEMMM EEETTTAAA

消息可能會包含任意註釋，這些註釋帶有’#’前綴。註釋不影響消息的含義或消息的任何其餘行爲。
消息可能會包含’標題’，這些標題是一些鍵-值對（用’:’分隔），且必須出如今消息的開頭。
消息帶有文本載荷。

咱們能作些什麼來減少上述消息的大小（這條消息的長度目前爲 200 個字符）？工具

嗯，註釋頗有趣，但咱們知道它並不實際影響消息的含義，所以咱們在傳送消息時會清除註釋。
可能會有一些可用於以一種有效的方式對標題進行編碼的智能技術，例如，咱們不知道是否全部消息始終都有’格式’和’日期’，但若是有，咱們能夠將它們轉換爲短整 ID 並僅發送這些 ID！這就是說，咱們不確信是不是這種狀況，所以咱們如今先不去管它。
載荷是僅文本，而咱們不知道其內容真正是什麼（很明顯，載荷使用一種’祕密消息’），只是看看文本，看起來在其中存在許多冗餘。也許，不發送重複的字母，咱們能夠僅對重複字母的數量進行計數，並更有效地對其進行編碼，是這樣嗎？

例如，’AAA’變爲’3A’，或者三個 A 的序列。

結合咱們的技術，咱們實現了下面的結果：性能

format: secret-cipher
date: 04/04/14
3A2Z4B3E3M 3E3T3A

新消息的長度爲 56 個字符，這意味着咱們勉強作到將咱們的原始消息壓縮達到了可觀的 72% - 這個結果不壞，總而言之，咱們僅僅開了個頭！字體

固然，您也許會懷疑，這已經很是好了，但這如何能幫助咱們優化咱們的網頁呢？無疑，咱們不打算嘗試編造咱們的壓縮算法，不是嗎？答案是不打算，咱們不會，但正像您將看到的那樣，優化咱們網頁上的各類資源時，咱們將使用幾乎相同的技術和思考方式：預處理，特定於內容的優化，以及不一樣的內容採用不一樣的算法。優化

源碼壓縮：預處理和特定於內容的優化

壓縮冗餘或沒必要要的數據的最佳方式是所有消除它。固然，咱們不能只是刪除任意數據，但在某些狀況下，咱們可能會有數據格式及其屬性的特定於內容的知識，這時常常有可能顯著減少載荷的大小而不影響其實際含義。網站

    <html>
      <head>
      <style>
         /* awesome-container is only used on the landing page */
         .awesome-container { font-size: 120% }
         .awesome-container { width: 50% }
      </style>
     </head>
    
     <body>
       <!-- awesome container content: START -->
        <div>…</div>
       <!-- awesome container content: END -->
       <script>
         awesomeAnalytics(); // beacon conversion metrics
       </script>
     </body>
    </html>

考慮以上的簡單 HTML 網頁和它所包含的三種不一樣的內容類型：HTML 標記、CSS 樣式和 JavaScript。其中每種內容類型針對構成有效 HTML 標記、CSS 規則和 JavaScript 內容的元素都有不一樣的規則，有用於指示註釋的不一樣規則，等等。咱們如何能夠減少此網頁的大小？

代碼註釋是開發人員的最好朋友，但瀏覽器不須要看到它們! 簡單地除去 CSS (/* ... */)、HTML () 和 JavaScript (// ...) 註釋能夠顯著減少網頁的總大小。
‘智能’CSS 壓縮工具能夠察覺到咱們正在使用一種無效方式爲.awesome-container定義規則，並將兩個聲明摺疊爲一個而不影響任何其餘樣式，節省更多字節。
在 HTML、CSS 和 JavaScript 中，白空（空格和製表符）僅僅是爲了開發人員方便。有一種附加的壓縮工具能夠去掉全部製表符和空格。

    <html><head><style>.awesome-container{font-size:120%;width: 50%}
    </style></head><body><div>…</div><script>awesomeAnalytics();
    </script></body></html>

在應用上述步驟以後，咱們的網頁從 406 個字符變爲 150 個字符 - 達到 63% 的壓縮節省！確實，其可讀性不是很好，但也並不是必須這樣：咱們能夠保留原始網頁做爲咱們的’開發版本’，而後並在咱們準備好在咱們的網站上發佈該網頁時再應用上述步驟。

退一步說，上述示例代表很重要的一點是：一個常規用途壓縮工具（意即一個旨在壓縮任意文本的壓縮工具）也可能會很好地壓縮上述網頁，但它歷來不會知道除去註釋，摺疊 CSS 規則，或進行許多其餘特定於內容的優化。這就是預處理/源碼壓縮/上下文感知優化能夠是如此強大的一個工具的緣由所在。

一樣地，能夠將上述技術擴展到超越僅基於文本的資產。圖片、視頻和其餘內容類型都包含它們本身的元數據形式和各類載荷。例如，任什麼時候候使用相機拍攝照片，照片一般也會嵌入許多額外的信息：相機設置、位置等。根據您的應用，此數據可能會很重要（例如，一個照片共享網站），或者徹底無用，您應該考慮是否應刪除它。實際上，對於每張圖片，此元數據加起來能夠達到數十 KB！

簡而言之，做爲優化您的資產效率的第一步，請構建不一樣內容類型的資源，並考慮您能夠應用哪些種類的特定於內容的優化以減少其大小，這樣作能夠產生顯著的節省！而後，在您肯定它們是什麼以後，請當即經過將其添加到您的內部版本和發行版本流程來自動執行這些優化 - 這是您能夠保證優化將保持原樣的惟一方式。

使用 GZIP 進行文本壓縮

GZIP 是一種能夠應用於任何字節流的通用壓縮工具：啓動以後，該工具會記住其中一些先前看到的內容並嘗試以一種有效的方式查找並替換重複的數據片斷 - 好奇的用戶能夠查閱 [GZIP 的出色的低層次解釋] (https://www.youtube.com/watch?v=whGwm0Lky2s&feature=youtu.be&t=14m11s)。可是，實際上，GZIP 對基於文本的內容壓縮效果最好，對於較大的文件，一般會達到高達 70-90% 的壓縮率，而經過其餘替代算法對已壓縮過的資產（例如，大多數圖片格式）運行 GZIP 則收效甚微，甚至沒有任何提升。

全部現代瀏覽器都支持並自動商定將 GZIP 壓縮用於全部 HTTP 請求：咱們的工做是確保服務器獲得正確配置，以在客戶端請求時提供壓縮的資源。

查看要推廣的 GZIP 最快速、簡單的方法是打開 Chrome DevTools 並檢查’網絡’面板中的’大小/ 內容’列：’大小’指示資產的傳輸大小，而’內容’指示資產的未壓縮大小。對於上述示例中的 HTML 資產，GZIP 在傳輸過程當中節省了 24.8 KB！