Smaller, faster fonts

A font that took almost five seconds

In the last lesson, Ravi copied his font's CSS from a blog post. It came with one file, caveat.woff2. This week he adds his tip to the mint tea page, in bold, under the description. First he wants to know what he's sending to his visitors. So he starts again from Caveat's own download.

He downloads Caveat from a font website. He gets one TTF file for each weight. TTF, short for TrueType font, is the format the website gives him. A weight is how thick the letters are: 400 is regular and 700 is bold. Ravi takes two files: regular for the words, and bold for the tip. They are 256,968 and 257,316 bytes, about a quarter of a megabyte each.

Asha opens the page on her phone, on a slow mobile link. The words come at once, in her phone's own font. That's what font-display: swap promised in the last lesson. Then she waits. Caveat arrives almost five seconds after she opened the page. With the blog post's file, it came at 2.2 seconds. Same font, same phone. Why is the font website's version so slow? And can Caveat come sooner than both?

The course loaded the page three times in Chrome 157, on a phone's screen. It used DevTools' Slow 4G network, and made the CPU 4 times slower, as in the last lesson. It kept every frame Chrome drew. Then it did the same for the page this lesson ends with.

1// The mint tea page on Asha's phone, as recorded (ms after she opened the page)2const fromTheWebsite = { files: 2, bytes: 514284, words: 1250, caveat: 4683 };3const finished = { files: 1, bytes: 74932, words: 1289, caveat: 1605 };4 5console.log(`From the website: ${fromTheWebsite.bytes} bytes in ${fromTheWebsite.files} files, Caveat at ${fromTheWebsite.caveat} ms`);6console.log(`Finished: ${finished.bytes} bytes in ${finished.files} file, Caveat at ${finished.caveat} ms`);

• Line 1 is a comment. Times are in milliseconds (ms) after Asha opened the page. They come from the load whose fonts arrived in the middle of the three.
• Line 2 is Ravi's page with the two TTF files. It holds how many font files there were and their bytes. Then it holds when the words appeared, and when the page was all in Caveat.
• Line 3 is the finished page: one file of 74,932 bytes.
• Lines 5 and 6 print From the website: 514284 bytes in 2 files, Caveat at 4683 ms and Finished: 74932 bytes in 1 file, Caveat at 1605 ms.

The finished page sent less than a sixth of the bytes. Caveat came more than three seconds sooner. Here is what Asha's screen showed:

Look at the left column. The words appeared at about the same moment on both pages. What changed is how long they stayed in the phone's font: 3,433 ms on the first page, and 316 ms on the finished one.

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

• Why is a TTF file so big? WOFF2: the same font in a smaller box.
• Does the page need every letter? Only the letters you need.
• One file or one per weight? One variable font or a file per weight.
• How can the font start sooner? Preloading the font the first view needs.
• Where should the files live? Self-hosting or a font service.

For the same ideas without a stopwatch, see Web fonts in the system design course. For how Next.js does these steps for you, see Optimizing fonts.

WOFF2: the same font in a smaller box

Here are Ravi's first two rules, one for each TTF file:

1@font-face {2  font-family: "Caveat";3  src: url("caveat-regular.ttf") format("truetype");4  font-display: swap;5}6@font-face {7  font-family: "Caveat";8  src: url("caveat-bold.ttf") format("truetype");9  font-weight: 700;10  font-display: swap;11}

• Lines 1 to 5 describe the regular file. Line 3 names caveat-regular.ttf, in the truetype format.
• Lines 6 to 11 describe the bold file. Line 9, font-weight: 700, says it's for bold text, like Ravi's tip.
• Both keep font-display: swap, the last lesson's choice.

What's inside a font file? Mostly letter shapes. Each shape is called a glyph. The file also holds tables of measurements, like how wide each letter is. A TTF file stores all of them as they are.

WOFF, the Web Open Font Format, is the same font with each table squeezed. It uses DEFLATE, the method gzip uses, from Text compression. WOFF2 does two things instead. First it rewrites the biggest tables, like the glyph shapes, in a form that packs better. Then it squeezes them with Brotli, a stronger method. The WOFF2 standard says this gives "improved compression and thus lower use of network bandwidth, while still allowing fast decompression even on mobile devices."

