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.
And this is probably a good reason why they do it this way, they would be stupid not to. Not that I'm happy we end up with this, but business wise it makes way too much sense.
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 don’t think there’s super meaningful data to be gleaned from server-side tracking, especially with browsers increasingly sending little to no information to third party resources. This is CSS, not a JS script that might collect more info and phone home. So yeah, the site going blank is higher priority to me than them knowing if I, the service provider, not my users, prefer Roboto over Open Sans, or if most users now support woff2 vs. ttf. But either way, we’re not going to use them anymore.
CSS can be crafted to conditionally load additional resources, which means it can be a vector for fairly sophisticated information gathering and tracking. For example: https://github.com/kkuchta/css-only-chat
Incidentally, not that it helps you if you're concerned about your users' privacy, you can use a lot of these third party resources pretty securely with a single Firefox setting:
network.http.referer.XOriginPolicy = 2
This tells Firefox to only send the referer header to sites on the same origin. This seems to break very few sites, but means there's no way Google could track me through web fonts even if they wanted to, since they don't know what site I've requested the font from.
That said, I think it's pretty plausible (as another user noted) that Google is only keeping general metrics here, not tracking anyone. 1/1000 requests is not very useful data, even if it provided them something on top of the Referer, which they already have.
That helps in some cases, but google would still know what font was requested and when. So if a certain site uses Noto Sans and Montserrat that narrows down which site you visited to ones that use those two. Considering google regularly crawls the whole web it definitely knows which sites match those two. That would be a pretty big group of sites, but the more sites that use the features that google fonts touts as performance gains like subsetting and the display parameter the more tracking bits google gains. The more fonts and options sites use the more unique the request signature becomes.
Basically if you don't want to be tracked the only good way is to not request anything from the tracking companies. As soon as your browser connects to them they have gained something. Use uMatrix to block all third parties by default, and only whitelist what is absolutely critical for the site to work.
There's a difference between user activity tracking (the context of the discussion you linked) and generic metric gathering, which is clearly a thing given that the post was a link to the public fonts analytics page.
(I work at Google, I know nothing specific about fonts)
I agree, but it's a problem because a big part of googles business relies on the former, so I can't trust them when they say that one of their products only does the latter.
I thought that was pretty clear in my previous comment, what part was unclear?
> A growing part of Google's business relies on b2b transactions. Are you also concerned that you're going to suddenly have to subscribe to search?
No, because search is profitable and already explicitly data-milked for most of it's worth. I'm concerned about the data collected in unprofitable services just because they are not profitable and claim to not have every iota of data extracted from them.
So I'm concerned that Google Fonts, ajax.googleapis.com and so on will start to be milked for data just like search is.
Why are you so confident that these services are unprofitable?
You're already assuming the main profit source would be second order effects (analytics value add). Why not go further and assume that there already are second order effects that make fonts profitable.
For example, more internet users means more profit for Google, and accessible cross language fonts lead to more web users.
Totally understand and agree that there is a difference: I just half-remembered an at-least tangentially related post and wanted to call it out in case others didn't catch it in the last couple days.
I think some actually conflate the generic vs. user-specific metrics collection quite frequently in arguments that I see on this site and I agree that it's definitely not the same but I still felt it was worth the call-out.
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.
Eliminating weaknesses to provide services that are faster and more robust is exactly why CDNs exist. Whether or not you find them necessary is up to you. Personally a world with content closer to my machine with more robust servers that can handle high traffic is better than the alternative.
You can get the best of both worlds by self-hosting and putting a CDN in front of that. This way you get robustness and your app will still function in isolation
I'd add that the nature and value of the internet itself is in having interconnectedness. Perhaps, not initially for a site's infrastructure, but only because no one saw that far ahead. None the less, the ideal was there.
If there's that much fear in connecting elsewhere then we've done something wrong. Of course, there are exceptions. There always are. But the arc of the internet is the natural ability to connect.
p.s. Using a CDN ideally saves the browser time. If I've already visited a site that used the same version of jQuery from the same CND then that's in the browser cache.
Sure. Maybe we need to refine this. I'm not sure. But let's not make connecting and sharing sound like a bad idea.
You have to accept that a server may fail to be accessible, whether it's yours or Amazon's. If this is an issue you add redundancy.
When you load lots of resources from God knows where in a way such that any single failure takes the page down, you are reducing the reliability that you could have had if the resources were all in the same place which you concentrate on keeping available.
If your site runs on AWS, it should run on AWS, not on AWS + Google Fonts + React CDN + Github + ...
But actually, there's nothing wrong with adding dependencies, granted that you correctly do your risk assessment. Are those developers assessing their risks and making an informed decision to add them?
I agree on that, I just don't see fonts as critical for your site, provided that you have a fallback. But I see how hosting the fonts is pretty easy to do and you avoid one point of failure for the user experience.
I'm really starting to doubt whether it's competitive to do your own thing anymore. And this seems to be getting worse.
Hard to compete with the combo of features & scaling that cloud provides. Attempting it pretty much guarantees you a gnarly trade-off somewhere (reliability, complexity etc).
> 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.
Yes, a well-designed system can minimize the impact by for example lazy-load the font file or even `Font Face Observer`[0] them for manual hot swap.
But that is not the main point. The main point is: You are the one who's in charge of the user experience, not Google. Don't shift the responsibility to somebody (external service) you don't have control of.
The software works the best when all it's parts are predicable, and make it more self-sufficient can help.
Google’s own pages don’t do that, they intentionally hide the text until the font loads to prevent a “flash of unstylised content.” (It’s quite a bit longer than a flash on many connections, plenty long enough to start reading.)
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.
These are good points, but there are a few things to consider. First, as the article points out, self-hosting may result in a faster experience for your users due to the slowness of Google's font delivery. Secondly, your site is likely already serving up other assets which are not nearly as large as the fonts themselves (CSS, logos, other images, JavaScript, etc), so the savings is really not that large in comparison. Third, you can make use of cache-control headers that will ensure that all of these assets don't expire on the client's side for as long as you'd prefer.
One of the benefits of a CDN is the "N" part. If you host on a single server and you start getting requests from across the globe, those users will have a slightly more fluid experience if they can download the assets from a server that's physically closer to them than if they have to wait for packets to hop across dozens of nodes.
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.
The issue isn’t Google being down, it is my ISP’s connection to Google that might be subpar.
They might have a direct peering which is down and unexpected traffic is flowing though transit, you got BGP flaps, you got local CDN outages... and in the eyes of the customer your website is down, not Google CDN.
This might not be end of the world. In a lot of cases convenience is worth the risks. There is no golden rule that one should never depend on third parties. It is always balancing pros vs cons.
Self hosting introduces extra code, resources and assets that you as a developer must introduce and maintain. This is not free.
Especially if worst thing that happens is a wrong font loaded.
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.
CJK fonts can be megabytes. The rest of an otherwise lean site can be a few hundred kilobytes or less.
E.g. my site's About page is tiny, but pulls in a CJK font (with delayed load) for one line of text. It would make no sense to self-host that: https://marcan.st/about/
A self-hosted font containing just those few characters would be tiny, and nicer to your visitors than forcing a mostly useless megabyte download on them. Makes a lot of sense.
K does not belong together with C and J in this case. If you are subsetting fonts to include the actually-used glyphs, the font file size for a typical Korean-language site will be considerably smaller than for a typical Chinese-language or Japanese-language site. That is, the active set of glyphs for Korean is much smaller even if the fonts you’d start the subsetting process from were about as large.
Self-hosting a Japanese font for one line of text is completely doable. I self-host all fonts for my site, which has a handful of CJK characters (across 4 fonts: Korean, Japanese, Traditional Chinese, and Simplified Chinese).
does it really make sense to load a large font for a single line of text on the page regardless if it is self-hosted or not? that must be one important line of text.
If you use a custom/download able font at all, it would make sense to use one copy (URL) - so every visitor only has to download it once - then use it from cache. This probably also the best reason to use a central CDN over your own - likely some other site already warmed up the client cache for you, with popular fonts (the ultimate in pre-warmed font cache, is of course the fonts the browser/os already have installed - unfortunately the lowest common denominator is a problem here, between Android, ios, os x, windows, Linux).
I'm not sure if Google font service actually does facilitate cross-site caching though - there might be tailored URLs or account?
Lol, his about page pulls a 1.42 MB font to display eleven characters in a light font weight instead of my system font. On a page that would otherwise be ~30 KB.
Fwiw I don't really think a one-time large font download is much of a problem - considering that improved typography is a very good way to improve how a site looks. And unlike your png - the text will display without the custom font. Fall-back fonts are only really a problem with icon font sets.
Png has poor screen reader support, though it can be amended via an alt tag, I suppose. [ed: but breaks copy and paste, which might be bad for an about page listing address and contact information - personally I'd much prefer fallback font to a png].
It's a shame there are no "bandwidth" queries in css, like there are @media queries - the client should be able to say - just content and essential downloads, please.
You can already do this with JavaScript now: https://developer.mozilla.org/en-US/docs/Web/API/NetworkInfo... though as you can see from the bottom of that link, Browser support is limited at the moment (and experimental so may even be removed/changed!).
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...
He took it too far, granted, but overall there's a valid point. By coincidence, I'm writing an applicant tracking tool in rails+react now, and I also wrote one in perl about 16 years ago.
The modern app uses so many javascript libraries, 3rd party fonts, and is generally just so... ouch.
I remember demoing the perl app internally at my first job, and in many cases our page could render the page about as fast as it took to click. Our boss thought it was a static html demo just based on how fast it was.
I've had similar experiences, except it used to be PHP for me back in the day, rather than perl - I recall a servicedesk system, as well as a purchase order approval system, amongst many others. Not a single line of JS in sight!
But some of us never abandoned server-side rendering - I work a lot with ASP.NET Core MVC, and it's great; I'm very productive with it. But I do add Javascript on top here and there, where it adds value.
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.
> Those charts are using “3gslow” mode, simulating a ludicrously slow and lossy mobile connection.
"3gslow" mode, unfortunately, accurately reflects the day-to-day connectivity most people see in non-capital cities around my country. It might be ludicrous, but it isn't necessarily far from the norm.
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".
I'm not quite sure what about e.g. Roboto or SF Pro Text isn't suited to long prose, or if you think OSes ship with just the font used for system UI (and not also dozens of others several of which were pretty much designed for longform text).
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.
Only thing I've noticed breaking badly are symbol fonts that try to be clever with ligatures, so that e.g. "arrow_right" gets turned into an arrow symbol. Happens a bunch on Google documentation sites.
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.
That post doesn't come across as anything but pure elitism, it makes no real point and just claims "yeah system and free fonts are just worse".
Fonts like Roboto, Fira, Open Sans, Ubuntu, Merriweather or Vollkorn are all "professional grade" font families with lots of variants and options. Basic typesetting knowledge is going to get you much much further than buying a random professional font if you're designing "a document".
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.
Some time ago I disabled all webfonts (ublock or umatrix) because
I really don't care about stupid individual fonts and I thought I
could save some bytes. Unfortunately that broke a lot of
video-players (like netflix) because they use font-symbols for
play/pause buttons etc.
Mm, to me that feels like an abuse of fonts — it's inaccessible at least. It makes me sad that they don't bother using the Unicode codepoints corresponding to those symbols if they exist.
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.
...rule one of accessibility is let the user configure how they access your content, and you just chose to override that. So that's a pretty weak excuse.
> 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.
Why isn't relying on default fonts provided by the user's system good enough for that?
I don't know what specific problem the parent is pointing to, but generally, users don't set up defaults, so you're really using the defaults of the vendor of whatever system the user uses. That may or may not be useful.
Tool customization may be where the users and power users are separated - but it's hard to tell who is who when you're just looking at an HTTP request.
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?
IMO: don’t force your users to load fonts. On slow connections they’ll read part of the page until suddenly the font loads and everything gets rearranged. Worse is what google does: hide the text with JavaScript until the font loads so the whole page takes eons before you can read it.
If there’s a font with identical metrics that most people have installed then fine, otherwise don’t be a dick to people on bad connections.
Besides performance and other completely technical reasons, in my view it is mostly a question how dependent an individual or a company wants to be.
Of course it can be technically and operationally convenient but it also means that now you are even more dependent on the fickle choices that Google makes that is per definition in their own interests.
Surprised I didn't see that point mentioned: If you self-host Fonts ("Google Fonts" is ultimately just a collection of open source fonts) it's one less thing to care about regarding privacy laws, sharing data with third parties and potentially having to justify due to GDPR etc.
From the post:
“That leads nicely into the privacy implications of using third-party CDNs. You have no idea what sort of tracking they are doing to your users by using them, rather than self-hosting. And recent legislation means a lot of sites have to explicitly list all the cookies used on the site, which gets more complicated when using a third-party.“
Probably better to split your font, and put your critical glyphs somewhere fast. Plus localStorage limits are very low, a couple decent sized fonts will blow your budget.
You can. Another thing you can do is setup a service worker and intercept requests to Google Fonts, responding with an entry from cache or indexeddb instead.
localStorage at least historically is painfully synchronous and in some cases it has to be fully loaded from disk before the page's JS can run. So if you're sure you're going to be using the font on every page I guess you can eat that load penalty, but then you have to deal with the size limit for localStorage (~2mb worst case, iirc), and also go to the trouble of doing string encode/decode to get the raw font bytes, then shove the font bytes into a blob and get a url for the bytes so you can finally load the font.
At the end of that whole song and dance you've wasted a bunch of CPU and probably wall clock time being clever. Not sure it'd be faster than just hosting the files locally the regular way.
If you're in the EU you might want to self-host the fonts (and other assets!) anyway for GDPR compliance - technically, loading any 3rd party asset exposes the visitor's IP address plus any possible tracking cookie plus the exact URL of the website your visitor is reading to the provider.
Google might say they're not doing any tracking on the fonts, but I don't believe them at all.
At this point you have to self host assets, assuming their license allows that, if you want to comply with privacy regulation. If you don't have a signed legal contract with Google asserting they are not tracking your customers via embedded links, then you must assume they are doing so and you are out of legal compliance.
Bug for those interested: https://github.com/google/fonts/issues/2345