DEV Community

tq-bit
tq-bit

Posted on

How to self-host Google fonts for your web application | Part 1/2: DIY vs. CDN

Google provides plenty of web services, one of which is Google Fonts. At the same time, using these services is as simple as opening a window (or browser tab, literally speaking). You might have a good reason though not to use these, and instead, provide font files from your own sources.

Motivation: Selfhosting vs. using a CDN

The following section deals with some concerns regarding the GDPR regulations for European users. I would like to emphasize that this is no legal advice and that you should contact a lawyer before using any of these practices.

Google fonts and convenience

Before you start hosting fonts yourself, you should consider if it adds value to your product. Google's CDNs do some real heavy lifting for you. Not only do they provide you just the styles you need, but also apply some smart response settings:

  • Cache headers on the client-side
  • Predefined @font-face rules & preloading
  • Browser specific- & compatible fonts

When loading fonts from a CDN, Google's servers take care of applying client-side caching.

To achieve comparable results on your own machine, you must customize it on your webserver. You can read on how to do it in the second part of the series.

Google fonts and privacy (brace yourself)

With this convenience comes some bitter taint. According to Google's Terms of Usage for their APIs:  (Section 3, Your API Clients, called on 08.09.2021), Google actively monitors access to their services, including the Fonts API.

The APIs are designed to help you enhance your websites and applications ("API Client(s)"). YOU AGREE THAT GOOGLE MAY MONITOR USE OF THE APIS TO ENSURE QUALITY, IMPROVE GOOGLE PRODUCTS AND SERVICES, AND VERIFY YOUR COMPLIANCE WITH THE TERMS.

Also, according to their FAQ (called on 08.09.2021), the statement on what data are collected seems rather fishy:

Q: What does using the Google Fonts API mean for the privacy of my users?

A: The Google Fonts API is designed to limit the collection, storage, and use of end-user data to what is needed to serve fonts efficiently. [...] Aggregate usage numbers track how popular font families are, and are published on our analytics page. We use data from Google’s web crawler to detect which websites use Google fonts. This data is published and accessible in the Google Fonts BigQuery database.

In plain English, this means something like (this is no legal advice, just my subjective interpretation):

  • You, as a website dev/admin, agree that Google monitors your user's activity whenever one or more font files are requested from their CDN
  • Also, Google does collect something, but they don't really tell you what

At a bare minimum, based on what they present on their analytics site, they're receiving:

  • The user's operating system
  • The user's browser
  • The requested font(s)

an image that shows the analytics site of google fonts

It is also a very common practice to survey access - log files. Assuming that is the (very likely) case, then Google also receives:

  • The user's the IP address
  • A timestamp of when a font has been requested

And this is where it gets legally complicated. A judgment of the European court in 2016 has interpreted IP addresses as personal data as per the following decree:

Article 2(a) of Directive 95/46/EC of the European Parliament [...] must be interpreted as meaning that a dynamic IP address registered by an online media services provider [...] makes accessible to the public constitutes personal data [...] which enable it to identify the data subject with additional data which the internet service provider has about that person.

If you're wondering: 'Why is this a problem?':

48) Thus, it appears that the online media services provider has the means which may likely reasonably be used in order to identify the data subject, with the assistance of other persons, namely the competent authority and the internet service provider, on the basis of the IP addresses stored.

Again, let me try to rephrase (and again, this is no legal advice):

  • If Google receives your user's IP address over the fonts API, they're collecting personal data. Thereby, Google becomes your user's data processor
  • Also, Google (most certainly) has the means to identify your user based on their IP address and thereby can perform profiling
  • As a consequence, you need your user's consent when it comes to data processing
  • According to law, if a user does not agree to make their personal information (IP address) available to Google, you are responsible to prevent the fonts from loading

The resume out of this for me was:

  • You have to ask your user for consent (in the EU) and take appropriate action if consent is withdrawn (that is perfectly okay if you already have such a system in place)
  • You save yourself a lot of headaches by just going with the self-hosting approach

Google fonts and performance (in terms of UX)

It might seem obvious that in terms of speed, almost nobody beats the big G. They have data centers all around the world that deliver fonts blazingly fast.

So in the case of self-hosting, we must make sure that during the time fonts are loaded, the user is still able to see something more than a blank page. This will be rewarded not only by happy readers but also by Lighthouse Scoring.

Using the online approach has us covered. By declaring display=swap, fonts will not block, but rather be switched out once the target font family is available.

<link href="https://fonts.googleapis.com/css2?family=Open+Sans&display=swap" rel="stylesheet">
Enter fullscreen mode Exit fullscreen mode

While fonts load, by default, a browser will block other content from getting rendered. According to MDN: font-display: swap gives the font face an extremely small block period and an infinite swap period.

Fortunately, this behavior can easily be replicated, and even extended, by preloading the necessary fonts.

<link rel="preload" as="font" href="https://fonts.googleapis.com/css2?family=Open+Sans&display=swap" onload="this.onload=null;this.rel='stylesheet'">
Enter fullscreen mode Exit fullscreen mode

Who wins?

Even though the CDN way is convenient and fairly easy to implement, my winner in this race is the self-hosting approach. Had I a system in place which does the legal consent gathering for me, I'd also vouch for the former. It just seems hardly reasonable to go through such a legal gauntlet for a blogging website.

If you would like to host your own Google Fonts, read ahead for the second part of this series: Download and provision.

This post was originally published at https://blog.q-bit.me/how-to-self-host-google-fonts-part-one/
Thank you for reading. If you enjoyed this article, let's stay in touch on Twitter 🐤 @qbitme

Discussion (2)

Collapse
organizedfellow profile image
Jaime Aleman

Absolutely brilliant!

We need better writers like you tw-bit, we really do!
You explain and document very well in your post and you provide links to other material. I wish you were getting more traffic and comments here.

You are doing very well my friend, good luck and I will continue to follow your posts.

Collapse
tqbit profile image
tq-bit Author

Hey Jaime, much obliged for the warm words.

Getting traffic is more about SEO in the end, which this post does not really fit. I'm writing for the enjoyment and always appreciate feedback like yours.