Font loading on the web

If we think this thought further we could separate the font metrics from the actual font shapes. The metrics are all that is needed for layout and the metrics data is tiny. We could load the metrics quickly then do layout and shape data loading in parallel.

This idea isn't new. TeX works that way. In fact the tiny font metrics data is all that TeX ever cares about and this data is enough for TeX to do its job, which is laying out the page. The actual font shapes are only read by other programs that turn the output of TeX plus the shapes into something printable or viewable. You could use TeX to typeset documents with fonts you didn't own because the metrics are not protected and publishers used to distribute the metrics to authors freely. I remember that Springer did this with their Springer customized Myriad an Minion tfm files.

The idea is not even TeX specific, as far as I know Adobe used to ship their fonts with separate metrics files too. *.afm - Adobe Font Metrics were a thing.

Wouldn't it be nice to come full circle and separate the layout from the rendering again?

In my opinion, 95 % of websites should just use system fonts. They’re good enough for almost every need really.

It gives you a pretty good looking native system font for most platforms.

Yes, it means you don't get as much control over your "brand" as a custom font. But it's a great option for those who value users' experience (fastest possible content load time, no font loading reflow, etc) over maintaining some nebulous notion of a consistent brand image through fonts on content/UI. The former tangibly benefits users, while the latter only (marginally) benefits the company/brand (99.9% of your users couldn't care less what font you used as long as it's not horribly out of place or ugly).

I would go as far as to say say this is the right tradeoff for most product/brands where your primary product/service isn't text-based (books, articles, other publications).

And if your layout is brittle enough to need pixel-perfect control over font dimensions, that's something better addressed through a more dynamic layout since it will also become a maintenance nightmare, as that's basically the antithesis to a responsive layout.

Compressed font formats aren’t typically as heavy as these kinds of resources. One could also optimize the font file size by choosing only the characters used by the website and getting rid of the rest.

> The fallback-to-custom-font matching works really well in most cases.

The article goes on to note that this is an approximation and that it doesn’t work well for all cases. I looked at the comparison screenshots, and while the text size and wrapping may be close enough, it’s quite different in terms of readability.

Websites may choose certain fonts for better readability and to better show the content structure and hierarchy. Whatever the reason, there is a specific set of preferences that the website author chose (especially if they decided to use custom fonts). That gets lost with generated substitutions like this.

It may be a good idea to spend a little time to decide, by hand, which fallbacks are good enough (which most websites do by including system defaults in the list, even a generic sans serif or serif). That way, the website’s look is still under your control in a better way (as the designer and/or developer).

Further, I suggest that in most cases you even shouldn’t know what the fallback will be—that most of the time I really, really wish people would fall straight back to a generic family. I’m tired of `font-family: Some Fancy Sans, Helvetica Neueueue, Helvetica, Liberation Sans, Arial, Droid Sans, sans-serif` and the likes. Mostly you should just go with `font-family: Some Fancy Sans, sans-serif`, and revel in not knowing what the fallback font actually is, because you’re following the user’s preference (well, for the small fraction of users that have expressed a preference, anyway; but we’ll probably appreciate it).

My use case was, I was building a website that uses HTML canvases + text and emojis to let users build custom greeting cards. I wanted users to be able to share their cards with their friends (or save it for later), but I didn't want to deal with signup or saving stuff to a database - so I just let people generate a long link that contains the card content. Since we were only using emojis and text, and since I was ok with just using one type of font, I figured I could shrink that info into a link - even if it's ugly[1]

When I first stared, I just used "Impact" font (I wanted a meme vibe), and it worked great - until I loaded it on my phone. So then I found a similar-ish font on google fonts, and that's when I first started seeing race issues. I spent some time messing with it, added preload, but it still doesn't load consistently. Especially I've noticed that the images that are used for the inside pages of a card (which are pngs generated by setting up a canvas then saving it as a blob) seem to load with a default font in race conditions. It all works again if people click to that image and load the actual canvas, but I doubt some people will do that. So it's very frustrating and I really wish there was a better way - because there really are cases where a specific font is necessary.

I think it's probably still not fixed, but here's an example of the type of load that was causing me problems.

[1] https://emojify.cards/?canvas-0=HEY+357+576+6.417+9.018+0+0+...