Re:Google Fonts: more than a trillion served
by markdown on Sunday December 01, 2013 @11:02PM
(#6831483)
Don't forget that browsers will wait for the CSS file to download before rendering the page.
Far better to let "unnecessary" image files load later via separate HTTP requests than to delay everything just so that you can save one or two HTTP round-trips.
This is a big issue on mobile.
I'd advise comparing both methods on https://developers.google.com/speed/pagespeed/insights/
Re:Google Fonts: more than a trillion served
by Silhouette on Monday December 02, 2013 @07:14PM
(#6837601)
YMMV, but we did plenty of testing for one site I currently work on with a heavy mobile access focus, and it wasn't even close. We could have added hundreds of extra KB in a CSS file and still beaten even a single additional image file that needed a whole extra HTTP round trip for a visitor with a typical intermittent mobile connection (poor reception, on the move, etc.). The multiple levels of set-up required in that context can easily dominate the overall time to seeing a useful page.
Of course it's less of a dramatic comparison if you don't have all that set-up overhead to worry about, but then the time to download an extra 200K of CSS is negligible on basically any broadband or stable 3G or better connection today, so we don't tend to worry much about that sort of situation. In practice, our decision on how to transmit medium-sized images is often based on cache-related factors.
In terms of file size, a naive implementation of replacing reference to image files with data: URIs carries a theoretical overhead of 1/3. However in practice, as long as you're serving the relevant CSS file gzipped, you're likely to see less than 5% overhead on a single file. If you've got several similar image files converted to data: URIs within the same CSS file, you might even see a significant gain because the compression can remove more redundancy.
In terms of HTTP requests, generally fewer is better, so it's hard to go wrong here by using data: URIs instead of separate but relatively small image files.
The only major factor I can immediately think of that is clearly in favour of separate image files, unless you're really at the level where the decoding performance for data: URIs makes a significant difference, is that the image files can be cached independently, which may or may not be a win depending on how you manage your CSS and how often the various parts of it change relative to each other.