11

我正在建立一个网站，我想尽可能减少HTTP查询，以提高网站速度和seo。我刚刚创建的页面正在滚动显示图像（图像具有属性data-scr，当用户向下滚动相应图像时，该属性会转换为src）。

因为所有图像都具有data-src而不是属性src，所以W3C向我显示错误。

这时，我找到了两种解决此问题的方法：

所有图像的初始src为空白1x1图像的url
所有图像的初始src将成为数据库64空白图像

当我使用空白1x1图像的URL时，（使用tools.pingdom.com测试）它显示1个HTTP请求。当我使用数据库base64空白图像时，它显示的请求数量与页面上的图像数量一样多。

对于网站更快的速度和更少的HTTP请求，哪种方法更有效？（假设用户以14.4kbps的互联网速度（即第一个互联网速度）加载网页）。

但是对于SEO？

还有其他选择吗？

— MM PP
source

8

“当我使用数据库64空白图像时，它显示的请求与页面上图像的数量一样多。” -那里有什么问题吗？使用数据URI的全部目的是没有外部HTTP请求。（只有不理解数据URI的用户代理才可以触发HTTP请求。）

— MrWhite

如果空白图片大于1x1 px（我想是），我建议使用更大的背景图片（10x10 px，100x100 px），因为渲染会更快。

— totymedli '16

3

不使用？您可以在将data-src转换为src的同时动态创建img标签。您可以存储图像列表并在需要时生成标签，而不是使用data-src保留空白图像。

— the_lotus

@Pharap无效，因为浏览器即使隐藏了图像也会下载图像。

— DisgruntledGoat

无论选择哪种方式交付内容，将其编码为png8都可能比JPEG更快。

— symcbean '16

12

如果只有很少数量的图像，并且要消除从服务器获取图像的网络开销，则应使用base64图像选项。但是，根据您在问题中所指示的内容，我认为这可以缩放为大量图像。在这种情况下，我将使用服务器中的单个1px x 1px透明图像，并具有较长的缓存寿命，因为它将从服务器中提取一次，然后缓存在浏览器和任何中间代理服务器中。

例如，此图像的大小约为95个字节（https://commons.wikimedia.org/wiki/File:1x1.png），对于base64编码的图像字符串，您会发现其大小与该图像相同档案大小，但会在您将其添加到的每个图像中重复。

对于2-5张图片，其大小和速度可以忽略不计，并且通过消除整个抓取操作而减少了服务器流量，但超过此数目，页面大小将开始变得太大而影响加载时间，进而影响SEO排名。

— 克里斯·卢瑟福
source

6

空白的base64映像可能具有55个字节：data:image/gif;base64,R0lGODlhAQABAAAAACwAAAAAAQABAAA=。如果图片的网址更长（例如：example.com/templates/template-name/files/1x1.png），则建议使用base64图片，因为您无需进行HTTP查询，并且字节数较小比图片网址（页面上的每个图片都重复）+外部图片尺寸。

— NETCreator主办2016年

@ NETCreatorHosting-WebDesign谢谢您的评论。我比较了使用base64图像和外部图像时网站的大小，使用base64图像时网站的大小较小。我每页使用约40张图像。

— MM PP

或者，您可以将图片上传到您的网站根目录并使用相对网址，这样网站就会小得多。

— NETCreator托管

3

gzip会处理重复，因此在页面中包含400个base-64编码的图像不会比400个图像URL占用更多带宽。

— user2428118 '16

3

@Aron如果您的页面大25.6 MB（400个82字节长的数据URI，其中64kB = 25,568,800字节），您将比32.8 kB的base64编码图像还要担心更大的问题。

— user2428118 '16

5

与数据URI肯定去，除非你需要的IE <8支持（浏览器的支持。）

直接在HTML中嵌入许多小图像看起来比直接链接要占用更多的带宽，但是gzip可以减轻这种增加；页面大小的唯一差异将来自空白图像的一个数据URI与服务器上图像的一个 URL的长度差异。甲空白GIF可以小如43个字节。基本为64编码，即82个字节。没有比500字节以上的HTTP请求（响应大小类似）更糟糕的事情了，然后我什至没有考虑TCP数据包大小和其他开销。

这是Base 64编码的43字节GIF图像：

data:image/gif;base64,R0lGODlhAQABAIAAAP///////yH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==

至于SEO，请查看Google网站的源代码，例如Google News，然后搜索data:image/gif,base64…

— 用户名
source

您的图片很大。检查上面的注释以获取55字节版本。

— 约书亚

1

关于StackOverflow的报告测试（2014年5月）的答案似乎表明，嵌入大量（〜1800）1px图像比重复链接到同一张外部图像要慢得多。一次请求外部图像并进行缓存，而作为HTML解析过程的一部分，浏览器必须分别解码每个数据URI-这似乎是瓶颈。这似乎表明应该将数据URI限制为少量（小）图像。

