如何将 <img> 标记 SRC 加载到 javascript 变量中，以便在多个图像中重复使用

How to load <img> tag SRC into a javascript variable to be re-used across multiple images?

本文关键字：图像 javascript img 标记 加载 SRC 变量      更新时间：2023-09-26

所以这是我快速下载网页的计划......

  1. 将所有图像放入单个 png-24 图像精灵中。
  2. 将该图像编码为 base64，并将其包含在网页 HTML 代码中。
  3. 复制原始图像精灵的SRC，并将其重新用于徽标，共享按钮，其他图像等。

我能预见的唯一问题是base64编码图像源的重复。

我可以使用jQuery轻松提取图像源并将其重新插入到我所有的空白图像（需要创建精灵的图像）中吗？

编辑：有些人提到base64图像没有缓存，

但是如果我告诉它，我的整个网页（包含base64图像）不会被缓存吗？

这是CSS图标/可重用图像的常用技术。

您可以使用$(element).attr('src');获取图像src。

但是，我没有看到将图像二进制文件（我假设您的意思是图像文件本身）编码为 base64 以包含在 HTML 标记中的优势。你可能有点想多了。

我认为您可以通过将图像数据重新编码为 base 64 来"保存"字节，主要是因为 base 64 是比原始数据中使用的编码更窄的字符集（想想二进制 111 = 十进制 7），所以我实际上期望更大的输出。（但这只是我的理论，如果我错了，请纠正我。

但是，例如，如果您确实设法将重新编码为最多相同大小的标记，那么您在"更快的下载"方面不会取得任何进展。您仍在下载相同数量的数据。很可能更多。

如果您确实管理较小的有效负载，那么编码/重新编码的性能影响是否值得？更不用说跨浏览器兼容性了。

更好的方法是将图像打包到单个图像文件中（这是您练习的精神），然后让浏览器正常下载。下载图像的一个副本后，只要浏览器缓存它，它就不会再下载它。

编辑

要回答您关于网页缓存的编辑，是的，您的网页将被缓存。您的 base-64 编码图像也是如此。但是，由于您的图像实际上是HTML标记的一部分，因此它们将与HTML页面一起缓存。

例如，如果我下载foo.html（包括我编码的精灵文件），我肯定会像往常一样获得我的标记。该页面将被缓存。

现在，我下载了bar.html（它也使用我的精灵文件）。我希望您的图像无法从bar.html缓存访问，因为就浏览器而言，该图像是foo.html HTML标记的一部分。它甚至可能不会意识到那里有一个图像。

缓存的工作方式（尽我所能理解）是 URL 匹配。这就是为什么如果我在一个页面中下载facepalm.jpg，并在另一个页面中再次请求facepalm.jpg，浏览器会识别出我已经下载了它，所以它没有。

使用您的编码计划，我不会向bar.html请求foo.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请求。 （即使"这就是谷歌所做的。 实现良好的性能是一种平衡行为，考虑到浏览器之间的差异，它更像是一门艺术而不是科学。

您不想这样做的原因：

  • 您的图像精灵不会跨页面缓存 - 换句话说，您必须在每个页面上传输整个图像。 假设单独提供的图像具有适当的缓存标头，则后续页面请求将变慢并浪费带宽。
  • Base 64 编码本质上是浪费带宽的。 base64 编码的文件将比原始文件大 33%。 对于几千字节大的文件来说，这并不重要，但对于大文件（如图像精灵）来说，这将是一个大问题。
  • 正如您已经意识到的那样，您必须在页面上的每个<img>标签中复制 base64 编码的精灵，这是非常浪费的，通过脚本修复此问题会让我们......
  • 你的图像变得依赖于JavaScript，这是一个坏主意。 如果脚本无法加载怎么办？ JavaScript 被关闭了？
  • 消除此图像HTTP请求实际上并没有在页面显示之前多长时间完成太多工作，因为图像不会阻止DOM就绪。 重要的是减少对阻止渲染的内容的HTTP请求：脚本和CSS。 （在大多数情况下，每个请求一个。 在脚本和 CSS 完全加载之前，您的页面根本不会呈现。 但是，页面确实会在图像下载之前呈现（尽管有空白空间）。
  • 您需要平衡图像类型与数字 HTTP 请求。 图标等通常应该在 PNG 中设置，以便在一个 HTTP 请求中下载尽可能多的图像。 任何自然界中的摄影都需要进入自己的JPEG。 不要将 PNG 用于图片。 这是错误的压缩算法，将导致文件比类似的 JPEG 大 1000%。
相关文章：