Fast Google Fonts with Cloudflare Workers
blog.cloudflare.comCouldn't you just download the Google fonts and serve them up yourself and use a Cloudflare rule to cache it on the edge, instead of going through all this work?
Sure! But note that Google serves different font formats depending on your user-agent, so you'll have to make sure to cover all the different formats and do your own user-agent matching. And keep it updated as user-agent capabilities change over time. It's not quite as easy as it sounds.
You can specify multiple formats in the CSS. Just put them in order, and the browser will download the first one it supports.
And the css is going to be gzip'd anyway.. so we're talking a few extra bytes. Nothing that would make any difference in page load time.
There's no need for all of that extra work you listed. But I get why you want it to sound complicated, so people will use your work instead. Shouldn't you put a "I work at cloudflare" in there somewhere?
Google Fonts will serve a different .woff2 font file depending on the user-agent. You cannot accomplish that with just CSS. See https://news.ycombinator.com/item?id=8802748
the only difference is that on non-windows platforms google strips font hinting. That's just a (very minor) performance optimization done to reduce file sizes. Just download the windows version of the fonts (in all of the formats - woff, woff2, eof, etc).. the minor difference in size isnt worth the effort.
You can also just download the ttf files, and run them through a web font generator w/ proper support for hinting, etc... and then you'll have all of the formats you need.
If anyone wants to do this, I have used this tool in the past: https://google-webfonts-helper.herokuapp.com/fonts
And I wonder what speed tradeoff there will be for commonly cached/repeated fonts like Roboto, like maybe only makes since to inline less common fonts
AFAIK Google Fonts doesn’t allow browsers to cache the fonts for tracking purposes...
They do browser caching, but it's not as long as many would like for a static resource like a font. There is no proof they use Google Fonts for tracking, though, it's entirely possible they'll use it for that in the future...but I don't see a reason for them to do so. Google Analytics is already on most websites.
Maybe it's because I just skimmed the article, but what about the security implications of this? Doesn't dynamically loading third party ressources and serving them under your own domain open a whole can of worms?
Sure, but this is Google Fonts so if someone comprises that then they have access to many sites on the web.
I will say that this is probably overly complex and it would be easier to just download and serve the font files from your own domain instead. The CSS optimization isn't that necessary and is pretty much the same for all modern browsers.
It's a tricky issue. I think you mean privacy implications,I don't see how this would add security risk.
For privacy,loading third party fonts like google fonts on your site allows the 3rd party(google) to track users. To avoid that,I try to load google fonts from my domain(and for performance when google is slow or unreachable). Arguably,if your site already uses google fonts,putting cloudflare between google and users reduces the amount of tracking users are exposed to. One might also say how privacy conscious site owners should avoid both google and cloudflare.
To elaborate on how Google can track your users:
The user's browser downloads the font off of Google's server, which gives Google their IP address, and the browser also tells Google's server what webpage it's currently visiting, via the HTTP referer.
And given that almost every webpage ships something from Google, Google has an almost complete browsing history for every public IP. There's generally multiple devices behind one public IP, especially for corporate networks or VPNs, so they still have to demultiplex that with further tracking, e.g. Google Analytics, Chrome Sync, Android, but that's rarely a problem either, as even if you're carefully avoiding these, everyone else under your public IP using them would be enough to single you out.
You're forgetting user agent strings as well. On mobile,They tell google the exact device make and model and in case of in-app browsers the specific app and version.
Right, how did I forget about those? That even is exactly the type of data that will allow identifying specific devices underneath one public IP.
Is this allowed under Google's privacy policy? How about the GDPR?
I mean, it's one thing to talk about what Google's technically capable of, and quite another for it to be legal.
I don't know Google's privacy policy too well and I'm not a lawyer, but I think, this is still kind of uncharted legal territory.
No end user ever gets to see Google's privacy policy before their data is submitted to Google. Not even for Google Analytics, where I am pretty sure that Google does use the data, if the webpage owner isn't paying.
At the same time, Google will point to webpage owners, saying that they need to inform their users (which they do), but if Google wanted to "do the right thing", they would acknowledge that clearly webpage owners don't do that, and that therefore essentially any usage of Google Analytics data happens without user consent.
Under the GDPR, something like this would almost certainly not be legal and Google would be responsible, too, even if they're not the "controller", just the "processor", as the GDPR calls it.
Of course, we'll only know for sure once the lawsuits against Google have gone through.
It's not allowed under the GDPR. But let us get real; this is Google doing it, and anyone complaining about this practice would first need to prove that it happens (which is not easy). You can (and should) expect large American companies to always ignore as many laws as they can get away with.
That's a caricature. In my experience, Google has lots of lawyers that are quite serious about making sure what they do is at least arguably legal, and company procedures to make sure that employees follow the rules. Not that it always works.
Arguably legal thanks to FISA court orders that benefit Google and usgov? Where blame can be placed on "coercion" by US intel community?
> An alternative would be to keep accumulating data and only process it when there is no split link tag at the end, but this way we can return more data to the browser sooner.
> One thing I was initially worried about was having to modify the “content-length” response header from the original response since we are modifying the content. Luckily, the worker takes care of that automatically and it isn’t something you have to implement.
If the worker is able to do this for you it’s clearly waiting for all of the incoming data to be processed before it begins sending to the browser, so dealing with the incoming data as chunks is actually needlessly complex.
What about caching? The static font files have a really long cache age. You don't consider anywhere that the user might already have the font file.