对 SQL 的 Ajax 请求将数百张图像返回到 JSON -> CSS 精灵？ Base64？
我们正在编写一个基于 Web 的活动日历，其中包含 SQL 数据库中的数千场戏剧表演、节日和音乐会。
用户访问网站，执行搜索，SQL 服务器返回 JSON，客户端的 jQuery 代码显示 200 多个事件。
我们的问题是每个事件都有一个图像。如果我返回 URL，浏览器必须对这些微小 (2-4Kb) 图像发出 200 多个 HTTP GET 请求。
将所有图像打包到一个 CSS 精灵中是很诱人的，但由于用户搜索可以返回图像的任意组合，因此这必须动态完成，并且我们将失去对缓存的控制。每次搜索都必须以全新的 CSS sprite 返回每个图像。此外，我们希望避免任何需要从文件系统动态读取或写入的解决方案：这太慢了。
我宁愿返回二进制图像作为 JSON 的一部分，并跟踪我们已经缓存的图像以及我们真正需要的图像。但我不知道怎么做。好像需要转换成Base64？有这方面的示例代码吗？
感谢您提供的任何帮助！ :)
We are writing a Web-based events calendar with thousands of theatre shows, festivals, and concerts in a SQL database.
The user goes to the Website, performs a search, the SQL server returns JSON, and jQuery code on the client side displays the 200+ events.
Our problem is that each event has an image. If I return URLs, the browser has to make 200+ HTTP GET requests for these tiny (2-4Kb) images.
It is tempting to pack all the images into one CSS sprite, but since the user searches can return any combination of images, this would have to be done dynamically and we'd lose control over caching. Every search would have to return every image in a brand new CSS sprite. Also, we want to avoid any solution that requires dynamically reading or writing from a filesystem: that would be way too slow.
I'd rather return binary images as part of the JSON, and keep track of which images we already have cached and which we really need. But I can't figure out how. It seems to require converting to Base64? Is there any example code on this?
Thanks for any help you can give! :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您正在使用的网站 (StackOverflow) 必须为问题页面中显示的 50 个问题提供 50 个头像。它是如何做到的？ 浏览器发出 50 个请求。
我想说，你最好实现分页，这样列表就不会变得太大。您还可以在背景上或当用户滚动并到达图像时加载图像。
跟踪下载的图像不是我们的工作，而是浏览器的工作。我们的工作是确保 URL 唯一且一致，并且响应标头允许缓存。
此外，base64 将使流长度至少延长 33%，而它在客户端的处理并不是微不足道的 - 我从未见过一个实现，但可能有人已经为此做了一些 javascript。
我相信您所需要的只是分页。
The web site you are using (StackOverflow) has to provide 50 avatars for 50 questions shown in the questions page. How does it do it? Browser makes 50 requests.
I would say, you had better implement pagination so that the list does not get too big. Also you can load images on the background or when the user scrolls and gets to the image.
Keeping track of images downloaded is not our job, it is browser's. Our job is to make sure the URL is unique and consistent and response headers allow caching.
Also base64 will make the stream at least 33% longer while it's processing on the client side is not trivial - I have never seen an implementation but probably someone has done some javascript for it.
I believe all you need is just pagination.
看起来原始发帖人基本上已经自行采用了这个解决方案，但是根据他们对 33% 空间开销的评论，我认为他们没有观察到将一堆图像进行 Base64 转换为一个图像时出现的意外现象响应实体然后对其进行 gzip 压缩...无论您相信与否，这很容易产生小于未编码图像文件总和的整体传输大小，即使每个未编码图像也单独进行了 gzip 压缩。
我在此处深入介绍了这种用于加速图像呈现的 JSON 技术CSS sprites 的替代品，包含几个实时示例。它的目的是表明它是一种优于 CSS 精灵的技术。
It looks like the original poster has proceeded with essentially this solution on their own, however based on their comment about 33% space overhead, I don't think they observed an unexpected phenomenon that you get when base64-ing a bunch of images into one response entity and then gzipping it...believe it or not, this can easily produce an overall transfer size that is smaller than the total of the unencoded image files, even if each unencoded image was also separately gzipped.
I've covered this JSON technique for accelerated image presentation in depth here as an alternative to CSS sprites, complete with a couple live samples. It aims show that it is often a superior technique to CSS sprites.
数据从来都不是随机的。例如，您可以为精灵命名
或以任何方式组织搜索。这可能是值得的。或许。
你需要做数学计算
Data is never random. For example you could name your sprites
or however you organise your searches. This might be worth it. Maybe.
You'll need to do the math
这就是我们的决定。
创建精灵有一些缺点：
为了减少图像丢失，我们需要将原始图像存储为 PNG，而不是服务器上的 JPEG。这会增加速度，并且使用 ImageMagick 创建动态 CSS 精灵已经相当慢了。
为了减小图像大小，最终的 CSS 精灵必须是 JPG，但 JPG 是有损的，并且对于图像网格来说，当 JPG 尝试混合和压缩时，边缘会变得很奇怪。我们可以通过在所有图像周围放置空白边框来解决这个问题，但即便如此，这也会增加复杂性。
使用 CSS sprites，智能缓存变得更加困难；无论我们过去发送过什么，我们都必须打包所有图像。 （或者我们必须保留所有旧的 CSS 精灵，无论它们是否包含我们仍然需要的许多或很少的图像）。
恐怕我们有太多用于预计算 CSS sprite 的日期-类别-位置组合，尽管我们肯定可以通过这种方式处理部分数据
因此，我们的解决方案是对其进行 Base64 处理，以实际一张一张地发送每个图像。尽管开销为 33%，但编码和管理的复杂性要低得多，并且当考虑到缓存问题时，甚至可能会减少数据传输。
谢谢大家对此的建议！
Here is what we decided.
Creating sprites has some downsides:
To reduce image loss, we need to store the originals as PNGs instead of JPEGs on the server. This is going to add to the slowness, and there's already quite some slowness in creating dynamic CSS sprites with ImageMagick.
To reduce image size, the final CSS sprite must be a JPG, but JPGs are lossy and with a grid of images, things get weird at the edges as JPG tries to blend and compress. We can fix that by putting a blank border around all the images but even so, this adds complexity.
with CSS sprites, it becomes harder to do intelligent caching; we have to pack up all the images regardless of what we've sent in the past. (or we have to keep all the old CSS sprites regardless of whether they contain many or few images we still need).
I'm afraid we have too many combinations of date-category-location for precomputing CSS sprites, although surely we could handle part of the data this way
Thus our solution is to Base64 it, to actually send each image one by one. Despite the 33% overhead, it is far less complex to code and manage and when you take caching issues into account, it may even be less data transfer.
Thank you all for your advice on this!