(no title)
Nooshu | 5 years ago
If you do use this method, I highly recommend testing both the standard loading method vs Base64 method on a low spec device (e.g. Moto G4 via WebPageTest) and seeing which performs best for your website.
This method used to be used on GOV.UK until we removed it 18 months ago. I wrote about the change here if you are interested: https://technology.blog.gov.uk/2018/10/04/making-gov-uk-page...
strenholme|5 years ago
I have had issues with a single font file sometimes hanging when trying to load it, so having them all in one file is also more stable; I plan on getting new hosting soon who will hopefully not have those kinds of issues. I also very aggressively cache the font file so it is only loaded once every six months for people who have been to my web page before.
It’s possible to avoid having base64 fonts block the loading of the page by putting the relevant <style>@import url('/fonts.css');</style> at the bottom of the page, at the expense of having a “flash” before the font is loaded.
I enjoyed reading the linked blog entry. One thing which stuck out is how you guys are able to interact directly with the type foundry to get them to make the web fonts smaller. I don’t have that luxury, but I do very aggressively subset my fonts, and I use zopfli with its most aggressive compression setting when making the WOFF fonts. I also use the Bitstream Charter font for italic and bold serif text, since that particular font is a very nice looking open source webfont with a very small size (download time) footprint. The main body text of Bitstream Charter is a little too thin (thin strokes) on Windows + Chrome (but it looks fine in IE, older Edge, and Firefox) especially on low DPI displays, so I use its (using more space and longer load time, alas) sister Charis SIL, a Bitstream Charter variant with thicker strokes, for the main body text.
One final thought: I think I still have an old Moto G3 with WiFi I can use to test things on that platform.