Insights · Oct 26, 2026 · 3 min read
Web fonts without the slowdown
Blank headlines and text that jumps as it loads are font problems, and both are fixable. The font rules we follow on every build, and used on this site this week.
FAST FONTSWithout the slowdownCustom fonts are a common reason a page shows empty space where the headline should be, or jumps a second later as the text re-flows. Neither has to happen. These are the font rules we follow on every build, and the same ones we applied to this site this week, when we moved its typeface from Google Fonts to our own server.
Load fewer font files
Every weight and style is another download, so ask for only what the design uses. Most sites need a regular weight, one heavier weight for headings and perhaps an italic. If the design really uses many weights of one typeface, a variable font can replace them with a single file, although web.dev points out that not every site benefits from switching.
Serve WOFF2, split by character set
Use WOFF2 only. Its Brotli compression makes files about 30% smaller than WOFF, and every current browser supports it. Then subset: split the font into files for the characters each language needs and describe each one with unicode-range, so a page in English downloads only the Latin file and never the Cyrillic or Vietnamese ones.
Self-host, or at least preconnect
Self-hosting serves the font over the same connection as your page and removes a third-party request. If you load fonts from a provider instead, add a preconnect hint to the font file origin, with crossorigin, so the connection starts early. web.dev notes that the speed difference between the two is less clear-cut than people expect, so we decide on control and privacy: with the files on your own server, no visitor's browser has to contact another company just to show your text.
Choose font-display on purpose
The font-display descriptor decides what the browser shows while the font downloads. Each value trades speed against how often visitors see the brand font.
swap: text appears straight away in a fallback font and switches when the web font arrives. The least delay, but a late switch can shift the layout.optional: a very short wait of about 100ms, then the fallback stays for that page view if the font is late. The fastest, but a slow first visit may not see your brand font.fallback: a 100ms wait and up to three seconds to swap, a middle ground between the two.block: hides the text while the font loads. Avoid it for body copy.
We use swap for the brand typeface and keep the fallback close in size, so the switch is hard to notice.
Preload only the font that matters
A preload tells the browser to fetch a font before it finds it in your CSS. Use it for the single file that renders your headline and opening paragraph, and nothing else: every preload competes with your hero image for bandwidth, and preloads ignore unicode-range. Font preloads need the crossorigin attribute even on your own domain, or the browser fetches the file a second time.
<link rel="preload" href="/assets/fonts/geist-latin.woff2" as="font" type="font/woff2" crossorigin>Match the fallback to stop layout shift
When the web font arrives, text re-flows if the fallback font has different proportions, and that movement counts towards Cumulative Layout Shift. The CSS size-adjust descriptor scales a local fallback such as Arial so it takes up nearly the same space as your web font. Frameworks can do the maths for you: Next.js next/font, for example, generates an adjusted fallback automatically.
Finally, put the @font-face rules in a style block in the page head rather than in a separate stylesheet, so the browser knows about the font as early as possible.
Where to start
Open your homepage in Chrome's developer tools, filter the Network panel by Font, and count the files and kilobytes. Then run Lighthouse and look at its font and layout shift findings. If you would like a second pair of eyes, a website review covers fonts alongside the rest of your page speed, and six fixes for a slow website lists the other usual suspects.
Questions we hear about this
Is Google Fonts bad for website speed?
Not necessarily. Its files are well compressed and split by character set. The costs are an extra connection to another domain and a request to Google from every visitor's browser, which a regional court in Munich ruled in January 2022 breached the GDPR when done without consent. Self-hosting the same files removes both.
How many font files should a page load?
As few as the design allows. We aim for one or two files on the first view of a page, in WOFF2, with only the character sets the page needs. More weights and styles can load later on pages that use them.
Should I use font-display: optional?
Use it when speed matters more than showing your brand font on a slow first visit. The browser waits about 100ms, then keeps the fallback for that page view if the font has not arrived. Later page views usually get the cached font straight away.


