3 ms·

That's awesome! Yeah, you can definitely go overboard with webfonts. The 3 that my blog[0] uses are base64 URLs in my single 100k CSS file. Reducing javascrip

That's awesome! Yeah, you can definitely go overboard with webfonts. The 3 that my blog[0] uses are base64 URLs in my single 100k CSS file. Reducing javascript and deferring the rest gets some solid speedups. Serving everything from a single domain reduces total load time, due to DNS lookups. You might even get away with not having social media widget JS, too: https://www.hanselman.com/blog/add-social-sharing-links-to-your-blog-without-widget-javascript https://www.hanselman.com/blog/add-social-sharing-links-to-y... [0] https://theandrewbailey.com/ https://theandrewbailey.com/

kevincox 4y ago
In my opinion very few if any sites need fonts. The user has a default font, who am I to say that I know a better one? If you want to be more pragmatic you can accept that most browsers use awful fonts by default. However coming soon is system-ui, ui-serif and ui-sans-serif which allow you to let the user to continue picking the font, expect not awful. (I still don't understand why browser didn't just update initial, serif and sans-serif to be non-awful, but I'm not a browser maker)
SquareWheel 4y ago
> The 3 that my blog[0] uses are base64 URLs in my single 100k CSS file. This is not an efficient approach. Base64 will make the fonts about 30% bigger, and webfonts are already too big. The fact that it's in CSS also means that it's now render blocking, and font-display can't be used. You're likely delaying your render time versus standard font loading. Do a comparison in WebPageTest and examine the waterfall.
- Schroedingersat 4y ago
  > Base64 will make the fonts about 30% bigger, and webfonts are already too big Does this actually change the transmitted size significantly?
  - theandrewbailey 4y ago
    After gzip or brotli, the increased size of base64 is negligible. That 100k CSS is less than 70k compressed.
  - SquareWheel 4y ago
    woff2 is already a highly-compressed format so you shouldn't expect much in terms of savings. Maybe gzip could offset some of the fat added by base64 though. 100KB for a font is a lot of data on a website. I'm using a custom subsetted version of Source Sans Pro at just 6.7KB.

kevincox 4y ago

In my opinion very few if any sites need fonts. The user has a default font, who am I to say that I know a better one? If you want to be more pragmatic you can accept that most browsers use awful fonts by default. However coming soon is system-ui, ui-serif and ui-sans-serif which allow you to let the user to continue picking the font, expect not awful. (I still don't understand why browser didn't just update initial, serif and sans-serif to be non-awful, but I'm not a browser maker)

SquareWheel 4y ago

> The 3 that my blog[0] uses are base64 URLs in my single 100k CSS file. This is not an efficient approach. Base64 will make the fonts about 30% bigger, and webfonts are already too big. The fact that it's in CSS also means that it's now render blocking, and font-display can't be used. You're likely delaying your render time versus standard font loading. Do a comparison in WebPageTest and examine the waterfall.

Schroedingersat 4y ago
> Base64 will make the fonts about 30% bigger, and webfonts are already too big Does this actually change the transmitted size significantly?
- theandrewbailey 4y ago
  After gzip or brotli, the increased size of base64 is negligible. That 100k CSS is less than 70k compressed.
- SquareWheel 4y ago
  woff2 is already a highly-compressed format so you shouldn't expect much in terms of savings. Maybe gzip could offset some of the fat added by base64 though. 100KB for a font is a lot of data on a website. I'm using a custom subsetted version of Source Sans Pro at just 6.7KB.