本文一共分為兩篇。閱讀第 2 部分。
幾年前我們只是單純的考慮，「減少請求數量」，使頁面載入速度更快。雖然這是乙個合理化的建議，但實際上，我們還可以通過合理的分配資源的請求數，來達到我們的目的。
不。不幸的是，base64編碼資源是一種非常反面的教材1。在這篇文章中，我會分享一些關於關鍵路徑優化，gzip，當然，還有對於base64編碼的看法。
我寫這篇文章的動機是因為我剛好為客戶做乙個效能審計，我遇到了我描述的問題。這是來自實際客戶端的實際樣式表：示例是匿名的，但這是乙個完全真實的專案。
寫這篇文章的起因是，我最近正在為客戶開發乙個效能檢測，正好遇到了這個問題。這是乙個匿名的真實案例。
我開啟了乙個網頁，檢視了網路配置， 發現了乙個css檔案(因為我們不想看到12個樣式表的請求鏈結，所以通常會統一到乙個檔案中)，在不壓縮的情況下，竟然達到了925k。線上的檔案位元組數大大減少，還是接近232k大小。
樣式表檔案竟然這麼大？我其實都不用看，也知道裡面一定有一些base64編碼格式。我不是說檔案大一定是因為base64的原因（可能是因為外掛程式，**組織混亂，歷史原因等），但檔案大通常都是因為base64。
不管是不是base64,925k的css都是驚人的。
壓縮後也只是減少到759k
gzipping 使得降到232k。相同的**，減少了將近693k。
232k 對於線上檔案來說，還是很大。
直勾勾的盯了螢幕88ms，只是為了解析那個大小的樣式檔案。
讓它通過網路載入，才是我們遇到的問題。
我美化了檔案2，儲存到本地，執行了csso，然後通過 gzip 執行它定時輸出的常規設定。如下：
接下來要做的是看看這些位元組中有多少是來自 base64 編碼檔案。為了解決這個問題，我簡單地（粗略地）刪除了包含data:字串的所有行 / 宣告（對於 vim 使用者來說是:g/data:/d33）。base64 編碼大部分用於影象 / 精靈和幾種字型。然後我將這個檔案儲存為no-base64.css，並做了相同的縮小，和gzip 壓縮：
在我們未壓縮的 css 中，消失了整整217k的 base64。仍然是很大的 css量（708k 是相當不方便），但我們已經想辦法擺脫了23.45％的**。
接下來真正讓我們驚訝的是，gzip壓縮後，我們的線上**從 708k 降到了 68k! 哇，這節省了 90.39%！
但是，這是 gzip 的非 base64 編碼版本。我們看看原始的 css（使用 base64 編碼的 css），我們發現我們只節省了 74.91％。
base64
毛尺寸壓縮大小儲存是
925k
232k
74.91％
沒有708k
68k90.39％
兩個檔案之間的差異是大概在 164k（70.68％）。我們可以通過將這些資源移動到更合適的地方，減少 164k 的 css。
base64 壓縮非常不好。下次有人嘗試，可以告訴他們gzip這點（如果他們試圖證明 base64更好）。
好吧，所以我們很清楚，現在 base64 增加檔案大小的方式，gzip 無法真正幫助我們，但這只是問題的一小部分。我們為什麼這麼害怕檔案大小的增加？單個影象可能大小就超過 232k，所以我們是不是從那裡開始研究更好？
不錯的問題，我很高興你提到了影象…
為了理解 base64 是多麼糟糕，我們首先需要了解好的 影象是什麼。爭議點：影象不像你認為的效能那麼差。
確實，影象是乙個問題。事實上，他們是頁面膨脹的第一貢獻者。截至 2016 年 12 月 2 日，佔平均網頁的 1623k（約 65.46％）。這使得232k 樣式表如滄海一粟。但是，瀏覽器處理和樣式表的方式有著根本區別：
瀏覽器渲染頁面，不會等待載入完成，甚至說，載入失敗，頁面也會渲染。不是關鍵資源，即使很大，也沒有關係。
另一方面，css 是乙個關鍵資源。在構建渲染樹之前，瀏覽器無法開始渲染頁面。瀏覽器在構造 cssom 之前不能構造渲染樹。在樣式表沒有解壓，解析，載入完成之前，他們不能構造 cssom。css 是瓶頸。
現在你應該可以明白為什麼我們這麼害怕的 css 位元組數：他們延遲了頁面渲染，展示給使用者乙個空白網頁。希望你現在可以意識到把 base64 編碼影象加到你的 css 檔案中是多麼的諷刺：你只是把數百千位元組的非阻塞資源轉換為阻塞資源去追求效能。原本不需要這些資源載入完畢，就可以展示頁面，但現在他們被迫走上了關鍵資源的道路。這並不意味著影象更早到達; 而是意味著關鍵資源 css 要稍後到達。真的這麼糟糕嗎？
恩，是的。
瀏覽器是很聰明的。真的很聰明。他為我們做了很多效能優化，他們知道如何更好（多總比沒有好）。下面我們看下響應式：
.masthead
@media screen and (min-width: 45em)
}@media screen and (min-width: 80em)
}
@media only screen and (-moz
-min
-device
-pixel
-ratio: 2),
only screen and (-o
-min
-device
-pixel
-ratio:2/1),
only screen and (-webkit
-min
-device
-pixel
-ratio:2),
only screen and (min
-device
-pixel
-ratio:2),
only screen and (min
-resolution:2***x),
only screen and (min
-resolution:192dpi)
.sprite.weather
.menu-icons
}
為了解決這個問題，人們開始用 base64 將他們的字型內嵌到樣式表：如果 css 和字型完全同時到達，那麼就不會出現 foit 或 fout，因為 cssom 的渲染和字型幾乎同時開始。
和上面的一樣，字型移到關鍵路徑，不會加快他們的交付，延遲了您的 css。有一些非常聰明的字型載入解決方案, 但 base64 不是其中之一。
base64 編碼意味著我們不能根據它們的更新頻率單獨地快取檔案，意味著無論什麼時候有更改，都要重新快取不相干的檔案。這太浪費資源了。
基本分離的關注點：字型的快取不應該依賴於影象快取，不應該依賴於樣式的快取。
好吧，讓我們快速回顧一下：
總而言之，這是乙個非常不好的情況：請避免 base64。
所有這篇文章所寫的都是我目前已知的東西。我沒有用任何資料去進行測試：只是展示了瀏覽器的工作方式。接下來，我決定去做一些測試，用事實和資料說話。轉到第 2 部分閱讀更多。
在 chrome 的 「 ** 」 標籤中開啟樣式表，然後按下{}檔案左下角的圖示即可。 ↩
在 chrome 的 「 ** 」 標籤中開啟樣式表，然後按下{}檔案左下角的圖示即可。 ↩
(:g) 表示全域性命令查詢包含data:（/data:）和刪除（/d）。 ↩
Base64 編碼和效能，第 2 部分
這是這篇文章的第 2 部分。閱讀第 1 部分。在樣式表中插入 base64 編碼的內容資源 主要是 引起爭議之後，我決定收集一些資料。我做了乙個簡單的測試，針對 傳統 方式和 base64 方式，資源載入的時間進行對比。建立兩個簡單的 html 檔案，用一張背景影象鋪滿整個頁面。第乙個使用常規編寫方...
base64編碼和解碼
base64是一種任意二進位製到文字字串的編碼方法，基於64個可列印字元來表示二進位制資料的方法。簡述base64編碼就是從二進位制到字元的過程。採用base64編碼具有不可讀性，需要解碼後才能閱讀。標準的base64並不適合直接放在url裡傳輸，因為url編碼器會把標準base64中的 和 字元變...
C 實現base64編碼 1
下面的 是php裡面的base64編碼邏輯，確實比我之前的要美觀很多，我只是簡單的用c 的類進行了一下封裝，刪除了一些沒用的邏輯，基本上還是原來php的 include include include using namespace std class base64 unsigned char ba...