前端開發中，使用base64圖片的弊端是什麼？

01-03

弊端主要不在於 base64 編碼後比原圖要大，

而是因為如果把大圖片編碼到 html / css 中，會造成後者體積明顯增加，明顯影響網頁的打開速度。

如果用外鏈圖片的話，圖片可以在頁面渲染完成後繼續載入，不會造成阻塞。

如果 base64 是被編碼到 css/js 中，是可以緩存的，因為 css/js 文件可以緩存。

使用 base64 的另外一個弊端是 IE 的兼容性問題。IE 8 以下不支持 data url，IE 8 開始支持 data url，卻有大小限制，32k（未測試）。

還有一個問題是，如果構建工具比較落後（或者沒有構建工具），手動插入 base64 是很蛋疼的，編輯器會卡到哭。

--------------------------------------

下面是我對 base64 + gzip 後文件體積做的實驗：

圖片信息：JPEG，質量 60%，1000*667，221 KB.

首先使用 base64 命令編碼：

base64 IMGTEST.jpg &> IMGTEST.jpg.txt

得到 txt 文件大小：294 KB

再使用 gzip 壓縮：

gzip IMGTEST.jpg.txt

得到 IMGTEST.jpg.txt.gz 文件大小：222 KB

直接 gzip 壓縮原圖：

gzip IMGTEST.jpg

得到 IMGTEST2.jpg.gz 文件大小：220 KB

基本如 @Lu Zheng 的答案，base64 文本文件相比原文件而言，大了一些 (1/3)，而經過 gzip 後兩者幾乎沒有區別。

測試用圖：

我又要來安利 webpack 了：url-loader 可以自動根據文件大小決定要不要做成內聯 base64 webpack/url-loader · GitHub

使用base64一般會比原圖要大一些，比較適合用於小圖標，大一點的圖片就免了…

大

不能緩存，除非緩存整個頁面。

個人覺得弊端包括以下幾點：

根據 base64 的編碼原理，大小比原文件大小大 1/3
儘管圖片請求少了，但是 HTML 文件本身尺寸會變大，會影響首屏載入，所以要權衡
代碼看起來會有點丑，大量編碼字元（當然也可以通過構建工具動態插入）
base64 無法緩存，要緩存只能緩存包含 base64 的文件，比如 HTML 或者 CSS，這相比直接緩存圖片要弱很多，一般 HTM 會改動頻繁，所以等同於得不到緩存效益

如果想要了解 base64 編碼原理的，可以關注「jscourse」公眾號並回復「base64」，一篇通俗易懂地講解 base64 編碼原理的內容就會給你，幫助你理解 base64 內部的機制，以及為什麼編碼後尺寸會變大。

利益相關：這篇內容是我做的，目的就是解決我自己的困惑，同時分享出來幫助到和我一樣有疑問的人！

BASE64 搞出來的圖片通常尺寸會大上 30% 左右。

然而我認為這不是致命傷，用 BASE64 來傳輸圖片最大的問題是，你之所以會這麼用是因為你想以字元串來傳輸二進位。

這個影響是很大的，尤其是你把它包進個什麼 JSON 或者 XML 或者什麼東西里。由於變成了需要解析的字元串對後端的壓力會陡增，你可以明顯看到處理速度的顯著下滑。

以及你還需要去調 nginx 配置文件以避免 nginx 覺得你字元串過長直接把包 Entity Too Large 拒掉。

base64編碼使用八比特表示六比特的內容，因此會打一些，4/3，但是網頁一版都有gzip壓縮，所以不會大太多，5%以內吧（沒測過，等普及知識被打臉）。不能緩存這點技術可以解決。

"如果 base64 是被編碼到 css/js 中，是可以緩存的，因為 css/js 文件可以緩存",圖片本身就可以緩存啊？

maven打包用yui壓縮時個別圖像會報錯

弊端在於渲染解析效率

編輯器卡死，插入，修改，預覽都沒直接用圖片方便。

低版本IE不兼容，大圖片渲染解析得比較慢，適用於小圖片

瀏覽器在decode base64的圖片時會非常慢,可以用canvas硬體加速方案【前端】載入的圖片太多或者太大怎麼辦(上)