The First Unsorted Tray: A Critique of the Modern Typography Stack
There is a piece of received wisdom so deeply embedded in the front-end craft that it’s often stated as an unassailable truth: for the fastest, most authentic rendering of type, self-host your fonts. We are told to bypass the sluggish, privacy-questionable Google Fonts API, download the WOFF2 files, and serve them directly from our own domains. This, the logic goes, gives us complete control. It shaves off a critical third-party connection and neatly aligns with the performance-first ethos. But in our rush to optimize, have we merely exchanged one set of complications for another, perhaps more insidious, kind?
The appeal is obvious. Direct control feels clean, professional. We run our font files through the same build processes as our JavaScript and CSS, subjecting them to compression, caching policies, and CDN distribution. We see the requests in our own logs. We feel, in a word, responsible. Yet, this responsibility often leads us to build what I’ve come to think of as the ‘modern typography stack’: a Rube Goldberg machine of @font-face declarations, preload hints, font-display: swap policies, and bespoke fallback logic, all in the name of speed.
The problem is not in the individual parts but in the cumulative weight of our good intentions. The very act of preloading a self-hosted font, for instance, becomes a high-stakes gamble. We are instructing the browser to prioritize this resource above nearly all else. If our font CSS is render-blocking—and it often is, to some degree—we risk creating a single point of failure. A slow-to-resolve DNS query for our own asset, a CDN hiccup, or even just the time to parse our own complex @font-face rules can now impose a penalty more severe than waiting for a well-tuned, geographically distributed third-party service.
Worse is the illusion of stability we create. The Google Fonts API, for all its faults, is a system built for one purpose: delivering fonts efficiently. It handles font subsetting, provides browser-specific file formats automatically, and its infrastructure is globally optimized. Our self-hosted solution, by contrast, is a static snapshot. We become the systems administrators of our own miniature font delivery network, a role for which our development and deployment pipelines are rarely designed. An update to a font file requires a full redeployment. Caching headers must be meticulously configured. We have traded a potential performance variable for a significant maintenance constant.
This is not a defense of external dependencies, but a critique of optimization dogma. The rule ‘self-host your fonts’ is not universally optimal; it is contextually so. For a high-traffic site with a dedicated infrastructure team, the control is a boon. For a smaller project or a rapidly iterating product, the complexity overhead of a self-managed font stack can easily outweigh the marginal gains. It becomes technical debt masquerading as best practice. The typography, meant to serve the content, instead becomes a master demanding constant attention. The tray of lead type is now on our own desk, and we are the ones who must sort it, lest the entire composition falls into disarray.
The smarter path is to acknowledge that performance is a spectrum of trade-offs, not a destination reached by following rules. Before reflexively self-hosting, we should ask: does the added complexity serve the user, or does it merely serve our sense of technical purity? Sometimes, the most stable and performant font is the one managed by specialists, not the one we’ve painstakingly, and perhaps naively, brought in-house.
Notes & further reading
A few pages I came back to while writing this: