Google recommends inlining small CSS • Hacker News Board

Re: Google recommends inlining small CSS

#101

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

dahart wrote: post #96

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 :)

Others have mentioned this is not necessarily a mis-use. I'll add that what I see here is potentially an override style that can be toggled dynamically. In that case, this may be the right thing to do, the !important declaration lets this rule collide and win over conflicting font-weight rules without having to keep track of which order the conflicting rules were declared in; they might be in separate files. The cano…

I agree, it is much easier and consistent to toggle a class with Javascript than to mess with the style attribute. For example, toggling one class in three is easier to deal with than removing/adding one property in three in a style attribute.

Re: Google recommends inlining small CSS

#102

Post by jqm » Tue, Jan 12, 2016, 3:15 PM UTC

jdudek wrote: post #46

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 :)

One can argue if it’s a misuse or not. It’s quite handy to have such utility classes that rely on !important and can be used in markup directly. I have plenty of those in my stylesheets. [1] http://davidtheclark.com/on-utility-classes/

Like your article. Especially agree with this phrase "authoring and maintenance considerations should trump kilobyte savings" (within boundaries of course).

Re: Google recommends inlining small CSS

#103

Post by talmand » Tue, Jan 12, 2016, 3:17 PM UTC

robmcm wrote: post #68

thirdsun wrote: post #53

Earlier quoted context omitted.

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.

The intentions are baked into your class name, if you were to change the style later and favor underlining rather than bold text, it would require a change to the HTML (or some rather misleading code). The same could be said for a mobile device, where italic could be hard to read, so, say a different font is used. Again this would require changes to the HTML and breaks the separation of style from markup. It doesn't…

There's nothing fundamentally wrong with having such utility classes. It could have a distinct use, especially for Javascript. It's just you shouldn't use such a class solely for design purposes, for the reasons you point out.

Re: Google recommends inlining small CSS

#104

Post by YngwieMalware » Tue, Jan 12, 2016, 3:24 PM 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.

I would probably want to fight you after reading this code.

Re: Google recommends inlining small CSS

#105

Post by brianzelip » Tue, Jan 12, 2016, 3:26 PM UTC

nvk wrote: post #71

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.

This is rude, there are many reasons and needs for no JS. A good example is Tor, where turning off JS helps with privacy.

I think grandparent is being sarcastic.

Re: Google recommends inlining small CSS

#106

Post by jakobegger » Tue, Jan 12, 2016, 3:29 PM UTC

Sometimes I wonder, if you can make the content above the fold load instantly, why can't you do that for the whole page?

Re: Google recommends inlining small CSS

#107

Post by johnsbrayton » Tue, Jan 12, 2016, 3:35 PM UTC

acdha wrote: post #97

johnsbrayton wrote: post #89

I agree that Google's recommendation here is a poor one in most cases. It would be better to do the following: 1. Have only one or two external CSS files per page. 2. Serve CSS compressed when possible. 3. Ensure that CSS does not require any server-side processing or compression, that the server just spits out a .css or .css.gz file when the CSS is requested. 4. Ensure that the CSS files are relatively small. 5. Ser…

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.

Re: Google recommends inlining small CSS

#108

Post by andrewguenther » Tue, Jan 12, 2016, 3:40 PM UTC

jakobegger wrote: post #106

Sometimes I wonder, if you can make the content above the fold load instantly, why can't you do that for the whole page?

Depends how big the page is ;)

Re: Google recommends inlining small CSS

#109

Post by robmcm » Tue, Jan 12, 2016, 3:43 PM UTC

talmand wrote: post #103

robmcm wrote: post #68

Earlier quoted context omitted.

The intentions are baked into your class name, if you were to change the style later and favor underlining rather than bold text, it would require a change to the HTML (or some rather misleading code). The same could be said for a mobile device, where italic could be hard to read, so, say a different font is used. Again this would require changes to the HTML and breaks the separation of style from markup. It doesn't…

There's nothing fundamentally wrong with having such utility classes. It could have a distinct use, especially for Javascript. It's just you shouldn't use such a class solely for design purposes, for the reasons you point out.

Yes using something like "strong" rather than "bold" as they did in the HTML spec.

For custom sections where you want to add styles you should consider what you are styling such as an "event", "highlight", "keyword", "first", "last" etc. Although the HTML5 tags are a lot more descriptive, numerous and extensible now, so css classes may not be the only option to add style descriptors to your content.

Re: Google recommends inlining small CSS

#110

Post by theandrewbailey » Tue, Jan 12, 2016, 3:52 PM UTC

I think that this is the wrong way for most websites to do CSS, as it contradicts both minimization+concatenation and HTTP2 best practices. If you have just one CSS file that's heavily cached and 100 KB (because you base64ed your webfonts to reduce request count), you should be fine.

Just last night, I tested trying to separate out my fonts from my CSS. Google Pagespeed Insights still threw a fit over no async CSS, even though the CSS was 5 KB. FFS, Goog! I decided against that madness.