Web fonts are nothing new. Even third-party fonts you can load from a content delivery network (CDN) are not so new anymore.
I once swore off everything but built-in system fonts. Well, I’ve back pedaled more than once. I’m using a bit of logic now. You need to think about what I’m going to tell you. I hope I’m not as dumb as you might think I am after you do.
Way back when, web typography was severely limited. The @font-face CSS specification eventually gave us the ability to load web fonts from remote sources. Google Fonts is probably the most popular source today.
A modern system font stack works extremely well, but it can’t account for every operating system variation. Like Linux Mint based on Ubuntu. The default font for each is different, even though Linux Mint wouldn’t exist without Ubuntu.
And then there are web font icon sets like Font Awesome. Dave Gandy “invented” the first Font Awesome icon set for use with Twitter in 2012. Basically, it uses extra available memory addresses not used by fonts. The icons are also font characters.
I swore off web fonts and font icons for a while and then brought them back using lines like these:
<link href="https://fonts.googleapis.com/css?family=Open+Sans:400,400i,700,700i" rel="stylesheet"> <link href="https://maxcdn.bootstrapcdn.com/font-awesome/4.7.0/css/font-awesome.min.css" rel="stylesheet">
I didn’t have a choice with the Google AMP project. It was the only way I could use them. I kept those lines until recently, intending to change things after switching to a semi-static WordPress site.
It took me longer than I anticipated but I finally did it. I stopped retrieving them from any CDN. I downloaded Font Awesome Version 4.7.0. Yes, there are more recent versions but I don’t need them. I downloaded Google’s Open Sans font using the google-webfonts-helper service.
The two CDN lines are now replaced by these:
<link href="https://www.rtcx.net/assets/css/open-sans-v15-latin.min.css" rel="stylesheet"> <link href="https://www.rtcx.net/assets/css/font-awesome-v4.7.min.css" rel="stylesheet">
You’re more than welcome to load each of these in your web browser for inspection (after you copy and then unminify them).
People, professionals and amateurs alike, always recommend using one CDN or another to serve static files. They assume the static files will load faster from some point closer to your web visitor. What if the CDN promptly serves the static files but the web page itself fails to completely load? It’s pointless to serve the static files without the full page.
I’m not convinced the few seconds potentially saved by a CDN are worth the cost. Not only that, I don’t like the idea that a CDN failure (which has actually happened) can cause even one lost visitor. And then there’s latency caused by any number of things. I figure my visitors should get as much as possible from the same source, mine. The loading speeds of the various components will probably be more consistent.
Good web hosting providers offer more than enough bandwidth. A CDN used to help offset costs but that isn’t necessary for most people these days.