我写了一个脚本，将所有内联图像替换为数据URI，以减少HTTP请求并加快移动设备的加载时间。
不幸的是，我发现加载速度更慢了。我觉得这取决于HTML文件的大小（大约100KB而不是5KB左右）：）？还是数据URI还有其他会拖慢页面加载的问题吗？
浏览器是否必须在完全下载整个文档后才能加载其中链接的资源？或者说，例如在文档顶部的CSS和JavaScript之类的链接资源会在浏览器完成下载整个文档之前加载吗？
CSS如何工作？浏览器是否必须在读取所有CSS设置之前加载完整个CSS文件？
如果是这样，是否最好为数据URI单独创建CSS文件：
“单独缓存的jpg文件”是否比“包含在缓存的CSS文件中的URI图像”加载更快？
对于如何使用数据URI还有其他建议吗？
src 属性的 img 标记）平均慢6倍。
[...]
因此，可以想象当测量数十万次移动页面浏览时，我惊讶地发现使用数据 URI 加载图像平均比使用二进制源链接img标记慢6倍！
虽然我没有深入研究这篇文章，但我认为问题的一部分可能是解码 base64 编码的数据 URI 所需的 CPU 功率。
作者建议仅“偶尔使用小图像”的数据 URI。
简而言之：如果图像很大，使用数据URI将延迟HTML的加载时间。
我编写了一个脚本，用数据URI替换所有内联图像，以减少HTTP请求并加快移动设备的加载时间。
如果执行请求的时间大于下载图像的时间，则这是一个好主意，因为浏览器无论如何都需要下载图像数据（无论是否使用数据URI）。如果将图像嵌入HTML中作为数据URI，则会增加HTML的总大小，其大小为所有图像的大小之和（加上数据URI编码约33%）。
例如，如果打开新请求的连接时间为1秒，您的图像每个需要0.2秒下载，您有10个图像，您的HTML需要0.5秒下载，则需要：
如果将图像编码为HTML中的数据URI（大小增加33％）：
这里的一个重要因素是获取整个页面HTML源代码所需的时间（1.5秒与3.5秒）。如果在绘制页面时必须拥有图片，则数据URI将是一种良好的优化方式。如果可以异步加载大部分带有图片的页面，那么最好优化完全下载HTML。
如果您的图片很大，将它们编码为数据URI会更糟糕。如果每张图片需要1秒钟下载，并且其他因素相同：
使用外部图片：
使用数据URI：
链接的资源有自己的加载和解析逻辑。 <script> 标签将同步加载 - 阻止浏览器解析 HTML 源代码，直到引用的脚本被加载并执行 - 除非它们具有 async 属性。外部样式表将并行下载，但会阻塞渲染，直到它们被加载。
如果是这样，是否最好为数据 URI 单独使用 CSS 文件，像这样：
- 为结构加载 CSS（没有数据 URI）
- 为背景图像加载 CSS（所有背景图像都以 URI 格式） “单独缓存的 jpg 文件” 是否比 “包含在缓存的 css 文件中的基于 URI 的图像” 加载更快？
如何使用数据 URI 的其他建议？
这取决于您要优化什么。您更关心首次呈现时间，即使页面不完整吗？还是更关心整个页面，包括所有图像，完全呈现的时间？
像任何工具一样，没有适用于所有情况的普遍规则，比如“总是使用数据URI”或“永远不要使用数据URI”。一个好的经验法则是对于小图标等小图片使用数据URI。Webpack的url-loader会自动实现这个逻辑，对于指定大小以下的文件使用数据URI，否则使用外部URL。