Web fonts that load fast for Core Web Vitals are fonts with small file sizes, efficient formats like WOFF2, and proper loading strategies that avoid blocking the page render. Fonts like Inter, Roboto, and Open Sans are popular choices because they stay under 30KB per subset and are widely supported. But the font file itself is only part of the equation how you load it, what format you serve, and whether you set proper fallback sizing all determine the actual impact on your LCP, FCP, and CLS scores.

What do Core Web Vitals actually measure about font loading?

Google's Core Web Vitals track three things: how fast the largest visible element paints (Largest Contentful Paint), how quickly users see any content at all (First Contentful Paint), and how much the page layout jumps around while loading (Cumulative Layout Shift). Web fonts touch all three. A heavy font file delays LCP if it blocks rendering. A slow first byte on a font request pushes back FCP. And if the browser swaps a system fallback font for the web font after it arrives without reserving space that swap causes visible layout shifts that hurt your CLS score.

The goal isn't to avoid web fonts entirely. It's to load them in a way that the browser can render text immediately and swap fonts without movement.

Which fonts have the smallest file sizes?

Font file size is the single biggest factor in load time. Latin-only subsets of modern fonts typically range from 15KB to 60KB in WOFF2 format. Fonts designed with performance in mind tend to sit at the lower end:

  • Inter around 15–17KB per weight for the Latin subset. One of the lightest variable fonts available.
  • Noto Sans approximately 16–20KB per weight in Latin. Google maintains it with consistent hinting across weights.
  • Roboto roughly 17–22KB per weight. Ships with Android and is optimized for small size.
  • Open Sans about 18–23KB per weight. A safe, well-hinted option for body text.
  • Lato around 20–25KB per weight. Slightly larger but still reasonable.
  • Fira Sans about 20–24KB per weight. Originally designed for Firefox OS, well-optimized.
  • Source Sans Pro approximately 18–22KB per weight. Adobe's open-source workhorse.
  • Montserrat around 17–21KB per weight. Popular for headings and UI elements.

A variable font file combining multiple weights can sometimes be smaller than loading two or three separate weight files. For example, a variable Inter file covering weights 400–700 is about 100KB in WOFF2 less than loading three static files separately. You can reduce font file sizes further by subsetting only the characters your site actually uses.

Does the font format really matter for speed?

Yes. WOFF2 compresses 30% smaller than WOFF on average, which translates directly into faster download times. Every modern browser supports WOFF2 there's no reason to serve WOFF as a primary format anymore. TTF and OTF files are uncompressed and should never be served on the web. If you're still including WOFF fallbacks in your @font-face declarations, you're adding dead code that no real browser needs. A full comparison of WOFF2 vs WOFF shows the gap is significant enough to affect your metrics.

Should you use the system font stack instead of web fonts?

The system font stack uses the default font on each operating system San Francisco on Apple devices, Segoe UI on Windows, Roboto on Android. There is zero network request and zero loading delay. For raw speed, nothing beats it.

The trade-off is visual consistency. Your text will look different on every platform. For blogs, documentation sites, and internal tools, this is usually fine. For brand-sensitive marketing pages, you probably want at least a heading font that matches your identity. A common middle ground: use the system stack for body text and load one lightweight web font for headings only. That cuts your font payload roughly in half.

What causes font-related layout shifts (CLS)?

Layout shifts from fonts happen when the browser renders text in a fallback font, then swaps to the web font once it finishes downloading. If the two fonts have different metrics different x-height, letter spacing, or line height the text reflows and elements jump around. Google measures this as part of your CLS score.

You can prevent this with the CSS size-adjust, ascent-override, and descent-override descriptors. These let you tell the browser to render the fallback font with metrics that match your chosen web font, so the swap is invisible. Pair this with font-display: swap to ensure text is visible immediately rather than hidden behind a blank screen.

An example CSS setup

@font-face {
 font-family: 'Inter';
 src: url('/fonts/inter-latin.woff2') format('woff2');
 font-weight: 400;
 font-display: swap;
 ascent-override: 90%;
 descent-override: 22%;
 line-gap-override: 0%;
 size-adjust: 107%;
}

The exact values depend on your fallback font. Tools like Font Style Matcher can help you find the right adjustments.

