We’re basically forced to switch to self hosting due to the bizarre way Google implements statistics for Google Fonts. 1 out of 1000 requests will include a “tracking font” which is actually invalid and breaks document.fonts.load. This was an incredibly frustrating bug to track down.
Thanks for sharing! Also `fonts.gstatic.com` is a CNAME alias for `gstaticadssl.l.google.com` which is commonly blocked by ad blockers. uBlock Origin recently added CNAME based blocking, and PiHole is rolling out support for it too. Just another reason to host it yourself.
The guy who is affiliated with Google Fonts who showed up on a thread a few days ago said that he didn't think there was any tracking related to new implementations of Google Fonts stuff.
I guess this says the opposite. Let me try to dig up the thread for completeness...
I could add another point: A software should be self-sufficient (at least to a degree). When user opens the page, the page should not require an external service to function.
Imagine a user who can access your page but cannot access Google, the user then has to wait a long time looking at a blank page before the web browser stopped trying, that is some really really bad experience.
And your users won't blame Google for been too slow, they will just simply close your page, and try another search result instead.
I usually just download and self-host for this reason. A software should never rely or be dependent to content delivery networks/repositories like Google Fonts. There's nothing wrong with Google Fonts as a service and repository (tracking stuff aside), but I've never felt comfortable at the idea that we just link, lets say, jQuery or Angular through CDN and call it a day.
I should add that most of my work is through intranet applications with servers only accessed through VPN and I've seen the firewall disrupt Microsoft services one too many times so... it's more of a "yea, it's just a save-as or copy file to my app assets folder" versus users sending me emails that the pages stopped working.
> Imagine a user who can access your page but cannot access Google, the user then has to wait a long time looking at a blank page before the web browser stopped trying, that is some really really bad experience.
Not quite how web fonts work, usually they just swap in for the system fonts once loaded.
Very important point. A major Austrian newspaper's web site currently doesn't work for me because I block FB's SDK. My choice in this case, but as a user I'm also at risk when FB can choose to block my browser and disable some (badly designed) web pages in the process.
On the other hand, self-hosting everything doesn't let you take advantage of caching.
What I mean is, if two sites use the same resource, and if both sites fetch the resource from the same URL, the resource will likely be cached by the browser once and reused again and again. This can be huge for load times when users visit a website for the very first time.
Or at least, this was the argument that was floating around in the community, when I used to do web dev. It's been a few years since, and I'd be interested to see if people have other arguments for/against this.
The odds of google being down / slow instead of your site are pretty bad.
Unless you build your own data center, pull in all the fiber yourself, make the network switches yourself, build the servers yourself, etc... you are always going to be dependent on a third party or external service.
One thing I see is that it by default includes specific support for IE6-IE9, IOS before v5, android before v4.4 which definitely should not be the default these days. It should be an option, but not the default.
If you have a worldwide CDN yourself, or you only care about local users, or your fonts are small (Latin subset), yes.
If you're using CJK fonts and you don't already have a CDN for your stuff, no. Google Fonts' CDN is going to beat your own server from any other continent.
If you're using the C in CJK, then there's a good chance absolutely anything will beat Google Fonts since approximately 99% of your users have Google permanently blocked.
I read this question more generally as I have just revisited it myself in the past week.
For me this isn't just a question about Google Fonts. It's a question about jQuery and React and any common js lib off a CDN. And it's even a question about DLLs. glibc, zlib, .net. If it doesn't ship as part of your product, but your product can't work without it...
There's the problem of malicious replacement. There's the problem of disappearance. And various other problems.
On the other hand, there are all the positives. One upgrade at one URL and tons of dependent software gets a free security fix or performance fix or what have you. There's better caching. There's the speed benefit of CDNs. There's the lower memory consumption of DLLs.
This time around I have decided to self-host. But I don't think there's one right answer.
Looking at this, as an old fart who works in the kernel, I just can't help but wonder:
How is it possible that we have arrived at something this painfully slow? What are we getting from all these zillion resources a page is loading to make it worth the 3-6 second wait?
The static web of the 90s over dialup was faster than this.
I want my 28800 modem, pentium pro running netscape on FreeBSD 2.x, and static pages back. It was faster (with images disabled at least) than today's web with a 1Gb/s symmetric fiber connection, FF/Chrome on a MBP, even with ads blocked.
While I take your point about bloated web pages, I think you have a serious case of nostalgia viewed through rose-tinted glasses.
I recall the days of a 14k modem, and they were not pleasant, even for just text. And when you added images to the mix, it was just painful. Let's not even discuss videos...
Those charts are using “3gslow” mode, simulating a ludicrously slow and lossy mobile connection. Also note that these fonts are loaded lazily and don’t have to block the page painting.
We ran into a rather large issue using Google Font CDN a few years ago. We were using Rubik font and pages were font was render as blank in certain browser combination.
They had to rollback, but there were a lot of escalations.
Safari does more than other browsers to prevent cross domain tracking. 3rd party cookies disabled by default, cookies in iframes considered 3rd party (so, blocked), and TIL it maintains a separate local cache for each domain to prevent fingerprinting a user across domains. I have a hunch you could probably drop 3rd party cookies using a <video> element (maybe for DRM stuff? Just a hunch I have because video-ad CPMs are consistent or better on iOS over android/desktop indicating perhaps advertisers know the user somehow). Awesome article, great reference links, super interesting!
Long prose does not benefit from those fonts. A system font is usually used for UIs and is optimized accordingly. There's more to font selection than "use the same font as native applications".
Personally I block all third party fonts and have never noticed an issue with a plain old font. The web is so much nicer with a very restricted font set and range of sizes.
As is pointed out in the article for the most part fonts are a form of progressive enhancement and lacking the font normally doesn't actually break a website. Unless a little less pretty == broken of course.
I love how this guy thinks. "Why does this font flash on pageload?" and then procedes a 5-page write up on the intricacies of fonts, caches and everything in between. Great write-up!
Free fonts aren't sufficiently better than the default system fonts to justify the slowdown. More people will leave your site because of the added microsecond latency than because "the font doesn't look good." You shouldn't use Google Fonts period.
A while ago I routed Google Fonts to ::/0.0.0.0 in my /etc/hosts file. It makes pages load a little faster, and shows me which websites thought to provide a sensible fallback and which did not.
So the only thing that self-hosting would be missing is all the magic that Google is doing server-side to optimize the served files for the particular browser that is making the request.
Things like encoding (WOFF vs WOFF2) and font hinting need to be dynamically enabled/disabled based on the browser making the request to get the best possible result.
You can’t do that with self-hosting without writing some code.... that would be a great open source plugin to have, so that self-hosting could be done without any quality compromises.
Getting the right asset served to every browser was the reason I punted on self-hosting fonts last time I tried.
For example, I care much more about the page looking correct (legible crisp rendering fonts) than shaving 10Kb off the page size. Nothing is worse than the wrong font package causing blurry letters on 20% of your users’ devices.
So, to counter the point that "fonts only make the web look pretty," consider that font choice has a major impact on how accessible your website is.
For example, most people don't consider that the W and the M in your font must look distinctly different, and not just vertical mirrors of each other. That is a user inclusion choice, not just a "make it look pretty" or "make it on-brand" choice.
If you use npm, there are packages for most (if not all?) google fonts via the Typefaces project, which makes them trivial to self host.
https://github.com/KyleAMathews/typefaces
Honestly though, this is absolutely ridiculous that you have to do something this complex to fix something so simple. Why doesn't Cloudflare just build this in and let users toggle it on and off under their performance tab?
[+] [-] tolmasky|6 years ago|reply
Bug for those interested: https://github.com/google/fonts/issues/2345
[+] [-] lightswitch05|6 years ago|reply
[+] [-] arthurcolle|6 years ago|reply
I guess this says the opposite. Let me try to dig up the thread for completeness...
EDIT: Well that was faster than I thought I'd be able to do. Here's the comment, and the thread: https://news.ycombinator.com/item?id=22369415
[+] [-] alwillis|6 years ago|reply
[+] [-] tjoff|6 years ago|reply
And another potential cost of relying on someone elses servers.
[+] [-] chiefalchemist|6 years ago|reply
I'm ask because, I wonder if Google adjusts that depending on the site? The traffic?? And/or what it thinks it need to know?
[+] [-] nirui|6 years ago|reply
Imagine a user who can access your page but cannot access Google, the user then has to wait a long time looking at a blank page before the web browser stopped trying, that is some really really bad experience.
And your users won't blame Google for been too slow, they will just simply close your page, and try another search result instead.
[+] [-] allenskd|6 years ago|reply
I should add that most of my work is through intranet applications with servers only accessed through VPN and I've seen the firewall disrupt Microsoft services one too many times so... it's more of a "yea, it's just a save-as or copy file to my app assets folder" versus users sending me emails that the pages stopped working.
[+] [-] yathern|6 years ago|reply
Not quite how web fonts work, usually they just swap in for the system fonts once loaded.
[+] [-] lazyjones|6 years ago|reply
[+] [-] butterthebuddha|6 years ago|reply
What I mean is, if two sites use the same resource, and if both sites fetch the resource from the same URL, the resource will likely be cached by the browser once and reused again and again. This can be huge for load times when users visit a website for the very first time.
Or at least, this was the argument that was floating around in the community, when I used to do web dev. It's been a few years since, and I'd be interested to see if people have other arguments for/against this.
[+] [-] spookthesunset|6 years ago|reply
Unless you build your own data center, pull in all the fiber yourself, make the network switches yourself, build the servers yourself, etc... you are always going to be dependent on a third party or external service.
[+] [-] rgbrenner|6 years ago|reply
https://google-webfonts-helper.herokuapp.com/fonts
[+] [-] h2odragon|6 years ago|reply
[+] [-] SahAssar|6 years ago|reply
[+] [-] owenshen24|6 years ago|reply
[+] [-] marcan_42|6 years ago|reply
If you're using CJK fonts and you don't already have a CDN for your stuff, no. Google Fonts' CDN is going to beat your own server from any other continent.
[+] [-] alwillis|6 years ago|reply
For example, here’s Lato: https://www.jsdelivr.com/package/npm/lato-font
[+] [-] nsomaru|6 years ago|reply
[+] [-] fiblye|6 years ago|reply
[+] [-] supportlocal4h|6 years ago|reply
For me this isn't just a question about Google Fonts. It's a question about jQuery and React and any common js lib off a CDN. And it's even a question about DLLs. glibc, zlib, .net. If it doesn't ship as part of your product, but your product can't work without it...
There's the problem of malicious replacement. There's the problem of disappearance. And various other problems.
On the other hand, there are all the positives. One upgrade at one URL and tons of dependent software gets a free security fix or performance fix or what have you. There's better caching. There's the speed benefit of CDNs. There's the lower memory consumption of DLLs.
This time around I have decided to self-host. But I don't think there's one right answer.
[+] [-] jeltz|6 years ago|reply
[+] [-] drewg123|6 years ago|reply
How is it possible that we have arrived at something this painfully slow? What are we getting from all these zillion resources a page is loading to make it worth the 3-6 second wait?
The static web of the 90s over dialup was faster than this.
I want my 28800 modem, pentium pro running netscape on FreeBSD 2.x, and static pages back. It was faster (with images disabled at least) than today's web with a 1Gb/s symmetric fiber connection, FF/Chrome on a MBP, even with ads blocked.
[+] [-] GordonS|6 years ago|reply
I recall the days of a 14k modem, and they were not pleasant, even for just text. And when you added images to the mix, it was just painful. Let's not even discuss videos...
[+] [-] thedance|6 years ago|reply
[+] [-] rawoke083600|6 years ago|reply
[+] [-] pcurve|6 years ago|reply
They had to rollback, but there were a lot of escalations.
You can see the issue here. https://github.com/google/fonts/issues/1137
Self-hosting fixed the problem. We no longer use Google Font CDN.
[+] [-] potench|6 years ago|reply
[+] [-] abiro|6 years ago|reply
https://www.smashingmagazine.com/2015/11/using-system-ui-fon...
This solves both privacy and performance problems and this is also what Bootstrap recommends now:
https://getbootstrap.com/docs/4.0/content/typography/
[+] [-] beefhash|6 years ago|reply
[+] [-] triangleman|6 years ago|reply
Not saying that you shouldn't use native fonts but man Dell threw a wrench into that idea for me.
[+] [-] vinniejames|6 years ago|reply
At the very minimum, always check the integrity hash of third party assets
[+] [-] bcrosby95|6 years ago|reply
[+] [-] paulie_a|6 years ago|reply
[+] [-] Yeroc|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] 101404|6 years ago|reply
[+] [-] lbj|6 years ago|reply
[+] [-] zelly|6 years ago|reply
https://practicaltypography.com/font-basics.html#why-use-pro...
[+] [-] TazeTSchnitzel|6 years ago|reply
[+] [-] zaroth|6 years ago|reply
Things like encoding (WOFF vs WOFF2) and font hinting need to be dynamically enabled/disabled based on the browser making the request to get the best possible result.
You can’t do that with self-hosting without writing some code.... that would be a great open source plugin to have, so that self-hosting could be done without any quality compromises.
Getting the right asset served to every browser was the reason I punted on self-hosting fonts last time I tried.
For example, I care much more about the page looking correct (legible crisp rendering fonts) than shaving 10Kb off the page size. Nothing is worse than the wrong font package causing blurry letters on 20% of your users’ devices.
[+] [-] bovermyer|6 years ago|reply
For example, most people don't consider that the W and the M in your font must look distinctly different, and not just vertical mirrors of each other. That is a user inclusion choice, not just a "make it look pretty" or "make it on-brand" choice.
[+] [-] web007|6 years ago|reply
https://github.com/JulietaUla/Montserrat/issues/60#issuecomm...
[+] [-] 33degrees|6 years ago|reply
[+] [-] tuananh|6 years ago|reply
[+] [-] partiallypro|6 years ago|reply