Data URI Sprites
ebaytechblog.com> the images on the page change with every request based on the item specifics, therefore combining them into one sprite image is not possible.
It is very possible. Just include the sprite dimensional and positional info in an inline CSS stylesheet on the page and generate a sprite sheet as you would normally. Base64 data: URIs add tons of overhead which will definitely end up being much slower. Not to mention that they're using PNG when they should be using JPEG, which just worsens the issue even more.
I think the issue is that the images are different sizes, so putting size/location into CSS would require generating both CSS and a Sprite Sheet for each request.
With Data URIs, they can convert to Base64 ahead of time, and then just concatenate them into a JSON request as needed. This potentially saves them an HTTP request per page load because it means the CSS can be static. The decoding overhead is on the client, which in most cases should offer better user perceived performance than an extra HTTP request for a dynamically generated stylesheet, so it's just a matter of whether it's outweighed by the increase in file size.
When you have a million JPEG images, you would need to generate a sprite on-the-fly every time a random subset of those images is requested. You have to decode the images and encode the sprite each time. That sounds really slow.
Better convert them to Base64 and just concatenate the ASCII strings. Store each Base64 string text file next to the image file.
I agree however that they should use JPEG for their Base64 sprites.
>> Just include the sprite dimensional and positional info in an inline CSS stylesheet on the page and generate a sprite sheet as you would normally.
Which set of images do you generate sprite for? Take ebay search results page , for every search it displays a different set of images.How can we construct a static sprite a ahead of time? However we can generate a dynamic sprite.
I have to agree w/Sephr. No need for javascript and, if copy of image packing info is sent to image packing server at the same time, final image should be ready to serve by the time client requests it.
Unless I am missing something the title is wrong. CSS Sprite means that there are several images in single image file. This is just Data URI encoded images, not sprites. IIRC google used similar technique for the previews of pages in SERPs.
They're sending the Data URIs in a single JSON file, so it gives the same benefit (fewer HTTP requests) as normal CSS sprites. When you just combine multiple images into one (as you do for normal CSS sprites) you lose the information on the size/location of each sprite. An array of Data URIs keeps the images separate, so you don't need to put size/location information into CSS/Javascript/HTML.
This is a really cool performance hack. However, doesn't this restrict the effectiveness of the browser cache to just the exact set of images requested at one time? For example:
- On page load 1, I request images A.png, B.png, and C.png.
- The JSON for [A, B, C] is returned and cached.
- On page load 2, I request image B.png.
Is there something I'm missing? Otherwise, it looks really cool.
Yes, caching is only for the exact subset.
But you could do your own little client side cache. When receiving the url/img-data pairs, just store them in the HTML5 browser storage database, as key:url/value:img-data pairs. Then you are independent from the grouping into subsets.
And before requesting your next image sprite, just check with the client side data storage what images you already have and which you need to request.
Indeed, they'd cache the [A,B,C] case as well as the [B] one separately, which does reduce the effectivity of caching if there are many common assets and combinations. However in their case the set of images is (supposedly) wildly different per page, so I guess this is not much of a problem.
Not mentioned, but important for developers: IE8 limits data URIs to 32KB. Any larger than that, and it will refuse to render.
The IE8 limitation is for 1 image, the JSON response which is a combination of multiple images, will not have data URIs for images greater than 32KB.
Base64 encoded data URI JSON in single call Vs sprite image in single call