Hacker News Reader

Comment by johnsbrayton | Hacker News Reader

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. Serve the CSS files with a very long cache time and with a version/hash string in the object name.

6. If feasible, make CSS changes relatively relatively rare.

If you do all of these things, adding the style into the web page will clutter your HTML and slow things down for frequent visitors. Yes, it might also increase perceived performance for some users who have not visited the site since the last change to the CSS.

View on HN

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 team of very talented engineers continuously monitoring and optimizing, etc. you might quite reasonably conclude that the biggest remaining area to improve page performance is chipping away at the long tail of users on high-latency connections, unreliable / flaky ISPs which might drop or delay requests for your render-blocking resources, etc.

The trick is realizing that relatively few people work at Google and most other places have not made the same investments to get to the point where this kind of micro-optimization is a net win versus the maintenance costs. Most sites tend to show easier problems - optimizing DNS, getting a CDN or using one better, reducing total transfer size, etc. – which are going to impact the user experience more than inlining some CSS.

This is particularly true as we rapidly head into an area where things like HTTP/2 are changing most of our optimization weights – e.g. packing things into CSS bundles is rapidly becoming an anti-pattern since it reduces the period where a cached resource is still valid.

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.

Reply on news.ycombinator.com