<style> tag to inline style=”" attrrib
As you may have noticed, I claim that CSS is bad for performance because:
- Most browsers block the very first paint until all screen CSS arrives
- Additionally many browsers block rendering until all non-screen (e.g.print) CSS arrives
- Sometimes CSS blocks downloads
See "The evil that CSS do" in CSS and the critical path for details.
CSS is the critical path to delivering any UI in the browser. Images arrive whenever, JS can be async.
So any page needs to get CSS out of the way ASAP.
Simple, highly optimized pages (e.g., e.g.) reduce CSS to the bare minimum and then shove it inline in a <style> tag.
ExCeSS
It's a fact of life that there will always be unused CSS, no matter how hard you try to reduce it. (Run PageSpeed for a proof)
Take the simplest CSS: your reset.css
It has stuff like
h1, h2 , h3, ..., abbr, blockquote{ margin:0; ....}
All the HTML tags are in there. But do you have all the tags in the page? Unlikely. So there's excess CSS even at the very base. It usually gets much worse from here. Whole features may or may not be in the page or combined in different ways, but the CSS to handle all combinations is always there, omnipresent.
To style="" attrib
I saw today that Mailchimp has this CSS inliner tool. (Because mail clients often strip <style>). It takes the <style> tags in the markup, strips them and adds style="" attributes where applicable.
I decided to give it for a spin with Facebook like and Google search's HTML. Remember: these are two already highly optimized pages.
Assuming the tool works correctly, the results were pretty impressive.
- Like: 8,133 bytes from 10,115 (20% reduction, 23% after
`gzip -9`) - Search: 63,508 from 90,846 (30% reduction, 27% post gzip)
I know, I know what you'll say: inline style="" is an abomination. Should we bring <font> back? What about the cascade? Is this transformation needed on every page view with dynamic content, how's that scalable? What if there's a lot of content with the same class, lot of duplicates?
I know, I know.
But, but... look at the results. 25% reduction of the HTML payload!
With web development moving more and more toward transformations and compilation (css preprocessors, coffee script, monification, etc) it may not be unthinkable.
Back to Earth
On more realistic note, just reduce the CSS to under 2K or thereabouts, inline it in the head, send it with the the first server flush (even before any data fetching) and you'll be in a good place already!
This entry was posted on Thursday, June 21st, 2012 and is filed under CSS, performance. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
Get notification for future posts: follow me on Twitter or subscribe to my RSS feed
June 21st, 2012 at 1:31 am
Sure, that’s great if your entire site is one page. Otherwise, though, putting your CSS in separate files and then serving them with an expiration date suitably far in the future so they can be cached properly will win every time. Reducing bytes is good; not having to send them at all is better.
June 21st, 2012 at 2:10 am
inline all css?
That’s like saying “use a knife as your only utensil! It’s sharper than all the others! No more need for spoons or forks”
June 21st, 2012 at 2:58 am
Interesting idea…
Wonder what effect it has on repeat views, next page load time etc.
And how many pages do they have to view before the saving is negated?
June 21st, 2012 at 3:07 am
I’m a big fan of inlining CSS on top, specially on pages I don’t expect users to return so soon or very often and yet give them a fast experience. Steve Souders covered in his first book a way to serve inline for first time visitors then pushing css/js once idle then setting a cookie, so on next visits the assets will come from cache (win win), not sure how reliable is such technique since cookies might “lie” about which asset users have in their cache.
June 21st, 2012 at 3:35 am
A 2KB savings is irrelevant from a user experience point of view. The guy paying the bill for bandwidth might care about this but it will be an imperceptible difference to the end user. What’s more interesting to me is the elimination of http requests.
I suppose in certain scenarios depending on the content (ex. max concurrent connections is exceeded in old IE) of the site this might provide a performance benefit.
June 21st, 2012 at 5:52 am
I can agree with inline-styling only on one condition: it’s a third-party content.
those can slow down your page really bad, throw additional files and there’s no way to control it.
@ unused css – it’s developer’s task to take care of that and investigate what’s really needed, what’s not and get rid of it – might be time consuming, but can pay off in shaved-off bytes
but inline-styling all things – bad, bad idea ( especially when it comes to pages with repeating content… which makes it ~90%* of them? )
June 21st, 2012 at 6:44 am
A compromise which might make your page appear to load faster would be to inline your base layout styles, such as the grid system, margins and paddings, etc. The theming and colors – most likely the bulk of your CSS – can be loaded as an external and cacheable resource.
June 22nd, 2012 at 3:12 am
I dont know where you guys live, but in most countries in europe, pageloading time is not a concern due to fast internet connections..
as long as your website loads as fast as other major international websites, visitors are happy.
also, most pageloading time can be reduced by using a fast webhost with good uplinks and cdn.
June 22nd, 2012 at 1:17 pm
@Jascha, heh, we live on Planet Performance (perfplanet.com)
June 22nd, 2012 at 4:52 pm
@Jascha I don’t know where you live, but here, 25 km south of Paris, France, I have a really slow 3G connection, any performance boost is welcome!
June 23rd, 2012 at 4:00 am
Time is Money!
keep on doing A Great work
+1 for your comment Stoyan!
June 25th, 2012 at 5:50 am
CSS es malo para el funcionamiento del Web site…
Estas son las razones? La mayoría de la transferencia directa del Web site del bloque de los browsers hasta que llega toda la pantalla CSS A veces CSS bloquea descargas sugerencia Reducir l……
June 26th, 2012 at 2:03 am
1) for single page apps this is of course good idea
2) is this mostly justified by average pageviews per user ? i mean, if the user views 2-3 pages from a site, and his cache does not survive till next visit, then its nice. But if you have some site with many hits per day (social network, browser game) – inlining css will hurt you and your users.
3) as you know, Opera does not block rendering, so (keeping in mind the fact that many features from Opera were then borrowed by other engines) – maybe we can hope that css will be fixed in all major browsers (sans “The non-updatable one”) ?
June 26th, 2012 at 5:14 pm
Did you test include minifying the HTML also, after the CSS had been inlined?
November 3rd, 2012 at 1:47 am
Confident, that’s fantastic if your whole site is one site. In any other case, although, getting your own Style sheet in separate data files then providing all of them with an conclusion day appropriately much later on for them to be cached effectively may win every time. Reducing bytes is nice; without
March 29th, 2013 at 3:20 am
I am genuinely pleased to read this weblog posts which consists of lots of helpful facts, thanks for providing such statistics.
May 6th, 2013 at 6:36 am
This is very interesting, You’re a very skilled blogger. I’ve joined your rss feed and look forward to seeking more of your great post.
Also, I have shared your web site in my social networks!