How do you load fonts without delaying LCP?

The fastest way to load a font is to tell the browser about it before it even discovers it in your CSS. You can do this with a <link rel="preload"> tag in your HTML <head>:

<link rel="preload" href="/fonts/inter-latin.woff2" as="font" type="font/woff2" crossorigin>

This starts the download immediately rather than waiting for the CSS to be parsed. For fonts used by your LCP element usually a heading or hero text preloading can cut hundreds of milliseconds off the critical path.

But preload only the fonts that matter. Preloading five weight variants of a decorative font defeats the purpose. Two preloads maximum is a reasonable rule for most sites. If you want to go deeper on deferred loading strategies, the lazy-loading web fonts tutorial covers techniques for non-critical fonts that can wait until after the initial render.

What about Google Fonts are they already optimized?

Google Fonts serves WOFF2 to modern browsers and automatically subsets by unicode range. It also sets proper cache headers and uses a global CDN. For most sites, Google Fonts is a solid default the optimization is built in.

The performance downside is the extra DNS lookup and connection to fonts.googleapis.com and fonts.gstatic.com. Self-hosting eliminates that connection overhead and gives you full control over caching, subsetting, and preload behavior. If you self-host, make sure you only include the subsets and weights you need. A list of the best lightweight Google Fonts for mobile performance can help you pick starting points.

Common mistakes that slow down font loading

  • Loading every weight as a separate file. If you only use Regular and Bold, don't load Light, SemiBold, and ExtraBold "just in case." Each file is another request.
  • Not subsetting. Full Google Fonts files include Cyrillic, Greek, Vietnamese, and Latin Extended characters. If your audience only reads Latin, you're downloading glyphs you'll never display.
  • Using font-display: block. This hides text for up to three seconds waiting for the font. It hurts perceived performance and LCP. Use swap or optional instead.
  • Hosting fonts on a slow server. If your fonts live on a $5 shared hosting plan with no CDN, every font request adds latency. Either use a CDN or self-host through a service that provides one.
  • Not preloading the LCP font. If your hero headline uses a web font and you don't preload it, the browser discovers the font late in the rendering pipeline.
  • Ignoring font-display for icon fonts. Icon fonts without proper display settings can cause layout shifts when symbols swap in.

How many font weights should a fast site use?

Two to three weights is the practical maximum for performance-conscious sites. A common pairing is Regular (400) for body text and Bold (700) for emphasis. If you want a lighter heading style, add SemiBold (600). Each additional weight means another file download (unless you're using a variable font). If you're using a variable font, you get all weights in one file but the file is larger it's a trade-off worth testing.

What about font-display: optional?

font-display: optional tells the browser to use the web font only if it arrives within a very short window (about 100ms). If it doesn't make it, the fallback font is used for the entire page session. The next visit will use the cached font. This eliminates layout shifts completely but means some first-time visitors will never see your web font. For content-focused sites where brand typography isn't critical, this is the fastest option. For brand-sensitive sites, swap with proper metric overrides is usually the better balance.

Quick font performance checklist

  1. Audit which fonts and weights your site actually loads remove anything unused.
  2. Serve only WOFF2 format. Drop WOFF, TTF, and OTF from your production build.
  3. Self-host your fonts and serve them from the same origin to avoid extra DNS lookups.
  4. Subset to only the character ranges your audience needs (usually Latin is enough).
  5. Consider a variable font if you need multiple weights one request instead of three.
  6. Preload only the one or two fonts used by your LCP element.
  7. Set font-display: swap with size-adjust and ascent-override to prevent CLS.
  8. Use <link rel="preconnect"> for any third-party font hosts you can't eliminate.
  9. Test with font file size optimization techniques to cut unnecessary bytes.
  10. Measure before and after using PageSpeed Insights, Lighthouse, and the Chrome UX Report.

Start by running your site through Lighthouse and checking which font requests appear in the "Reduce unused CSS" and "Avoid chaining critical requests" audits. That will show you exactly which fonts are slowing things down and by how much. Then work through the checklist above, one item at a time, and re-test after each change. Small font optimizations add up shaving 100ms off font loading can be the difference between a "needs improvement" and "good" LCP score.