data: URI and performance, or how to slow down Firefox 10 (ten) times

Actually, from the title should be almost everything is clear. But the picture is not very much in the topic: on it you need to draw Fox, creeping after catching up with IE.

This post is the answer to “Over the Hill” , because there were a couple of free hours, and there was something to occupy.

UPD A plugin was found - Wappalyzer - which slowed down the display of data: URI in Firefox by an order of magnitude. But even with it turned off, Firefox continues to play almost all browsers.
')
But all in order.

Prehistory

A few months ago, an American (with a Russian name like) knocked me on Skype and asked what I know about the latest optimizations from Yahoo! (well, those where they data: URI finally implemented ) and especially about the performance of data: URI. I said that, probably (because data: URI is a picture in base64), the latter work somewhat slower than normal background pictures, and it seems like they should slow down.

I quickly assembled the preliminary environment and after half an hour I gave preliminary results: data: URI is inhibited, but sometimes it is very much inhibited. Such a situation seemed to me suspicious, so I pushed the idea until better times. And here they are :)

Test environment

If it is very short, then correctly measure the rendering of the page in the browser - the task is very, very difficult. In this case, it is solved in a very rough approximation (which is enough for a general assessment of the situation, but it is not specifically used anywhere else). We insert the timer to the top of the page, on the onload hang the completion of the countdown. The whole mechanism will work either on the local computer (to eliminate network delays), or on a server with hard caching (browsers do not re-request resources with conditional caching headers during one session: this will be checked, maybe I'll post an article on this topic).

Fine. As a result, we have a “local” page (after the first request the page closes the tab with it, open a new tab and open the original page in it: this creates the necessary “purity” for the experiment), which is displayed in the browser from the hard disk. After that, the rendering time will (by 99%) depend on the features of the browser, and not on the speed at which resources are received.

Additionally, of course, all the tests were run 10 times. 3-delta emissions were not taken into account. As a result, the overall accuracy is not less than 10% (i.e. everything is most likely an error of 3-5%).

Test One: pictures against the background

Once upon a time there were recommendations against the use of ordinary images. It was recommended to do everything in the background images. This is not the case (displaying the cached page in ms).

Test	Chrome2	Fx3.5	Opera10	IE8	IE6 / 7
"Clean" pictures	33	ten	52	189	182
Background pictures	124	eleven	47	181	130

As we can see, only Chrome “came off” (Safari was not taken into account because of wildly optimized timers that work “too quickly” ), but this is imperceptible from the background of the main browsers.

Conclusion: there is essentially no difference. Especially if we take into account the total working area of ​​images of 670,000 square pixels (it will be further explained why this is a bit).

Test two: performance data: URI / mhtml

We go further. Remember that data: URI only supports IE8, for IE6 / 7 you need to use mhtml . Additionally, IE8 does not support images larger than 24 KB. Therefore, in the table for IE, the results are mhtml, for the rest - data: URI.

Test	Chrome2	Fx3.5	Opera10	IE8	IE6 / 7
data: URI and mhtml	56	162	70	225	442

Some brakes are already noticeable here. For Firefox, rendering the same images cost 10 times harder. But we are considering the use of these techniques for background images? And for them:

Test	Chrome2	Fx3.5	Opera10
background pictures in data: URI	83	155	69

The general trend, as we see, remains. But that is not all

Output: data: URI slows down in Firefox, mhtml slows down in IE.

Test three: performance of a large amount of data: URI / mhtml

Attentive readers have long prepared a question: what do the same incredibly large pictures show us. On the "real" sites, everything is different! I hasten to disappoint them: CSS Sprites 1000 by 1000 pixels (million square pixels) are not so rare. On average, on each site, 5–20% of the page area is occupied by background images. At a resolution of 1200x1024 it is approximately from 60 to 250 thousand square pixels (that is, only 3-10 times smaller than the original images).

But why it got there, let's take 80 different images (with a total area of ​​160 thousand pixels) and see how browsers draw from. And this is how (IE8 uses data: URI):

Test	Chrome2	Fx3.5	Opera10	IE8
many pictures in data: URI	65	105	85	99

Something like, right? Yes, we reduced the total size of images by 4 times, but with an increase in the number of objects by 40 times (from 2 to 80), the situation almost repeated. On real pages there are several dozens, sometimes even a couple of hundreds of background images. Those. our tests are getting closer and closer to reality.

Conclusion: the slow base64 rendering depends not only on the size of the area, but also on the number of objects.

Test Four: face to face does not see

But here again there was a slight slyness: after all, we do not know how browsers will behave if they see the same number of ordinary images on the page - how will they “slow down” in this case? For this purpose, 2 more identical environments were collected. For each used 2 different images and 10 objects, cutting out of them the background.

Test	Chrome2	Fx3.5	Opera10	IE8	IE6 / 7
background pictures	124	24	63	166	131
background pictures in data: URI	41	140	73	-	-

For IE6 / 7/8, you can extrapolate the results obtained from mhtml-pages, or rebuild environments with mhtml background images. But the main results can be said right now.

We take the browser usage statistics, multiply the browser share by the relative acceleration when using CSS Sprites (i.e. background images) versus the data: URI / mhtml approach. We get a figure of 100ms for our total area of ​​5 * 670000 = 3.35 million pixels (and 10 objects). For an “average” site with 50 objects with background images and 100 thousand pixels in the total area, we will get about 15 ms of delay when displaying each page (no matter how many resources are in the browser cache, the network delays have already been played). If we have a few hundred objects with background images, and a total area of ​​one million pixels (for example, some complicated web interface), then the average delay for users can grow up to half a second or more. Such are the pies.

Conclusion: data: URI + mhtml can significantly slow down.

What to do?

It would be nice if Firefox and IE take care of fast page rendering and can display base64-data as quickly as regular images. In this case, the use of multiple base64-images will, in general, be no worse than CSS Sprites. Now the best way is to pre-use CSS Sprites, and then convert the minimum number of images into base64-format, thus all costs will be minimized.

PS If someone really does not like the photos on the test pages - skip, please, links to any suitable in size - I will replace. Just nothing more was at hand :)

PPS All calculations in this note are estimated. They are designed to show only the "weak points" of images in base64-format, and not to give a clear algorithm for calculating when they can be used and when not.