小心 base64 编码数据拖慢你的后台服务

问题回顾

今天，同事小赵接到客户导入新闻数据要求，由客户提供新闻数据。于是小赵通过 SQL 脚本把新闻数据入库后，发现前台展示新闻特别慢。幸好当时是晚上凌晨1点，用户比较少，处理问题来得及，最终经过近半小时的排查问题，原来问题出在这里。

问题定位

在小赵导完数据后，测试小赵发现内容管理列表页访问特别慢，加载完数据需要 16 秒左右。

于是我用 F12 打开 chrome 调试工具，发现获取新闻内容列表数据的 API 接口：“getManageArticleList" 接收的数据有 7.1 M，接口响应时间长达 16 秒多，太不正常了。

但是同一个接口换一个查询条件，接收的数据只有 367 KB，响应时间 4.5 秒。

由此，这说明两个问题：

第一、API 接口的请求与响应是没问题的

第二、换查询条件后，接口响应时间差距近 12 秒之多，说明接收数据有问题

既然是数据问题，于是在和小赵对比入库前和入库后的新闻数据后，发现问题出在图片 base64 加密存储。

原来，客户提供的文章数据中包含图片，但由于客户原图不在了，只能从别的地方收集新闻时，把包含图片的新闻采用了 base64 加密串给了小赵。而这些 base64 加密的图片每张基本上在 1 M 左右，前端一次性分页加载 10 条共 7M 的数据，变慢就不足为怪了。

另外，为什么新闻列表页需要加载图片呢？

通过代码走查，发现图片是放在 contentText 字段里面，但是 新闻内容列表 select 分页语句却包含了 contentText 字段，明显 select 语句不合理。

select ..., contenText from article 

解决方案

由于时间比较紧迫，本次发版又不涉及服务升级，只能从修改数据入手了。

第一步，用 like 模糊查询存在包含 base64 串的文章，共 34 条记录，数据比较少

select id,title,contenText from article where contenText like '%data:image%'

第二步， 从新闻详情页下载图片，用 fastdfs 分布式文件服务器上传图片后，得到图片的下载地址，替换 img 标签的 src 属性值。

图片地址格式如下：

group1/M00/00/00/rBIK6VcaP0aARXDSNFHrUgHEviQ663.jpg

10 个人 34 条新闻，花了近 20 分钟，完成 base64 图片地址替换后，问题解决。

问题总结

什么是 base64 编码？

base64 编码简单来说就是把一张图片数据加密成一串字符，使用该字符串代替图像地址。

用 base64 把图片加密成一串字符的好处是：“可以不需要单独用文件服务器存储文件，节省一个 http 图片请求。”

但是，如果不合理利用 base64 带来的问题是：“CSS 文件的体积变大，CSS 文件的体积直接影响渲染，导致用户会长时间注视空白屏幕。”

#index {  background: url(data:image/png;base64,xxxxx) no-repeat center;}

所以，使用 base64 编码的前提是图片足够小，以一个 3kb 的 logo 图片为例:

一张 3.27 KB logo 图片，已经很小了，但是如果将其制作转化成 base64 编码，生成的 base64 字符串编码足足有 4406 个,也就是说，图片被编码之后，生成的字符串编码大小一般而言都会比原文件稍大一些。即便 base64 编码能够被 gzip 压缩，压缩率能达到 50% 以上，想象一下，一个元素的 css 样式编写居然超过了 2000个 字符，那对 css 整体的可读性将会造成十分大的影响，代码的冗余使得在此使用 base64 编码将得不偿失。

看似微不足道的问题，如果追踪溯源，还是能学习到一些技术有趣的一面，只是看你有心了。

延伸

CssSprites 与 base64 比较？

参考

https://www.jianshu.com/p/681e5e0933e3