Should you self-host Google Fonts?
tunetheweb.com
tunetheweb.com
Bug for those interested: https://github.com/google/fonts/issues/2345
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
The font that gets loaded once every thousand requests is https://fonts.gstatic.com/stats/Roboto/normal/400 so it’s some form of statistics. But again, my actual concern is that it breaks.
Here’s the code I used to “catch” it. Here, it took roughly 500 requests: https://runkit.com/tolmasky/5e49b314ef61f900146c9a3b
Edit: To be clear, I’m not implying this is something they try to keep secret, just showing a way to observe it since it purposely rarely shows up.
Or bad content cached on one of these/cdn server.
(I work at Google, I know nothing specific about fonts)
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.
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?
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.
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.
network.http.referer.XOriginPolicy = 2
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.
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.
And another potential cost of relying on someone elses servers.
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?
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.
Not quite how web fonts work, usually they just swap in for the system fonts once loaded.
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.
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.
In the case of Fonts though, it's a good source of user and browser data, so it's not likely to be shut down any time soon.
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.
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.
If my site is down, they already can't access it. Using Google Fonts just adds an additional failure probability, however small it may be.
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.
Not sure that's viable in today's cloud-y world
Edit: Removed cache statement.
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).
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.
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?
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.
As per article that's no longer true. Thanks fingerprinting.
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.
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.
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.
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/
I'm not sure if Google font service actually does facilitate cross-site caching though - there might be tailored URLs or account?
If it truly is a must make it a small (self-hosted) png.
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.
One time. Per site. On slow and/or expensive mobile connection?
The png will also display without the custom font...
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!).
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).
For example, here’s Lato: https://www.jsdelivr.com/package/npm/lato-font
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.
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.
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...
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.
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.
"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.
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.
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:
Not saying that you shouldn't use native fonts but man Dell threw a wrench into that idea for me.
At the very minimum, always check the integrity hash of third party assets
https://practicaltypography.com/font-basics.html#why-use-pro...
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".
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.
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.
Why isn't relying on default fonts provided by the user's system good enough for that?
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.
https://github.com/JulietaUla/Montserrat/issues/60#issuecomm...
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.
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.
Can service workers intercept requests to other sites?
Yes, SW can cache all resources. This is how offline PWAs work.
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.
Google might say they're not doing any tracking on the fonts, but I don't believe them at all.
Step 2) realize that this computer shit is hard
Step 3) let google do it instead