使用数据内联图像的最佳实践：-URLs？ [英] Best practice for inlining images using data:-URLs?
问题描述
我有一个简单的rails应用程序，它使用 canvasContext.toDataURL（）存储用户在HTML5网站中创建的图像。有一个索引动作，它显示缩略图列表，并显示每个图像的显示动作，显示图像。
我在后端完全懒惰，我只保存base64编码的 data：image / png; base64，... 原始图像的字符串和缩略图，这也是客户端生成的。这些图像使用< img src =data：/> URIs包含在页面中。
现在，因为在v9之前IE并没有完全支持这个功能，所以我将不得不实施某种解决方法，可能需要使用 data - 来生成生成的图像的URL。属性，然后在使用jQuery进行页面加载后替换源属性。
这引出了一个问题，是否使用
是否有任何建议或最佳做法？图像可能高达500 KiB，并且它们每个仅被使用一次。包含图像的页面一旦创建就不会改变，所以它应该可缓存很好，包括图像。包含缩略图（大约60 KiB）的索引页面使用分页，因此该页面几乎不可缓存。您可以假设HTML页面在制作过程中会缩小或压缩。 解决方案
最佳做法是：不要。 / p>
无论如何，您将需要一种解决方法，它将完全复制基本功能，所以您只是另一个地方可能会出错以及更多需要测试的案例。
你说图像应该是非常缓存的，但是你发送的图像不允许包含缓存信息。但是，使用更常见的方式通过单独的HTTP请求发送图像，您可以发送过期和最大年龄请求以指示图像在一年内不会更改。如果您对图像不会改变充满信心，您还可以设置最后修改的和电子标签（您甚至不需要任何逻辑来决定etag，只需发送IMMUTABLE作为标签），并且通过发送304来响应每个有条件的GET，甚至没有检查（因为再次，如果你是超级自信的话，你只能这样做，否则尽管你仍然可以对304进行更常规的检查） 。
如果图像只被使用过一次，然后让图像由创建它的东西提供服务，并根据查询中的某些识别特征（基于特定到你在做什么），并将它写入到浏览器的流中。你仍然可以在你的应用程序中进行更好的分离，让它在自己的位置完成。
即使使用gzip，你也不会超过流的大小。
I have a simple rails app that stores images created by users in an HTML5 site using canvasContext.toDataURL(). There's an index action, which shows a list of thumbnails, and a show action for each image, showing the image.
I'm being absolutely lazy in the backend here, I just store the base64 encoded data:image/png;base64,... Strings of the original image and a thumbnail, which is also generated in the client. The images are included in the page using <img src="data:"/> URIs.
Now, since this isn't fully supported in IE before v9, I will have to implement some kind of workaround, probably by including the URL of the generated image using a data- attribute and then replacing the source attribute after page load using jQuery.
This brings up the question whether it's good practice to inline rather large images into HTML using data: URLs...
Are there any recommendations or best practices? The images might be up to 500 KiB, and each of them is used only once. The page containing the images will not change once created, so it should be cacheable pretty good, including the image. The index page containing the thumbnails (which are around 60 KiB) uses pagination, so the page will hardly be cacheable. You can assume that the HTML pages will be deflated or gzipped in production.
Best-practice is: Don't.
You'll need a workaround anyway, which will completely duplicate the basic functionality, so you've just another place things can go wrong and more cases to test.
You say the images should be very cacheable, but you're sending them in a way that doesn't allow you to include information about caching. However, with the more common approach of sending images over a separate HTTP request, you can send expires and max-age requests to indicate the image won't change for a year. If you're super-confident that the image won't change you can also set a last-modified and an e-tag (you don't even need any logic to decide on the etag, just send "IMMUTABLE" as the tag) and respond to every conditional GET by sending a 304 without even checking (because again, you only do that if you're super-confident, otherwise though you can still implement a more conventional check for 304).
If the image is just used once, then have the image served by something that creates it and writes it based on some identifying features in the query (just what is specific to what you are doing) and writes it to the stream to the browser. You'll still have nicer separation within your application to have this done in its own place.
Even with gzip, you aren't going to beat this on stream size.
这篇关于使用数据内联图像的最佳实践：-URLs？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
