Saturday, December 12th, 2009

Performance of data URIs

Category: Performance

Rob Flaherty has done a little experimenting with data URIs and performance. The study only looked at Firefox 3.5 with empty cache, but the results were interesting for the questions they raise as much as the answers the provide.

He used a CSS file with 31 images and converted them all to data URIs using Nick Zakas’s CSSEmbed. For an extra variant, he used DURIS to extract the data URIs to a separate CSS file so that the basic CSS in <head> becomes much smaller and therefore loads much faster.

All three scenarios yielded similar performance – with HTTPWatch, the times were 1.35s, 1.13s, and 1.13s. So the two data URI scenarios were only marginally better. But more interestingly, a commenter from South Africa chimed in with wildly different results (using Firebug): 4.04s, 1.44s, 1.92s. The implication is clear: latency can be a big factor in some cases, and round-tripping to fetch 31 images is going to bring that out.

Another interesting factor is perceived speed. This is, after all, arguably the most important thing when it comes to performance. Although the two data URI scenarios completed in the same speed, the second setup felt faster because it got the images out of the way and allowed the main stylesheet to load fast. The data URI images were then loaded in a stylesheet at the bottom of the page, after a script had been loaded.

The study also raises questions about data URI loading. A commenter posted a waterfall showing the data URI images take significantly longer to load than regular downloaded images. This is the kind of thing that needs more research and why the study is interesting because of the questions it raises.

Rob also posted a study recently on background-image performance in various browsers.

Posted by Michael Mahemoff at 7:46 pm

4 rating from 28 votes


Comments feed TrackBack URI

This is a great study with some really interesting results. Nice!

Comment by btflynn — December 13, 2009

[also posted over on ravelrumba]

Do not load stylesheets in the footer. You’re not seeing the pain of doing this because you’re only looking in Firefox. Firefox charges ahead and renders the page before all stylesheets are downloaded. Chrome, Safari, and IE do the opposite – rendering is blocked until all stylesheets arrive at the browser.

Sprites and data: URIs are better than a bunch of separate background images. The choice between those two comes down to IE 6/7 support. Sites that have enough developer time to handle different implementations can choose the data: URI & MHTML path. Otherwise, sprites is the path – they’re more work to build & maintain, but they work across all browsers. Splitting images across two stylesheets will actually delay rendering in Chrome, Safari, & IE. So, if you’re doing the data: URI path, I recommend embedding the images in one stylesheet in the HEAD.

Comment by souders — December 14, 2009

It’s Nicholas Zakas, not Nick.

Comment by cancelbubble — December 14, 2009

Where result of your research? Read last message on (from Ruslan | December 1, 2009 at 3:39 am) and try test pages.

Comment by sirus — December 15, 2009

(also posted on ravelrumba)
I completely understand and agree that as a rule we want stylesheets in the header. But I wonder if this particular case with data URI images is an exception. Putting the embedded data URIs in the HEAD means everything else is blocked while the heavy stylesheet is d/led. This prevents background images too large to serve as data URIs from being kicked off until the data URI stylesheet has downloaded. A previous test I did showed that this blocking scenario can easily result in significant delays.

Isolating the data URIs in a footer stylesheet allows the regular background images to d/l in parallel with the data URIs. You could also argue it results in a more responsive page.

As Ruslan said, without a better solution it looks like a stalemate.

Comment by robflaherty — December 15, 2009

“The data URI images were then loaded in a stylesheet at the bottom of the page, after a script had been loaded.”

Just to be clear, he specifically loaded it after an externally hosted script file was loaded to force browsers to render the page even before loading the images.

However, I would note that another method would be to load the images css file via a javascript function and apply the styles after the page has loaded so the browser doesn’t even know about it while loading the page.

Comment by garyamort — February 6, 2010

Leave a comment

You must be logged in to post a comment.