一个页面要多人获取头像， base64 传输 body 巨大，有什么好办法吗

我们都是 Img 标签指向 jpg 就完事了。

缩略一下再搞？

所有人头像放一个请求里吗？为啥要这样

@hefish 我也想...

头像不都是缩略图存本地吗

一个个拉呗，拉完缓存不就好了？ http2 不是普及了吗？

你们不会是把头像 base64 后存数据库吧

页面本身不是自带缓存吗？本地有的话，刷新也就只是请求一次

用 img 标签，浏览器会自动缓存
可以从头像大小入手，以 Github 为例 48x48 的头像可以处理到 4kb 以下

另外如果图片加载对页面影响大，那就单独从文件存储拉图片，不去占用后端接口服务器的带宽就好

频繁刷新这个问题可以考虑在客户端 diff 一下只拉新用户的头像，模拟一下 img 标签的行为...

base64 不是压缩。你把 base64 换成原始的 jpg 。每个图像差不多 5k 。啥都不用改。直接可以把 4M 变成 300K.

@felixlong 他应该是只能返回 JSON 格式，所以就先压缩了图片的二进制再用 base64 编码的。

nginx 启用 http zip ，文本的 zip 完会小很多

为什么要这样骚？ img 标签加个 lazyload 属性完事。

@lalalaqwer 应该是，正确的做法是存路径

槽点太多，1 、base64 不是压缩 2 、后台返回头像的 url 即可 3 、所有头像懒加载、异步加载

?

后端肯定是返回链接地址, 哪有直接返回图片本身的.

你这啥问题？图片不都是返回地址么

可以用不同的压缩算法压缩响应，如果可以用二进制流传输会比 base64 小一点。base64 会膨胀一点。

你是说把所有人的头像图片作为整体来传输，有人的改变了就把 60 个人头像的这个整体重传一边？这不是给自己找麻烦嘛。

6 啊 这种设计真的无力吐槽

建议接口改成 api/(unique_id).jpg

oss ？

其实用 base64 传输体积更大了，直接传输还省点流量。。。

正常操作不是图片存 oss ，后端存图片地址？

4MB/4*3=3MB （ Base64 导致增大 1MB ）
3MB/60=50KB （ 50KB 一张图，应该还能再压缩一下到 10-20KB 一张头像）

所以，请使用 url ，依靠浏览器缓存，除了第一次 后面随便你变动，老图都没有流量消耗

这实现方案是谁定的。。。

读了好几遍也没弄明白这个场景为啥要用 base64..用 oss 上 cdn 吧，不行的话，前端手动实现一个缓存？感觉好像也没啥用..后端，把 base64 写成文件，提 url 让前端用，作用估计也有限..主要不知道这里的，吃不消体现在哪里，页面卡？还是接口返回慢？ 4mb 说大不大，页面我觉得很少会因为这个卡的..

图像存在了数据库里面？

@zephyru 页面在取到数据前会转 loading ，数据越大 loading 越久，之前有实现过 url ，体验不好，有的图片如果加载慢就是空白放着，还有可能有的图片永远加载不出来，前端没法缓存，因为有可能随机几秒到几分钟之后 60 个全变的。前端是不知道哪些是变的哪些是不变的。

返回地址吧，base64 不适合

@fyxtc img 标签正解，直连浏览器有缓存，后面上 cdn 也可以加速，不用回源站

img 标签会有 onload 和 onerror 进度事件，监听就能知道哪些加载好了，哪些还在加载中，哪些加载错误
@fyxtc

应该是为了解决浏览器的问题：同域名并发请求数少，同时加载 60 个图片会加载很久

你这个问题可以让前端去解决，因为你这需求以为是保密数据需要解密从数据库读取。如果不是的话返回地址和版本号给前端，从前端去判断哪些需要更新，缓存图片的方法很多种，如果不想缓存就给链接添加一些参数，图片加载不出来就让前端优化加载逻辑。

@okakuyang 感谢大家，我修改一下