Fonts That Do Not Block Text
I’ve spent the last nine years un-breaking sites that were perfectly fine until someone decided they needed a “revolutionary” page builder and fifteen different Google Font weights. Most people will tell you that you need some complex, expensive plugin to fix your Core Web Vitals, but they’re usually just trying to sell you a solution to a problem they helped create. If you’re staring at a layout that jumps around like a caffeinated squirrel every time it refreshes, you don’t need more bloat; you need to understand how to optimise font loading without breaking the design intent.
I’m not here to give you a generic checklist of “best practices” that you can find in a thousand other tutorials. I’m going to show you how I actually handle it when I’m deep in the code, from self-hosting files to managing that annoying Flash of Unstyled Text. I’ll give you the straight truth on which decisions are worth the performance hit and which ones are just expensive vanity projects. No hype, no fluff—just the technical reality of making sure your typography actually shows up when your users do.
Table of Contents
Mastering the Font Display Swap Property
If you aren’t using the font-display swap property, you’re essentially asking your users to stare at a blank screen while your fancy typeface decides to show up. I’ve inherited more “premium” sites that felt broken simply because the text was invisible for three seconds during load. By setting this to `swap`, you tell the browser to use a system font immediately and then switch to your chosen typeface once it’s actually ready. It’s a basic move, but it’s one of those essential web font performance best practices that separates a professional build from a hobbyist mess.
However, there is a catch that most people ignore: the visual jump. If your fallback font is a tiny Arial and your brand font is a massive, chunky serif, your layout is going to twitch like it’s had too much espresso. This is how you accidentally reduce cumulative layout shift fonts—or fail to, depending on how much you care about UX. You can’t just set it and forget it; you have to actually look at the dimensions of your fallback and make sure the transition doesn’t feel like a physical punch to the user’s eyes. It’s about making sure the designer’s intent doesn’t get lost in a jarring layout shift.
Google Fonts Optimization Techniques for Speed
Look, I get it. Google Fonts is the easiest way to make a site look like it wasn’t designed in 2004, but it’s also a massive performance trap if you just copy-paste the embed code and call it a day. Every time I inherit a site where the developer just slapped a Google stylesheet in the header, I see the same thing: a massive delay while the browser waits for those external servers to respond. If you want to actually follow web font performance best practices, you need to stop treating Google as a magic wand and start treating it like a dependency that needs managing.
The quickest win is to stop making your users’ browsers go on a scavenger hunt. Instead of relying on those endless external requests, I almost always advocate for the self-hosting web fonts benefits. When you host the files locally on your own server, you eliminate that extra DNS lookup and the latency that comes with it. It’s one less decision for the browser to make and one less thing that can break. Plus, it gives you total control over how those files are served, which is the only way to truly reduce cumulative layout shift fonts and keep the reading experience from feeling like a glitchy mess.
Five ways to stop your typography from killing your Core Web Vitals
- Stop hosting everything on Google’s servers. I’ve seen too many sites making unnecessary trips to a third-party domain just to grab a single weight of Roboto. Download the files, host them locally on your own server, and keep the connection count down.
- Use sub-setting to prune the fat. Most font files are bloated with character sets for languages your clients aren’t even using. If you’re building a site for a local bakery in Chicago, you don’t need Cyrillic or Greek glyphs slowing down the render.
- Preload the critical stuff, but don’t go overboard. I’ll tell you which fonts to preload—usually your main H1 or body text—but if you preload ten different weights, you’re just creating a bottleneck that defeats the whole purpose.
- Stick to a limited number of weights. Every extra weight you add is another request the browser has to handle. A designer might want every single variation from Thin to Black, but for the sake of performance, pick three and move on.
- Audit your “mystery” fonts. I’ve inherited so many sites where a random plugin or a bloated theme injected a third-party font that nobody even asked for. If it’s not in your design spec, it shouldn’t be in your code.
Stop Letting Your Typography Kill Your Performance
Look, optimizing font loading isn’t some magic trick; it’s just about being intentional. We’ve covered the heavy hitters: using `font-display: swap` so your users aren’t staring at a blank screen while a heavy file downloads, and being smart about how you pull from Google Fonts without bloating your request queue. If you’re self-hosting, great—just make sure you aren’t accidentally loading five different weights of a typeface that nobody is even using. At the end of the day, every millisecond you shave off that initial render is a win for the user and a middle finger to the bloated page builders that try to solve everything with more code.
I’ve spent nine years cleaning up the digital equivalent of architectural disasters, and most of them could have been avoided if someone had just thought about the assets first. Typography is the soul of a site, but it shouldn’t be its anchor. Don’t let a beautiful typeface become the reason your Core Web Vitals look like a crime scene. Build with purpose, audit your decisions, and remember that a site that looks stunning but takes ten seconds to load is just a pretty failure. Go make something fast.
