[throwaway03cc]

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.

[jchulce]

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

[ajross]

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.

[Scaevolus]

The overhead is slightly worse when it's compressed alongside normal HTML content (the Huffman trees aren't so favorable).

    $ wget http://en.wikipedia.org/wiki/ASCII
    $ (cat ASCII;dd if=/dev/urandom bs=8000 count=1 | base64) | gzip | wc -c
    50578
    $ (cat ASCII;dd if=/dev/urandom bs=9000 count=1 | base64) | gzip | wc -c
    51621

Around 4% overhead. Either way, it's negligible.

[b1tr0t]

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

[byroot]

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

[b1tr0t]

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)