I agree entirely; the clients don't. It's an almost universal question brought up by them during the design phase - "this font looks like everyone else, we want our own". The changes to TypeKit have certainly put a squeeze on their options, but they still almost universally hate the system level fonts. Wish I could convince the business guys to push back, but eh, there are bigger problems we face on a day to day basis.
That might change. Google are changing their search ranking metrics to include the new Core Web Vitals metrics[1]. One of those is "Cumulative Layout Shift", or how much the page changes the layout over time. Using a font that isn't performant will cause the page to render, and then to move around once the page loads, which could push your site down on Google's search results page.
Has anyone ever suggested doing "progressive fonts"? I.e., start the font downloading before the page renders at all; have the font organized so the first thing that's received is the bounding boxes + kerning table + ligatures table (= enough to know how much space an inline flow of graphemes will take up); then load the page, with the page layout already settled, while loading the font itself in the background. Eventually, the text just pops into existence (without disrupting the layout) once the font is available.
Or, if you don't want to make the browser engine understand the intricacies of font formats, just split the font file for each font-family into two new file-subformats, one for layout-description and one for visual-description. Then add a rule to the CSS parser, saying that CSS references to font layout-description files are loaded synchronously (i.e. blocking rendering), while CSS references to font visual-description files are loaded asynchronously (as they always have been.)
This is a great idea. Actually drawing the glyphs can be computationally expensive too. I'm not sure what browsers do, but in the last game I made, it was an enormous win to have a glyph cache for the various combinations of (size,glyph,quantized pixel alignment) rather than rendering each glyph from scratch.
I could imagine quickly getting layout information, then asynchronously getting glyph drawing information and painting from the glyph cache when it becomes available. You could even paint a similar fallback font using the layout information of the real font to avoid redoing layout on the whole page while still being readable until it finishes.
Just HTTP2 Server Pushing a smaller set of fonts will do the job. I have a website with 6 font variants that loads in 200ms. It loads even faster once the fonts are cached.