Nothing is lost. The standard says the unpacked font "will retain the exact functionality of the input font file". Converting takes a few lines. Ravi uses fontverter, a small npm package. For WOFF2, it runs Google's own WOFF2 encoder.

1import { readFileSync, writeFileSync } from "node:fs";2import fontverter from "fontverter";3 4const ttf = readFileSync("Caveat_400Regular.ttf");5const woff2 = await fontverter.convert(ttf, "woff2");6writeFileSync("caveat-regular.woff2", woff2);7console.log(`${ttf.length} bytes -> ${woff2.length} bytes`);

• Lines 1 and 2 load Node's file functions and fontverter.
• Line 4 reads the regular TTF file from the font website.
• Line 5 converts it to WOFF2. Line 6 saves the new file.
• Line 7 prints 256968 bytes -> 102596 bytes.

The course made both files in both web formats, and compared the sizes:

1// Caveat regular in three formats, and the TTF squeezed by a server with Brotli (bytes)2const ttf = 256968;3const woff = 134460;4const woff2 = 102596;5const ttfWithBrotli = 114311;6 7console.log(`WOFF2 is ${Math.round((1 - woff2 / ttf) * 100)}% smaller than the TTF`);8console.log(`WOFF2 is ${Math.round((1 - woff2 / woff) * 100)}% smaller than WOFF`);9console.log(`WOFF2 is ${ttfWithBrotli - woff2} bytes smaller than the TTF sent with Brotli`);

• Lines 2 to 4 hold the regular file's size as TTF, WOFF and WOFF2. Line 5 is the TTF squeezed with Brotli by a server, as a server can do for any file it sends.
• Line 7 prints WOFF2 is 60% smaller than the TTF.
• Line 8 prints WOFF2 is 24% smaller than WOFF. The WOFF2 report measured a middle value of 23.94% on Google's fonts, so Caveat is typical.
• Line 9 prints WOFF2 is 11715 bytes smaller than the TTF sent with Brotli.

Line 9 answers a fair question. Why not let the server squeeze the TTF? Because WOFF2 rewrites the tables first. The same Brotli, on the plain TTF, still left 11,715 more bytes.

Ravi points his two rules at caveat-regular.woff2 and caveat-bold.woff2, with format("woff2"). On Asha's phone, the files arrived at 2,928 and 2,960 ms, instead of 4,651 and 4,659. The page was all in Caveat at 2,974 ms. Pick each step to see its frames:

Why it matters: web.dev quotes the 2022 Web Almanac: "WOFF2 is now supported everywhere." So it's the only format you need. On Asha's phone, that one change saved 1.7 seconds.

Only the letters you need: subsets and unicode-range

Ravi's WOFF2 files still hold every letter Caveat has. A character is one letter, digit or sign, like a, 7 or ?. The regular file has 1,011 glyphs for 754 characters. They cover the Latin and Cyrillic alphabets, with their accented letters. The mint tea page uses 36 different characters.

A subset is a copy of a font with only some of its characters. It's like carrying a phrasebook instead of the whole dictionary. The usual cut is by alphabet: keep the Latin letters, digits and signs, and leave the rest out. Ravi uses subset-font, an npm package. It does the work with HarfBuzz, a font library built to run in Node.

1import { readFileSync, writeFileSync } from "node:fs";2import subsetFont from "subset-font";3import { LATIN_RANGE, charactersIn } from "./font-optimization-examples.ts";4 5const ttf = readFileSync("Caveat_400Regular.ttf");6const latin = await subsetFont(ttf, charactersIn(LATIN_RANGE), { targetFormat: "woff2" });7writeFileSync("caveat-latin-regular.woff2", latin);8console.log(`${ttf.length} bytes -> ${latin.length} bytes`);

• Line 3 imports two things from this lesson's own code. LATIN_RANGE is the Latin range of Caveat's Fontsource files, below. charactersIn turns it into a string with one of each character.
• Line 6 asks subset-font to keep only those characters, and to save the result as WOFF2.
• Line 8 prints 256968 bytes -> 49832 bytes.

The Latin subset is less than half the full WOFF2 file: 49,832 bytes against 102,596. Ravi's two subsets come to 101,904 bytes, about what one full WOFF2 file was. On Asha's phone, the page was all in Caveat at 2,369 ms. That's 605 ms sooner than with the full WOFF2 files.

