Web fonts

Why fonts hurt the first view

Picture a news site with a custom serif for headlines and a custom sans for body text. On a fast laptop the page looks perfect. On a phone on a train, the reader sees the photo and the buttons, but an empty gap where the headline should be. Two seconds later the headline appears, and the article jumps down by a line just as the reader taps a link.

Nothing was broken. The page was waiting for two font files, and then it moved when they came in. Those are the two classic font problems, and both have names.

FOIT and FOUT

• FOIT, the flash of invisible text: the browser lays the text out but paints it invisible while it waits for the font. The reader sees blank space where words should be.
• FOUT, the flash of unstyled text: the browser paints the text at once in a fallback font (say Arial), then swaps to the web font when it arrives. The reader can read right away, but sees the text change shape, and often sees the page move.

Neither flash is free. FOIT costs reading time: on a slow network the text can stay invisible for up to 3 seconds. FOUT costs stability: the web font usually has different letter widths and line heights from the fallback, so lines wrap differently and everything below them shifts. That shift counts towards CLS, Cumulative Layout Shift, one of the Core Web Vitals.

Why fonts behave differently from other files

Images can arrive late without hiding the text around them, and scripts can be deferred. Fonts sit between the text and the pixels: the browser can't draw a single glyph (the shape of one character) of a web font until it has the file.

Fonts are also found late. The browser learns that this h1 needs a given family at weight 700 only after it has the HTML and the CSS and has matched rules to elements. By then the page could otherwise be painted. So the work falls into three parts:

1. Decide what to show while waiting: invisible text, fallback text, or the fallback for good. This is font-display.
2. Make the wait shorter: find the file earlier (preload, self-hosting) and make it smaller (WOFF2, subsetting, variable fonts).
3. Make the swap harmless: tune the fallback font so it takes the same space as the web font (size-adjust and the metric overrides), or skip web fonts and use the system font.

This lesson builds on two others. The critical rendering path lesson explains why the browser waits for CSS before the first paint; fonts add a second wait on top. The loading strategies lesson covers priorities and preload syntax; here we look at which font files deserve it.

The mental model: a three-period timeline

Every web font goes through the same timeline, defined in the CSS Fonts spec. From the moment the browser requests the file, the font is in one of three periods, and the period decides what the reader sees.

1. Block period. The font hasn't arrived, so the browser draws the text with an invisible fallback: it takes up space but you can't see it. If the font arrives now, it is used at once.
2. Swap period. The browser now draws the text in a visible fallback font. If the font arrives during this period, the browser swaps it in and re-lays out the text.
3. Failure period. The font is treated as failed. The fallback stays for the life of the page, even if the file arrives later. The file still lands in the HTTP cache, so the next page can use it.

That is the whole model. FOIT is a long block period. FOUT is the font arriving during the swap period. A font that never shows on a slow connection arrived in the failure period.

An everyday comparison

Think of a restaurant waiting for the chef's special sauce. In the block period the waiter holds the plate in the kitchen: you see nothing, but the dish will be perfect. In the swap period the plate comes out with ketchup, and the sauce is swapped in if it shows up while you eat. In the failure period you finish with ketchup, and the sauce goes into the fridge for your next visit.

A wedding cake can wait in the kitchen; a burger should come out now. font-display makes that choice per font face.

When the clock starts

The timer starts when the font is first needed and requested, not when the page starts loading. If the CSS takes 800 ms and the font request starts at 900 ms, a 3 second block period hides the text until about 3.9 seconds after navigation. That is why finding the font earlier (chapter 5) helps every value: the clock starts sooner, and the file arrives sooner within it.

Try it below. Pick a font-display value, set how long the font takes to download, and step through time to see what the reader sees.

How the browser loads a font, step by step

A web font starts as an @font-face rule in your CSS. The rule doesn't download anything by itself. It only tells the browser: "there is a font family called this name, and here is where to get the file for this weight and style".

