Skip to main content
Topic: Base64 image uri's in CSS. (Read 3235 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Base64 image uri's in CSS.

Did a bit of reading up on this. Apparently, according to Google devs, it's slower than the old way.

http://stackoverflow.com/questions/1124149/is-embedding-background-image-data-into-css-as-base64-good-or-bad-practice

QuoteUPDATE: Bryan McQuade, a software engineer at Google, working on PageSpeed, expressed at ChromeDevSummit 2013 that data:uris in CSS is considered a render-blocking anti-pattern for delivering critical/minimal CSS during his talk

https://benfrain.com/is-it-worth-using-data-uris-for-image-assets/

QuoteSince originally writing this post a number of reports have come out to indicate that for the most part, using Data URIs in CSS is actually a render blocking anti-pattern (basically it will make your page seem slower, not faster, particularly on mobile).

This is claimed to hold despite the reduction in http requests. Has anyone looked into this in any depth?
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Base64 image uri's in CSS.

Reply #1

The original sentence from Bryan McQuade is:
QuoteLarge data URIs inlined in render-blocking CSS are harmful for render performance.
he talks about "large", sooo... dunno.
Bugs creator.
Features destroyer.
Template killer.

Re: Base64 image uri's in CSS.

Reply #2

Well I haven't watched the actual video, but the synopsis above it just says:

QuoteMy Chrome Dev Summit talk on Instant Mobile Web Apps. Summary:
render the initial view on the server, not the client. client-side rendering is a mobile performance anti-pattern.
minimize render blocking resources
    eliminate blocking JS in the initial rendering path
   
minimize (possibly inline) blocking CSS in the initial rendering path. this also means not inlining images in CSS as data URIs. doing so is harmful for time to initial render.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Base64 image uri's in CSS.

Reply #3

Just watching the video, and he gets to the base64 stuff at about 22:47.

What it comes down to is that if you use base64 for the images they become blocking content. IOW, nothing else will render until the image is rendered.

OTOH, if you use the old school url for the image it is not blocking content. The rest of the HTML will render before the image. So unless the image is critical and the other HTML isn't, it looks like the best bet is image url's.

ETA: The sentence about "large" uri's is at the end of the video in the last few seconds, but from what he said earlier it sounds like he thinks pretty much all base64 uri's are "large".
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Base64 image uri's in CSS.

Reply #4

This is interesting too: https://www.giftofspeed.com/defer-loading-css/

The script at the end of that article being the really relevant part.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Base64 image uri's in CSS.

Reply #5

Interesting reading.  

I've seen quite a few lazy load type scripts, especially with webfonts.  Almost seems like a trick just to get google page speed to show high numbers for a site.  Some of that, to me,  hurts the end user experience, either with FOUT or the white page (like opacity 0 on the html) until everything is loaded and then the fade in.   Really not sure whats right vs cool to do these days.

Re: Base64 image uri's in CSS.

Reply #6

Yeah I'm not sure about the lazy loading either. Just saw it, read it, and thought I might as well link it.

The use case for a forum is not as simple as the example given in the video, since that was for a mobile app which will have users always landing on the same page initially. That makes heavy optimisation of that page possible, which is not the case with something like a forum where people may land on almost any page initially. So a forum is going to be forced to load a lot more CSS up front just to cover all bases, although where the CSS can be broken down into different files for different areas that should still be an advantage.

The rest seems to make sense though. If standard url's in CSS render after the rest of the HTML (which they do) and base64 uri's put a blocking step at each image (which they are claimed to do) then that would be a good argument for not using uri's too much. I must admit I do prefer url's simply because they make the files more readable, and readable files are a lovely thing to have, but if url's also have a performance advantage (at least in some instances) then I'd be even more wary of going with base64 uri's by default.

I'd be interested to find out more about this.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P