— DocRoot '16

@Joshua尽管该图像在我的浏览器（Firefox）中正确显示，但是其他某些程序（例如Paint）无法将其打开，因此我会避免使用它。

— user2428118 '16

2

此时，我找到了两个解决此问题的方法：将所有图像的初始src设为数据库64空白图像

此选项不仅需要现代的浏览器，而且在客户端可能会比较慢，因为浏览器必须对图像数据进行base-64解码才能生成图像。

所有图像的初始src为空白1x1图像的url

如果所有图像插槽的空白图像URL都完全相同，并且具有在HTTP标头“ cache-control”中定义的较长的缓存生存期，则可以这样做。这样做的问题是，随着新图像文件的加载，图像方块将跳到新的大小，这可能会使用户体验变得不那么美妙。

几乎完美的主意是...

页面启动时，显示一个网格，其中包含可容纳每个图像的固定尺寸的框。如果整个网格不适合屏幕，也可以。然后创建在HTML加载后执行的javascript，并在该javascript中创建一个新的图像元素并将其附加到网格的每个单元格，然后将图像源设置为正确的图像文件。这样做直到第一个屏幕填满。然后在javascript中检测滚动，然后在发生滚动时，对新单元格重复上述过程。

现在，如果您想要最好的，而质量不是一个大问题，那么我建议（我也在我的网站上实现）是构造一个网格并将其设置为使得该网格的背景图像是格式化为图像正方形的所有图像的Sprite工作表。由于所有图像都需要一个请求，因此该方法灵活且加载速度快。

如果您想走快速路线，请使用以下HTML模板。仅提出两个请求。HTML代码和一张图片。在此代码中，我假设工作表中的每个图像的宽度均为100像素，高度为200像素，并且每个图像彼此之间完美对齐且没有间隙。

<html>
<head>
<style type="text/css">
#imagegrid {background-color: black; background-image:url('http://example.com/url/to/imagesheet.jpg');}
A {display:block;width:100px;height:200px;margin:10px;float:left;}
#image1{background-position: 0px 0px}
#image2{background-position: 100px 0px}
#image3{background-position: 200px 0px}
...
#imageN{background-position: XXXpx 0px}
</style>
</head>
<body>
<div id="imagegrid">
<a href="image_one.htm" id="image1"></a>
<a href="image_two.htm" id="image2"></a>
<a href="image_three.htm" id="image3"></a>
...
<a href="image_N.htm" id="imageN"></a>
</div>
</body>
</html>

在我的代码中，我添加了3个点。这意味着，只要Sprite工作表仅包含一行图像，就可以通过增加数字并每次将位置增加100来继续添加图像。另外，对于某些浏览器（例如Opera），您可能需要在背景位置值前面添加一个负号，以使其正常工作。

— 麦克风
source

2

除非您的图像大小为半GB，否则无法对图像进行base64解码对性能产生任何可衡量的影响。

— user2428118 '16

它也取决于计算机系统。如果客户端仍具有老式计算机（例如奔腾1），则可能会降低性能。

— 迈克

1

形象，因为可维护性。

以我的经验，使用图像效果更好。这在实际代码中更明显，更容易记住。我怀疑您会记得透明图像的编码字符串，即使这样做，您的后继/胶体也是如此。
如果几周后返回此代码，则说明已忘记了base64。

如果您使用图像，那么维护代码会很辛苦，最小的专业人士对此并不重视。

— 马丁
source

许多人使用脚本来生成base-64值，因此记住这些值的要求是不可能的，除非OP恰好仅使用一组HTML文件来表示其网站的代码。

— 迈克

1

仅约3个额外的字节，0个额外的http请求和0个额外的img src长度（或0个未缓存的数据图像占位符）怎么样。可以将空白src用于图像吗？

<img src data-src="banannanannas.jpg" />

并且，如果它们具有alt标签，则可以从错误/失败图像中隐藏它们：

<img src data-src="banannanannas.jpg" onerror="this.alt=''" alt="some desc" />

显示：无。砍掉alt标签从图像占位符边界开始有轻微的FOUC延迟。也许也可以清除。

— 陶品
source

2

尽管空src属性仍然会在W3C验证程序中引发错误（这似乎是个问题）。

— MrWhite

@ w3dk是的，这很糟糕，但随后又很少有现代化的方法通过。

— dhaupin '16

如果要传递W3C规则，则需要为src指定某些内容，即使其URL返回404错误也是如此。我还建议指定图像的width和height属性的值，以便用户首先看到实际的占位符，而不是在加载过程中途膨胀的小盒子。

— 迈克

空白图像。使用方法：Base64与1x1 JPEG图像

形象，因为可维护性。