Google recommends inlining small CSS • Hacker News Board

Re: Google recommends inlining small CSS

#11

Post by 3princip » Tue, Jan 12, 2016, 9:48 AM UTC

Which mandates 'unsafe-inline' if you're using a content security policy (CSP).

>Banning inline script is the biggest security win CSP provides, and banning inline style likewise hardens your application.[1]

So which is it? Should we be moving away from inline scripts and CSS, and tightening it up with CSP, or is performance/fewer requests more desirable? Also, with HTTP2, the performance issue seems moot.

[1]http://www.html5rocks.com/en/tutorials/security/content-secu...

Re: Google recommends inlining small CSS

#12

Post by fkooman » Tue, Jan 12, 2016, 9:48 AM UTC

I love how they, in that example, use JS to load the rest of the CSS. Seriously?

Re: Google recommends inlining small CSS

#13

Post by majewsky » Tue, Jan 12, 2016, 9:49 AM UTC

mozumder wrote: post #8

If you have single-page web apps, you might as well inline your entire site's CSS, since it's never going to look for the CSS again.

Not necessarily. If the app changes seldomly, you could reuse a CSS file across multiple sessions, whereas the HTML (i.e. "GET /") is probably always served up fresh.

That does not apply, of course, if your initial HTML page is a static asset, too.

Re: Google recommends inlining small CSS

#14

Post by jholman » Tue, Jan 12, 2016, 9:50 AM UTC

ars wrote: post #6

Note they mean inlining the css rules in a block. Not inlining the css as the style attribute of a tag. The goal is not to have to fetch a second css page.

That is not the goal. Read TFA; their example specifically still loads small.css by dynamically creating a element after pageload (in a RequestAnimationFrame or onLoad).

The goal is to have the CSS already present when the "above-the-fold" content renders, so that it's that much faster to render correctly, improving user experience.

Re: Google recommends inlining small CSS

#15

Post by te_chris » Tue, Jan 12, 2016, 9:51 AM UTC

mozumder wrote: post #8

If you have single-page web apps, you might as well inline your entire site's CSS, since it's never going to look for the CSS again.

This is basically what webpack's css-loader does.

Re: Google recommends inlining small CSS

#16

Post by sanxiyn » Tue, Jan 12, 2016, 9:53 AM UTC

PavlovsCat wrote: post #10

Are there any findings about whether such godawful class names affect rendering performance? I mean just matching strings such as this one: com-google-api-explorer-client-history-EmbeddedHistoryItemView_HistoryItemUiBinderImpl_GenCss_style-showHideHeaders It's generally really hard for me to take HTML advice from google seriously, their page sources at best look mediocre, and at worst they make my eyes bleed. How can…

Class names are interned (see https://en.wikipedia.org/wiki/String_interning), so string length does not affect rendering performance.

Re: Google recommends inlining small CSS

#17

Post by NetStrikeForce » Tue, Jan 12, 2016, 9:56 AM UTC

(Disclaimer: I'm not a coder, so I easily get overwhelmed by what others might see as very simple)

It may be better for delivery, but the second example is unreadable compared to the clean one. I can see why it's much better to add 15KB to your HTML file than having to request those 15KB from a separate file (one or two full round-trips of added latency :)).

Re: Google recommends inlining small CSS

#18

Post by theinternetman » Tue, Jan 12, 2016, 9:59 AM UTC

fkooman wrote: post #12

I love how they, in that example, use JS to load the rest of the CSS. Seriously?

"Too many devs spoiling the broth" in a nutshell.

Over-engineered absurdity

Re: Google recommends inlining small CSS

#19

Post by bleachedsleet » Tue, Jan 12, 2016, 10:07 AM UTC

NetStrikeForce wrote: post #17

(Disclaimer: I'm not a coder, so I easily get overwhelmed by what others might see as very simple) It may be better for delivery, but the second example is unreadable compared to the clean one. I can see why it's much better to add 15KB to your HTML file than having to request those 15KB from a separate file (one or two full round-trips of added latency :)).

While you're correct in observing that the first example is shorter and potentially easier to read at a glance, there is a method to the madness in the second. They inlined the CSS needed for content above the fold which speeds up load times theoretically. They then use JS to load the rest of the CSS later on so they can control exactly when the stylesheet is loaded...just linking like one would normally do would negate the perceived benefit. The end result should be comparable overall load times but the end user should perceive a slight decrease since important information is styled immediately. So yeah, the second is a little more confusing and in this case is drastic overkill, but their point still stands.

Re: Google recommends inlining small CSS

#20

Post by drinchev » Tue, Jan 12, 2016, 10:09 AM UTC

I think this Google rule is too specific and in the same time too general for being alive.

The whole idea :

> Inline small CSS.

is too specific. I think when you work on a huge web-application you don't want to create such a bloat in your layouts and personally I don't think that this approach scales. On the other hand if you go with a simple web page, like a landing page with a couple of elements ... go for it.

> If the external CSS resources are small

What is "too small" anyway ? ( too general )