base64 编码图像是否优于 Intranet 中的常规图像？ [关闭]答案

【问题标题】：Is base64 encoded images better than regular images in an intranet? [closed]base64 编码图像是否优于 Intranet 中的常规图像？ [关闭]
【发布时间】：2023-03-20 07:40:01
【问题描述】：

在我的公司，我们有一个内部网，我们的品牌网络文件总共可能有 20 个小图像（基本上是图标）和一堆 js 和 css 文件。我想尝试完全优化性能。我已经完成了所有基本技巧，例如缩小和合并。但是现在对于图像，我想知道最好的方法是什么，因为它是一个具有快速内部下载速度（快速 wan）和双核 i7 计算机的 Intranet。此外，其主要的 6 个办事处分布在加拿大和美国。

我想到了一种方法，我使用一种工具自动将每个图像转换为 base64 编码，然后将它们放入 js 或 css 文件中。然后使用该工具将css填充到js文件中。现在我剩下 1 个 js 文件，其中包含所有 css 和 base64 字符串，大小约为 350KB。也因为它的1个js文件，它可以被缓存在服务器端和客户端。

有谁知道这有什么优点和缺点，以及可以做些什么来改进它？

谢谢

【问题讨论】：

不要将 css 放在 js 中，这将比“正常”执行要慢，因为 css 在正文加载之前就已应用，并且您不想等待 JS 发布+在那个时间段解析...
我知道让浏览器必须将所有 css 代码插入到 dom 中涉及到额外的工作，但这意味着少了 1 个 http get 请求，而对于我的 i7 机器，我不这样做'认为与加载外部 css 文件相比，最终用户会注意到差异。
http 在局域网上非常快，因此没有理由争取“减少 1 个 http 获取请求”。这与 CPU 无关，而是与您正在并行处理的长期优化的渲染管道有关，这会导致几个额外的页面布局步骤，这些步骤甚至可能在并排的情况下很明显。除此之外，您不能像那样注入任何/所有 CSS，因为它会破坏相对路径。 dataURLs 为每个图像增加了 33% 的额外权重，与 reg 图像相比，这可能抵消了额外的标头数据包。然后是每次主题调整的维护噩梦……总之，考虑一下这个方案是否值得……
dataURLs 不缓存，因此您每次都必须发送整个图像信息，而不是只发送一次 (etag) 或什么都不发送（遥远的未来 expires）关于 dataURL 的一件很酷的事情是，它们可以很容易地保存页面以供离线查看，如果这很重要的话......
@dandavis 是不是dataURL的嵌入到HTML文件中是不缓存的，但是在我的情况下，它们都包含在一个JS文件中，JS文件可以被缓存在服务器端和客户端。

标签： javascript html image performance base64

【解决方案1】：

使用 base64 并不会真正压缩您的图像，它只是使其不依赖于文件。它实际上使图像更大。

节省图像空间的好方法是使用精灵表，并使用在线图像压缩器压缩图像。

我建议只使用图像本身。如果必须的话，可以压缩它们。

【讨论】：

我对整体图像尺寸大 1.3 倍感到满意，因为总图像尺寸无论如何都非常小。另外由于是i7机器的内网，下载速度非常快，所以1.3倍还算轻。但是我想知道降低 http get 请求是否值得？
就我个人而言，我不相信它，html 实际上会有更高的响应时间，但从它的声音来看，对于你的系统来说，这可能只是几分之一秒哈哈，所以真的取决于根据您对文件结构的偏好。
但也要考虑到，所有的dataURL都在一个JS文件中，JS文件可以缓存在服务器端和客户端。除了对 JS 文件的引用之外，实际上没有在 HTML 文件中硬编码。
不要引用我的话，但是 JS 是否仍然需要在 HTML 中呈现（是否缓存在 js 文件中），这仍然会增加每个图像的页面负载。反对让图像自己缓存，或在精灵表中。
是的，从客户端渲染需要做更多的工作，但我认为这些 i7 机器的运行速度比用户注意到的要快。

【解决方案2】：

高速内网20张图片，总大小350KB。

在这种特殊情况下，您在优化上花费的时间似乎比最终结果所能带来的收益要多。

如果您想将其归结为单个 http 请求，请获取一个 php 文件以将它们转换为 base64 数据 url 并将它们嵌入到您的源文件中。

您也可以使用 JSON 文件并通过 JS 加载它。在那里，您将获得图像延迟加载的效果。

在我看来，这种情况下最好的方法是纯 img 标签。

【讨论】：