Variable type in production

Variable fonts have been “production-ready” for years, yet most sites still ship six static files. The reason is rarely the font itself: it’s the subset, hosting, fallback and CSS chain that hasn’t been calibrated.

What you gain

A single file covers every weight and, if the font exposes it, optical size too. You go from five or six WOFF2 files to one asset, and crucially you stop fighting the visible jump between heading and body: the browser can interpolate.

What you pay

The single file weighs more than a single static. If your site only needs two weights without italic or opsz, variable may be a bad trade. Practical rule: three weights or more, variable; one or two, statics.

Where it breaks

• No subset. Shipping the full file with every glyph is the main cause of slow sites with variable type. pyftsubset with extended Latin coverage usually does the job.
• Misused font-display: swap. On XL headlines, the fallback-to-variable jump is loud. Prefer optional or a tuned size-adjust.
• Axis animations. Animating font-variation-settings is legal but CPU-heavy. If you do it, restrict it to the transition and add will-change: font-variation-settings.

Reasonable minimum setup

1. One variable subsetted to your main language.
2. Named fallback with size-adjust to minimise CLS.
3. font-display: swap for body, optional for large headlines.
4. Preload only the file you need in the first viewport.

Do these four things and a well-chosen variable feels better than a classic static system, and weighs less.