Variable fonts in production, four months in

An update on the variable-fonts-only experiment from earlier this year. Four months in. What worked, what did not, a few patterns that surprised me.

What worked.

The single-file simplification. Every site shipped in the last four months has loaded one variable file per family. No “Light”, “Regular”, “Medium”, “Bold” weight files. One file. Tunable in CSS. The file size is consistently smaller than the equivalent static set, by 30 to 60 per cent depending on the family. The simplification is invisible to the user and substantial to the site’s performance budget.

The optical sizing axis. Fraunces was the test case. Setting opsz dynamically by font-size, using font-optical-sizing: auto (which is now the default in most modern browsers), produces typography that feels noticeably more considered than the same family used as static cuts. The spacing tightens at small sizes. The contrast eases. The italic settles. None of this is something I have to think about. The browser is doing the work.

The grade axis. Discovered late. Use it sparingly. Adjusting grade (“how dark the type is at a given weight”) by 50 units when switching from light mode to dark mode produces text that reads better in both, because the dark mode is no longer slightly too heavy. Most variable serifs I have used either ship with grade or have an --grade axis hidden behind a different name.

What did not work.

The Adobe Fonts variable inventory. Still patchy in 2024. Several of the families I wanted to use shipped only some axes through Adobe’s CDN, with others hidden behind a “request access” wall. I have moved most font hosting to self-hosted variable files where the licence permits.

The font-variation-settings inheritance. This is a CSS quirk, not a font one. font-variation-settings is, in most current browsers, treated as a single property, which means setting weight on a child element resets the optical-sizing axis from the parent unless you also restate it. The fix is to use the dedicated CSS properties (font-weight, font-optical-sizing, etc.) where the browser supports them, and only fall back to font-variation-settings for axes that do not have a dedicated property yet. MDN’s notes on this are accurate but easy to miss.

A few surprises.

Italic-by-axis (slnt) versus italic-by-cut. Most variable families ship italic as a separate file. A few (Recursive, some Pangram families) ship it as an axis on the upright file. The axis approach is technically tidier but produces italics that do not have the redrawn letterforms that proper italics have, only slanted uprights. The cut approach is more disk space, more correct visually. Pick the cut where you can.

I have stopped designing with static cuts as the mental model. The mental model is now “this typeface family, at this point on its axes”. This sounds like a small change. It changes how I think about type pairings, weight relationships, and size scales. The result is, I think, more coherent.

For those wanting to read more on the subject, Mandy Michael’s writing on variable fonts is the deepest practical treatment I have come across. v-fonts.com is the catalogue I keep open when starting a new project. The companion pieces here on variable fonts, finally and mostly Inter cover the earlier shape of this argument.

If you have not yet moved your default workflow to variable fonts, this is the year to do it. The catalogue is no longer thin. The browser support is no longer a problem. The performance benefit is real. The design benefit is, in my experience, real too.