Bear Blog – A privacy-first, fast blogging platform

One other thing that is almost always overlooked is that you don’t tend to use all styles on a given page, and you could strip out the unused styles. For example, the front page linked here has over 4KB of stylesheet, unminified and with unused styles; minified, it’s 3KB; with unused styles removed (including the wonky body:hover), it’s about 662 bytes. Something in the vicinity of 1KB is for specific pages, and 1KB for editing (form fields and such). If you try actively minimising the front page (removing unnecessary whitespace and attribute quotation marks, minifying and paring the stylesheet, and removing a few pointless elements), the whole thing ends up under 3.4KiB (down from 7.8KiB).

(Mind you, most browsers can do some degree of intra-session sharing of an in-memory representation of a stylesheet, for performance and memory usage reasons, and doing this will thwart that. But that’s only likely to make things faster over inlining if you’ve got much heavier styles, dozens or hundreds of kilobytes, the sort that you wouldn’t be so likely to inline anyway.)

As for the “making additional requests thing”: you still have to remember latency, because you’re adding another whole round trip to the waterfall. In the case of bearblog.dev which is hosted somewhere on the other side of the world from me (I’m in Australia), that will add an absolute minimum of over 260ms, more commonly half a second or more. Inlining of small resources like this when you have a very short waterfall already significantly improves load performance. The HTTP/2 and HTTP/3 improvements are about requesting more than just a couple of resources: in a case like this if you had one HTML and one CSS resource from the same host, HTTP/2 would not improve anything over HTTP/1.1.

I’ve spent a lot of time obsessing over this—and being perplexed by performance-focused web devs favoring inline styles generally. Here’s what I’ve found.

- External <link> stylesheets are exactly as you describe, with some important caveats depending on specifics of the actual page, site, host, resources, and other bundle characteristics.

- Perceived performance is almost universally better, for all network conditions I’ve tested, when at least a portion of a page’s styles are inlined in <head>. Yes, even with HTTP/2. Yes, even with optimal metadata hints which should degrade better on a slower network. The most reasonable conclusion I can come to is that the main document parser is so well optimized that beating it is like challenging the Harlem Globetrotters on “fundamentals”: you’re going to be right, some of the time; you’re going to lose, every time.

- The benefits of inline styles degrade pretty quickly for subsequent navigations, with appropriate cache headers. This is expected, but with perf (web or otherwise) validating assumptions isn’t something you should leave unspoken.

- Many hosts have bad cache headers, even those you’d expect to do better (glares at GitHub Pages, my host).

- While the benefits of inline styles degrade rapidly, the drawbacks rarely if ever accelerate enough to care except under the worst network circumstances. And the drawbacks of <link> stylesheets accelerate much more rapidly.

- Most of these facts are mostly unnoticeable, on most mainstream devices, for most of this audience. You have to measure to register a difference, and the measuring has a greater impact than any measurable implementation difference.

- The notable exception, one which users will notice regardless of their device capabilities or network conditions, is web fonts. If you load them, the best perceived performance strategy is to mark them optional. Even so, they have the greatest impact on perceived performance, on otherwise well optimized pages, on high perf devices with good network conditions.

- When loading fonts on a page, inline styles perform dramatically better than <link> stylesheets regardless of any other implementation detail or circumstance. They have better perceived performance if baseline styles like colors and basic typography are inlined as well. This is what is commonly glossed over (and sometimes overloaded to mean more) as “critical styles”.

- From this point on, <link> styles perform “the same or better” for a basically useless unit of “better”. Assuming a relatively flat request waterfall. HTTP/2 helps if you know your entire dependency graph upfront, which nearly no site does… and it doesn’t matter, because Push is dead or on its way out and that graph is meaningless if the client disregards it.

- Good luck knowing your dependency graph. The tools that are designed for it are concerned with JS bundles. Your best bet is the added build-time complexity of CSS-in-JS and dynamic atomic classes (which are both great, albeit an unpopular combination). If you don’t, you’re either serving redundant styles, too many (my personal preference, after critical styles), or you’ve rolled your own static analysis tool (please share!).

There's no FOUC if you add a stylesheet to <head>, and it concerns me that people seeing that flash have come to expect it as a fault of CSS, when it's really these frameworks making a decision to load the stylesheet via javascript.

I've actually been thinking about different ways of adding exactly that to a static site - technically you could have something like a comments form that just writes to a text file somewhere (perhaps updating a Gist with the API you mentioned[1]), which the static site reads from upon page reload.

Sounds a bit inelegant I guess, but could be interesting to implement.

[1] https://docs.github.com/en/rest/gists/gists#update-a-gist