因为所有图像都具有
data-src属性Q4312079q的W3C显示了错误。这时我发现了两个解决方案，以解决此问题：
所有图像的初始src都是空白1x1图像的url
所有图像的初始src都将成为数据库64空白图像
当我使用空白1x1图像的URL时，（使用工具进行了测试。 pingdom.com）显示1个HTTP请求。当我使用数据库base64空白图像时，它显示的请求与页面上图像的数目一样多。
其中更有效的方法是，网站速度更快，HTTP请求更少？ （假设用户以14.4kbps的互联网速度（即第一个互联网速度）加载网页）。
但是对于SEO？
还有其他选择吗？
#1 楼
如果只有很少数量的图像，并且要消除从服务器获取图片的网络开销，则应使用base64图像选项。但是，从您在问题中所指示的内容来看，我认为这可以缩放为大量图像。在这种情况下，我将使用服务器中的单个1px x 1px透明图像，并具有较长的缓存寿命，因为它将从服务器中提取一次，然后缓存在浏览器和任何中间代理服务器中。例如，此图像的大小约为95字节（https://commons.wikimedia.org/wiki/File:1x1.png），对于base64编码的图像字符串，您会发现其大小与该图像文件相同对于2-5张图像，其大小和速度可以忽略不计，并且通过消除整个抓取操作而减少了服务器流量，但不仅仅如此。页面大小将开始变得太大，这将影响加载时间，进而影响SEO排名。
评论
空白的base64映像可能具有55个字节：data：image / gif; base64，R0lGODlhAQABAAAAACwAAAAAAQABAAA =。如果图片的网址更长（例如：example.com/templates/template-name/files/1x1.png），则建议您使用base64图片，因为您无需进行HTTP查询，并且字节数较小比图片网址（页面上的每个图片都重复）+外部图片尺寸。
– NETCreator托管
16 Apr 15'4:36
@ NETCreatorHosting-WebDesign谢谢您的评论。我比较了使用base64图像和外部图像时的网站大小，而使用base64图像时则较小了。我每页使用约40张图像。
–MM PP
16年4月15日在4:43
或者，您可以将图片上传到您的网站根目录并使用相对网址，这样网站就会小得多。
– NETCreator托管
16 Apr 15'4:46
gzip将处理重复操作，因此在页面中包含400个base-64编码的图像不会比400个图像URL占用更多的带宽。
–user2428118
16-4-15在7:31
@Aron如果您的页面大25.6 MB（400个82字节长的数据URI，其中64kB = 25,568,800字节），那么与32.8 kB的base64编码图像相比，您有更大的问题要担心。
–user2428118
16-4-15的12:00
#2 楼
绝对要使用数据URI，除非您需要对IE <8的支持。（浏览器支持。）他们直接，但gzip将减轻增长；页面大小的唯一差异将来自空白图像的一个数据URI与服务器上图像的一个URL的长度差异。空白GIF可以小至43个字节。基本为64编码，即82个字节。没有比500字节以上的HTTP请求和类似大小的响应更糟糕的了，然后我什至没有考虑TCP数据包大小和其他开销。这里是Base 64编码的43字节GIF图像：
data:image/gif;base64,R0lGODlhAQABAIAAAP///////yH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==
对于SEO，请看一下Google网站（例如Google新闻），并搜索
data:image/gif,base64…评论
您的图片很大。检查上面的注释以获取55字节版本。
–约书亚
16年4月15日在15:21
关于StackOverflow的报告测试（2014年5月）的答案似乎表明，嵌入大量（〜1800）1px图像比重复链接到同一外部图像要慢得多。一次请求外部图像并进行缓存，而作为HTML解析过程的一部分，浏览器必须分别对每个数据URI进行解码-这似乎是瓶颈。这似乎表明应该将数据URI限制为少量（小）图像。
– DocRoot
16-4-16在12:22
@Joshua尽管该图片可以在我的浏览器（Firefox）中正确显示，但是其他某些程序（例如Paint）无法打开该图片，因此我会避免使用它。
–user2428118
16年4月16日在18:33
#3 楼
此时，我找到了两个选项来解决此问题：
所有图像的初始src都是数据库64空白图像
只需要一个现代的浏览器，但是它在客户端可能会比较慢，因为浏览器必须对图像数据进行base-64解码才能生成图像。
所有文件的初始src图片是空白1x1图片的网址
没关系如果所有图像插槽的空白图像URL都完全相同，并且具有在HTTP标头“ cache-control”中定义的较长的缓存生存期，则移动。这样做的问题是，随着新图像文件的加载，图像方块将跳到新的大小，这可能会使用户体验变得不那么美妙。 br />
启动页面时，显示一个带有固定大小框的网格，该框可以容纳每个图像。如果整个网格都不能显示在屏幕上就可以了。然后创建在HTML加载后执行的javascript，并在该javascript中创建一个新的图像元素并将其附加到网格的每个单元格，然后将图像源设置为正确的图像文件。这样做直到第一个屏幕填满。然后在javascript中检测滚动，然后在发生滚动时，对新的单元格重复上述过程。建议（我也在我的网站上实现了）是构造一个网格并将其设置为使得该网格的背景图像是所有格式为图像正方形的图像的精灵表。由于所有图像都需要一个请求，因此该方法灵活且加载速度快。
如果您想走快速路线，请使用以下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），您可能需要在背景位置值前面添加一个负号，以使其起作用。
评论
除非您的图像大小为半GB，否则base64解码图像将不会对性能产生任何可衡量的影响。
–user2428118
16年4月15日在8:39
它也取决于计算机系统。如果客户端仍然有老式计算机（例如奔腾1），则可能会降低性能。
–迈克-不再在这里
16年4月15日在23:23
#4 楼
图片，因为具有可维护性。以我的经验，使用图片效果更好。这在实际代码中更明显，更容易记住。我怀疑您会记得透明图像的编码字符串，即使这样做，您的继任者/胶原还是要记住的。
如果几周后再返回此代码，您就忘记了base64。 />如果使用图像，维护代码会很辛苦，最小的专业人士对此并不重视。
评论
许多人使用脚本来生成base-64值，因此记住这些值的要求是不可能的，除非OP恰好仅使用一组HTML文件来表示其网站的代码。
–迈克-不再在这里
16年4月15日在23:29
#5 楼
仅约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延迟。也许也可以清除。
评论
尽管空的src属性仍将在W3C验证程序中引发错误（这似乎是个问题）。
–怀特先生
16年4月15日在19:25
@ w3dk是的，这很糟糕，但随后又很少有现代化的方法通过。
– dhaupin
16 Apr 15 '19：32
如果要传递W3C规则，则需要为src指定一些内容，即使其URL返回404错误也是如此。我还建议指定图像的width和height属性的值，以便用户首先看到实际的占位符，而不是在加载过程中途膨胀的小盒子。
–迈克-不再在这里
16年4月15日在23:32
评论
“当我使用数据库64空白图像时，它显示的请求与页面上图像的数量一样多。” -那里有些问题吗？使用数据URI的全部目的是没有外部HTTP请求。 （只有不理解数据URI的用户代理才可以触发HTTP请求。）如果空白图像大于1x1像素（我想是），我建议使用更大的背景图像（10x10像素，100x100像素），因为渲染会更快。
不使用？您可以在将data-src转换为src的同时动态创建img标签。您可以存储图像列表并在需要时生成标签，而不是使用data-src保留空白图像。
@Pharap无效，因为浏览器即使隐藏了图像也会下载图像。
无论选择哪种方式交付内容，将其编码为png8都可能比JPEG更快。