[derefr]

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.)

[singron]

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.

[0-O-0]

> the text just pops into existence

This is very jarring and happens all the time with web fonts.

[nicbou]

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.