Google recommends inlining small CSS • Hacker News Board

Re: Google recommends inlining small CSS

#51

Post by oneeyedpigeon » Tue, Jan 12, 2016, 11:46 AM UTC

seanwilson wrote: post #38

laurent123456 wrote: post #29

Earlier quoted context omitted.

Also, since they are talking about optimization, I wonder why they make embedded fonts a requirement to view their plain-text page. I disable loading of fonts because it's useless and often slows everything down, and this is how their page look without these fonts: http://i.imgur.com/oDO8gRt.png

I imagine the vast majority of web users have font loading enabled so they optimised and tested for that.

So, ... screw the minority? Seriously, one of the benefits of the web stack is that it makes it very easy to cater for a wide variety of capabilities, rather than resorting to "Best viewed with Internet Explorer 5"-type behaviour.

Re: Google recommends inlining small CSS

#52

Post by Nutmog » Tue, Jan 12, 2016, 11:47 AM UTC

Whatever happened to the programming rule of don't micro-optimize until you've measured the performance? There seems to be a lot of recommendations to do ugly things to websites in the name of optimization, but they still add complications that are hard to understand. Pictures used to by supposed to be optimized by pre-scaling them to the size they'd be displayed at. Now we have retina displays and that doesn't work anymore. You have to do more complicated things instead. HTML and co has become very low level-like and almost complex enough that perhaps humans shouldn't be doing it. It reminds me of the days of assembly language and all the ugly little tricks to squeeze out more clock cycles that are now handled by compilers.

Re: Google recommends inlining small CSS

#53

Post by thirdsun » Tue, Jan 12, 2016, 11:51 AM UTC

pkorzeniewski wrote: post #37

I remember a CSS class in some enterprise software I was working on several years ago: /* bold */ .bold { font-weight: bold !important; } It has became my favourite real-world example of CSS misusage :)

I agree with jdudek here. While I'd never use important, I usually have a lot of small utility classes like bold, italics, uppercase, truncated etc.

I don't see what's wrong here - they come in handy when you need a one-time style alteration.

Re: Google recommends inlining small CSS

#54

Post by tuzemec » Tue, Jan 12, 2016, 11:53 AM UTC

pkorzeniewski wrote: post #37

I remember a CSS class in some enterprise software I was working on several years ago: /* bold */ .bold { font-weight: bold !important; } It has became my favourite real-world example of CSS misusage :)

It's quite common to have such classes if you work with some kind of CMS system. In one of my previous companies we had bunch of similar classes that allowed basic layout adjustments (like margins, paddings, font-sizes). It's quite handy if you want to just edit the html and do not touch the css files at all.

Re: Google recommends inlining small CSS

#55

Post by andrewingram » Tue, Jan 12, 2016, 11:54 AM UTC

danjordan wrote: post #44

andrewingram wrote: post #36

The problem i've always had with this, and the "above the fold" rule as it appears in the pagespeed insights tool, is the definition of "fold" varies wildly. So I see CSS optimisation as a multi-step process. * Switch to a component-based rendering architecture (I favour React) * Map CSS rules directly to components (I use CSS Modules) * Have a JavaScript entry-point per route. The entry-point should only contain wha…

Does this have any negative effects on browser caching?

The only part of the process that's a bit weird is loading style sheets programmatically. But I think people normally do that by adding a link tag to the DOM, so it should use browser caching as usual.

