Fonts You Are Loading and Not Using

Why fonts matter more than their size suggests

A font file is not large by modern standards. What makes it consequential is when it loads and what waits for it.

By default, many browsers will hold the text invisible until the font arrives, on the reasoning that showing it in the wrong typeface and then changing is jarring.

The consequence is a page that has downloaded all its text and is showing none of it, waiting on a decorative file.

On a slow connection that can be several seconds of blank space where the answer already exists.

The weights problem

Where the waste usually is.

A typeface family has weights: light, regular, medium, semibold, bold, and italic versions of each. Selecting a family frequently loads many of them.

A typical small business page uses two: regular for text and bold for headings. Sometimes three.

Loading eight when you use two means six files downloaded and never displayed, which is pure waste.

The fix is choosing weights explicitly rather than accepting whatever the default embed provides.

A worked example

A consultancy site loading two font families, one for headings and one for body, at four weights each.

Eight files, about four hundred kilobytes together, all downloaded before any text appeared.

Checking the actual usage: the body font at regular and bold, and the heading font at one weight. Three of eight.

Reducing to three weights and allowing text to display immediately in a fallback took roughly a second and a half off the point at which the page became readable.

The visual difference during that first moment is a brief flash as the font swaps in, which almost nobody notices and which is preferable to a blank page.

Nobody commented on the change. The page simply appeared faster, which is what was wanted.

Letting the text show first

The single most valuable setting in this subject.

A property called font-display controls what happens while a font is loading. Set to swap, the text appears immediately in a fallback and changes when the font arrives.

That produces a brief visible change and it means somebody can start reading a second or two sooner.

For a business site, where the point is the information rather than the typography, that trade is almost always correct.

Many font services now default to this behaviour and older embeds frequently do not, so it is worth checking what yours actually does rather than assuming.

The counter-case

Where the flash of a fallback font is genuinely unacceptable.

Brand-critical design work where typography is the product, and a visible swap undermines the impression the page exists to create.

Pages where the fallback is so different in width that the layout visibly shifts, which is worse than waiting.

The answer there is not to block rendering. It is choosing a fallback with similar metrics so the swap is barely perceptible, which takes some care and solves both problems.

Blocking the text entirely is rarely the right answer for a business site, whatever the design argument.

Self-hosting against a font service

A choice with reasons on both sides.

A font service is convenient and means a request to another company, with the delay and the dependency that implies.

Hosting the files yourself removes that request, gives you control over exactly which weights exist, and avoids a third-party dependency on a page you otherwise control.

It is slightly more work to set up and generally the better arrangement for a small site that has already trimmed everything else.

Check the licence before self-hosting, since not every font permits it.

System fonts, which cost nothing

Worth considering seriously rather than dismissing.

Every device has fonts installed already. Using them means no download, no delay, and no swap.

The page then looks slightly different on different devices, which is the reason people avoid it and rarely a problem in practice.

For a business whose site is about information rather than visual identity, system fonts are a legitimate choice that removes this entire category of problem.

The compromise many sites settle on: a system font for body text and one loaded font for headings, which keeps the character where it is most visible and the speed where it matters most.

Preloading the ones you keep

A small refinement worth knowing once the count is down.

A font referenced inside a stylesheet is not discovered until that stylesheet has been downloaded and read, which delays it by a step.

Telling the browser to fetch it early, alongside the stylesheet rather than after it, brings the swap forward and shortens the period where the fallback is showing.

It is one line and it only helps for fonts you genuinely need immediately, which for most sites is the body text weight and nothing else.

Preloading everything defeats the purpose, because the browser then competes with itself for the connection.

Icon fonts

A related item that is frequently worse than the fonts themselves.

Some themes load an entire icon library, hundreds of symbols, to display four arrows and a telephone.

That is a substantial file for a handful of small images, and the alternatives are straightforward: individual SVG icons, or a subset containing only what is used.

Worth checking, because it is common and entirely invisible until somebody looks at the list of what is actually being downloaded.

How much this is actually worth

Proportion, because font optimisation attracts more attention than its return justifies.

On a site whose images are four megabytes, fixing the fonts is rearranging furniture. The images are the problem and the fonts are a rounding error.

On a site where the images are already handled and the scripts are trimmed, fonts become the next largest thing and worth an hour.

The exception is the blocking behaviour, which is worth fixing on any site regardless of the rest, because it delays the text specifically rather than the page generally.

So: fix the render-blocking behaviour now, and come back to weights and self-hosting once the larger items on the page have been dealt with.

Checking yours

1. Look at the network requests and filter for font files.
2. Count how many weights are being downloaded.
3. Count how many are visibly used on the page.
4. Check whether text appears before or after the font arrives.
5. Check for an icon library loading in full.

The gap between steps two and three is the waste, and on most sites it turns out to be at least half of what is being downloaded.

What else is being requested unnecessarily is covered in how many things a page loads.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.