为什么不将页面内容中的大图像制作成雪碧图?

11

使用CSS精灵图来处理图片的一般规则是,只应该对较小的图片(如图标)使用,而实际的图片内容应该始终通过 <img> 元素表示。 我的问题是:为什么?难道使用精灵图的优点在处理内容图片时不值得吗?

我读过的一个原因是为了启用 alt 文本,以更符合语法和屏幕阅读器的可访问性。然而,当这是一个问题时,你是否可以轻松地使用一个单独的微小透明的图片,将所有语法糖放在一个呈现实际视觉内容的精灵图上?

6个回答

9
您可以这样做,但是需要注意以下几点:
  1. 与图标等UI类型的图片相比,内容图片往往不会被重复使用。比如新闻网站:如果他们在每个故事中使用的每个内容图片都是雪碧图的一部分,那么这个雪碧图会很快变大,即使只有查看一个故事的用户也需要下载整个雪碧图。

  2. 通常情况下,网站内容的维护者并不了解CSS。希望内容编辑通过编辑主雪碧图文件、重新保存为JPG格式并添加CSS来放置图片到页面上是有些不合理的。

  3. 如果将许多大型图片文件设置为雪碧图,则雪碧图文件将变得非常大。当用户首次访问页面时,可能需要下载很长时间,或者占用那些只看到其中一个图像的用户过多的带宽资源。

显然,这些都是概括性陈述 - 在特定情况下,将更大/更多的内容图片设置成雪碧图可能是完全合理的。

对于雪碧图中的任何精灵图像,您都可以使用一个微小的透明图像文件来使用<img>标签,这通常对于裁剪和超越background-position允许的位置很有用。


1
不错的回答。很棒的信息。有一个问题:您指出使用background-image属性可以省去透明图像的需要。但我没有看到在background-image属性中任何可以指定alt-text的地方。我有什么遗漏吗? - Jeffrey Blake
1
@Jeffrey:啊,不,使用background-image<img>标签上并不意味着不需要alt文本。我只是说,如果你愿意,可以将所有的精灵图像都放在<img>标签中,而不仅仅是内容相关的图像。 - Paul D. Waite
再说一点:内容图片也是内容。与<img>元素不同,背景图片没有alt属性,并且屏幕阅读器等辅助技术不会对其进行通告。 - steveax
@steveax:正如OP所说,“我读到的一个原因是为了启用alt文本的使用,使其在语法上更正确且易于屏幕阅读器访问。但是,如果这是一个问题,你是否可以使用单个微小的透明图像,并将所有语法糖放在呈现真实视觉内容的精灵之上?”也就是说,你可以将你的精灵作为<img>元素的背景。 - Paul D. Waite
@steveax:那么他们刚刚在一个锋利的边缘案例上割伤了自己。我认为一些浏览器确实在其右键菜单中有“查看背景图像”的选项,因此屏幕阅读器提供类似功能并不是不可能(尽管显然使用精灵背景会得到多个图像)。 - Paul D. Waite
显示剩余2条评论

6

我能想到的另一个原因是搜索引擎;如果您在图片上使用了描述性的alt标签或者在figure元素中使用了figcaption,那么搜索引擎就能够找到、分类和显示它。


1
搜索引擎实际上会索引alt文本吗?它不是太容易被滥用了吗? - Paul D. Waite
@Paul D. Waite 图像搜索在谷歌上似乎可以使用,所以我猜他们必须这样做,但也许他们会将其与页面内容进行比较。 - jeroen
我认为Google图像搜索不依赖于alt文本。例如,这个页面有一张没有alt文本的猪肉卷图片,在“pig in blanket”谷歌图像搜索中排名第一。 - Paul D. Waite
@Paul D. Waite 他们肯定比我现在想得更多 :-) 但我仍然认为,带有实际图像的图像标签对于图像搜索比没有图像标签或带有背景的透明图像效果更好。 - jeroen
1
@jeroen:嘿!我猜他们可能花了一些时间在上面。替代文本确实可能会产生影响,或者将来可以使用。 - Paul D. Waite

1