The other caveat is that the nature of generating common bundles automatically means that what's in those bundles will vary whenever the code is changed. This means that you'll lose the benefits of browser caching each time you release. If you have dependencies that you can guarantee will be in the common bundle (like it's safe to say React will always be in it, along with any other architectural libraries), then you're better off externalising them to somewhere that sticks around between releases (and therefore benefits more from browser caching). This will also make your common bundles much smaller.

Re: Google recommends inlining small CSS

#56

Post by frabcus » Tue, Jan 12, 2016, 11:56 AM UTC

We inline the front page CSS on https://pdftables.com/, both for user experience and for SEO reasons.

The Node module UnCSS (https://github.com/giakki/uncss) is working reliably for us, using PhantomJS to automatically extract the CSS rules we need for our front page.

The full CSS rules are then loaded at the end of the page - just in case UnCSS missed a browser specific or Javascript triggered rule, and to get the files into the cache.

Re: Google recommends inlining small CSS

#57

Post by acjohnson55 » Tue, Jan 12, 2016, 11:57 AM UTC

losvedir wrote: post #39

Interesting. The sample code includes this bit: var raf = requestAnimationFrame || mozRequestAnimationFrame || webkitRequestAnimationFrame || msRequestAnimationFrame; if (raf) raf(cb); else window.addEventListener('load', cb); I've never thought to use requestAnimationFrame like that. When exactly does it fire? Is that the preferred callback these days for loading code after the page is "done" in some fashion? I've g…

Yep, you're right that that's how jQuery works [1]. I'm not an expert in this, but I would expect requestAnimationFrame to be quicker than DOMContentLoaded, because it should occur before a paint [2], rather than after the event fires, which is presumably afterward. If the stylesheet is in cache, this gives the browser a chance to load it before the first render, to prevent a flash of unstyled content.

[1] https://github.com/jquery/jquery/blob/dabd5ba96c05279b3ffb05...

[2] https://developer.mozilla.org/en-US/docs/Web/API/window/requ...

Re: Google recommends inlining small CSS

#58

Post by Flimm » Tue, Jan 12, 2016, 12:01 PM UTC

freshyill wrote: post #47

bigethan wrote: post #21

Earlier quoted context omitted.

Seriously. CSS loading/parsing is render blocking. By loading CSS that isn't needed immediately asynchronously in a way that will use the browser cache if it's available, it makes the page visible much faster. It feels like overkill in the simple example, but it's a tried and true method. ( https://github.com/filamentgroup/loadCSS has > 2k stars if that kinda thing means anything) From my experience on a large websit…

In a few hours, I'm launching a very large website that relies heavily on LoadCSS(). Page load times have been excellent in the pre-public phase, even though our critical styles contain a mountain of Autoprefixer-generated flexbox prefixes. My understanding is that all of this will become an antipattern once we can support http/2. For today, however, it provides a very real performance boost.

My understanding is that concatenation will be become an anti-pattern with http/2, but not ``, ``, or loadCSS.

Re: Google recommends inlining small CSS

#59

Post by seanwilson » Tue, Jan 12, 2016, 12:03 PM UTC

oneeyedpigeon wrote: post #51

seanwilson wrote: post #38

Earlier quoted context omitted.

I imagine the vast majority of web users have font loading enabled so they optimised and tested for that.

So, ... screw the minority? Seriously, one of the benefits of the web stack is that it makes it very easy to cater for a wide variety of capabilities, rather than resorting to "Best viewed with Internet Explorer 5"-type behaviour.

What browser doesn't support fonts?

If web developers had to support every permutation of turning off cookies, fonts, images, JavaScript, stylesheets etc. you'd never get anything done.

Re: Google recommends inlining small CSS

#60

Post by acjohnson55 » Tue, Jan 12, 2016, 12:13 PM UTC

danjordan wrote: post #44

andrewingram wrote: post #36

The problem i've always had with this, and the "above the fold" rule as it appears in the pagespeed insights tool, is the definition of "fold" varies wildly. So I see CSS optimisation as a multi-step process. * Switch to a component-based rendering architecture (I favour React) * Map CSS rules directly to components (I use CSS Modules) * Have a JavaScript entry-point per route. The entry-point should only contain wha…

Does this have any negative effects on browser caching?

Yes, bundling can potentially negatively impact caching. In the worst case, the bundles are mostly the same. Also, if your leaf component style files change rapidly, you'll invalidate the hashes on large bundles pretty frequently.

For this reason, I think a better solution might be to inject critical styles into a STYLE tag in the HEAD, and then deliver one style file per component. The intuition behind this is that you can do your initial render with only the original payload (ideally in the first roundtrip), and that will buy you plenty of time for the cascade of web requests to get all the individual component files. With HTTP/2 multiplexing coming, there's no much penalty there. And then you get to cache your page at the granularity of a single component.