Live data from Hacker News

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

mobify.com

1–10 of 25 posts

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

#3

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.

IIRC CSS downloading is not blocking until the browser have to execute some JS.

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

#4

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.

even though base64 increases raw size by about a third, this is mitigated by gzip or deflate encoding by the webserver. The actual transmitted size is only about 5% bigger

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

#5
post #4

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.

even though base64 increases raw size by about a third, this is mitigated by gzip or deflate encoding by the webserver. The actual transmitted size is only about 5% bigger

I measure less than that:

    dd if=/dev/urandom bs=1024 count=64 | base64 | gzip | wc -c
    64+0 records in
    64+0 records out
    65536 bytes (66 kB) copied, 0.0127386 s, 5.1 MB/s
    67302
This particular run comes out to ~2.7% overhead, and in fact it's very repeatable. The half dozen runs I did were within 20 bytes of each other.

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

#7
post #6

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

I wouldn't imagine having two or more images would make much of a difference until you start reaching the max # of TCP connections per host, since these images would download in parallel. Would still be interesting to see results for.

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

#8
post #6

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

I wouldn't imagine having two or more images would make much of a difference until you start reaching the max # of TCP connections per host, since these images would download in parallel. Would still be interesting to see results for.

Article author here -- I agree, it would be interesting to see results. One reason for using more than a single image: no navigation timing API in iOS.

iOS may now lag behind Android in handsets shipped -- but it's still a dominant player in web visits on mobile!

Unfortunately that means that for RUM tests I needed to have results that were insensitive to differences of a few ms.

Here's a petition asking Apple to include the navigation timing API in a future iOS release:

http://www.change.org/petitions/apple-please-support-navigat...

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

#9
post #5
post #4

Earlier quoted context omitted.

even though base64 increases raw size by about a third, this is mitigated by gzip or deflate encoding by the webserver. The actual transmitted size is only about 5% bigger

I measure less than that: dd if=/dev/urandom bs=1024 count=64 | base64 | gzip | wc -c 64+0 records in 64+0 records out 65536 bytes (66 kB) copied, 0.0127386 s, 5.1 MB/s 67302 This particular run comes out to ~2.7% overhead, and in fact it's very repeatable. The half dozen runs I did were within 20 bytes of each other.

Dead on! The overhead with gzip is very tiny. The size of the payload should also not be a factor in the cached condition.

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

#10
post #3

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.

IIRC CSS downloading is not blocking until the browser have to execute some JS.

The first CSS file on a page is blocking for all modern browsers regardless of JS or no JS.

Exceptions for:

* media queries, which are evaluated, if the CSS is not applicable it isn't downloaded

* disabled stylesheets which are ignored

(edited for formatting)

Post reply on HN