More often than not, base64 encoding has a negative net-impact.

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

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

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.

Out of curiosity, how did your LCP in Chrome timeline [1] look like before/after inlining? If LCP is lower with inlining, then the approach works beyond doubt!

1: LCP – Largest Contentful Paint – a core web vital metric representing time for the visible viewport to be stable. This is better than the old "document ready" because document ready is technical, hundred other things like reflows can happen after document ready. Whereas LCP represents from a user perspective when the viewport is ready. When fonts create reflows, the viewport becomes unstable and LCP will be higher. Lower LCP = Better user-perceived loading time. https://web.dev/lcp/

I agree that one CSS file is often faster, but the thing you say about waterfall isn't true if you are using HTTP/2. You are better of serving multiple files for the fonts.

Whether that's better depends on the user's RTT to the server, and if there's already a connection in place when the browser requests the font.

> I don’t know why more websites don’t do this.

Simply because it's not very performant. base64 will make the file about 30% larger, and web fonts are already too big. It'll also block the rest of the CSS file which can delay layout calculations, and the font-display property won't work either.

> I don’t know why more websites don’t do this. Even having one large CSS file with everything compressed is much much faster then the waterfall of more files/connections.

I could make a similar argument to say not to use CSS files, just embed everything into the page.

Unless you have a ton of files, listing them all in the html will make them load just about as fast as a single file listed in the html.

> I could make a similar argument to say not to use CSS files, just embed everything into the page.

Then the poor user has to download heavier html on every page as the browse the site.

Webdevs usually forget that neither practically unlimited bandwidth nor quotas should be take for granted. A lot of people have slow internet connections, don't make 'em suffer.

I actually think there are cases for this. Say, you have a small amount of CSS and/or the user will in all probability just look at the one page on the site.

There absolutely are, and I've done it myself. But it's a rare site that would really benefit from the method.

Yeah but the first load is faster!

Brotli. Brotli. Brotli. Chomp 25 percent off the CSS. Use static compression so there is no gzip going on before the file is served. Combined with embedded fonts in the CSS, stripped to the glyphs could be the speediest. Woff2 has its own compression, would be good to have that uncompressed in the font and compressed in the Brotli.

Seems less efficient and harder to maintain than preloading the optimally precompressed font file before the CSS statement as per step 3 of this guide. Not to mention this method preserves the flexibility offered in step 2 of the guide.

I've done this a few times as well. Another benefit of this is that there is neither FOIT nor FOUT.