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

[fyxtc]

差不多 60 个人头像，base64 已经是压缩图片后编码的 b64 了，可是字符串放在 body 里还是巨大，差不多还有 4MB ，而且这个页面是会频繁刷新的，有成员变动就自动去获取新数据，几秒就干一个 4MB ，吃不消啊

[hefish]

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

[wolfan]

缩略一下再搞？

[hsfzxjy]

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

[fyxtc]

@hefish 我也想...

[hhjswf]

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

[IvanLi127]

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

[k9982874]

无力吐槽。。

[lalalaqwer]

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

[opengps]

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

[rabbbit]

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

[opengps]

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

[Trim21]

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

[felixlong]

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

[Trim21]

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

[tulongtou]

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

[muzuiget]

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

[jack4536251]

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

[SnailLin]

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

[Ericcccccccc]

?

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

[tairan2006]

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