When to skip web fonts

A second font with four weights

Ravi's mint tea page has used Caveat since lesson 20.1. Last lesson, he gave it a fallback face: a local font, sized like Caveat, so the swap moves nothing. This week, Meera, a designer, draws the page again. She keeps Caveat for the heading. "Handwriting is lovely in a title," she says. "But it's hard to read in long text."

For the rest of the text, she picks Lora. It's a calm book font with serifs: small strokes at the ends of the letters. And she wants four weights. Lesson 20.2 met weights: how thick the letters are, from 400 for regular to 700 for bold. Meera asks for 400, 500, 600 and 700. She wants each one in italic too. Italic letters slope, and some have shapes of their own.

That's eight styles: four weights, each upright and italic. Lora comes as one file per style. So Ravi's page would send eight more files to Asha's phone. But her phone already has fonts of its own. The shop's name has used one since lesson 20.1, and the buttons since lesson 20.3. Nothing was ever downloaded for them. So Ravi wonders. What would Meera's eight files cost Asha? And could the text simply use the phone's own font?

The course loaded the page three ways in Chrome 157, set up like Asha's phone, as before. That means a phone's screen, DevTools' Slow 4G network, and a CPU 4 times slower. The heading stayed in Caveat each time. Only the text changed:

• in the phone's own font;
• in Lora, with only the regular file;
• in Lora as Meera asked, with eight files.

1// Asha's phone, Slow 4G: the text's font, as recorded (ms after she opened the page)2const pages = {3  "system font": { loraBytes: 0, wordsAt: 1265, finalAt: 1265 },4  "Lora, 1 file": { loraBytes: 21148, wordsAt: 1236, finalAt: 2051 },5  "Lora, 8 files": { loraBytes: 177736, wordsAt: 1232, finalAt: 2964 },6};7 8for (const [page, { loraBytes, wordsAt, finalAt }] of Object.entries(pages)) {9  console.log(`${page}: ${loraBytes} bytes of Lora, words at ${wordsAt} ms, final at ${finalAt} ms`);10}

• Line 1 is a comment. Times are in milliseconds (ms) after Asha opened the page. Each page was loaded three times. These times come from the load in the middle.
• Lines 3 to 5 hold one page each. Each has the bytes of Lora it downloaded, when the words first appeared, and when the text took its final font.
• Line 9 prints one line per page. The first is system font: 0 bytes of Lora, words at 1265 ms, final at 1265 ms.
• The second is Lora, 1 file: 21148 bytes of Lora, words at 1236 ms, final at 2051 ms. The third is Lora, 8 files: 177736 bytes of Lora, words at 1232 ms, final at 2964 ms.

The words came at about the same moment on all three pages, a little over a second in. That's font-display: swap at work, from lesson 20.1: it shows the words at once in a font the phone has. What changed is how long the text kept changing. With the phone's own font, the text was final from the first paint, the first frame with the page on it. With Meera's eight files, it settled 1.7 seconds later. Here is what Asha saw:

Look at the heading in the bottom row. Caveat came last on every page. With the phone's font, it came at 2,238 ms. With eight Lora files, it came at 3,249 ms, about a second later. All nine font files shared the same slow line. So even Caveat, which every version had, came later.

So the eight files cost Asha twice. Her text took its final look later, and so did the heading.

The rest of the lesson takes one question at a time:

• Which fonts does a device already have? System font stacks.
• How many files does a design need? How many weights you need.
• What if a file is missing? Faux bold and italic.
• How do you choose with a designer? Talking with designers about fonts.

For the same ideas without a stopwatch, see Web fonts in the system design course.

System font stacks: fonts the device already has

Every phone and computer comes with fonts. Its menus, settings and buttons use one of them. That's its system font. web.dev puts the gain simply: "Because the font is already installed, the font does not need to be downloaded."

How does a page ask for it? It can't name one font, because each system has a different one. So CSS has a name that means "the font this device uses": system-ui. The CSS Fonts spec says it "lets text render with the default user interface font". It's a generic family: a name CSS defines, which the browser turns into a font that's installed.

Ravi's page has used it all along. Here are three lines from its stylesheet:

