• mobify. com * 发表了一篇博文：On Mobile, Data URIs are 6x Slower than Source Linking (New Research)

[...]
所以你可以想象我惊讶地发现，当测量成千上万的移动页面浏览量的性能时，使用数据URI加载图像平均比使用二进制源链接（如带有src属性的img标记）慢6倍!
我没有深入研究这篇文章，但我猜部分问题可能是解码base64编码的数据URI所需的CPU能力。
作者建议只"偶尔为小图像"使用数据URI。

HTML内容按其在HTML文件中的显示顺序加载。较大的数据URI会降低页面速度。IE浏览器（IE6）不支持较大的数据URI。
建议使用小于20KB的图像的数据URI，并且通常使用。
你可以选择图像压缩，js，css压缩来提高页面速度。

• • TL; DR：**如果图像较大，则使用数据URI将延迟加载HTML

我构建了一个脚本，用数据URI替换了所有内联图像，以减少http请求并增加移动设备上的加载时间。
如果执行请求的时间大于下载图像的时间，这是一个好主意，因为浏览器在任何情况下都需要下载图像数据（无论是否是数据URI）。如果图像作为数据URI嵌入到HTML中，则HTML的总大小将增加所有图像大小的总和（加上数据URI编码的大约33%）。
例如，如果为新请求打开连接的时间是1秒，而您的图像下载每张需要0.2秒，并且您有10张图像，而您的HTML下载需要0.5秒，则需要：

• 1s +0.5s = 1.5s（仅HTML）
• 图像为10 x（1 + 0.2）s = 12s

如果您将图像编码为数据URI（比HTML大33%）：

• 1秒+0.5秒+（10 x 0.2秒x 1.33）= 4.2秒
• （并且没有外部图像请求）

这里一个重要的因素是获取页面的整个HTML源代码所需的时间（1.5秒vs 3.5秒）。如果绘制页面时拥有图像至关重要，那么数据URI将是一个很好的优化。如果异步加载图像来绘制页面的大部分内容是可以接受的，那么首先完全下载HTML可能会更好。
如果你的图片很大，那么将它们编码为数据URI就更糟糕了。如果下载每张图片需要1秒，而其他因素都是一样的：
使用外部图像：

• 1s +0.5s = 1.5s（仅HTML）
• 10 x（1s +1s）= 20s（对于图像）

使用数据URI：

• 1秒+0.5秒+（10 x 1秒x 1.33）= 14.8秒，直到HTML下载完毕!

我想这取决于html文件更大（大约100kb而不是大约5kb）：）？
当浏览器下载页面的HTML源时，它开始解释和显示它。当它到达引用单独资源的元素时，如具有外部URI（非数据URI）和（异步）脚本标记的图像，它将开始下载它们或排队下载它们，但继续下载和处理页面的HTML。
这意味着随着页面的下载，用户看到的内容越来越多，尽管没有图像，有时也没有加载字体。
当浏览器到达一个带有数据URI的图像标签时，它必须下载并解析整个数据URI字符串，然后才能处理HTML源代码中的任何内容。因此，如果您的原始HTML为1kb，并且您嵌入了一个1MB的图像数据URI，那么当浏览器到达该图像标签时，它将暂停下载由数据URI编码的图像占用的1MB HTML源代码。然后再处理页面的HTML。
浏览器必须先下载完整个文档，然后才能加载喜欢的源代码吗？或者在浏览器下载完整个文档之前，是否会加载链接源代码，例如文档顶部的css和javascript？
链接源有自己的加载和解析逻辑。<script>标记将同步加载-阻止浏览器解析任何HTML源代码，直到引用的脚本被加载和执行-除非它们有async属性。外部样式表将并行下载，但将阻止渲染，直到它们被加载。
There's a good explanation here.
如果是这样的话，是否最好为数据URI创建一个单独的CSS文件，如下所示：
1.为结构加载CSS（无数据URI）
1.为背景图像加载CSS（所有背景图像都是URI格式）"单独的chaced jpg文件"加载速度会比"缓存的css文件中包含的基于URI的图像"快吗？
关于如何使用数据URI还有其他建议吗？
这取决于你想优化什么。你更感兴趣的是第一次呈现的时间，即使页面不完整？还是整个页面（包括所有图像）完全呈现的时间？
像任何工具一样，没有什么万能的规则可以适用，比如"总是使用数据URI"或"从不使用数据URI"。一个好的经验法则是对图标这样的小图像使用数据URI。Webpack的url-loader自动实现了这个逻辑，对指定大小的文件使用数据URI，否则使用外部URL。