Could Ravi keep only the page's own 36 characters? The course tried. That file is 18,132 bytes. But Ravi will change the tip and the steps. The CSS Fonts standard picks a font "for each character". If the subset lacks a character, the browser takes the next font in the list. So a new letter would show in the phone's font, in the middle of a Caveat word. Subset by alphabet, unless the text never changes, like a logo.

One file for each alphabet

Ravi adds the tea's Ukrainian name under the heading: М’ятний чай. Now some visitors need Cyrillic letters, and most don't. The answer is several subset files, and a rule for each that says which characters it covers. That's the unicode-range descriptor. Unicode gives every character a number, its code point, written like U+0410. A unicode-range lists code points, one by one or in ranges.

Caveat already comes in four such files on Fontsource, which puts open fonts in npm packages. They are latin, latin-ext (more accented Latin letters), cyrillic and cyrillic-ext. Here is the Cyrillic file's rule:

1@font-face {2  font-family: "Caveat";3  src: url("caveat-cyrillic.woff2") format("woff2");4  font-weight: 400 700;5  font-display: swap;6  unicode-range: U+0301, U+0400-045F, U+0490-0491, U+04B0-04B1, U+2116;7}

• Line 3 names the file, caveat-cyrillic.woff2.
• Line 4 says this one file covers every weight from 400 to 700. The next section explains how.
• Line 6 is the unicode-range. U+0400-045F is the main Cyrillic alphabet. The rest are a few more letters and signs.
• The other three rules look the same, each with its own file and range.

The standard is strict about these ranges: "User agents must not download or use the font for codepoints outside this set." A user agent is the browser. So the browser looks at the text, and fetches only the files whose range covers a character on the page.

The course loaded the page with all four rules twice: once in English, and once with the Ukrainian name.

1// The four-file page on Asha's phone, as recorded (ms after she opened the page)2const english = { files: ["caveat-latin.woff2"], caveat: 2217 };3const ukrainian = { files: ["caveat-latin.woff2", "caveat-cyrillic.woff2"], caveat: 2650 };4 5console.log(`English: ${english.files.join(", ")}, Caveat at ${english.caveat} ms`);6console.log(`With Ukrainian: ${ukrainian.files.join(", ")}, Caveat at ${ukrainian.caveat} ms`);

• Line 2 is the English page. Chrome fetched only caveat-latin.woff2, and the page was all in Caveat at 2,217 ms.
• Line 3 is the page with the Ukrainian name. Chrome also fetched caveat-cyrillic.woff2, 77,216 more bytes.
• Lines 5 and 6 print one line for each page.

The English page fetched one file of four, and the Ukrainian page two. The frames show one more thing. At 2,629 ms, the heading and the words were in Caveat, but the Ukrainian name was still in the phone's font. Each file swaps in on its own, when it arrives:

Try it in your own browser. The playground adds Caveat's four files with their ranges, and draws your text with them. Type English, then a Polish city like Łódź, then some Cyrillic.

Why it matters: split a font by alphabet, and each visitor downloads only the alphabets on the page. The Ukrainian name cost 77,216 bytes, and only on the page that shows it.

One variable font or a file per weight

Ravi still sends two files, one for regular and one for bold. Each is a static font: one weight per file. A variable font holds a whole range of weights in one file. The OpenType font standard says variations let a designer "incorporate multiple font faces within a font family into a single font resource."

How can one file hold every weight? It stores each letter once, at its default weight: 400 for Caveat. Then it stores how far each point of the letter's outline moves for heavier weights. The standard calls these moves deltas. For a weight in between, the browser works out the shape from the deltas. The range of weights is the weight axis. Caveat's goes from 400 to 700.

The rule for a variable file names a range of weights instead of one:

1@font-face {2  font-family: "Caveat";3  src: url("caveat.woff2") format("woff2");4  font-weight: 400 700;5  font-display: swap;6}

• Line 3 names one file, caveat.woff2.
• Line 4, font-weight: 400 700, says this file covers every weight from 400 to 700. The CSS Fonts standard accepts a range here "in place of a single value".
• The words ask for 400 and the tip asks for 700. Both come from this one file.

