search

guardian / frontend

The Guardian DotCom.
https://theguardian.com
Other
5.85k stars 556 forks source link

Inline base CSS in the head #531

Closed commuterjoy closed 11 years ago

commuterjoy commented 11 years ago

The recent gzipping L3 problem reminded me of our large CSS call in the <head>.

Investigation with @phamann shows we could reduce the call to 3kb (gzip) of inlined CSS in every HTML page we serve - essentially the contents of the _base less directory - then further CSS could be loaded async.

Reading around the subject, Eg, http://calendar.perfplanet.com/2012/deciphering-the-critical-rendering-path, I think this will reduce perceived rendering speed to the user as well as DomContentLoaded times - @ahume ??

Background ...

The L3 problem is shown here. Increasing our CSS file from 50kb to 250kb (at 2pm) seemed to increase the DomContentLoaded times by 50-75%.

12-march-mDot-performance

ahume commented 11 years ago

Yes, prototype it. Would love to see us render article pages with just one HTTP request!

Definite trade-off though.

It's difficult to determine what the extent of FOUC would be on different pages. For example if galleries didn't have enough of their CSS on initial render, how much would that impact perceived performance as things jump around once the CSS loads. Presumably on larger screens you'd want the layout rules before render, etc... There's probably somewhere we could draw the line, and it would probably differ on different pages.

Async loading CSS seems to be a bit of a minefield, which I think is why browser's don't generally do it. I heard Scott Jehl (who wrote the eCSSential thing for Filament Group) say in a podcast the other day to just get your CSS down in one big blob fast.

We might get better return on investment (and less complexity) by splitting gallery/video/football/etc CSS into their own files, and not loading them on articles/fronts. I'd prefer to see that done first, because it should be pretty straight-forward. Same with JS.

Of course, the elephant in my head here is that there's the same trade-off with CSS on modern browsers as with JS (ie, <script async would be better for most of our users than the appendChild(script) we currently use). By being clever we lose preparser optimisations, prefetching DNS, and other nice things that Chrome/WebKit does. We're slowing modern browsers to better support old mobiles. I believe this is the right call at the moment, but in the future, as we all know, some server-side detection could fix this for us. :)

What modern browsers do: http://www.igvita.com/2012/06/14/debunking-responsive-css-performance-myths/

mattandrews commented 11 years ago

Good article on number of CSS files here: http://css-tricks.com/one-two-three/

On 13 March 2013 12:09, Andy Hume notifications@github.com wrote:

Yes, prototype it. Would love to see us render article pages with just one HTTP request!

Definite trade-off though.

It's difficult to determine what the extent of FOUC would be on different pages. For example if galleries didn't have enough of their CSS on initial render, how much would that impact perceived performance as things jump around once the CSS loads. Presumably on larger screens you'd want the layout rules before render, etc... There's probably somewhere we could draw the line, and it would probably differ on different pages.

Async loading CSS seems to be a bit of a minefield, which I think is why browser's don't generally do it. I heard Scott Jehl (who wrote the eCSSential thing for Filament Group) say in a podcast the other day to just get your CSS down in one big blob fast.

We might get better return on investment (and less complexity) by splitting gallery/video/football/etc CSS into their own files, and not loading them on articles/fronts. I'd prefer to see that done first, because it should be pretty straight-forward. Same with JS.

Of course, the elephant in my head here is that there's the same trade-off with CSS on modern browsers as with JS (ie, <script async would be better for most of our users than the appendChild(script) we currently use). By being clever we lose preparser optimisations, prefetching DNS, and other nice things that Chrome/WebKit does. We're slowing modern browsers to better support old mobiles. I believe this is the right call at the moment, but in the future, as we all know, some server-side detection could fix this for us. :)

What modern browsers do: http://www.igvita.com/2012/06/14/debunking-responsive-css-performance-myths/

— Reply to this email directly or view it on GitHubhttps://github.com/guardian/frontend/issues/531#issuecomment-14837620 .

Matt Andrews (@mattpointblank http://www.twitter.com/mattpointblank) Web Developer Guardian News and Media www.guardian.co.uk

Please consider the environment before printing this email.

Visit guardian.co.uk - website of the year

www.guardian.co.uk www.observer.co.uk www.guardiannews.com

On your mobile, visit m.guardian.co.uk or download the Guardian iPhone app www.guardian.co.uk/iphone and iPad edition www.guardian.co.uk/iPad

Save up to 32% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit guardian.co.uk/subscribe

This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way.

Guardian News & Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software.

Guardian News & Media Limited

A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP

Registered in England Number 908396

commuterjoy commented 11 years ago

@ahume @mattandrews See the hack at bf399b6

I've embed 3.3kb of CSS in the head - the least I could get away with without a nasty FOUC on articles - and deferred the bulk of it (36kb) to inside a domReady call.

I'm seeing quicker DomContentLoaded times in Chrome inspector, but I might be kidding myself.

Doesn't feel more responsive to the eye really.

phamann commented 11 years ago

Am unsure if we are ready for this yet, don't feel the CSS is modular enough yet. Something hopefully will change over the coming weeks.

I had some interesting discussions with @stephanfowler in relation to the swipe functionality, as that requires us to be more modular with our fragmentation for css and js files on a feature-by feature basis, so you can pre-load necessary code for features on potential next pages. I.e moving from an article to a gallery e.t.c.

commuterjoy commented 11 years ago

@phamann I agree really, one big css file is simple. Perhaps @stephanfowler could tackle swipe this week?

stephanfowler commented 11 years ago

@commuterjoy ok will do.

@phamann yes but no but... actually on-demand loading might not be worth the complexity in the context of swipe.

If we do go for on-demand loading of only the required modules/css - then for swipe we may obviously need to subsequently load other modules as needed by other page-types that we're preloading. But a constraint relates to how we actually do preloading. The least obtrusive method (at least wrt. server side & cacheing) is to ajax a normal page URL, regex out the header/footer from the un-parsed response text, then .innerHTML() the resulting text into a hidden element. The innerHTML method executes any

Githubissues.
  • Githubissues is a development platform for aggregating issues.