By Mehdi HassanHow do custom fonts affect web font performance?
Custom fonts affect web font performance in two ways: they're extra downloads that can delay readable text, and when they arrive they can make text reflow, which counts as layout shift. Both are fixable without giving up the typeface that carries your brand.
The browser can't show text in a web font until the font file has downloaded. In the meantime it shows either nothing (invisible text) or a fallback system font. When the real font arrives, the text redraws, and if the two fonts have different widths and heights, lines rewrap and the page jumps. That jump feeds Cumulative Layout Shift, one of Google's Core Web Vitals. If the headline is your largest element, slow fonts can delay Largest Contentful Paint too.
The goal of this guide is simple: keep the typeface, lose the shift.
What should design and development agree before choosing fonts?
Design and development should agree how many families, weights and styles the site really needs before anything ships, because every one of them is another file. Most marketing sites look better with a tighter type system anyway.
- One or two families. A display face for headings and a text face for body copy is plenty. Our guide to font pairing for brands covers combinations that work on screen.
- A short weight list. Regular, medium or semibold, and bold covers most layouts. Light weights at small sizes also hurt legibility.
- Italics only where used. If italics appear only in a pull quote, consider whether that's worth a file.
- Language coverage. Know which scripts and languages you need before subsetting, so you don't cut characters you'll need later.
- A license that allows self-hosting. Check this early. Some commercial licenses limit web use or require their own delivery service.
Readability belongs in the same conversation: size, line height and contrast affect who can read the page. See our basics of accessible design for type and contrast.
How do you load custom web fonts without hurting performance?
You load custom web fonts without hurting performance by serving small WOFF2 files from your own domain, preloading the critical ones and controlling what the browser shows while they load. The steps below are the order we apply them in on our builds.
Self-host the font files
Serving fonts from your own domain avoids an extra connection to a third-party server and lets you set long cache lifetimes. Frameworks make this easy: Next.js's font module downloads and self-hosts fonts at build time.
Use WOFF2 only
WOFF2 is compressed and supported by every current major browser. Older formats only add weight for browsers almost nobody uses.
Subset to what you use
Remove glyphs and languages the site doesn't need. A Latin-only subset of a large family is much smaller than the full file. Keep a separate subset for other languages if the site is multilingual.
Preload the critical one or two
Preload only the font files used above the fold, usually the heading weight and the body regular. Preloading every weight competes with your hero image for bandwidth.
Choose a font-display strategy
Use swap so text shows immediately in a fallback, or optional when you'd rather keep the fallback than shift late. Avoid leaving text invisible while fonts load.
Match the fallback metrics
Use the size-adjust, ascent-override, descent-override and line-gap-override descriptors on a fallback font face so the system font takes up the same space as your brand font. This is what removes the jump.
Test on a slow connection
Throttle the network in DevTools and watch the first load. You should see readable text at once and little or no movement when the brand font swaps in.
Which font-display value should you use?
Use swap for brand-critical fonts with matched fallbacks, and optional when stability matters more than showing the brand font on a first visit. Each value trades visible text against late movement differently.
Value | What the browser does | When to use it |
|---|---|---|
swap | Shows fallback text at once, swaps when the font loads | Brand fonts, with fallback metrics matched |
optional | Uses the font only if it arrives almost immediately, otherwise keeps the fallback for that page view | When you want no late shift at all |
fallback | Brief invisible period, short swap window, then keeps the fallback | A middle ground for body text |
block | Hides text for a while waiting for the font | Icon fonts only, and better replaced with SVG icons |
auto | Leaves it to the browser, often similar to block | Avoid: be explicit |
With optional, returning visitors usually get the brand font from cache, while a first visit on a slow connection might see the fallback. For many marketing sites that's an acceptable trade. For a brand whose typeface is the identity, use swap with carefully matched fallbacks.
Are variable fonts better for performance?
Variable fonts are better for performance when you use several weights of one family, because one file replaces many. If you only use one or two weights, a couple of static files are often smaller than a full variable file.
Pros
- One file can replace a whole set of weights and widths
- Fewer requests and simpler preloading
- Lets designers fine-tune weights for headings and responsive type
- Smooth weight transitions for hover and motion effects
Cons
- A full variable file can be larger than the two static weights you actually use
- Not every commercial family offers a variable version or license
- Subsetting tools must support variable axes
- Rendering differences between browsers need checking at small sizes
Our rule: count the weights in the design system first. Three or more weights of the same family usually favor a variable font; one or two usually favor static files.
How do Framer, Webflow and Next.js handle fonts?
Each platform handles fonts differently, and the amount of control you have over preloading and fallbacks varies. Next.js gives the most control; Framer and Webflow handle more for you but expose fewer settings.
In Next.js, the font module self-hosts Google and local fonts, subsets them, and generates fallback metrics, which removes most font-related shift without manual work. Our explainer on next/image, fonts and scripts shows how. In Webflow and Framer, uploading custom fonts and limiting weights is most of what you control, so the type-system discipline above matters even more. Our guide to Core Web Vitals fixes for Framer, Webflow and Next.js lists the platform-specific settings.
Hypothetical example: keeping a heavy display face
For example, suppose a fintech brand uses a distinctive display serif in four weights plus italics, loaded from a third-party font service, and its mobile homepage shows a visible jump in the headline.
The design team agrees the site only uses two weights of the serif and no italics on the web. Development self-hosts those two weights as Latin-subset WOFF2 files, preloads the heading weight, sets font-display to swap and adds a fallback font face with matched metrics. The typeface stays exactly the same; the jump and the extra connection are gone.
How do you check whether fonts are causing layout shift?
You check whether fonts cause layout shift by recording a page load in Chrome DevTools and looking at what moves when the font swaps in. The Performance panel marks layout shifts and shows which elements moved.
Also look at field data. Search Console's Core Web Vitals report shows whether real visitors experience layout shift on each group of pages. If the problem shows up mostly on first visits from mobile, fonts are a likely cause. Pair that with a lab check, keeping in mind that PageSpeed Insights scores differ from real-user data, and confirm the fix in field data a few weeks after release.
