<style> tag to inline style=”" attrrib

June 21st, 2012. Tagged: CSS, performance

As you may have noticed, I claim that CSS is bad for performance because:

  1. Most browsers block the very first paint until all screen CSS arrives
  2. Additionally many browsers block rendering until all non-screen (e.g.print) CSS arrives
  3. 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!

Tell your friends about this post: Facebook, Twitter, Google+

19 Responses

  1. 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.

  2. 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”

  3. 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?

  4. 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.

  5. 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.

  6. 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? )

  7. 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.

  8. 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.

  9. @Jascha, heh, we live on Planet Performance (perfplanet.com) :)

  10. @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!

  11. Time is Money!
    keep on doing A Great work :)

    +1 for your comment Stoyan!

  12. 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……

  13. 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”) ?

  14. Did you test include minifying the HTML also, after the CSS had been inlined?

  15. 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

  16. I am genuinely pleased to read this weblog posts which consists of lots of helpful facts, thanks for providing such statistics.

  17. HTTP://www.viwawa.com

    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!

  18. I get the point, but I think it is worth noting that a default Content Security Policy disables inline styles – and for good reason – http://channel9.msdn.com/Events/Blue-Hat-Security-Briefings/BlueHat-Security-Briefings-Fall-2012-Sessions/BH1203

  19. hfghfghfghfghfghgh
    fgh
    gfhfg
    hfgh
    fh
    fgh
    fghfg
    hfg
    hfghfg
    hhfghfghfhfghfg
    h
    hfgh
    gfh
    gfh
    gfh
    fgh
    gfh
    gfh
    fgh
    fgh
    fg
    hfg
    h
    fgh
    gfh
    fgh
    fgh
    fg
    hfg
    hfg
    f
    hf
    hf
    hfg
    hfg
    hfg
    h
    fgh
    fgh
    fgh
    fgh
    fghfg
    hfg
    hfg

Leave a Reply