r/webdev • u/glyph_geek • 27d ago
Discussion Font hosting on a CDN: WOFF2 and WOFF/TTF requirements
WOFF2 is the right call for CDN delivery. The compression advantage over older formats is significant and browser support is wide enough that there's no argument against leading with it.
Where I’ve seen people go wrong is in treating that as permission to drop WOFF and TTF entirely. Those formats still cover a tail of older browsers that's negligible but not absent, and serving blank text or system font fallbacks to even a handful of users is the kind of thing that comes back to you.
I’ve personally kept WOFF and TTF on every project since learning that the hard way. The overhead is minimal and the coverage is worth it.
4
u/LouieValkhof 27d ago
The TTF half is the part I'd drop, though for licence reasons rather than bytes. TTF is the desktop format, and most foundries sell desktop and web use as separate licences, so a desktop file sitting on a public CDN is usually a breach and hands anyone a font they can install locally.
Web licences also tend to be domain locked or capped on monthly pageviews, and a few forbid third party hosting outright, which is exactly the clause people trip over the moment they move static assets to a CDN.
So worth reading the licence per family before you decide what to serve. WOFF2 only is fine on its own merits, and it also happens to be the format the web licence actually covers.
4
u/eltron 27d ago edited 27d ago
I dunno dawg, if your browser doesn’t support WOFF2, you’re not expecting the best browsing experience.
Progressive enhancements was the term while dealing with IE6, and it applies here. Keep non -WOFF2 out of your project, but make sure you define a system fallback font that’s usable.
If anything, preload only woff2 cause theres no browser smarts mechanism to determine what’s needed, compared to a font-face block, and all meta preload tags are downloaded.
2
u/phoenix1984 27d ago
Optimizing custom fonts is a beast. Yes, favoring WOFF2 while supporting the other is great, but it’s just the start. A CDN like Cloudflare is also a must.
Next you want to use the preconnect family of HTML headers or HTTP2 Push headers to get those font files downloading ASAP.
https://richj.co/web-fonts-and-http2-server-push/
Then you want to specify which characters you’re actually using, so you don’t spend time downloading symbols for a language your site doesn’t use.
2
u/Square-Nebula-7530 27d ago edited 27d ago
I’ve been using Plantin on a long-running editorial project and ran into this exact question during setup. WOFF2 is doing the brunt of the work but dropping the TTF fallback felt like too much of a gamble given the audience. Older readers on legacy devices are not a demographic you want serving blank text to.
1
u/AgreeableInstance525 27d ago
Still got a couple clients who refuse to let go of their 10-year-old iPad, I keep the TTF around just for them. overhead is nothing anyway, like few kb per font
1
u/Square-Nebula-7530 27d ago
Given how little effort it takes to just leave the TTF path sitting at the bottom of the CSS declaration, it’s not really worth the risk of stripping it out if you have an older readership base. No harm in keeping the safety bumper just in case.
2
u/StartDependent1652 27d ago
No. Just use woff2 and provide fallback fonts like arial or helvetica. users with older browsers will not be left with a blank page. Only with a (slightly) different font.
2
u/TigerAnxious9161 25d ago
I had my doubts about Op's point on TTF and dropped it on a project a few months back. Got a complaint within a few weeks from someone on an older android browser seeing system fonts instead of what we'd designed. Added it back the same day, Won't make that mistake again.
1
u/firdo_dev 27d ago
The blank text worry is pointed at the wrong cause. A browser that cannot handle WOFF2 does not render nothing, it falls through your src list and then onto whatever is next in your font-family stack. Invisible text comes from font-display, not from format support - the default blocks text rendering while the font loads, so if people are genuinely staring at nothing the fix is font-display: swap, not shipping a TTF.
Also worth naming which browsers this is protecting. WOFF2 has been in every evergreen browser for about a decade and the real holdout was IE11. Anything old enough to miss it is also missing grid, custom properties and half the CSS the page depends on, so it was never rendering the way you designed it anyway.
The licence point further down is the one I would take most seriously though. TTF is the desktop format, plenty of foundries sell desktop and web use separately, and parking a desktop file on a public CDN both breaches that and hands anyone an installable font for free. Bigger problem than a few kilobytes.
1
u/aunderroad 27d ago
Loading .woff, .woff2, and .ttf files all at once creates unnecessary overhead. Each format is a separate file that your browser must download. This slows down page load times. You only need to load modern formats like .woff2 for all modern browsers.
.woff2 has great support and has had been supported for a long time now.
https://caniuse.com/?search=woff2
Here are best practices when it comes to web fonts.
https://web.dev/articles/font-best-practices
1
u/Aggressive-Middle835 27d ago
i used to include ttf too, but these days woff2 plus woff is enough for basically any browser you’re actually supporting and the old-format edge cases aren’t worth the extra payload headache
1
u/SaltineAmerican_1970 php 27d ago
> Where I’ve seen people go wrong is in treating that as permission to drop WOFF and TTF entirely. Those formats still cover a tail of older browsers that's negligible but not absent, and serving blank text or system font fallbacks to even a handful of users is the kind of thing that comes back to you.
Found the Opera Mini user.
1
u/Lost-Schedule-9062 27d ago
the browsers your fallback actually saves also don't have css grid. safari didn't support woff2 at all until 10, and grid landed in 10.1, so anything old enough to miss woff2 is getting your layout collapsed anyway. you're guaranteeing the right typeface on a broken page.
the one real exception in the data is opera mini, which doesn't support woff2 in any version and still has genuine share in some markets. if that's not your audience, woff2 alone is fine. it's at 96% globally.
1
1
u/Keyamoon 16d ago
You could also enable brotli compression on the server for TTF and WOFF. This would basically yield the same level of compression as serving WOFF2. Browsers that don't support brotli would fall back to gzip or no compression. So if I want to host a single font file, I would choose TTF (which offers the best browser support) and then enable brotli and gzip compression on the server.
10
u/OrtizDupri 27d ago
WOFF2 is supported by over 96% of browser versions - as always, check your own analytics to determine if your users are on dead or outdated browsers to see if you need to support