所以这是我的快速网页下载计划......
我能预见的唯一问题是 base64 编码图像源的重复。
我可以轻松地使用 jQuery 提取图像源并将其重新插入到我的所有空白图像（需要创建精灵的图像）中吗？
编辑：有些人提到 base64 图像没有被缓存，但是如果我告诉它，我的整个网页（包含 base64 图像）不会被缓存吗？
这是 CSS 图标/可重用图像的常用技术。
您可以src使用$(element).attr('src');.
但是，我看不到将图像二进制文件（我假设您的意思是图像文件本身）编码为 base64 以包含在 HTML 标记中的优势。你可能有点想多了。
我不认为你可以通过将图像数据重新编码为 base 64 来“保存”字节，主要是因为 base 64 是一个比原始数据中使用的编码更窄的字符集（想想 binary 111= decimal 7），所以我期望一个实际上更大的输出。（但这只是我的理论，如果我错了，请纠正我。）
但是，例如，如果您确实设法重新编码为最多相同大小的标记，那么您就不会在“更快的下载”方面取得任何进展。您仍在下载相同数量的数据。很可能更多。
如果您确实管理较小的有效负载，那么编码/重新编码的性能损失是否值得？更不用说跨浏览器的兼容性了。
更好的技术是将图像打包成单个图像文件（这是您练习的精神），然后让浏览器正常下载。一旦图像的一个副本被下载，只要它被浏览器缓存，它就不会再下载它了。
要回答您对网页缓存的编辑，是的，您的网页将被缓存。您的 base-64 编码图像也是如此。但是由于您的图像实际上是 HTML 标记的一部分，它们将与HTML 页面一起缓存。
例如，如果我下载foo.html（其中包括我的编码精灵文件），我肯定会像往常一样获得我的标记。该页面被缓存。
现在，我下载bar.html（它也使用我的精灵文件）。我希望您的图像不能从 缓存访问bar.html，因为就浏览器而言，该图像是 .html 标记的一部分foo.html。它可能甚至不会意识到那里有一个图像。
缓存的工作方式（据我所知）是URL 匹配。这就是为什么如果我在一个页面中下载facepalm.jpg，然后在另一个页面中再次请求facepalm.jpg，浏览器会识别出我已经下载了它，所以它不会。
根据您的编码计划，我不会向 请求foo.html（或其中的一部分）bar.html，因此我希望您的图像缓存不会像您在问题中所期望的那样工作。
但是，如果我foo.html 再次访问，我将获得缓存该页面的所有好处，因为我已经“之前下载过”。
我同意，更好的计划是使用具有许多精灵的单个图像，然后使用
background: url(...)
background-position: 0px 0px;
CSS 中的属性。这样，您只需要加载 1 个缓存的图像。
您可以使用var imgSrc = $("#yourImage").attr("src");然后使用$("img").attr("src", imgSrc);来完成您的要求。
我不确定将其编码为 base64 是最佳选择，因为 base64 图像不会被缓存，因此每次页面访问都会重新加载它。现在已经被广泛接受的是 base64 编码增加了大约 33% 的文件大小。
阅读更多：http ://davidbcalhoun.com/2011/when-to-base64-encode-images-and-when-not-to
我认为 base64 是个坏主意。只需正常加载精灵。
不要盲目地不惜一切代价消除所有可能的 HTTP 请求。（即使“这是 Google 所做的。”）实现良好的性能是一种平衡行为，考虑到浏览器之间的差异，它更像是一门艺术而不是科学。
你不想这样做的原因：
<img>页面上的每个标签中复制 base64 编码的 sprite，这非常浪费，而通过脚本修复这个问题会让我们...