@font-face {
  font-family: "Brand Sans";
  src: url("/fonts/brand-sans-400.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

@font-face {
  font-family: "Brand Sans";
  src: url("/fonts/brand-sans-700.woff2") format("woff2");
  font-weight: 700;
  font-style: normal;
  font-display: swap;
}

body { font-family: "Brand Sans", Arial, sans-serif; }

Each @font-face rule describes one face: one family at one weight and style. A family with regular, bold, italic, and bold italic is four rules and usually four files. The font-family on body lists the web font first and fallbacks after it, ending in a generic family such as sans-serif.

The steps, with a worked example

Take a page on a 4G phone with a 100 ms round trip, with the HTML, stylesheet, and fonts all on one origin. Here is what happens, with rough, illustrative times.

1. 0 to 300 ms: HTML. The browser connects (DNS, TCP, TLS), sends the request, and starts receiving HTML. The preload scanner sees the link rel="stylesheet" and requests the CSS.
2. 300 to 550 ms: CSS. The stylesheet downloads. The browser parses it and records the two @font-face rules. Nothing is fetched for them yet.
3. 550 to 600 ms: style and layout. The browser matches rules to elements. It finds text in the body that needs Brand Sans 400, and an h1 that needs Brand Sans 700. Only now does it know which faces are used.
4. 600 ms: font requests. Both font files are requested. The font timeline clock starts for each. With swap, the text is painted at once in Arial.
5. 600 to 850 ms: font download. Two files of about 25 KB each come in. Each face swaps in as it arrives, and the text re-lays out.

The key point is step 4. The font request can't start until the CSS is downloaded and parsed and styles are computed. Fonts are the last link in a chain: HTML, then CSS, then the fonts the CSS names, and on a slow network each link costs round trips.

Fonts are lazy on purpose

Why wait for style matching? A site often declares faces a given page doesn't use: a design system might list 12 faces, and a login page might use two. Downloading only the faces that some text needs saves bytes on every page.

The same laziness applies to characters. If an @font-face rule has a unicode-range and no text on the page uses a character in that range, the file is never fetched. Chapter 6 uses this to split one big font into small pieces.

The cost of this laziness is late discovery. The preload scanner, which reads ahead in the HTML to find files early, can't see font URLs inside CSS. The fix, preloading, is in chapter 5.

Fonts are always fetched with CORS

Font files are always requested in CORS mode (Cross-Origin Resource Sharing), even from your own origin. A font on another origin, such as a CDN domain, must come with an Access-Control-Allow-Origin header, or the browser refuses to use it. This is also why font preloads need the crossorigin attribute.

font-display: the five values in detail

font-display is a descriptor inside @font-face. It sets the length of the block and swap periods for that face. The spec gives recommended lengths for its five values, and the major browsers follow them closely.

auto and block

auto is what you get if you write nothing, and the major browsers treat it like block: hide the text for up to 3 seconds, show the fallback, then swap whenever the font comes. This is the source of most FOIT on the web, because many sites never set font-display.

Use block on purpose only when the fallback would be wrong rather than just ugly, as with an icon font whose fallback shows meaningless characters. SVG icons are the better fix there.

swap

swap shows text right away in the fallback and swaps to the web font whenever it arrives, even 10 seconds later. It is the most common choice and what Google Fonts gives you with &display=swap in the URL. Text is never hidden for long, which helps FCP (First Contentful Paint) and keeps text-based LCP (Largest Contentful Paint) from waiting on the font.

The cost is the swap itself. If the fallback and the web font take different space, the page moves when the font lands, and a swap at 10 seconds jumps text the reader is in the middle of. swap plus a matched fallback (chapter 7) is a strong default; swap alone moves the problem from FOIT to CLS.

fallback

fallback is swap with a deadline. Fallback text appears at once, and the font swaps in only if it arrives within about 3 seconds. After that the page keeps the fallback and the font is cached for the next page, so there is no late jump while someone is reading.

optional

optional says: use the web font only if it is ready almost at once, otherwise don't use it on this page at all. There is no swap, so there is no swap-related layout shift. On a cold first visit the reader often sees the fallback, but the file usually still downloads, so on the next page the cached font shows from the first paint.

Chrome adds one helpful rule: when an optional font is preloaded, the first render may wait up to about 100 ms for it. On a decent connection a small, preloaded font makes it, so even first-time visitors see it without a swap. On a very slow connection the spec lets the browser abort or deprioritize the download, since the font won't be used anyway.

Mistake to avoid: using optional for a font that is part of the product's identity, like a wordmark set in text. New visitors on slow phones may never see it; optional is for fonts that are nice to have.

Getting the file early: preload and self-hosting

Every font-display value works better when the font arrives sooner. With swap, an early font means an early swap, before the reader starts reading. With optional, it decides whether the font is used at all.

Preload the right file, and only that file

A preload names a file in the HTML itself, so the request starts while the CSS is still downloading. The loading strategies lesson covers the syntax and priorities. For fonts there are three rules on top.

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

• Always add crossorigin, even for a font on your own origin. Fonts are fetched in CORS mode, so a preload without crossorigin doesn't match the real request: the font downloads twice and Chrome warns that the preload was unused.
• Preload the exact URL the CSS uses: same path, format, and subset. Preload brand-sans-400.woff2 while the CSS asks for brand-sans-400.latin.woff2, and you pay for both.
• Preload one or two files, not the family. Preloads are fetched at high priority and compete with the CSS and the LCP image. Preload the faces used above the fold, usually the body regular and maybe the headline weight.

A preload is a promise to use the file. If no text uses that face, Chrome logs a warning a few seconds after load and the bandwidth was wasted. Mistake to avoid: a shared layout that preloads four faces on every page, including pages that use one.

The Google Fonts chain

Google Fonts is easy: one link tag to a stylesheet on fonts.googleapis.com. That stylesheet, built for the user's browser, holds @font-face rules pointing at files on fonts.gstatic.com. That is two extra origins, each needing its own DNS lookup, TCP connection, and TLS handshake, before the first byte of font arrives.

The usual patch is preconnect: link rel="preconnect" href="https://fonts.gstatic.com" crossorigin sets up the connection to the font host early, in parallel with the CSS. That saves the connection setup, a few round trips, but the font URL is still only known after the Google stylesheet arrives.

The shared cache is gone

The old argument for Google Fonts was the shared cache: millions of sites use Roboto, so the user probably has it cached already. To stop sites from learning your history by timing cache hits, browsers now partition the HTTP cache by top-level site: Safari since 2013, Chrome since version 86 (2020), and Firefox since version 85 (2021).

So Roboto cached on site A is not reused on site B, and every site pays for its own copy. A third-party font host now brings the extra connections and no cache benefit.

When you self-host, give font files a hashed or versioned name and send Cache-Control: public, max-age=31536000, immutable. A published font file never changes; a new version gets a new name. Repeat visits then get the font from the disk cache with no request, which is what makes optional show the web font from the second page on.

Making the file smaller: WOFF2, subsets, variable fonts

The second way to shorten the wait is to send fewer bytes. A font file holds a drawing for every glyph it supports, plus tables for spacing, kerning (the space between letter pairs), and ligatures (joined letters like fi). A family covering Latin, Greek, and Cyrillic in many weights can weigh several hundred kilobytes, and a typical English page needs a fraction of that.

WOFF2 is the only format you need

Designers ship fonts as TTF or OTF; the web formats wrap them with compression. WOFF2 uses Brotli plus font-specific transforms, and is commonly about 30% smaller than the older WOFF and about half the size of the raw TTF. Every browser in use today supports it, so a single src: url(...) format("woff2") is enough, and old EOT, SVG, TTF, and WOFF fallbacks can go.

Since WOFF2 is already compressed, don't gzip or Brotli it again at the server; it gains nothing and costs CPU.

Subsetting: keep only the glyphs you use

Subsetting means building a new font file with only some of the glyphs. A font with 2,000 glyphs for many languages might be 150 KB as WOFF2, while a Latin subset of about 220 glyphs, enough for English and most Western European languages, is often 20 to 35 KB. Tools such as pyftsubset (from the fontTools project) and glyphhanger do this.

pyftsubset BrandSans.ttf \
  --unicodes="U+0000-00FF,U+0131,U+0152-0153,U+2000-206F,U+20AC,U+2122" \
  --layout-features="kern,liga" \
  --flavor=woff2 \
  --output-file=brand-sans.latin.woff2

The risk is cutting too much. If the subset lacks é and a user is named Zoé, the browser draws that one letter from the fallback font, in the middle of the name. Check product names, user content, currency signs, and smart quotes, and check that the license allows subsetting.

unicode-range: subsets the browser picks for you

unicode-range lets you ship several subsets under one family name, and the browser fetches only what the page's text needs. You write one @font-face rule per subset, with the same family, weight, and style, and a different unicode-range.

@font-face {
  font-family: "Brand Sans";
  src: url("/fonts/brand-sans.latin.woff2") format("woff2");
  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+2000-206F;
  font-display: swap;
}

@font-face {
  font-family: "Brand Sans";
  src: url("/fonts/brand-sans.cyrillic.woff2") format("woff2");
  unicode-range: U+0400-045F, U+0490-0491, U+04B0-04B1;
  font-display: swap;
}

An English page downloads only the Latin file; a page with one Russian word downloads both. Google Fonts serves every family this way. Japanese and Chinese fonts, with thousands of glyphs and several megabytes in full, are cut into over a hundred small slices, and a page fetches only the slices its characters fall in.

Variable fonts: one file, many weights

A static font file holds one weight and one style. A variable font holds a design that can vary along axes: weight (wght), width (wdth), slant (slnt), italic (ital), and optical size (opsz) are the standard ones. A file whose weight axis runs from 100 to 900 can draw any weight in that range, including values like 450.

@font-face {
  font-family: "Brand Sans";
  src: url("/fonts/brand-sans-var.latin.woff2") format("woff2");
  font-weight: 100 900; /* a range, not one value */
  font-display: swap;
}

h1 { font-weight: 750; }
.caption { font-variation-settings: "opsz" 12; }

A variable file is bigger than any single static weight, because it stores how each glyph changes. The win comes with several weights: for one weight ship a static file, but from about three weights the variable file is usually smaller than the static files combined, and it is one request instead of several.

Prefer the standard properties (font-weight, font-stretch, font-style) over font-variation-settings, which sets all axes at once and doesn't cascade per axis. Use the calculator to compare setups and watch the bytes a first visit pays.

Stopping the jump: matching the fallback's size

With swap or fallback, the reader sees the fallback first and the web font later. If the two take the same space, only the letter shapes change and nothing moves. If they don't, lines wrap at different words and every block below shifts, so the fix is to make the fallback take the same space as the web font.

What makes two fonts take different space

Every font is drawn on a grid called the em square. The font's metrics, numbers stored in the file, say how its glyphs sit in that square. Four of them decide the space text takes:

• Advance widths: how wide each glyph is. A wider font makes each line longer, so lines wrap sooner and paragraphs gain lines.
• Ascent: how far above the baseline the font reaches, for tall letters and accents.
• Descent: how far below the baseline it reaches, for letters like g and y.
• Line gap: extra space the font asks for between lines. With line-height: normal, the line box is ascent plus descent plus line gap.

Arial and a typical brand sans can differ by several percent in average width, ascent, and descent. Over a 60-word paragraph, a 7% width difference is enough to add or remove a line, and one extra 24 px line pushes everything below it down 24 px.

size-adjust and the override descriptors

CSS lets you adjust a local font through @font-face. You declare a new family, say Brand Sans Fallback, whose src is local("Arial"), and add descriptors that reshape Arial's metrics to match the web font.

@font-face {
  font-family: "Brand Sans Fallback";
  src: local("Arial");
  size-adjust: 107.4%;      /* scale glyph widths and heights */
  ascent-override: 90.2%;   /* of the font size */
  descent-override: 22.5%;
  line-gap-override: 0%;
}

body {
  font-family: "Brand Sans", "Brand Sans Fallback", sans-serif;
}

• size-adjust scales the whole fallback font, outlines and metrics together, by a percentage. It is the main tool for matching average width, and it doesn't change the computed font-size, so em units elsewhere are not affected.
• ascent-override and descent-override replace the ascent and descent in the file with a percentage of the font size. They fix the line height and where text sits vertically.
• line-gap-override sets the line gap, usually to 0%, to match a web font that has none.

The values come from the two fonts' metric tables, not from guessing. size-adjust is roughly the ratio of the web font's average character width to Arial's. Each override is the web font's ascent or descent divided by its em size, then divided by the size-adjust, because the browser scales the overrides by size-adjust too. The numbers above are illustrative; yours will differ.

Let a tool generate them

Few teams compute these by hand. next/font in Next.js reads the font at build time, generates a fallback @font-face with size-adjust and the overrides based on Arial or Times New Roman, and adds it to the font-family. Fontaine, from the UnJS ecosystem, does the same as a build plugin for any framework. Capsize, a library from SEEK, exposes the metrics of many fonts if you want to write the rules yourself.

Toggle the matched fallback below and step the font in. With plain Arial the paragraph rewraps and the button jumps; with the adjusted fallback the words land in the same places.

Limits of metric matching

• It matches averages, not every glyph, so a line can still break at a different word now and then. The shift becomes rare and small, not zero.
• The fallback must exist on the device. Arial is on Windows, macOS, and iOS, but usually not on Android or Linux, where local("Arial") finds nothing. Tools often list a second local font, such as Roboto on Android, with its own numbers.
• Support varies. Chrome and Firefox support all four descriptors. Safari supports size-adjust from version 17, but at the time of writing the three overrides are only in Safari Technology Preview, so vertical metrics may still differ there.

System font stacks and the Font Loading API

Two tools sit at opposite ends. A system font stack skips web fonts entirely: zero bytes, no waiting, no swap. The Font Loading API gives JavaScript control over when each font loads and what happens then.

System font stacks

Every operating system ships a well-designed UI font: San Francisco on Apple devices, Segoe UI on Windows, Roboto on Android, and often Cantarell or Ubuntu on Linux desktops. A system font stack asks for whichever one the device has.

body {
  font-family: system-ui, -apple-system, "Segoe UI", Roboto,
    "Helvetica Neue", Arial, "Noto Sans", sans-serif,
    "Apple Color Emoji", "Segoe UI Emoji";
}

code {
  font-family: ui-monospace, SFMono-Regular, Menlo, Consolas,
    "Liberation Mono", monospace;
}

system-ui is the standard generic family for the platform's UI font; the names after it cover older browsers and gaps, and ui-monospace does the same for code. Bootstrap since version 4 and the WordPress admin use stacks like this. The text is drawn at the first paint and matches the rest of the user's device.

The costs: the page looks a little different on each platform, and the brand has no typographic voice. A common middle ground is a system stack for body text and UI, and one web font, subset and preloaded, for headlines or the logo.

Mistake to avoid: relying on system-ui alone on a multilingual site. Under some Windows language settings it has picked a font that suits that language but looks odd for Latin text, so list "Segoe UI" and the others after it.

The Font Loading API

document.fonts is a FontFaceSet: all the fonts the document knows about, from CSS and from script. It lets you load fonts on demand, check whether one is ready, and wait for loading to finish. Each font is a FontFace object whose status moves through four values.

// Load a face from script, then add it to the document.
const face = new FontFace("Brand Serif", "url(/fonts/brand-serif-700.woff2)", {
  weight: "700",
  display: "swap",
});
document.fonts.add(face);
await face.load(); // status: loading, then loaded or error

// Ask for whatever CSS face matches, and wait for it.
await document.fonts.load("700 2rem 'Brand Serif'");

// Is it ready without a download? (true once loaded)
document.fonts.check("700 2rem 'Brand Serif'");

// Resolves when pending font loads and layout are done.
await document.fonts.ready;

When to use it in practice:

• Measuring text. A canvas chart, a virtualized list that measures row heights, or a text-fitting headline must wait for document.fonts.ready. Measure earlier and you measure the fallback.
• Canvas and WebGL text. Canvas doesn't re-draw when a font arrives. Call document.fonts.load() for the font, then draw.
• Grouping swaps. With several faces, each swap re-lays out the page. Loading them through the API and adding a fonts-loaded class to html once all are ready turns several reflows into one.
• Fonts for later. A rich text editor with a font picker can load each font only when the user picks it.

Mistake to avoid: hiding text with a class until document.fonts.ready resolves. That rebuilds FOIT in JavaScript, with no 3-second limit, and if the script fails the text never appears. Use the API to improve a CSS setup that already works, not to replace font-display.

Failure modes, accessibility, and real products

Font bugs rarely show up on a developer's machine, where fonts are cached, the network is fast, and the font may be installed locally. They show up on a cold cache and a slow phone, so test with DevTools throttling, the cache disabled, and the web font not installed.

What breaks in production

Accessibility

• Invisible text is inaccessible text. During FOIT the text is in the DOM, so screen readers can read it, but sighted users on slow networks, often on cheap phones, can't. Short block periods are an accessibility choice.
• Respect user font settings. Some readers choose their own fonts, such as a dyslexia-friendly typeface, or larger sizes. Use rem for sizes and don't fight user stylesheets with !important.
• Avoid icon fonts. Screen readers may announce the private code points or ligature words behind icons, and the icons break when fonts fail or when readers override page fonts. Inline SVG icons with proper labels avoid these problems.
• Readable fallbacks. If the web font fails for good, the page lives in the fallback, so pick one that is legible at your sizes.

Privacy and security

Third-party font hosts see every visitor's IP address, user agent, and the page that asked (through the Referer header). In January 2022 the Munich Regional Court ruled that a site embedding Google Fonts from Google's servers had passed a visitor's IP address to Google without consent, which pushed many European sites to self-host. Self-hosting also removes a third party from your Content Security Policy: font-src 'self' is enough.

The local() source has a privacy angle too: the list of fonts a device has installed is a fingerprinting signal. Browsers restrict it in different ways; Safari, for example, only exposes fonts that ship with the system. That is one more reason to use local() only for well-known system fonts, like the Arial fallback in chapter 7.

In real products

• GitHub draws its interface with a system font stack, so text never waits on a font file.
• Next.js sites using next/font get self-hosted files, font-display: swap by default, preloads, and a generated metric-matched fallback: this lesson's recipe, done at build time.
• News and publishing sites are a natural fit for optional or fallback on body text, so a late font never moves an article someone is already reading.

Using it in a system design interview

Fonts rarely get their own interview question, but they come up in almost every performance discussion: a news site, a product page, a design system. Bring them up when you talk about the first paint, LCP, or CLS. A sentence or two at the right moment shows depth; a five-minute lecture does not.

The recipe to draw

If the interviewer wants detail, draw the recipe as layers, from the CSS down to the network, then walk through the steps.

1. Budget the faces. Two families at most, and only the weights the design uses. Ideally a system stack for UI text.
2. Self-host WOFF2, subset to the languages you serve, split with unicode-range if you serve several scripts. Variable font if you use three or more weights.
3. Cache forever with hashed file names and immutable.
4. Preload the one or two faces used above the fold, with crossorigin.
5. Choose font-display: swap or optional for text, never auto.
6. Match the fallback with size-adjust and the overrides, generated by next/font, Fontaine, or similar.
7. Measure CLS and LCP from real users, split by first visit and repeat visit.

How deep to go by level

What to say

A good one-breath answer for a content site: "Body text uses a system stack. Headlines use one self-hosted variable WOFF2, Latin subset, about 40 KB, preloaded with crossorigin, font-display: swap, and a size-adjusted Arial fallback generated at build time, so the swap doesn't move anything. Files are hashed and cached for a year." Then stop and let the interviewer pick a thread.