Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google recommends inlining small CSS

developers.google.com

Post reply on HN
Print view View original

111–120 of 143 posts

Re: Google recommends inlining small CSS

#111

Post by acdha »

johnsbrayton wrote: post #107
acdha wrote: post #97

Earlier quoted context omitted.

The problem is basically telling whether your challenges are like Google's. An external link requires a separate request, possibly even separate DNS lookups, server connection, SSL negotiation, etc. and nothing will render until those complete. If you're Google with a strong culture of web performance and have generally solved all the normal server issues with a globally-distributed network of edge servers, a 24x7 te…

You're absolutely right. The guidelines I outlined don't work well if retrieving the CSS requires a subsequent DNS lookup. One could argue that serving CSS from the host that serves the HTML is a good idea, but there are other tradeoffs involved.

Yeah, this is a really hard thing to get right in general guides or tutorials since there are so many assumptions underlying the decisions and people might end up reading one far enough in the future that thing have changed – we saw that with connection limits and caching esoterics which became obsolete once IE6 disappeared.

The main thing I'd like to see in guides like this would be some general advice about how to measure this kind of thing (e.g. browser dev tools) and, more importantly, how to avoid some of the common confounds like local caches when measuring using a tool like WebPageTest.org.

Re: Google recommends inlining small CSS

#112

Post by Lanari »

Google's point here is to load a header really fast, the user will get this feeling that some progress happened, JavaScript will load the rest of the CSS after, while the rest of the page is getting loaded/rendered...

Still, I won't use their method.

Re: Google recommends inlining small CSS

#113

Post by vec »

yoz-y wrote: post #87
Klathmon wrote: post #72

Earlier quoted context omitted.

Because small doesn't mean 4 lines, they just used 4 lines for the example. Think of this like a "Hello World" for inlining CSS.

In that case (as others have stated) they should really precise what do they mean by small. I am convinced that a single network call (preceded by JavaScript overhead) dwarfs any reasonable amount of CSS code you could put in a single HTML file.

It will, but it's still a net win because Google's not actually optimizing for time to load. They're optimizing for time to usability. Moving all of the non-essential CSS out of the head and into a post-load request increases the total request time but decreases the time until the user can begin interacting with the page.

It's still drastic overkill for almost everyone except Google, but it does make sense for their use case.

Re: Google recommends inlining small CSS

#114

Post by rudolf0 »

ymse wrote: post #70
aexaey wrote: post #61

Offered example is missing this in the "you can inline" snippet: ..least whole point of this excercise is to make life a little bit more miserable for those pesky users who dare to disable js.

FTA: Note that the web platform will soon support loading stylesheets in a non-render-blocking manner, without having to resort to using JavaScript, using HTML Imports. https://w3c.github.io/webcomponents/spec/imports/#link-type-... All is not lost, it seems.

This is like 15 years overdue.

Re: Google recommends inlining small CSS

#115

Post by lewisl9029 »

This is probably not a very good general recommendation, but inline CSS actually makes quite a bit of sense to me when using React/Redux.

Style is generally heavily interconnected with app state in modern web apps, so why not take advantage of a sophisticated state management system like Redux to declaratively manage your styles along with your state rather than adding/removing class names at runtime imperatively? With React's implementation of inline-styles, you can treat your styles as just another piece of JS data in your state tree, and have the entire power of the JS language at your fingertips to compose/extend/manage them, including powerful functional transformations, a flexible and statically analyzable module system, and prototypical inheritance, if you're into that kind of thing.

With this approach, you completely remove any need for preprocessors, get rid of a whole class of CSS limitations like the lack of a proper module system, and global scoping and the associated specificity issues, and your components become truly self-contained by default.

That said, I don't have a lot of actual experience with this approach in practice, so I definitely could be missing some nuances and practical limitations. I'd love to hear some opinions/experiences regarding using inline styles in React/Redux.

Re: Google recommends inlining small CSS

#116

Post by nostrademons »

yoklov wrote: post #78
adevine wrote: post #73

Earlier quoted context omitted.

Only if you have specified Content-Security-Policy headers in your response, without also specifying "unsafe-inline": http://www.html5rocks.com/en/tutorials/security/content-secu...

What potential security vulnerability do inline styles have?

In the pre-IE8 days, you could include CSS expressions within CSS that let you execute arbitrary Javascript when the CSS was evaluated. This was a very common vector for Internet worms; UGC sites would think they were safe because they stripped out tags, javascript: URLs, and inline event handlers (onload was another common attack vector), but then an attacker would add a custom style attribute with a CSS expression and pwn your computer.

That specific danger has largely gone away (except on all the corporate networks that are still on IE6 because custom apps), but there's still a desire to minimize attack surface. What if calc() or var() is found to have a bug in the future that allows arbitrary code execution?

Re: Google recommends inlining small CSS

#117

Post by nostrademons »

Nutmog wrote: post #52

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…

Most of these recommendations are based on measurements. I recall a coworker doing several experiments on Google Search about inlining CSS vs. making a separate request, and the break-even point was surprisingly high (~10K or so of CSS).

Publishing recommendations like this is a recognition that many small companies don't have the resources that Google does to rigorously experiment with different approaches and collect data.

That said, if you do have the resources, you should always measure & experiment with your own situation. Many of these recommendations go away with HTTP2, for example, and it's likely that the guidelines won't be updated until long after HTTP2 is widely adopted.

Re: Google recommends inlining small CSS

#118

Post by exodust »

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.

I did that for a single page web app once, but I took it a step further and inlined the JS too. I was surprised how much I enjoyed developing that way, and how much it didn't bother me. I kept libraries such as Jquery separate. Just the code I was editing I kept all inline in one large HTML file.

The self-contained simplicity was appealing, the only hurdle was navigating a large file in my editor. But there's ways to manage that with bookmarks and neatly organised sections and so on.

I liked how the smallest component of the app, was the app itself. I see HTML, CSS and JS working together as one unit anyway in a single-pager, so I wanted them living and versioned together. On this particular app, I had lots of dynamic elements updating around and lots of exploring new concepts. Wanted to avoid dependency fragmentation headaches. And to be honest, switching between frontend files can be annoying (to me) when I'm doing lots of tinkering. I'd rather switch between locations in the same file.

Re: Google recommends inlining small CSS

#120

Post by duskwuff »

robodale wrote: post #84
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 :)

Crazy off topic, but similar misusage: Vendor-installed SQL server database. In this DB is a table called tblYesNo with one column called YesNo. In the table are the following two rows: YES NO

  INSERT INTO tblYesNo VALUES ('FileNotFound');
-- http://thedailywtf.com/articles/What_Is_Truth_0x3f_
Post reply on HN