Data URL(base64)的优缺点

Base64：就是说选出64个字符，即小写字母a-z、大写字母A-Z、数字0-9、符号”+”、”/”（再加上作为垫字的”=”，实际上是65个字符）———作为一个基本字符集。然后，其他所有符号都转换成这个字符集中的字符。

Data URL，就是利用base64编码把图片数据翻译成标准ASCII字符

前端图片使用base64的缺点

• 根据 base64 的编码原理，base64 编码后比原图要大 1/3
• 尽管图片请求少了（Data URL是在本地直接绘制图片，不是从服务器加载，所以节省了HTTP连接，起到加速网页的作用。），但如果把大图片编码到 html / css 中，会造成后者体积明显增加，明显影响网页的打开速度
• 代码看起来会有点丑，大量编码字符（当然也可以通过构建工具动态插入）
• base64 无法缓存（Data URL形式的图片不会被浏览器缓存，这意味着每次访问这样页面时都被下载一次。这是一个使用效率方面的问题——尤其当这个图片被整个网站大量使用的时候。），如果 base64 是被编码到 css/js 中，是可以缓存的，因为 css/js 文件可以缓存。这相比直接缓存图片要弱很多，一般 HTM 会改动频繁，所以等同于得不到缓存效益
• IE 的兼容性问题。IE 8 以下不支持 data url，IE 8 开始支持 data url，却有大小限制，32k（未测试）。
• 如果构建工具比较落后（或者没有构建工具），手动插入 base64 很麻烦，编辑器十分卡。

 

总结：本方法适合于小图片，大图片就不要考虑了，另外IE8以下浏览器不支持这种方法。用这种方法会加重客户端的CPU和内存负担。

 

前端图片使用base64的优点

1. 减少了HTTP请求

2. 某些文件可以避免跨域的问题

3. 解决了图片更新要重新上传，还要清理缓存的问题

————————补充

有一种情况用base64编码作为background-p_w_picpath背景图片利要远大于弊的

在web页面制作的时候，由于某些现实原因，我们可以会用到下面这一类图片：

• 这类图片不能与其他图片以CSS Sprite的形式存在，只能独行

• 这类图片从诞生之日起，基本上很少被更新

• 这类图片的实际尺寸很小

• 这类图片在网站中大规模使用

想想看，你的经历中有没有需要同时满足上面四条的背景图片呢？