前端开发中，使用base64图片的弊端是什么？ 第1页

阻塞加载

在下面这样的html文件中

前面的
src="data:image/png;base64,xxx"
后面的

我们都知道，html是流式下载的，或者说浏览器加载所有文件其实都是从前往后单线程流式下载的

这种流式下载意味着前面的没加载完，我不可能先加载后面的

假设base64编码后的字符串长度为256kb，用户的网速为每个连接32kb/s，而除去这个字符串外html大小仅为32kb，其中图片前后各16kb

那么不考虑其他资源加载的情况下，用户会先在半秒后看到这个图片上面的内容，然后花费8秒加载图片，再在半秒后看到完整的网页

而如果使用外链图片，用户会在1秒后看到没有图片的网页，并且在第8.5秒时就看到了图片（而不是9秒，随着html边下载边解析，解析到图片就已经开始下载图片了）

这个简单的例子还看不出多大的差距

我们不妨再考虑的更极端一些

假设在图片之后，body结束之前，有一个256k的外部的界面相关js脚本

如果使用base64编码，那么直到9秒后，js脚本才开始加载，又过了8秒，js脚本加载完成了，用户才看到了完整的应有的界面

如果图片也使用外链，那么在一秒之内，图片和js都已经开始加载了，只需要再过8秒，也就是总计用时9秒，用户就看到了完整的网页

以及如果你正在使用全站CDN，比如cloudflare，默认对html是不缓存的，但却缓存图片。如果使用base64，会消耗更多的回源流量，并降低加载速度

那么有没有办法解决这个问题呢？其实是有的

我们可以把base64图片放在js里，使用异步加载js的办法尽可能减少首屏时间

同时因为js可以被CDN缓存，也不会增加回源流量

之所以使用base64，优势在于可以发起更少的http下载请求，在文件较小的情况下可以通过减少握手延迟而加快加载速度

这里给出了一个我全部使用base64加载按钮图标的案例

base64放在js里并完全异步加载，首屏只需要一个1.5k的html和一个1.6k的css，brotli压缩后首屏请求仅不到2k，尽可能最快速度渲染首屏，每次访问CDN仅回源1.5k（不过因为现在使用cloudflare pages托管，可以视为完全不回源）