在什么时候请求图像文件比内联编码它的 base64 更快？答案

【问题标题】：At what point is requesting an image file faster than base64 encoding it inline?在什么时候请求图像文件比内联编码它的 base64 更快？
【发布时间】：2018-09-27 07:46:28
【问题描述】：

我正在尝试提出指导方针或性能测试，以帮助我选择哪些图像以内联方式呈现为 base64 编码字符串，哪些图像应作为来自 cdn 或类似文件的文件请求。

确定请求时间和延迟渲染在衡量所请求图像的性能方面相当简单，但我无法很好地了解使用 Chrome 控制台的内联图像的渲染时间。显然内联较小的图像并请求将较大的图像作为文件，但什么是好的截止点？

例如，如果图像大小为 2kb，并且将其作为文件请求需要 100 毫秒，我如何知道渲染同一图像的内联版本需要多长时间？

【问题讨论】：

标签： html image browser base64

【解决方案1】：

渲染内联 base64 编码的字符串总是更快。网络请求总是比解码 base64 字符串所需的 CPU 处理时间更长。您应该问自己的问题是关于何时下载字节的权衡：在 HTML 的有效负载中或稍后在单独的 HTTP 请求的有效负载中。添加到 HTML 中的内容越多，页面加载时间就越长。下载图像而不是内联图像的好处是，如果您不需要立即显示，可以通过异步获取延迟它。

所以问问自己，是尽快显示图片更重要，还是让页面在没有图片的情况下尽快准备好使用更重要？ CSS 中的内联也有同样的权衡讨论。

【讨论】：

有趣，很好的答案！这里是否考虑缓存？即我想加载一个大图像并使用带有合理设置的缓存控制标头的浏览器缓存可能比重新渲染内联版本更快。我仍然不清楚获取图像的任何一种方式的渲染时间是否相同，并且请求只是增加了额外的时间。
好问题。每个浏览器可能会有所不同。我想读取文件的字节和解释/渲染将是相同的，所以问题是缓存开销或 base64 解码是否需要更长的时间。
啊，因此决定因素是获取时间与 base64 解码的比较。这对我来说很清楚。