CSS Sprites vs. Data URIs: Which is faster on mobile?

I’m all for research and hard data, but I can’t help being a little sceptical of these results.<p>We use data: URIs all over the place, typically storing icons and other small graphics as background-image sources in CSS. Over the broadband connection I’m using right now (roughly 5Mb&#x2F;s download speeds) and with a cleared cache, our home page seems to be downloading and rendering in about 1.5s in all of the major browsers, and the lion’s share of that is downloading the HTML file first and then downloading various standalone images that we haven’t yet optimised at the end. Over a 3G mobile connection of dubious quality, in the browsers I can readily test with, there’s a lot of extra lag up-front, but little difference in the middle section where we download and render the CSS&#x2F;data: images. These results are both fairly consistent with what we’ve seen throughout development and testing, across a decent range of test scenarios over an extended period.<p>So while I’m not sure from these articles where the difference might lie, I don’t see how to reconcile the results we’ve seen with the idea that switching to data: URIs somehow slows things down by 6x or 10x as reported in the linked article series. I wonder whether either the people doing these experiments weren’t measuring what they thought they were measuring or perhaps they’ve hit an awkward use cases that some&#x2F;all major browsers don’t optimise well rather than a general problem with using data: URIs. The latter is certainly plausible, as there are cases with for example SVG where some browsers seem absurdly slow but everything works with the kind of performance you’d expect in others.<p>Meanwhile, data: URIs continue to have some concrete practical advantages for mobile, perhaps most obviously that they tend to circumvent mobile Internet providers “helpfully” compressing your graphics on the fly so they look terrible on your visitor’s 300dpi smartphone&#x2F;tablet display, which is a particular problem with image sprites if their compression starts bleeding one image into the next. For reasons like this, we’ve found that in practice our decisions about how to send graphics on web pages are rarely dominated by speed considerations anyway — though they surely would be if using data: URIs really slowed down our pages by a factor of 6-10x!

For completeness, it could be interesting to also test:<p>• separate image files: after the cost of the initial many-separate-loads (which might be minimized by pipelining&#x2F;SPDY), once reaching the cached-condition, might having them as individual artifacts again show some wins (no translations&#x2F;trimming; shorter&#x2F;simpler CSS)?<p>• data URIs inside CSS rather than HTML: on the off chance that leads to better post-data-decode image caching than re-parsing the cached HTML

The main takeaway seems to be: &quot;This is in spite of the fact that the CSS sprite actually requires an extra connection and incurs all the associated connection overhead including TCP slow start!&quot;<p>However, if the CSS file and sprite reside on the same server, and HTTP&#x2F;1.1 with keepalives is used, chances are that the sprite will come down a preheated TCP connection (and thus also foregoing an SSL handshake, if fetching via https). The article doesn&#x27;t actually mention how client and server are set up, and what the base network latency between them is.<p>It would be nice to see the test results with and without keepalives to see how this influences the results, as well as what the median network latency between client and server were during these tests.

Data URIs use base64 which adds quite a lot more the to image size. Ofcause it will be slower. Also, using Data URI over images will hang the users connection longer waiting for the Css to load before being able to see the page.

I&#x27;d be curious as to the underlying why here.<p>I imagine that CSS parsers aren&#x27;t particularly designed with any kind of parallel operation, whereas grabbing images (&amp; decoding them) is largely done in parallel (up to the number of max connections). So while you&#x27;re parsing the CSS you can be getting the images, offsetting the connection cost.<p>In the CSS case, the device needs to get the (slightly larger) CSS, un-gzip it (with more complex tables), Base64 decode - and then decode the image as before. I wouldn&#x27;t be surprised if this is a completely sequential activity with the rest of the CSS parsing.

I&#x27;d be interested in seeing these results with SVG.<p>There&#x27;s a lot of commonality between the images, <a href="http://g-ecx.images-amazon.com/images/G/01/common/sprites/sprite-dp-2._V384267953_.png" rel="nofollow">http:&#x2F;&#x2F;g-ecx.images-amazon.com&#x2F;images&#x2F;G&#x2F;01&#x2F;common&#x2F;sprites&#x2F;sp...</a><p>Even with Base64 encoding, much of that commonality would remain and thus I&#x27;d think that if you had all these sprites as SVG in a single file, as Data URIs, gzip would do a very good job indeed on the CSS file.<p>In a PNG sprite I wouldn&#x27;t be so sure.

Inlining all of your images as data URIs in your CSS is not a good idea because it will block the rest of the stylesheet from loading whilst images will not.

I must have missed the Data URI hype, because I&#x27;m not at all shocked that CSS spriting is faster than using Data URI. We are comparing using a binary image format, and a base64 encoded image inlined into CSS&#x2F;HTML.<p>What isthe basis or the source of the idea that base64 encoded images inlined into the CSS would be faster?

I have the same question as Jochem Bökkers and Anil Namde had in the comments - why wouldn&#x27;t you use both? I&#x27;m sure there&#x27;s a good answer, but I don&#x27;t understand.

I see the author has previous posts about what is not causing the delay, but what are the mostly likely culprits and do all browsers suffer similarly?

Might want to see whether this varies with the number of images (instead of 1) and the size (instead of 25kb).