The standard way to ship CSS is an external file: one .css, linked from the <head>, fetched once and cached by the browser for every page after that. It’s a good default, and most of the web should keep doing it. This site doesn’t, and the reason isn’t that external stylesheets are wrong - it’s that the trade they make only pays off under a condition this kind of site usually doesn’t meet.
The trade an external file is actually making
Linking a stylesheet costs one request the first time a visitor loads it. Every page after that reuses the cached copy for free, so the more pages someone views in a session, the better that one-time cost looks. It’s a bet on a second page view - the file’s price gets paid once and amortized across everything that follows.
A lot of visits to a small marketing site never place that bet. Someone arrives from a search result on one specific page - a service, a journal post - reads it, and either leaves or converts right there. There was no second page view to spread the cost across, which means the “it’s cached after that” argument never gets to fire. What’s left is a plain cost: a render-blocking request sitting between the browser having the HTML and being allowed to paint it correctly, since CSS deliberately blocks rendering so you don’t see a flash of unstyled content.
What we do instead
Every page’s styles get written directly into that page’s own <head>, in a <style> tag, at build time - no link, no separate request, ever, for the page’s own styles. We still author the CSS once, as a single stylesheet, the normal way; the build step is what splits the right slice of it into each page automatically. A visitor’s very first request already contains everything needed to render the page correctly, in the right order, with nothing else to wait on.
The honest cost is the mirror image of the win: nothing is shared across pages anymore. A visitor who does browse five pages in one sitting downloads a similar block of CSS five times instead of once, where the linked-file approach would have made the last four free. That’s a real trade, not a free lunch - we’re deliberately giving up the multi-page discount because the single-page case is the far more common one, and because the stylesheet itself stays small enough that paying for it repeatedly barely registers next to the request it replaces.
The one thing we don’t inline
There’s a genuine exception, and it’s worth being specific about it rather than pretending the rule is absolute. The cookie-consent banner on this site is a third-party library with its own CSS - meaningfully bigger than the rest of a typical page’s styles put together. Inlining it would mean every single page carries that extra weight in its <head>, whether or not the visitor ever interacts with the banner, and whether or not they’ve already made a choice on an earlier visit. So that one stylesheet is loaded lazily instead: fetched only once the banner is actually about to appear, well after the page itself has rendered and become usable.
That’s not a contradiction of the inlining approach - it’s the same judgment applied honestly in both directions. The core styles are small, needed by everyone, and needed immediately, so they’re inlined. The consent banner’s styles are comparatively large, needed by not-everyone, and not needed immediately, so they’re deferred. “Inline almost everything” and “except this one case” come from asking the same question - does this need to block the first paint - and getting a different answer each time.
Why this is a decision about this site, not a rule
None of this generalizes into “always inline your CSS.” A site where people genuinely browse many pages per visit, or an application people keep open in a tab for a while, would make the opposite call correctly - the caching discount is real when there’s something to discount against. It only makes sense here because this is a static site built ahead of time rather than one assembled per request, and because the shape of the traffic - mostly short, mostly one or two pages - is one we actually know, not one we’re guessing at. It’s one specific, deliberate answer inside the broader question of what actually makes a page feel fast: not a universal rule, just the right call for the kind of site this happens to be.
If your own site ships one large shared stylesheet to every page regardless of how much of it that page actually uses, it’s worth finding out which trade you’re actually making - we’re happy to take a look.