1body { font: 16px/1.4 system-ui, sans-serif; }2button { font: 600 18px system-ui, sans-serif; }3p, li { font-family: system-ui, sans-serif; }

• Line 1 is from lesson 20.1: the page's base font. The shop's name uses it.
• Line 2 is from lesson 20.3. It gives the buttons the same font, at weight 600.
• Line 3 is new. It puts the text in the system font too: the price, the description, the steps, the note and the tip.

Each line lists two fonts. A list like that is a font stack: fonts in order of preference. The browser walks down it and uses the first font it has. sans-serif, at the end, is another generic family. Every browser has a font for it, so the list never runs out.

Here is the same walk down the list, as a small model in JavaScript. It isn't the browser's own code.

1// A small model: the browser takes the first font in the list that this device has2const stack = ["system-ui", "Segoe UI", "Roboto", "sans-serif"];3const oldAndroidBrowser = new Set(["Roboto", "Noto Sans", "sans-serif"]);4 5const picked = stack.find((font) => oldAndroidBrowser.has(font));6console.log(`Picked: ${picked}`);

• Line 2 is the stack.
• Line 3 is the fonts an old Android browser has. It doesn't know system-ui.
• Line 5 finds the first font in the stack that the browser has. Line 6 prints Picked: Roboto.

So which font does system-ui give? The course asked DevTools, on the Mac it recorded on. In the Elements panel, the Computed tab has a Rendered fonts section. It lists the fonts that really drew an element's text. For every part of the text on the system page, it listed .SF NS, a local file: one installed on the computer. That's San Francisco, Apple's own typeface. Apple calls its SF Pro "the system font for Apple platforms".

Other systems give other fonts. The HTTP Archive's Web Almanac lists them: San Francisco on macOS and iOS, Segoe UI on Windows, and Roboto on Android.

The bold and italic parts came from the Mac's font too. DevTools listed real bold and italic faces, like .SFNS-Bold and .SFNS-RegularItalic. Apple says SF Pro "features nine weights". So the system page got all eight of Meera's styles for free.

Longer stacks, for older browsers

Older browsers didn't know system-ui, so they skipped it. That's why many sites also list the system fonts by name. Bootstrap, a popular CSS library, calls this its "native font stack":

1body {2  font-family: system-ui, -apple-system, "Segoe UI", Roboto,3    "Helvetica Neue", "Noto Sans", "Liberation Sans", Arial, sans-serif,4    "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji";5}

• Line 2 starts with system-ui. -apple-system is an older name Safari used for San Francisco. "Segoe UI" is for Windows, and Roboto for Android.
• Line 3 adds Helvetica Neue for older Apple systems. Bootstrap lists Noto Sans and Liberation Sans for Linux. Then come Arial and the generic sans-serif.
• Line 4 lists emoji fonts, so emoji show in color.

A browser that knows system-ui stops at the first name. The rest are for browsers and systems that don't.

The ui- families

The CSS Fonts spec adds four more generic families. Each is a version of the system's own font:

• ui-sans-serif: plain letters. On Apple systems, the spec's example is San Francisco.
• ui-serif: letters with serifs, like Apple's New York.
• ui-monospace: every letter the same width, like SF Mono.
• ui-rounded: letters with round ends, like SF Rounded.

The spec warns that they're "not expected to map to any font on platforms without an appropriate system font." Only Safari supports them. So always put another font after one. GitHub does this for code, in its design system, Primer:

1code, pre {2  font-family: ui-monospace, SFMono-Regular, SF Mono, Menlo, Consolas, Liberation Mono, monospace;3}

Line 2 asks for ui-monospace first. Next come monospaced fonts by name, for each system. Last is the generic monospace.

Try the families in your own browser. The playground draws a sample in the family you pick, with monospace after it:

Where system-ui needs care

The spec adds a warning. Which font you get depends on the system, its language settings and the user. Some systems pick a poor font for some languages. The spec's example: "Simplified Chinese users might get a monospaced serif font on older version of Windows".

It also says system-ui "may or may not be suitable for large paragraphs of text". MDN suggests sans-serif for long paragraphs. web.dev is more hopeful: system fonts "can work particularly well for body text". For a page in another language, check the text on real devices.

