@Dave Crossland The base64 encoding doesn't get the benefit of caching; maybe negligible for a "font presentation" stub. But for reducing requests, absolutely.
Still curious that they deemed the files "crippled enough" to not be rip-worthy simply by lacking the space character while retaining everything else fairly unnecessary for a "font presentation" website in the files. The rationale probably being that the threat comes from scrapers that mindlessly pull every woff they encounter and which only want whole fonts, not from intelligible sources that might be savy enough to add the space back in. It is thoughtful though in the sense that kerns against space are a fairly minor degradation, and the flash of "unstyled" space characters rendering in a system font initially is also not very intrusive to the font evaluation experience.
Reminds me that some ~5 years ago I implemented a character set viewer based on SVGs. It is astonishing how much bigger "a full glyphset" becomes without nice woff compression. I think in the end we even tweaked how many decimals to retain the SVG point data in order to make them smaller. As far as I remember we also added matrix transforms individual to each character that got "un-transformed" from a json map when rendered on the site, so even the inlined SVGs as such would be a pain to reverse engineer. Absolutely ludicrous exercise in practice, but fun from the standpoint of a technical exercise.
@Dave Crossland The base64 encoding doesn't get the benefit of caching; maybe negligible for a "font presentation" stub. But for reducing requests, absolutely.
I don't understand. If a base64 font is encoded into a CSS file, isn't the CSS cached? What am I missing?
The space thing is kinda cute: the main font gets an ultra wide space character, which makes it unusable for any text containing space characters. They negate this on their site by prioritising a font with the correct space character in the font stack.
Like with all webfont obfuscation, it's easily circumvented.
Regarding inlining fonts in CSS, caching is indeed not the problem, and there are actually benefits, but you'd need to weigh the pros and cons carefully.
[…] much narrower user agent support but smaller file sizes (WOFF2)
is no longer the con it once was. However, base64-encoding data will increase its byte size by about ⅓. So while you will save an additional request, the server now might need to send more data over the wire and do it without the option to do so in parallel.
Roel Nieskens said: Regarding inlining fonts in CSS, caching is indeed not the problem, and there are actually benefits, but you'd need to weigh the pros and cons carefully.
Yes, you're right of course, I confused myself thinking about performance. As per what Florian pointed out, it does grow the size, I think that's what I was thinking of... just had this mental "base 64 no no" sign flashing in my mind.
For a site where you'd use some fonts/families only on some pages you might split the inlined CSS per family so you have more flexibility and don't load e.g. the entire catalog of inlined fonts in the main CSS on the homepage. Splitting them, however, you may not get the benefit of the "instantly" available font because now you are waiting on different CSS requests to resolve before render happens. Also compared to simply defining all webfonts and letting the browser load them when and if needed it requires a lot more thoughtful planning, too. You end up always waiting "for the entire CSS" with all the inlines before even one starts rendering, no matter which of those defined fonts you are actually using. And if you split them into one CSS file per style, then you end up with the same amount of HTTP requests either way, and all one has achieved would be a little obscurity for the price of more bandwidth and more implementation complexity.
It might be a reasonable approach to inline e.g. your site's main text/UI font but for presenting a catalog of fonts I don't think base64 encoded CSS is the way to go.
With HTTP/2, which is widely supported now, browsers can request all files in one TCP connection, and in parallel. If you need even more optimization, look into HTTP/2’s ability to prioritize certain files, and to push any dependency files (e.g. CSS and WOFF2 that are linked in a certain HTML file) to the client before it even requests them.
All that means for me that I wouldn’t bother with base64 encoded files inside other files, which as has been mentioned, is very ineffective file size wise.
Also, incremental font transfer is coming. Of obvious benefit for larger fonts, especially CJK, but it is something that font foundries could specify as a license requirement for self-hosted webfonts if they wanted to restrict complete fonts being served and downloaded every time.
I'm looking forward to seeing incremental font transfer solve most network performance problems. It's coming, but I'm not holding by breath. It needs support in the browser *and* the server, and while browsers get updated relavtively quick I wonder when and how regulr hosters decide to implement incremental serving on their side. There's many more different webserver software than browsers. For incremental font transfer to work, it needs to be supported on both sides.
On the subject of loading fonts for typohraphy sites, I prefer the CSS Font Loading API over plain CSS as it give much more control over what should happen before and during loading, and how the font should be applied. CSS leaves loading and applying the font as much as possible to the browser, which is good for "normal" sites. But FOUT makes no sense for a specimen site, and the ability to swap fonts when needed is very powerful. For example, loading an alphabet-only font for your "quick brown fox", and upon the type tester becoming active, swap in a full(er) font.
[…] much narrower user agent support but smaller file sizes (WOFF2)
is no longer the con it once was. However, base64-encoding data will increase its byte size by about ⅓. So while you will save an additional request, the server now might need to send more data over the wire and do it without the option to do so in parallel.
Except... most browsers accept gzip'ed Content-Encoding, and most servers gzip their CSS, and since base-64 is text, it probably gzip's quite nicely back down to the size it was before.
Simon Cozens Just checked in a browser's web inspector, and it seems like it is. CSS file (with a base64 encoded font source): 81 kb → transfer size: 60 kb. WOFF file: 60 kb → transfer size: 60 kb.
Comments
You may have the bandwidth, but maybe the visitor doesn't.
Like with all webfont obfuscation, it's easily circumvented.
Regarding inlining fonts in CSS, caching is indeed not the problem, and there are actually benefits, but you'd need to weigh the pros and cons carefully.
All that means for me that I wouldn’t bother with base64 encoded files inside other files, which as has been mentioned, is very ineffective file size wise.
Just checked in a browser's web inspector, and it seems like it is.
CSS file (with a base64 encoded font source): 81 kb → transfer size: 60 kb.
WOFF file: 60 kb → transfer size: 60 kb.
Seems I needed reeducating about base64 encoded webfonts entirely, thanks!