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

31–40 of 143 posts

Re: Google recommends inlining small CSS

#31

Post by mattmanser »

_alexander_ wrote: post #4
oliwarner wrote: post #2

> If the external CSS resources are small It's not a general rule, it's just suggesting that your 50 character block of CSS (that might be dynamic or conditional) would be better off as part of the main markup than a separate request and all the overhead associated with that. If your static CSS exists in lots of small files, you would strongly benefit from rolling them together. Both these recommendations may change…

Interesting research about http2 - http://engineering.khanacademy.org/posts/js-packaging-http2....

Although they seem to be saying that something is wrong with google app engine rather than http/2.

Re: Google recommends inlining small CSS

#32

Post by DanielBMarkham »

Over time I've developed some opinions not shared by most. I only use a framework when under extreme duress. I use static pages wherever possible. I measure payload size.

I'm also beginning to re-think CSS. I love CSS, but just like with OO, I'm thinking it may tempt us to think of structural considerations when we may just be wasting our time. I think the next app I write, I'm going to evolve my CSS, starting with inline styling, moving out to an inline style node in HEAD, then dynamically loading it from JS as in the Google example, and then finally using a class/series of classes.

In much the same way, in FP you can just make it work, then generalize, then group, then eventually create modules/classes full of generalized functions. This way of thinking seems to result in far quicker execution and far less complexity. Not sure if it translates to CSS, though. It'll be interesting to try it out.

Re: Google recommends inlining small CSS

#33

Post by yoz-y »

I do not understand this particular example. They replace 4 lines of external CSS + 1 line of loading by 1 line of internal CSS + 2 lines of tags + 11 lines of JavaScript which then asynchronously loads 3 lines of CSS.

So we went from a blocking call and 5 lines of code to 17 lines and an async call. How is this in any way better than simply cramming the 4 lines of CSS internally? Maintenance will not be simpler because you will still probably have several rules to maintain over several files (and the inlining can be automated).

This seems like horrible over-engineered advice _especially_ for small CSS files.

Re: Google recommends inlining small CSS

#34

Post by fhd2 »

blowski wrote: post #5

This makes perfect sense for classes like ".article51_footer_wrapper_margin50", look up the rule, and sure enough it looks like `.article51_footer_wrapper_margin50 { margin-bottom: 50px; }` Seriously, just inline rules like that. If it is only applied in one specific place across the entire site either because it cannot or does not need to be made more general, then inlining it is easier to maintain and understand.

Note that TFA is about using a style tag rather than a separate CSS file. It actually discourages the style attribute.

Re: Google recommends inlining small CSS

#35

Post by eric_bullington »

DanielBMarkham wrote: post #32

Over time I've developed some opinions not shared by most. I only use a framework when under extreme duress. I use static pages wherever possible. I measure payload size. I'm also beginning to re-think CSS. I love CSS, but just like with OO, I'm thinking it may tempt us to think of structural considerations when we may just be wasting our time. I think the next app I write, I'm going to evolve my CSS, starting with i…

> ...I'm going to evolve my CSS, starting with inline styling, moving out to an inline style node in HEAD, then dynamically loading it from JS as in the Google example, and then finally using a class/series of classes.

I'm sure it will load spectacularly fast, but that sounds like a maintenance nightmare.

I spent a lot of effort on my "brochure" sites making sure that non-JS users will have a good experience (that includes being able to navigate the site, a privilege an increasingly large number of sites don't extend to non-JS users)[1]. Loading even part of my CSS through JS would ruin that experience.

1. I do make web apps that require JS, but only for actual applications that work in a similar manner to desktop apps, not for informational sites like blogs.

Re: Google recommends inlining small CSS

#36

Post by andrewingram »

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 what's needed for that route, common bundles can be used too (I use webpack for this).

* Have equivalent CSS entry points per route (again, Webpack).

* On initial (ie server) render, render a style tag into the document that contains the content of the relevant entry CSS. By definition this is very close to being only the CSS required for that page (if your components have various different classes depending on config, there may be some bloat here, not sure if there's a workaround).

* On that same render, don't include an external reference to the actual stylesheets. (At this point we're mimicking Google's advice)

* On first client-side navigation (yeah, i'm assuming you're using client-side routing), load the required stylesheets for the destination URL, remove the style tag, then continue the navigation.

I'm actually excited, because in the React ecosystem, we're not too far removed from this entire process being relatively trivial to implement. I'm assuming other ecosystems are similar.

Re: Google recommends inlining small CSS

#38

Post by seanwilson »

laurent123456 wrote: post #29
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…

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.

Re: Google recommends inlining small CSS

#39

Post by losvedir »

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 gotten used to using jQuery's `$(document).ready(..)` which as far as I know uses DOMContentLoaded or window.onload behind the scenes. When does the first animation frame happen in relation to those callbacks?

Re: Google recommends inlining small CSS

#40

Post by theinternetman »

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…

> How can code so complicated lead to such bland looking pages?

That also perform utterly atrociously, compare modern Google Maps to classic Google Maps. The performance difference is night and day in the favour of the old school tiles version.

Post reply on HN