Earlier quoted context omitted.
For my blog, I embedded all my webfonts into my CSS using base64 data URIs. That CSS is 100k, but my server gzips it to 72k, which is not much bigger than the CSS without the fonts + the fonts separately. Because I don't have HTTP2 yet, fewer requests make it faster (especially considering HTTPS), despite the extra size.
If you’re talking about https://theandrewbailey.com/blog/ then your CSS with and without the base64 encoding looks like this: 101K 9 Dec 18:30 with.css 99K 9 Dec 18:31 with.min.css 73K 9 Dec 18:31 with.min.css.gz 6.8K 9 Dec 18:30 without.css 5.2K 9 Dec 18:31 without.min.css 1.8K 9 Dec 18:31 without.min.css.gz Although this might be true: > …72k, which is not much bigger than the CSS without the fonts + the fonts sepa…
One advantage of embedding the fonts is that it eliminates FOUT. If the fonts were split out, once the fonts were loaded, the page would need to be re-rendered anyway. I don't see much practicality of rendering an already light page if it's going to be re-rendered differently quickly after.
By embedding the fonts, I've optimized for latency in downloading fewer files over HTTP1. Even a 2k CSS and 20k-ish font are hardly worth the cost in opening the connections; a 73k all-in-one is more efficent. Let's assume a reasonable 8mbit connection and 50ms RTT.
To download the 72k CSS on a new connection (because it's early in the page load), that takes 100ms to establish TCP and HTTPS handshake, and 122ms to download the 72k embedded font CSS, total: 222ms (at least, not including processing overhead).
For the split version: 100ms for handshakes, and 52ms for the 2k CSS transfer. Here, the browser might keep it open to download one (the headline font) (negligible load time for a open connection), and open another connection for the body text font. (the third monospaced font is rarely used.) The open one would download one 23k font in 73ms. The other connection (in parallel) will take 100ms for handshake, and 73ms for another 23k font. total: 325ms (at least, not including processing overhead).
For higher bandwidth connections, bigger files make even more sense. For split files to truly win, latency will need to be impossibly low, which for the hosting from my apartment basement (even on 150mbit fiber), is impossible.
Even though it's render blocking, browsers will continue loading other assets anyway. A mostly (if not fully complete) page will show the first time, often within a second on wired connections.
> I hope this comment is taken in the spirit it’s intended: I like making the internet fast :)
Yup. Me too!