Why it matters: a system font stack costs no bytes and no requests, and the text never swaps. On Asha's phone, the system page's text was final at its first paint in all three loads, between 1,250 and 1,271 ms.

How many weights you need

Meera's eight styles mean eight @font-face rules. Lesson 20.1 met these rules: each one tells the browser where a font file is. Each rule describes one face: one style of the family. Here is one of the eight:

1@font-face {2  font-family: "Lora";3  src: url("lora-latin-600-italic.woff2") format("woff2");4  font-weight: 600;5  font-style: italic;6  font-display: swap;7}

• Lines 2 and 3 name the family and the file.
• Lines 4 and 5 say which style this file is: weight 600, in italic.
• Line 6 is the swap from lesson 20.1.

The other seven rules are the same, with another file and other numbers. web.dev says it plainly: "A font file contains a single style, unless it's a variable font." So each style is one more download.

A rule alone downloads nothing. The CSS Fonts spec says the browser must "only download those fonts that are referred to within the style rules applicable to a given page." So a file is fetched only when some text uses its style. Meera's page uses all eight, once each. So all eight came:

1// Lora's eight files on Asha's phone, as recorded2const files = 8;3const bytes = 177736;4const firstChange = 2864;5const textFinal = 2964;6 7console.log(`${files} files, ${bytes} bytes`);8console.log(`The text changed from ${firstChange} ms to ${textFinal} ms`);

• Lines 2 and 3 are the files and their bytes: about eight times the one regular file.
• Line 4 is the first frame where some of the text had changed to Lora. Line 5 is the frame where the text stopped changing.
• Lines 7 and 8 print 8 files, 177736 bytes and The text changed from 2864 ms to 2964 ms.

Each file arrived on its own, and Chrome drew the text again as each one came. So in those 100 ms, the text changed its look 7 times. Pick a page to see every frame:

Why it matters: each style costs a file. The files share the line, so more files also push back the fonts that matter most, like Caveat in the heading.

A missing weight borrows a near one

What if Ravi sends fewer files than the text asks for? The browser picks the nearest face it has. The spec gives the rule. For a weight above 500, heavier faces come first: "weights greater than or equal to the desired weight are checked in ascending order". For a weight from 400 to 500, it tries faces up to 500 first, then lighter ones, then heavier ones.

The course drew four weights with one, two and four of Lora's files. Then it asked DevTools which face drew each one:

1// Four weights, with only Lora's 400 and 700 files: the face DevTools listed for each2const drawnWith = { 400: "Lora-Regular", 500: "Lora-Regular", 600: "Lora-Bold", 700: "Lora-Bold" };3 4for (const [weight, face] of Object.entries(drawnWith)) {5  console.log(`font-weight: ${weight} drew with ${face}`);6}

• Line 2 holds what DevTools listed with two files, 400 and 700.
• Lines 4 to 6 print one line per weight. They print font-weight: 500 drew with Lora-Regular and font-weight: 600 drew with Lora-Bold, among others.

So 500 borrowed the regular face, and 600 the bold one. On screen, Meera's four weights were two. With only one file, all four drew with the regular face. Here are all three cases:

Why it matters: a missing weight isn't an error. It borrows a face, so the design gets fewer weights than it asked for. Ask which weights readers can really tell apart.

Or one variable file for every weight

Lesson 20.2 met variable fonts: one file that holds a whole range of weights. Lora comes as one too: one file for upright, one for italic.

1// Lora's Latin files, from Fontsource (bytes)2const staticFiles = [21148, 22756, 21900, 23376, 21916, 23340, 21044, 22256];3const variableFiles = [37788, 40772];4const sum = (files) => files.reduce((total, bytes) => total + bytes, 0);5 6console.log(`8 static files: ${sum(staticFiles)} bytes`);7console.log(`2 variable files: ${sum(variableFiles)} bytes`);

• Line 2 is the eight static files' sizes, in bytes. Line 3 is the two variable files.
• Line 4 adds up a list.
• Lines 6 and 7 print 8 static files: 177736 bytes and 2 variable files: 78560 bytes.

