Web fonts and performance: every millisecond counts for AI
The web font problem nobody takes seriously
I have a confession. I once spent an entire evening optimizing web fonts for a client site. Four hours. For typefaces. My wife was less impressed than I was. But it saved 800 milliseconds of load time.
800 milliseconds.
That sounds like nothing, but it's the difference between an LCP of 1.8 seconds (green, beautiful, celebration) and 2.6 seconds (orange, problematic, AI crawler checking its watch).
And I see it at almost every website we work on at Kobalt: a beautiful design with three custom web fonts, each loaded in five weights, all via Google Fonts. It looks fantastic. And it eats your performance alive.
Largest Contentful Paint (LCP) is the time until the largest visible element on the page has loaded. Often a hero image or a large heading. Google considers an LCP below 2.5 seconds good. AI crawlers look at similar thresholds. Above 3 seconds? You're going to lose content.
font-display: swap — the fastest win you can book today
If I could change one thing about every website I encounter, it would be this: add `font-display: swap` to all font declarations.
What it does: the browser first shows a fallback font and replaces it once the web font has loaded. Text is immediately visible. No waiting. No invisible text.
Without swap, the browser waits for the font before showing text. This is called FOIT (Flash of Invisible Text). And it blocks your LCP directly. Your page sits there, white, waiting, while an AI crawler has already decided there's nothing to find.
How to set it up:
- Via Google Fonts URL: add `&display=swap` to the end of your URL. Done.
- Via self-hosted fonts: add `font-display: swap;` to your @font-face declarations in your CSS.
- Via a font plugin (WordPress, etc.): look in the settings for "font display" or "swap." Most modern plugins support this.
Subsetting: load only what you need
This is where it gets fun. A complete web font file contains hundreds of characters you'll never use. Cyrillic. Arabic. Mathematical symbols. If you have an English-language website, you only need the Latin alphabet.
Subsetting cuts away all unnecessary characters. The result: a font file of 150 KB becomes 30 KB. Five times faster. For free.
- Via Google Fonts: use `&subset=latin` in your URL to load only the Latin subset.
- Via self-hosted fonts: use Glyphhanger or pyftsubset to subset. FontSquirrel's WebFont Generator also works for a quick online subset.
- Convert to WOFF2: the most efficient font format, supported by all modern browsers. Use only WOFF2 and forget the rest.
Never use more than two web fonts on a site. One for headings, one for body text. More is rarely necessary and always more expensive in load time. If the design specifies three or more fonts, that's a conversation worth having with the designer. I've had that conversation many times. You get used to it.
System font stacks: my honest, unfiltered opinion
Here's my firm stance, and I know designers won't love me for it: for most business websites, a system font stack is the best choice.
Not the prettiest. The best.
A system font stack uses the fonts already on the device. No download, no load time, no FOIT. Zero milliseconds overhead.
- font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif;
- On a Mac the visitor sees San Francisco. On Windows, Segoe UI. On Android, Roboto.
- All professional, highly readable fonts. Without a single millisecond of extra load time.
Is it as distinctive as a custom font? No. Is it the right trade-off for a B2B service provider serious about AI visibility? Often, yes.
But wait. Is that actually always true? No. If your brand revolves around visual identity (design agencies, luxury brands), then a custom font is worth the investment. You just need to know the performance cost and consciously accept it. Not accidentally.
At Kobalt we help clients with exactly that trade-off. Sometimes the answer is: "yes, load that custom font, but do it properly." Sometimes it's: "use a system stack and invest those 800 milliseconds in something that delivers more."
A website that loads in 1.2 seconds with a system font always beats a website that loads in 3.5 seconds with a beautiful custom font. For humans and AI crawlers alike. That's not an opinion. That's a stopwatch.
Frequently asked questions
Is preloading fonts worthwhile?
Yes, for your primary font (body text or your largest heading) preloading is worthwhile. Add a `` tag in your `
`. This tells the browser to fetch the font with high priority, even before the CSS is parsed. But don't overdo it: preload a maximum of one or two files. Otherwise you lose the gain through bandwidth competition.Is Google Fonts good or bad for performance?
Nuanced answer: Google Fonts aren't inherently slow. But the default implementation via a `` tag adds an extra DNS lookup and connection step. Self-hosting is almost always faster. Use the google-webfonts-helper tool (gwfh.mranftl.com) to easily self-host your fonts. It takes fifteen minutes and gains you hundreds of milliseconds.
Do AI crawlers notice the difference between fast and slow font loading?
Not directly at font level, but via the impact on LCP. If your font blocks the LCP, it takes longer for the page to be considered "fully" loaded. AI crawlers have a time budget per page. Above 3 seconds LCP, that budget runs up and the crawler may decide to crawl your page incompletely. And you won't notice. Until you see your citations declining.
How does your website score on AI readiness?
Get your AEO score within 30 seconds and discover what you can improve.
