图片显示用静态资源+相对路径 对比 用 base64，性能上有区别吗

[unt]

图片 2k,base64 3k 。

页面上渲染 3000 个图片，性能上有差距吗。

[for8ever]

有区别，base64 可以减少 HTTP 请求，对于小图片用 base64 更好

[loading]

base64 就是要等 html 全部下载完才渲染（？）

我觉得你应该看看 雪碧图

[opengps]

网络连接数可能占用更少，但 cpu 占用会更多

[matepi]

浏览器也是能并发连接的啊

[okakuyang]

什么场景这么极端

[641571835]

@for8ever 如果是 http2 这个不是问题吧

[uasier]

合理操作应该是雪碧图

[uasier]

同时也可以看看是否需要懒加载

[retrocode]

网页的话还是建议图片形式, 好歹可以懒加载, 图片转 base64 后体积会变大, 你还是要等数据加载完才能渲染,而且更慢

转 base64 只适合散碎图片,如图标之类的, 整合成一个文件加快加载速度,

如果是本地页面的话, 你想骚套路也不是不可以,随便搞, 还能方便加密混淆

[mxT52CRuqR6o5]

3000 个图片传统方案是雪碧图 /fonticon ，对业务代码有一定入侵

[churchill]

看到 雪碧图 这个翻译忍不住要吐槽

[zephyru]

一个可视区内为例，3000 张一个可视区，用 base64 大概是，先等所有图片下载完再展示（我就当你是嵌在 html 里了）
相对路径则是先展示轮廓再展示，浏览器并发，不同浏览器不一样通常是 6 ～ 8 个，所以 3000 张同屏怎么也会有先后顺序
你要全部加载完哪个更快？主要看设备，通常来说，一个大文件会比 3000 个小文件快，取决于大小差异和实际使用的 http 协议，用 http3.0 的话，小文件估计会快一点，1.0 大文件会快一点。
个人建议，用相对路径，需要一次性展示的话自己控制图片的加载完再展示，而不是使用 base64 这样完全不可控。
一个可视区放不下的情况，比如滚动加载，就别 base64 了，没啥意义。

[IvanLi127]

3000 个图片。。要不 http/2.0 ？

[Huelse]

如果图片要更新的话不如懒加载，看那些壁纸站也是这么做的

[unt]

是 3000 张相同的图片，可以认为是图标， 我说的有歧义，骚瑞~

[28Sv0ngQfIE7Yloe]

3000 是每次固定还是随机？

[tigaDark]

1.一个页面放下了 3000 个图片,也无法全部显示

[tigaDark]

2.静态资源+相对路径 用的是 http 获取图片
3.base64 则是用类似字符码? 直接显示在页面上
4.浏览器的 http 并发请求大概是 8-10 条
5.性能得看你的电脑配置,图片大小 综合看...

[unt]

@tigaDark #18 同一张图片只请求一次，只会有一个 http 请求，而且有缓存，实际渲染时不需要发 http

[Alander]

一个页面放得下 3000 个图片？如果放不下就懒加载随便怎么选；如果放得下 http1.1 就用雪碧图吧

[laqow]

感觉看引擎和硬件渲染。另外渲染 css 背景，img 标签，或者 appendChild Image 对象的性能应该都不同

[daoqiongsi1101]

@for8ever 用 http/2 协议就没你说的这个问题

[cleveryun]

@unt 3000 个相同图片的话，那必然是用 http 地址比 base64 好，而且好太多了，3000 个一样的 http 地址，你只为图片浪费了 2k 带宽，3000 个 base64 你需要 3k x 3000 =9000k 带宽。你审查下用 base64 的 img 标签，内容是直接塞进 html 里的，有几个就是几倍的大小。

[janus77]

肯定不是一个屏幕几千张啊。用懒加载就行了，一个屏幕最多也就一百张左右

[superares]

可以看下 Google 的图片搜索，前面两排左右的结果是 base64 ，后面的就是图片地址了。base64 就是为了快速出图片，但是不适合大量图片