That file is the blog post's caveat.woff2 from the last lesson. It's Caveat's variable Latin file from Google Fonts, the same one Fontsource ships. So the blog post's file had already been through the steps so far: WOFF2, a Latin subset, and one file for both weights.

1// Caveat, Latin only, as WOFF2 (bytes)2const twoFiles = 49832 + 52072;3const variable = 74932;4 5console.log(`Two files: ${twoFiles} bytes, one variable file: ${variable} bytes`);6console.log(`The variable file saves ${twoFiles - variable} bytes and 1 request`);

• Line 2 adds up Ravi's two Latin subsets. Line 3 is the variable file.
• Line 5 prints Two files: 101904 bytes, one variable file: 74932 bytes.
• Line 6 prints The variable file saves 26972 bytes and 1 request.

On Asha's phone, the page was all in Caveat at 2,221 ms, 148 ms sooner than with two subsets. Here is how far the four steps took Ravi's bytes:

A variable file isn't always smaller. web.dev warns that variable fonts "typically have larger file sizes than individual non-variable fonts that only contain one style." Google Fonts' static Latin file for regular alone is 48,836 bytes, less than the variable one. Drag the slider to see where the balance tips:

Why it matters: if your pages use two or more weights, one variable file is usually fewer bytes, and always fewer requests. If they use one weight, a static file is smaller. Lesson 20.4, When to skip web fonts, asks how many weights you really need.

Preloading the font the first view needs

The file is small now. But it still starts late. In the last lesson, the font waited for the HTML, then the stylesheet, then the styles. On the variable page, the stylesheet arrived at 1,168 ms, and Chrome asked for the font at 1,172 ms.

A preload names a file in the HTML itself, so the browser can ask for it at once. You met preloads in Resource hints and in Remove render delay. Here is Ravi's, in the page's head:

1<link rel="preload" href="caveat.woff2" as="font" type="font/woff2" crossorigin>2<link rel="stylesheet" href="styles.css">

• Line 1 is the preload. rel="preload" says "fetch this now", and href names the file. as="font" says what kind of file it is, so it gets a font's priority.
• type="font/woff2" names the format. A browser that can't read WOFF2 skips the preload.
• crossorigin asks for the file the way fonts are always asked for. The next part explains why that matters.
• Line 2 is the stylesheet, as before. Its @font-face rule still describes the font.

1// One variable file on Asha's phone, as recorded (ms after she opened the page)2const withoutPreload = { fontAsked: 1172, fontArrived: 2202, caveat: 2221 };3const withPreload = { fontAsked: 598, fontArrived: 1586, caveat: 1605 };4 5console.log(`Without: font asked at ${withoutPreload.fontAsked} ms, Caveat at ${withoutPreload.caveat} ms`);6console.log(`With preload: font asked at ${withPreload.fontAsked} ms, Caveat at ${withPreload.caveat} ms`);

• Line 2 is the variable page without a preload. The font was asked for at 1,172 ms, and the page was all in Caveat at 2,221.
• Line 3 is the same page with the preload. Chrome asked for the font at 598 ms, at the same moment as the stylesheet. It arrived at 1,586.
• Lines 5 and 6 print Without: font asked at 1172 ms, Caveat at 2221 ms and With preload: font asked at 598 ms, Caveat at 1605 ms.

Caveat came 616 ms sooner. The preload didn't make the file smaller. It let the font download while the stylesheet was still on its way.

One thing got a little worse. Without the preload, the words first appeared at 1,226 ms. With it, they appeared at 1,289 ms, in all three loads. A preload isn't free. web.dev warns that it comes "at the cost of taking away browser resources from the loading of other resources."

Why the preload needs crossorigin

The CSS Fonts standard fetches every font in CORS mode. CORS is the way one site lets another use its files. Fonts use it even when they come from the page's own site. A plain preload doesn't. The HTML standard files each preload under a key, and the key includes how the file was asked for. So a preload without crossorigin never matches the font the stylesheet wants. Ravi tries it:

1<link rel="preload" href="caveat.woff2" as="font" type="font/woff2">2<link rel="stylesheet" href="styles.css">