从我继续研究这个问题来看,另一个潜在的问题是内存消耗。尽管精灵图可能被压缩到足够快速下载,但它们在客户端机器的内存中占用的空间是在浏览器渲染它们之后,这意味着即使是文件大小相当小的精灵图,它们所占用的内存也可能非常大。

我还没有看到明确的答案,关于是否与不使用精灵图加载同样数量的图像时所看到的内存占用量相比,这种内存占用量是否更大。对于引发这个问题的项目,我将在未来几周进行测试,因此一旦得出结论,我将返回并更新这个答案。


1

精灵通常用于静态内容(在许多页面上都出现的图像)。

内容图片通常只出现在一个页面上,因此您无法将其添加到精灵文件中。

如果您想要实时生成精灵,请制作包含所有图片的自定义精灵文件,但我认为其生成成本远高于所节省的重复HTTP调用成本。

精灵的目的是为了节省HTTP请求,但您不应该浪费服务器端计算时间来制作它,也不要将昂贵且无用的图片放入精灵文件中。


缓存对于影响多个页面和单个页面上的图像来说比精灵更重要。节省HTTP请求开销确实是精灵的主要优点,但为什么不能将其应用于内容图像以及更通用的整个站点图像呢?根据页面的不同,这仍然可能会带来很大的节省!假设服务器计算时间不是问题,因为精灵将由页面设计者生成。 - Jeffrey Blake
我不会期望设计师制作与内容相关的精灵图,因为它应该是动态内容。一种做法可能是在页面制作过程中自动生成精灵图(精灵地图需要随内容更新)。但这只对包含大量图片的页面有意义,并且与经典的UI精灵图相比,它不会像缓存那样受益。 - TonioElGringo
我这里不是在寻找缓存的好处。在合理范围内,无论你使用精灵还是标准图像,这些好处都适用。我只关心通过合并大量HTTP请求节省的开销。谈论缓存的适用性就像苹果和橙子一样毫无关联。而声称所有网页内容图像都应该是动态的,这种说法在我看来过于宽泛了。 - Jeffrey Blake
我想说的是,通常设计和构建网站的人与放置内容的人不是同一个人。正如Paul D. Waite所说:“网站内容通常由不懂CSS的人维护”。显然,如果这不是您的情况,并且您有许多与内容相关的图片页面,则可以考虑将它们合并成精灵图。此外,缓存效益与精灵图使用有关。 - TonioElGringo

1

在整个网站中,应该使用精灵图来作为常见图标,而不是页面特定的内容。当您将大图片制作成精灵图时,会浪费很多白色空间。

根据http://blog.vlad1.com/2009/06/22/to-sprite-or-not-to-sprite/,这也是一个问题:

另一个(但不太重要)的缺点是,如果使用精灵图的页面使用许多浏览器中存在的全页缩放功能进行缩放,则浏览器可能需要额外的工作来获得这些图像边缘的正确行为 - 基本上是为了避免精灵图中相邻的图像“泄漏”。对于小图片,这不是问题,但对于大图片可能会影响性能。


我不认同“仅用于全站图片”的说法,因为没有其他理由支持这种做法。这正是我在这里质疑的。虽然如此,在单个页面上减少HTTP请求仍然有益处。话虽如此,对于性能影响的信息表示赞同。 - Jeffrey Blake
2
如果您的网站总共有50k的图片和2MB的页面特定内容,为什么要在不需要这些图片的页面上下载2MB的内容呢?这是浪费带宽。 - JSantos
2
好的。显然,您会有一个特定于页面的精灵图。 - Jeffrey Blake

0

精灵用于减少对服务器的请求量。大量小请求的影响比一个较大的请求更容易使服务器变慢。但是,如果精灵的图像(我喜欢称之为精灵地图)太大,也会降低性能。另一个重要的事情就像你所说的,每个单独图片都有可能给出一些名称,通过搜索引擎进行管理和索引。


除了JSantos提到的缩放讨论之外,大型精灵图如何降低性能?您是否知道Mozilla标准精灵图为1000x2000像素? - Jeffrey Blake
他们使用了一个1000x2000像素的地图,但这并不是标准或推荐的尺寸。我的地图从未达到那个大小。大尺寸的地图会增加加载时间、处理时间和内存使用量,从而失去了精灵图地图的优势。 - Eddy Freddy

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接