背景图像：精灵还是不精灵？
任何人都可以评论是否使用精灵图像的决定吗？我看到了以下好处/权衡（其中一些可以减轻）：
单个图像上的精灵
优点：
- 管理的图像更少
- 更容易实现主题图像
- 图像交换（JS / CSS）发生得更快（因为它们不需要额外的图像加载）
- 由于 HTTP 请求较少，图像加载速度更快
- 需要缓存的图像更少（尽管总体 KB 几乎没有差异）
缺点：
- 更多的后台位置来管理
- 图像负载可能会过度 -膨胀（精灵可能包含未使用的图像），导致页面加载速度可能较慢
- 图像加载速度较慢，因为它们无法同步下载
Can anyone comment on the decision to use sprites for images or not? I see the following benefits/trade-offs (some of which can be mitigated):
Sprites over individual images
Pros:
- Fewer images to manage
- Easier to implement themed images
- Image swaps (JS/CSS) happen faster (because they do not require additional image loads)
- Faster image loads due to fewer HTTP requests
- Fewer images to cache (although virtually no difference in overall KB)
Cons:
- More background positions to manage
- Image payload may be over-inflated (sprite may contain unused images), causing page load may be slower
- Slower images loads because they cannot be downloaded synchronously
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为这个问题没有一个明确的答案。根据需要和个人喜好，意见会有所不同。
我的指导方针是始终评估最终用户的利益与开发人员的利益。 IE。作为开发人员，您所做的工作的真正价值是什么。
减少 HTTP 请求数量始终是优化网页时首先要解决的问题之一。正确使用缓存可以实现与使用精灵相同的效果。毕竟，图形通常可以缓存很长时间。
与将图形添加到精灵中相比，最小化脚本和样式表可能会带来更多好处。
用于管理精灵的代码可能会增加复杂性和开发人员开销，尤其是随着开发人员数量的增加。
在我看来，学习正确使用缓存头并正确配置您的网络服务器或代码通常可能是提高性能的更可靠的方法。
I don't think there's one definitive answer to this. Opinions will differ according to need and individual preference.
My guideline is to always evaluate the benefit for the end user vs. the benefit for the developers. ie. what is the real value of the work you're doing as a developer.
Reducing the number of HTTP requests is always one of the first things to fix when optimizing a web page. Proper usage of caching can achieve much of the same thing as using sprites does. After all, very often graphics can be cached for a really long time.
There might be more benefit from minimizing scripts and stylesheets rather than adding graphics into a sprite.
Your code for managing sprites might increase complexity and developer overhead, especially as number of developers increases.
Learning proper use of cache-headers and configure your web-server or code properly might often be a more robust way of improving performance in my opinion.
如果您有相当多的菜单条目想要在其中执行翻转图像，我建议您使用精灵系统，而不是执行多个图像，所有这些图像都需要单独下载。我这样做的原因与您在帖子中提到的内容非常一致，但做了一些修改：
图像交换不会用 javascript 完成；我见过的大多数精灵只是在无序列表中的链接本身上使用 :hover 。
根据文件类型/压缩，图像文件本身的下载可以忽略不计。在整体下载和加载方面，下载一张图像比下载多张图像通常更快。
If you've got a decent amount of menu entries in which you want to do roll-over images I'd recommend going to a sprite system as opposed to doing multiple images, all of which need to be downloaded separately. My reasons for so are pretty much inline with what you have mentioned in your post with a couple modifications:
The image swaps wouldn't be done with javascript; most of the sprites I've seen just use the :hover on the link itself within an unordered list.
Depending on the filetype/compression the download of the image file itself will be negligible. Downloading one image as opposed to multiple is generally faster in overall download and load.