Line 1 is the same preload with crossorigin left out. Chrome asked for the font twice: once for the preload, at 593 ms, and again for the stylesheet, at 1,177 ms. Its console said why, word for word:

A preload for 'https://shop.test/no-crossorigin/caveat.woff2' is found, but is not used because the request credentials mode does not match. Consider taking a look at crossorigin attribute.

The credentials mode is one part of how a file is asked for: when to send credentials, like cookies. A preload without crossorigin uses one setting, and a font uses another. Resource hints explained the two. It's like a parcel sent under the wrong name: it arrives, but nobody can collect it.

Whether the second request downloads the font again depends on the HTTP cache. On the course's test server, it did. A server proves who it is with a certificate. The test server's was home-made, and Chrome was told to accept it anyway. Chromium's source says: "Do not cache content with cert errors." So nothing was cached, and Asha downloaded the font twice. The page was all in Caveat at 2,215 ms, about the same as with no preload. In Resource hints, Chrome trusted the server, and the second request found the font in the cache. Either way, the preload was wasted.

Preload the right font

A preload says "this page needs this file now". web.dev lists two catches. A preload "ignores unicode-range declarations", so it fetches its file even if no character needs it. And too many preloads "may divert bandwidth from other critical resources." So preload only the font the first view needs. With the four subset files, that's the Latin one on an English page. With one variable file, it's that file.

Why it matters: a preload lets the font download alongside the stylesheet, which saved 616 ms here. Without crossorigin, it's wasted, and it can cost a whole second download.

Self-hosting or a font service

Ravi's font files live on his own site. That's called self-hosting. Many sites use a font service instead: a site that hosts fonts for anyone to link to. You paste a few lines into your page's head, and it sends the rest. The course built a stand-in on its own computer, so no request left it. fonts.test sends the stylesheet, and files.fonts.test sends the font files. Connections in practice used the same names.

1<link rel="preconnect" href="https://fonts.test">2<link rel="preconnect" href="https://files.fonts.test" crossorigin>3<link rel="stylesheet" href="https://fonts.test/css2?family=Caveat:wght@400..700&amp;display=swap">

• Lines 1 and 2 are preconnects: they open connections to the service's two hosts early. The second has crossorigin, because the fonts will be fetched in CORS mode.
• Line 3 links the service's stylesheet. Its address names the font, the weights from 400 to 700, and display=swap. The & is how HTML writes &.

A font service does the earlier steps for you. Its stylesheet lists one WOFF2 file per alphabet, each with a unicode-range. Google Fonts' docs say the browser "will select from the subsets supported by the font to get what it needs to render the text." The stand-in sends Caveat's four rules, pointing at files.fonts.test.

The cost is more places to go. The course's servers logged every request on a fresh visit to the page with the font service. Ravi's site sent the page and its own stylesheet. fonts.test sent the font stylesheet. files.fonts.test sent one file, caveat-latin.woff2, asked for in cors mode, as the standard says.

Each new host needs its own connection. That's why web.dev says fonts from third-party sites need "separate connection setups." This recording can't show that cost. On Asha's phone, the page was all in Caveat between 2,225 and 2,255 ms with the service, and between 2,205 and 2,233 ms self-hosted. DevTools adds its delay to each request, not to each connection: Lighthouse's docs call it request-level throttling. Connections in practice measured it on a line that slows connections too. The font service's two hosts cost two new connections in a row: 600 ms of handshakes before the font could even be asked for.

There used to be one more reason to use a font service. If a visitor had seen a popular font on another site, it might be in their cache. Not any more. Since version 86, Chrome keeps a separate cache for each site, as The browser's caches showed. Chrome's post on the change named fonts: services that share "fonts and popular scripts" across many sites "may see an increase in their traffic." Firefox 85 split its HTTP cache and its "font cache" the same way.

A font service is like a takeaway: someone else does the cooking, but every order comes from another kitchen. Read each row of the table as a question, then compare the two answers:

So self-hosting means doing the service's work yourself. web.dev lists it: WOFF2, subsets, a CDN and HTTP/2. It adds: "Always check the font licenses to confirm they allow subsetting and self-hosting." Caveat's licence, the SIL Open Font License, lets fonts be "used, studied, modified and redistributed freely".

