The Font Loading Mistake That Was Slowing Down My Site
A render-blocking font request is invisible until you actually measure for it.
*A render-blocking font request is invisible until you actually measure for it.*
You don't notice a render-blocking font request by looking at your site. It loads fine on a fast connection, on a phone you've already visited the page from a dozen times, with fonts cached. It only shows up when you actually measure — and on ShabelleHub, that measurement was a chunk of the gap between a 69 and a 92 PageSpeed score.
What Was Actually Happening
ShabelleHub was loading Google Fonts the standard way most tutorials show: a <link> tag pointing at Google's font CDN. This works, but it means the browser has to make an external request, wait for it to resolve, and only then render text — or render with a fallback font and swap it in later, causing a visible layout shift. Either way, it's a dependency on a third-party server sitting directly in the critical rendering path.
The Fix: Self-Hosting via next/font
Next.js's next/font/google module solves this by downloading the font files at build time and serving them from your own domain, with the font-loading strategy optimized automatically — no external request, no render-blocking round trip, no layout shift from a font swap.
Migrating wasn't a pure drop-in replacement, though. The site uses Space Grotesk, which is a variable font — meaning a single font file contains a full range of weights rather than separate files per weight. Self-hosting a variable font through next/font required an explicit fix to get the weight axis rendering correctly; without it, the font would load but ignore the specific weight values used throughout the site's CSS, silently falling back to a default weight.
Verifying the Fix Actually Worked
The temptation with a fix like this is to assume it worked because the site "looks the same." The real verification came from checking the network waterfall and confirming there was no longer an external request to Google's font servers blocking initial render, and from re-running Lighthouse to confirm the font-related flags had cleared.
A Note on Font-Display Strategy
Beyond simply self-hosting, next/font also controls the font-display behavior automatically, which determines what happens visually in the gap before a custom font finishes loading — whether the browser shows invisible text, a fallback system font that later swaps, or some blend of the two. Getting this behavior right matters as much as eliminating the external request in the first place, because a badly configured font-display can still produce a jarring layout shift even with a font that loads quickly, simply because the swap itself is abrupt. Part of verifying the fix included deliberately throttling the network in testing to simulate a slower connection than the one being developed on, to confirm the fallback-to-final-font transition looked acceptable under worse conditions than the best-case scenario a developer's own connection usually represents.
Why This Matters More Than It Seems
Font loading is one of those performance issues that's easy to deprioritize because it doesn't look broken. But render-blocking requests and layout shift from font swaps are exactly the kind of thing Core Web Vitals penalizes, and Core Web Vitals feed directly into search ranking. A font that takes an extra 200-400ms to resolve, multiplied across every visitor on every page load, adds up to a real, measurable drag on the site's SEO performance — invisible in casual browsing, very visible in the data.
The Variable Font Detail, Expanded
Variable fonts are a genuinely elegant piece of font technology — instead of shipping separate files for regular, medium, bold, and everything in between, a single file encodes a continuous axis of weight (and sometimes width, slant, and other properties) that the browser can interpolate on demand. That's a real file-size win when a design uses multiple weights of the same typeface, which ShabelleHub's design does. The catch, when self-hosting through next/font, is that the tooling needs to be told explicitly which axis and which range of values to expose — without that, the font loads, technically works, but silently ignores the specific weight values requested in CSS, falling back to whatever the browser considers a default. The page doesn't error, doesn't warn, it just renders slightly wrong in a way that's easy to miss unless you're specifically comparing font weights against the design before and after the migration.
Checking the Fix Held Up Across Pages
Font loading configuration in Next.js is typically set up once, centrally, and then used everywhere — which is efficient, but also means a mistake in that central configuration propagates to every page rather than staying contained to one. After the fix, the verification process specifically included checking font rendering across several different page types — the homepage, a tool detail page, the blog listing — rather than just the page where the bug was first noticed, on the theory that a font configuration issue is much more likely to be global than local.
The Takeaway
Self-hosting fonts through next/font is close to a free performance win for any Next.js site still pulling from Google's CDN directly — the main friction is handling edge cases like variable font weights correctly, which is worth testing explicitly rather than assuming it "just works" after migration.
📬 Get the latest AI tool reviews
Expert picks and comparisons, weekly. No spam.