These are valid points, but in non-perf benchmark terms, what is the benefit to rendering before fonts load? I have never appreciated getting to read for a couple of seconds before the screen repaints and I lose where I was and just start over.
I have never appreciated being on a slow connection and not being able to view the info I need because fonts are downloading for 30 to 60 seconds.
If your font I'd big enough that it's causing a "couple of seconds" then you should just use the system fallback font rather than leaving me staring at a blank screen
Re:Faster web fonts
by silverwind on Sunday May 16, 2021 @06:20AM
(#27172620)
Web fonts with limited glyph sets are like 30kB before base64, it's certainly worth it to block for a few milliseconds more to prevent FOUC/FOIT altogether.
- base64 encoded strings are larger than the real file size.
- It blocks browser rendering. Browsers can still render a page while it's downloading the fonts. Not while it is downloading CSS.
- Makes cache busting hard. You will update CSS files more often than fonts. Fonts, served with right headers, can stay longer in browser cache.
- Base64 encoded strings don't compress well. I go as far as sorting the attributes/combined classes to increase the compressibility of the CSS, but base64 strings hardly compress.
You won't see FOIT/FOUT because the browser is outright blocking the rendering until the CSS is completely downloaded. That is arguably a worse outcome.