The Font That Looked Fine Until It Reached the Web
The typeface was perfect in the mockup. Then the page loaded, blinked, and swapped fonts halfway through a sentence. Here is what happens to a typeface on its way from a designer’s folder to a stranger’s browser.
The typeface was the easy part. Someone found it, everyone agreed on it, and in the mockup it did exactly what a good typeface does — made the words look like they belonged to something. Then the site went live, and on the first load the homepage came up in a font nobody chose, sat there for half a second wearing the wrong clothes, and abruptly changed its mind. Lines shifted. A headline that fit on one line now wrapped onto two. Someone on a slow connection saw no text at all for a moment, just a headline-shaped absence. The design had not changed. What changed is that the type had to travel.
A typeface is an idea; a font is a file
It is worth separating two words that get used interchangeably. A typeface is the design — the shapes, the proportions, the personality that a type designer spent years refining. A font is the file that carries that design to a machine, and files have opinions. They have a size, a format, a set of characters they happen to include, and a list of software that will or will not open them. On a printed page or inside a design app, none of that matters much; the file sits on a disk and does its job. On the web, the file has to be downloaded by a stranger, over a connection you do not control, before a single word can be rendered the way you intended. That download is where beautiful type goes wrong.
The numbers are less abstract than they sound. A single weight of a well-made typeface, in the format a designer typically receives, can easily run a few hundred kilobytes — and a design rarely uses one weight. Regular, italic, semibold, bold, maybe a light for captions: five files, each one a separate download, all of them standing between the reader and the sentence they came to read. It is common for the type on a page to outweigh every image on it.
The formats, briefly and without the folklore
There are only a handful of formats you are likely to meet, and the differences between them are simpler than the file extensions suggest:
- →TTF and OTF are the working formats. They are what a foundry sends you and what your operating system installs. Both are perfectly capable, both are uncompressed, and both are heavier than anything you want to send across a network.
- →WOFF was the first format built specifically for the web. Underneath it is essentially the same font data, wrapped in compression and a little metadata. Same shapes, smaller download.
- →WOFF2 is the same idea with much better compression, and it is the one that matters today. Compared with the raw file it typically cuts thirty to fifty percent of the weight — sometimes more — with no visible difference whatsoever. Every browser in current use supports it.
- →EOT and SVG fonts are relics of a browser era that has ended. If you find them in a tutorial, the tutorial is old.
The practical upshot is unglamorous: the file a designer hands over is almost never the file a website should serve. It is a source, not a deliverable — the same way a layered master image is not the thing you upload. Converting it to a web format is a small, mechanical step that happens to be the single largest improvement most sites can make to how their type loads.
Why the text flashes before it settles
That blink you keep noticing has a mundane cause. A browser meets a paragraph, discovers it needs a font that has not arrived, and must decide what to do while it waits. It can show the text immediately in a fallback face and swap once the real font lands, which is why a page seems to change its mind mid-sentence. Or it can show nothing at all and hold the space empty until the download completes, which is why a headline sometimes appears seconds after the layout around it. Neither behaviour is a bug. Both are the browser making the best of a font that is taking too long.
The shift that comes with the swap is worse than it looks, too. Fallback faces have different letter widths, so when the real font arrives the text reflows — buttons move, a line that fit now wraps, and a reader who had just begun a sentence loses their place. Nobody consciously registers this. They register that the site feels cheap.
Shipping less of the font you already have
Compression is the obvious lever, but it is not the only one. A modern font file is generous by default: it may carry Cyrillic, Greek, Vietnamese, a full set of mathematical symbols, and glyphs for languages your site will never publish a word in. All of it downloads. Trimming a font to the characters you actually use — subsetting, in the jargon — routinely halves what is left after compression. A handful of habits cover most of the ground:
- 1Convert to a compressed web format before anything else. It is the cheapest win available and requires no design decisions.
- 2Ship only the weights and styles the design genuinely uses. Two well-chosen weights read better than five vaguely different ones anyway.
- 3Drop character ranges the site will never render, and be honest about which those are — an English blog does not need Cyrillic.
- 4Tell the browser to show fallback text immediately rather than leaving a hole, and choose a fallback whose proportions are close enough that the swap does not rearrange the page.
- 5Load the fonts that appear above the fold first, and let the rest arrive when they arrive.
The licence is part of the file
One thing worth saying plainly, because it is easy to miss in the technical detail: a licence to install a font on your computer is not automatically a licence to serve it from a website. Desktop and web licences are usually sold separately, and putting a desktop font on a public server can quietly breach the terms someone paid for. Converting a file to a web format changes nothing about who is permitted to use it. Check what you bought, or use a typeface whose licence explicitly allows web use — there are a great many, and some of them are extraordinary.
Type is the interface
It is tempting to file all of this under performance and move on, but that undersells it. On most websites, the type is not decorating the content — the type is the content, the thing the reader came for, the surface everything else is arranged around. When it arrives late, swaps clumsily, or drags a megabyte of unused alphabets behind it, that is not a technical footnote. It is the first impression, mishandled. The good news is that the fix lives almost entirely in the file rather than the design: convert it, trim it, load it thoughtfully, and the typeface everyone agreed on in the mockup finally shows up on the page looking exactly like itself.