Frameworks can do this for you. Next.js's next/font self-hosts Google fonts. Its docs say they're "served from the same domain as your deployment, meaning no requests are sent to Google by the browser". See Optimizing fonts.

Why it matters: a font service saves you work, but it costs connections and no longer shares a cache. Self-host when you can do its work. Then measure both, including connection setup, as web.dev suggests.

Which fonts should you preload?

For each font file, ask two questions. Does the first view need it? And does your HTML know its address?

Common mix-ups

• "WOFF2 changes how the font looks." No. The standard keeps "the exact functionality". In every recorded version, the heading in Caveat measured the same width: 169.7 pixels.
• "A subset should hold only the letters on this page." No. Text changes, and a letter the subset lacks shows in the next font. Subset by alphabet, unless the text never changes.
• "With unicode-range, the browser downloads every file listed." No. The English page fetched one file of four.
• "A variable font is always smaller." No. One static weight, 48,836 bytes, is smaller than the variable file, 74,932.
• "crossorigin is only for files from other sites." No. Fonts are fetched in CORS mode even from your own site. Without it, Chrome asked for the font twice.
• "Visitors already have popular fonts in their cache." No. Chrome and Firefox keep a separate cache for each site.

Practice exercises

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

const latin = [0x0000, 0x00ff];
const cyrillic = [0x0400, 0x045f];
const text = "Чай";

const needs = ([first, last]) => [...text].some((character) => character.codePointAt(0) >= first && character.codePointAt(0) <= last);
console.log(`latin: ${needs(latin)}, cyrillic: ${needs(cyrillic)}`);

const staticFiles = [48836, 51020, 50904]; // regular, bold, medium
const variable = 74932;
const total = staticFiles.reduce((sum, bytes) => sum + bytes, 0);

console.log(total > variable ? `variable saves ${total - variable} bytes` : `static saves ${variable - total} bytes`);

<link rel="preload" href="caveat.woff2" as="font" type="font/woff2">
<link rel="stylesheet" href="styles.css">

<link rel="preload" href="caveat.woff2" as="font" type="font/woff2" crossorigin>

Check your understanding

For each question, ask what the step changed: the bytes, the number of files, or when the font was asked for.

Key takeaways

• WOFF2 is the same font, rewritten and squeezed with Brotli. Caveat's was 60% smaller than the TTF.
• Subset by alphabet. With unicode-range, each visitor downloads only the alphabets on the page.
• One variable file holds a range of weights. For Caveat, it beats static files from two weights on.
• Preload the one font the first view needs, with crossorigin. Here it brought Caveat 616 ms sooner.
• A font service does these steps for you, but adds hosts and connections, and its files are cached per site.

Sources

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

• WOFF File Format 2.0, W3C.
• WOFF 2.0 Evaluation Report, W3C.
• Best practices for fonts, web.dev.
• wawoff2: Google's woff2 for Node.js, the Fontello project.
• fontverter, Andreas Lind.
• Caveat on Fontsource, Fontsource.
• Caveat in Expo's Google Fonts packages, Expo.
• subset-font, Andreas Lind.
• CSS Fonts Module Level 4: the font matching algorithm, W3C.
• CSS Fonts Module Level 4: the unicode-range descriptor, W3C.
• unicode-range, MDN.
• OpenType Font Variations overview, Microsoft.
• CSS Fonts Module Level 4: font-weight ranges in @font-face, W3C.
• Variable fonts, MDN.
• Optimize web fonts, web.dev.
• rel=preload, MDN.
• CSS Fonts Module Level 4: font fetching requirements, W3C.
• HTML Standard: the preload link type, WHATWG.
• Chromium 157: resource_fetcher.cc, the warning for an unused preload, the Chromium project.
• Chromium 157: http_cache_transaction.cc, no caching with certificate errors, the Chromium project.
• Google Fonts API: getting started, Google.
• Lighthouse: network throttling, the Lighthouse project.
• Gaining security and privacy by partitioning the cache, Chrome for Developers.
• Firefox 85 cracks down on supercookies, Mozilla.
• Fonts (next/font), Next.js.

Coming next: Fallback fonts without layout shifts, also in Loading content fast: LCP. Caveat still swaps in after the first paint, and the lines move. Next, make the fallback take the same room as the font.