With the two variable files, the text was final at 2,497 ms. That's 467 ms sooner than with eight files, and still 1,232 ms after the system page. Lesson 20.2 also warned that a variable file is usually bigger than any one static file. The last section has a playground for that balance.

Faux bold and italic when a file is missing

Look again at the page with one Lora file. Its price and tip ask for bold, and some of its words for italic. But Ravi sent only the regular file. DevTools listed that one file for every part of the text. So where did the bold and the italic come from?

The browser made them. The CSS Fonts spec calls this synthesis: making a missing style from a face that's there. A browser might "synthesize a bold face by drawing a thin stroke around each glyph". A glyph is the drawn shape of one letter. For italic, it slants the upright letters. Made-up styles like these are called faux bold and faux italic. Faux means fake.

When does Chrome fake bold? Chromium's source decides it in a few lines. The text has to ask for weight 600 or more, and the family's heaviest face has to be under 600. That's why, in the last picture, 500 stayed plain regular with one file. Italic is faked when the family has no sloped face at all.

How good is the fake? The course drew a bold phrase and an italic phrase in Lora three ways, at 32 px:

The spec is honest about it. Synthesis "does not meet the level of quality of a face designed for the purpose." In the screenshots, the faux bold is only a little darker. The faux italic is the same letters, slanted. The real italic has letters of its own. Look back at the opening picture too. On the one-file page, the price and the tip look almost regular once Lora arrives. The widths tell you more:

1// "Ravi's tip" at 32px, measured with Lora's files (px wide)2const regular = 131.75;3const fauxBold = 131.75;4const realBold = 138.5;5 6console.log(`Faux bold: ${(fauxBold - regular).toFixed(2)} px wider than regular`);7console.log(`Real bold: ${(realBold - regular).toFixed(2)} px wider than regular`);

• Lines 2 to 4 are the bold phrase's width: in regular, in faux bold, and in real bold.
• Lines 6 and 7 print Faux bold: 0.00 px wider than regular and Real bold: 6.75 px wider than regular.

The fake keeps the regular letters' widths. The real bold is wider. So a line laid out in faux bold can grow when the real file arrives. That's a font swap moving the page, as in lesson 20.3. The italic went the other way: 140.75 px faked, and 135.23 px real.

Turning the fakes off

The font-synthesis property says which styles the browser may fake. Its starting value lets it fake them all.

1p, li {2  font-family: "Lora", serif;3  font-synthesis: none;4}

Line 3, font-synthesis: none, tells the browser not to fake any style. Bold text with no bold file then draws in regular. Italic text with no italic file stays upright. You can also allow one kind only: font-synthesis: style allows faux italic, but no faux bold.

MDN gives one reason to turn faking off. In Chinese, Japanese and Korean, faked styles "might impede the legibility or change the meaning of the text."

Try all three in your own browser, with Lora's files from this site:

Why it matters: a missing file doesn't break the page, because the browser fakes the style. But the fake looks worse, and the real file can still move the text when it comes. Send the styles the design depends on, or design without them.

Talking with designers about fonts

Meera chose Lora for a reason: it looks like the shop. Ravi doesn't want to just say no. He wants her to choose with the price in front of her.

So Ravi makes a menu from the recordings. Read each row across: one way to set the text, and what it cost on Asha's phone.

Most of the web pays some of this price. The Web Almanac measures millions of pages each year. In its 2025 data, web fonts were on about 88% of sites. The median page, the one in the middle, asked for 4 font files. On phones, the busiest tenth of pages asked for 9 or more. About 9% of mobile pages listed system-ui.

Then Ravi and Meera ask a few questions together:

• Which text carries the brand? A heading or a slogan may need the web font. Long text may not.
• Which styles do the pages really use? Count them on the real pages, not in the font's catalogue.
• Can readers tell the weights apart? With two files, 500 looked like 400, and 600 like 700.
• Static files or a variable font? It depends on how many styles you keep. The playground below shows the balance.
• What shows before the font arrives? That's the fallback, from lesson 20.3.

Pick a set of styles to see what it costs as static files and as variable ones:

Ravi and Meera read the menu together. They keep Caveat for the heading: it's the shop's handwriting, and it's one file. The text goes in the system font stack. It was final at the first paint. On the recording Mac, the system font had a real face for every style Meera wanted. Meera asks for one thing: the tip stays bold. On the system page, it already was.

Why it matters: designers choose fonts for good reasons. Show them the cost in their own terms: what the visitor sees, and when. Then you decide together.

Web font or system font?

For each piece of text, ask what the font itself adds. Is it the brand, or just easy reading?

Common mix-ups

• "system-ui is one font." No. It names each device's own interface font: San Francisco on a Mac, Segoe UI on Windows, Roboto on Android.
• "Eight @font-face rules download eight files." No. The browser downloads a face only when some text on the page uses its style.
• "Without a bold file, bold text shows as regular." No. Chrome fakes bold from weight 600 up, unless font-synthesis says not to.
• "Faux bold is as good as the real bold." No. It was only a little darker, and kept the regular widths. The real bold was 6.75 px wider.
• "Four weights in the CSS means four weights on screen." No. With only a 400 and a 700 file, 500 drew as regular and 600 as bold.
• "ui-serif works in every browser." No. Only Safari supports the ui- families. Always put another font after one.

Practice exercises

Answer each one first, then open the hints if you need them.

// Lora's regular and italic Latin files (bytes)
const regular = 21148;
const italic = 22756;

console.log(`2 files, ${regular + italic} bytes`);

// The CSS rule for a weight under 400: lighter faces from the heaviest down, then heavier ones from the lightest up
const faces = [400, 700];
const wanted = 300;
const lighter = faces.filter((weight) => weight <= wanted).sort((a, b) => b - a);
const heavier = faces.filter((weight) => weight > wanted).sort((a, b) => a - b);

console.log(`font-weight: ${wanted} uses the ${[...lighter, ...heavier][0]} face`);

@font-face {
  font-family: "Lora";
  src: url("lora-latin-400-normal.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}
p, li { font-family: "Lora", serif; font-synthesis: none; }
.price { font-weight: 600; }

@font-face {
  font-family: "Lora";
  src: url("lora-latin-400-normal.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}
p, li { font-family: "Lora", serif; }
.price { font-weight: 600; }

Check your understanding

For each question, ask whether the font is already on the device, and which style the text asks for.

Key takeaways

• A system font is already on the device. A stack like system-ui, sans-serif costs no bytes, and the text never swaps.
• system-ui is San Francisco on a Mac, Segoe UI on Windows and Roboto on Android. End every stack with a generic family.
• Each style of a static font is one file, downloaded only if some text uses it. Eight files kept the text changing until 2,964 ms.
• A missing weight borrows a near face. Chrome fakes bold from 600 up, and fakes italic; font-synthesis can turn that off.
• Show designers the cost: bytes, files, and when the text is final. Keep web fonts for the text that carries the brand.

Sources

The facts on this page come from these standards, docs, data and source code:

• Best practices for fonts: use fewer web fonts, web.dev.
• CSS Fonts Module Level 4: generic font families, W3C.
• Fonts for Apple platforms, Apple.
• DevTools: PlatformFontsWidget.ts, the Rendered fonts section, the Chrome DevTools project.
• Web Almanac 2025, Fonts: generic and system fonts, HTTP Archive.
• Reboot: native font stack, Bootstrap.
• font-family, MDN.
• Primer primitives 11.10.0: font-stack.json5, GitHub.
• CSS Fonts Module Level 4: font loading guidelines, W3C.
• CSS Fonts Module Level 4: the font matching algorithm, W3C.
• Lora, Fontsource.
• CSS Fonts Module Level 4: controlling synthetic faces, W3C.
• Chromium 157: css_segmented_font_face.cc, when Chrome fakes bold and italic, the Chromium project.
• Chromium 157: font_selection_types.h, the bold threshold, the Chromium project.
• font-synthesis, MDN.
• Web Almanac 2025, Page Weight: fonts request volume, HTTP Archive.

Coming next: Delivering CSS. The fonts are done. Next, the stylesheet itself: how to get the CSS a page needs to it fast.