Many websites use external Google fonts. The fonts are then loaded from a Google server. This article shows that integrating Google fonts in this way is problematic and actually impossible. The acceptable solution for most websites is simple.
Update October 2022
Recommendations for warnings received:
The most important thing: Remove all Google Fonts embeds first. Also, Google Maps and Google reCAPTCHA use Google Fonts. It's best to remove all Google tools at least temporarily. Instead of Google Maps, use my map plugin. Instead of Google reCAPTCHA, a textual math task with input field ( "How much is 17 minus three? Please write as a word.") often works.
Update from 26.08.2022
The following judgment of the LG Munich has meanwhile spilled over into Austria. It led to such great upheavals that even the Data Protection Authority of the Republic of Austria initiated an official examination procedure against Google due to Google Fonts (according to a notification dated 23.08.2022).
Update from 31.01.2022
Meanwhile there is a verdict of the LG Munich, according to which the embedding of Google Fonts was classified as unlawful. I had always seen it that way, as my following contribution shows. By this, a warning wave rolled in Germany.
Introduction
In contrast to some of my previous posts, e.g. Cookies, on the ePrivacy Directive or on Consent Tools, the following information is not earth-shattering. The combination of technical and legal consideration as well as the technical solution possibility are hopefully somewhat new. However, I had to notice already that even a self-proclaimed data protection officer intentionally uses external Google fonts. I assume she does this either because she hopes for SEO-effects (through the unlawful integration) or because she is not aware of the solution mentioned below.
Other writings, such as those from Google, are incidentally more clearly subject to consent requirements. For example Fast Fonts (fonts.com), because they use a tracking pixel for billing purposes.
Google Scripts are also referred to as Google Fonts. They stand out in that almost every font is supported and can be embedded into websites seemingly simply and without financial costs. If one embeds Google Fonts as Google suggests, connections to Google servers are established.
Here is a real example of such a data transfer caused by integrated Google fonts:
As can be seen in the network protocol, two different domains are called simultaneously, namely googleapis.com and gstatic.com, along with their respective subdomains.
This type of integration I call external Google Fonts, because they are loaded from Google servers. It looks different when the fonts are loaded from a server of one's own or from a provider with whom contractual guarantees have been made.
I have decided to also pack this post into category Bullshit Basics, because many are still trying to find all possible arguments as to why external Google Fonts should be allowed after all.
What about data protection?
The inclusion of external Google fonts violates Art. 5 Abs. 1 GDPR. There, the principle of data minimization is named. Against this stands a possibly legitimate interest that allows certain data processing. The legitimate interest is defined in Art. 6 GDPR. Whoever collects data must prove, according to Art. 5 Abs. 2 GDPR, that they comply with the principles of Art. 5 Abs. 1 GDPR (data minimization etc.).
The violation exists because it is easily possible to integrate Google fonts locally. All required font files are simply downloaded, adapted accordingly and then stored on your own web server. Local files can then be used on your own website. Data is no longer transferred to Google or other third parties.
Article 25 of the GDPR requires a data protection-friendly design of technology. ([1])
This shows that there is clearly no legitimate interest. Nobody will get away with this in court. If anyone claims otherwise, they either have no idea or are taking the wrong pills and are suffering from excessive hubris.
What about cookies?
Normally no cookies are processed when calling Google Fonts. I would like to note, however, that this can also be otherwise. It is enough if there is a single publicly accessible website worldwide in the domain of Google Fonts.
There are countless websites of this kind, as a search for websites with the primary domain googleapis.com proves:
From these numerous existing websites, some set cookies on a domain that concerns Google Fonts. If someone then loads one of these web pages and subsequently a German website that loads external Google fonts, this German website is thereby violating the ePrivacy Directive. At least the operator of the website would have to prove first that the opposite is the case. I hope for him that he then has the phone number of a very good contact at Google handy.
I myself know such websites that generate cookies, which then become relevant for Google Fonts. Accordingly, Google Fonts also require consent based on Article 5 Section 3 of the ePrivacy Directive in conjunction with the BGH ruling of 28.05.2020 – I ZR 7/16. In any case, the operator of the website must prove that Google does not use these cookies, which would be quite difficult and implausible. Finally, it is a matter of so-called Third-Party Cookies.
What about Google?
In my opinion, numerous Google tools are not data protection compliant in any case, without exception. Whether Google tools are loaded with or without consent is a different question. Here it's about transparent and concrete naming of mandatory information according to Art. 13 GDPR.
In addition, Google itself admits that it is able to skim data from your Google account when you are logged in there along with raised data when retrieving Google Fonts. In the data protection declaration, which applies to Google Fonts, it says:
We collect data […] such as […] the people you interact with most frequently online or the YouTube videos you find interesting. […] If you are logged into a Google account, we also collect data that we store in your Google account and consider to be personal data.
Google directly admits to exploiting your personal data
Accordingly, the following information on Google tools used must be provided:
- Purposes of data processing by the service provider
- Data recipient
- Risks, such as transfers to certain third countries or certain types of recipients, such as authorities or intelligence services
- Purposes of cookies (these are generally only known to the service provider, who in the case of Google usually does not sufficiently disclose the purposes
As you can easily see, this information cannot be made concrete, transparent and correct for Google tools.
In addition, one can always refer to Art. 44 GDPR for the Google Corporation regarding data transfer to insecure third countries. However, I have made it a habit to only subordinate this problem because the aforementioned data protection considerations already suffice as an argument against external Google fonts. ([1])
Anyone who considers all the above arguments for local and against external Google Fonts to be invalid can certainly present a contract that they have concluded with Google in order to obtain suitable guarantees from Google for GDPR-compliant data processing. Ideally, an opt-out option for collected data should also be offered. Have fun!
On the website of a provider of consent tools, it is incidentally reported that the latter uses external Google fonts, as well as the problem of using external Google fonts. That the mentioned website itself uses external Google fonts is all the more surprising. Since the fonts are not found on every subpage and also not on the page with the article about Google Fonts, this shows that the provider of the consent tool did not do this intentionally and is possibly overwhelmed by compliance with data protection provisions.
What is mit Content Delivery Networks?
So-called CDNs offer a fast, hopefully always available storage. The justification for using such systems is often a supposedly faster loading time of the website. So far, however, no one has been able to prove this to me (I don't want to rule out that this is the case, but I would like to have at least proof for the first load). As a commenter on this post mentioned, follow-up requests for the same resource, which are used by various websites simultaneously, are optimized. However, follow-up requests within the same website itself are already faster due to the local cache of the user. It's only about the initial request of a website that uses the same resources just as lawfully as other websites do. If a local cache at the user is long-lived, it performs better than any CDN. Since Google Fonts are widely used, the chance of having a local cache hit is high. Those who regularly clear their browser caches for data protection reasons may not want to be tracked by a data protection-hostile CDN in return. For security and data protection reasons, modern browsers sometimes use Cache Partitioning. As a result, there is a separate cache per website. Thus, the argument of the global cache at the user, which could build up across multiple websites, is almost obsolete.
It is questionable whether loading a small, static file from a CDN happens faster than from a local storage. Browsers cache requests of this kind, so that on subsequent requests by the same user often the local copy is drawn, which is the fastest.
If you load resources from CDNs, the browser can possibly parallelize loading processes by triggering the loading processes from several different servers almost simultaneously. This means that files from the local server can be loaded almost simultaneously with files from other servers.
Anyone who thinks that Google fonts have to be loaded from a CDN so that the first call of the website is faster should first check whether all other speed optimizations on the website have been exhausted. If you load unnecessary fonts because they are not used, you do not need to use the argument of faster CDN loading time on the first call.
If you absolutely want to use a CDN, you can do so. However, it must be ensured that the operator of the CDN is bound by the GDPR and, of course, complies with it. American companies can therefore be ruled out as CDN providers, unless you want to work with consent and accept a certain degree of legal uncertainty.
Incidentally, you can also set up a CDN yourself. Apparently, the operator of the website is so important that he needs a CDN. Then it should be possible to do this. After all, it's just a file server with a fast Internet connection. Such servers can be rented anywhere in Germany. A German company would be happy to offer a data protection-compliant CDN on a broad basis. I think there is a market for this.
Under no circumstances should one, in my opinion, rely on Cloudflare, as this provider cannot offer good data protection, according to my research . [Akamai] can also not be considered data protection friendly. ([1])
What is the solution?
Google Fonts can be locally embedded. This can be done manually or with the help of a tool. The tool is Google Webfonts Helper. After calling up the website of the tool, you can select a font in the left area (at least on desktop PC display). In the main area, the finished files for local embedding of the fonts can then be downloaded.
I would also like to describe the manual method here to illustrate the basic principle.
To do this manually, download the font files. This is done as follows:
External fonts are loaded through a file like the following: https://fonts.googleapis.com/css?family=Roboto. This can be seen in the website's source code. Another possibility is the developer console of Firefox and other browsers, which can be opened with the F12 key. After opening the console, call up the webpage. The network analysis menu shows data transfers. There you will find then loading processes from the domain fonts.googleapis.com and others.
Open the font file in the browser and copy its content into a file named roboto.css. (Choose a different name for other font types sensibly.).
You will see lines that refer to external files. These look like this, for example:
src: url(https://fonts.gstatic.com/s/roboto/v20/KFOmCnqEu92Fr1Mu72xKOzY.woff2) format('woff2');
Normally only the sections relevant are those marked with the comment / latin /, possibly also those with extended Latin character set / latin-ext /.
Download all files of this kind. Change in roboto.css so that it points to their local file. In the Google Terms of Service, I see no indication why this should not be allowed.
You can save yourself potentially false privacy texts for Google Fonts from now on. Nobody can accuse you anymore of having forgotten the privacy policy or violating data protection regulations by using external Google fonts.
As you can see, the solution is relatively simple and not rocket science. It doesn't matter for data protection purposes that this procedure is best carried out by someone with an affinity for technology. If necessary, ask someone who is familiar with it. If he is good, he will get it done in a very short time.
For WordPress websites, I recommend using design themes that either embed Google Fonts locally or provide an option for it.
With my online Webpage-Check, it can be quickly checked whether a webpage uses Google Fonts. The check only checks the first few subpages. This is usually enough for a good assessment.
Possible counterarguments and rebuttals
The counterargument of allegedly longer loading times can be ruled out for small font files, also due to my own years of experience with local fonts. Whoever wants to can use a data protection compliant CDN, but not Google's! Building one's own CDN is also possible and certainly worthwhile for websites that rely on a loading time five milliseconds shorter than local integration.
Below I have described a speed test that proves that external Google fonts do not increase speed.
The argument that the scripts are then no longer automatically (by Google) maintained, is none. After all, scripts should last forever exactly as they were installed. The fact that browsers would change significantly and require a Font Update would be very rare. When new fonts are delivered, it will rarely happen that the dot on the i was forgotten during font design. When existing fonts are concerned, the question is what can still be changed. It's about a font type and not an atomic reactor.
I know from my own experience that there is no maintenance problem. In addition, there are judgments in other cases according to which an entrepreneur with an online offer is obliged to regularly view and re-evaluate his offer. The entrepreneur even becomes liable if a platform on which he advertises his products independently and fully automatically makes the entrepreneur's offer illegal. Exactly the same commitment can be expected for writings (see, for example, OLG Frankfurt, decision of 18.03.2021, ref. 6 W 8/18).
Legally speaking, no one has been able to show me where it says that local integration, as I described above, is prohibited. On the contrary, the scripts run under the SIL Open Font License. Google labels all fonts on Google Fonts as Open Source and free:
All the fonts and icons in our catalog are free and open source…
From: https://fonts.google.com/about?preview.size=165
This is confirmed by Google elsewhere: "All fonts are released under open source licenses. You can use them in any non-commercial or commercial project."."
I think that by integrating Google Tools, their website is given more weight and then appears more prominent in search results of the Google search engine. Alone because many websites integrate Google Tools, this argument does not hold up. In addition, I can claim from experience that higher-quality on-page SEO measures have significantly less effect than a good content strategy. This also includes spreading contents in suitable media. For this, Google is in no way necessary (except if one wants to publish a video on YouTube, but even here there are better alternatives, because YouTube can be described as overcrowded).
Overview of the responses
Some are quite creative when it comes to somehow justifying the illegal use of external Google Fonts. The following table shows a brief presentation of the alleged arguments and their rebuttal.
| Alleged argument | Debilitation |
|---|---|
| External Google fonts are faster |
|
| Local fonts make too much work |
|
| Google fonts must not be integrated locally | Where is that? Even if it were so: Everyone can download TrueType Fonts (also from the Google Fonts Platform) and convert them into Web Fonts. There are freely available helper programs for this. Attention: The SIL Open Font License of Google Fonts requires a renaming of the font after conversion, if further distribution takes place (see comment below the contribution). On the website of Google Fonts, it says about the Roboto font, for example: You can use them freely in your products & projects – print or digital, commercial or otherwise. However, you can't sell the fonts on their own. See also Art. 5 GDPR and Art. 25 GDPR. |
| Only external Google fonts are maintenance-free | Before a font is replaced for purely technical reasons, the website has updated itself multiple times. I have looked at some font updates on the Google Fonts marketplace. The updates are all unnecessary if the font was already in use beforehand. They often involve new font types (such as semi-finished printing) or purely organizational reasons. The need for maintenance hardly ever arises – that's something I can claim after 30 years of IT experience. Here is another example: The source files of the Roboto font were last updated four years ago. Only the Makefile was optimized syntactically in 2020, which doesn't matter when using the fonts as a finished product. Moreover, entrepreneurs are required to regularly check their offers and possibly replace the font. Furthermore, the local cache in user browsers ensures that fonts are sometimes reloaded only after a year or more. See also Art. 5 GDPR and Art. 25 GDPR |
| External Google Writings were cached | That's true. But all other files end up in the browser cache as well. When a website is called for the first time, it may make a difference with popular fonts. It makes no difference on subsequent calls or if the user frequently clears their browser cache for data protection reasons. There are even helper programs that do this, such as the open-source solution BleachBit. A partitioned cache of modern browsers (cache partitioning) ensures from security and data protection reasons that there is no global cache that would work across websites. |
| The download is blocked for certain fonts | This argument is incorrect. Google Fonts is a platform that also displays fonts from other providers, but links to the providers' websites for downloading. Example: Palatino Font, which in this respect is not a Google font at all, but that of another provider (namely Monotype, fonts.com). |
| Better findability | Through embedded Google tools, Google receives a signal that a website has been called up. This signal may not be legally evaluated in order to weigh the website more heavily. Regardless of this, it also brings no success. SEO measures from a certain maturity level bring at least one order of magnitude less success than a targeted content strategy and distribution, as I can report from experience. See also Art. 5, Art. 25 and Art. 44ff GDPR. |
If you want to sleep peacefully or want to do something for data protection or simply comply with the law, then embed Google Fonts locally.
The attitude of supervisory authorities
In Germany, there is one data protection supervisory authority per federal state and also the Federal Data Protection Commissioner, who is responsible for public bodies, for example.
The statements of supervisory authorities are opinions, namely official opinions. They can be used to make a risk assessment, with which it can be estimated how likely a fine by a supervisory authority is. The legal question cannot be clarified in this way. Courts can consider official opinions as an indication, but they are not bound by them in any way. Supervisory authorities are generally more lenient than courts, so my experience goes. This helps little if a reprimand from a private person or a competitor is pending.
Each state data protection officer may have a different opinion and recommendation. Here are two examples:
- Bavaria: Following the verdict of the LG Munich court on 20 January 2022, the Bavarian Data Protection Authority (BayLDA) has quasi-banned the use of Google Fonts for public authorities. Previously allowed external Google Fonts. I'm not clear why , as there is no explanation in the FAQs. Thank you to the Bavarian authority for responding so quickly and comprehensively. The response makes it clear that data transfer to insecure third countries is considered critical, and external fonts are generally not permitted. Bavaria notes that data transfer to the US without consent is only possible under the strict conditions of the Schrems-II ruling. ([1])
- Baden-Württemberg: No explicit position, but a hint at data protection problems and the recommendation to bind writings locally.
Speed test: local versus external Google fonts
For comparison, the otherwise identical HTML page was tested once with external Google Fonts and once with local Google Fonts. The external Google Fonts were, as recommended by Google, linked using preconnect, making a faster loading time possible.
For testing, the online Webpagetest was used. The test was performed from a server in Frankfurt with the Chrome browser.
Test run with external Google fonts
The result shows an overview of the proportion of external fonts in the total loading time and the data transfer:
As you can see, the external Google fonts account for 15% of the total time of all requests required to access the website. The proportion of data transferred is 20.1% of the total.
In a waterfall diagram, the loading time for external Google fonts is as follows:
However, the relevant loading time is the blocking time, i.e. the time it takes to load the page with external Google fonts longer than it would without these fonts:
Here you can see the relevant loading times in more detail:
The first request started at time 0.696 seconds. The last request ended at time 0.699 seconds + 88 milliseconds (Time to first byte) +26 milliseconds (Content Download) = 0.813 seconds.
The relevant total loading time for the first call for external Google fonts was therefore 0.813 – 0.699 seconds = 114 milliseconds.
The subsequent retrieval was evaluated in the same way. It amounted to 91 milliseconds.
Test run with local Google fonts
The result shows an overview of the share of local fonts in the total loading time and the data transfer:
The proportion of loading time in relation to all requests is so low for local Google fonts that I had to move the cursor over the red piece of cake. It amounts to 12.8 %. The proportion of data transferred is 18.3% of the total. However, the connection time is apparently not included here.
Local Google fonts generate the following loading times when first called up:
However, the relevant loading time is the blocking time, i.e. the time it takes to load the page with local Google fonts than it would without these fonts. A chart by server, as with external Google fonts, does not help here because files other than fonts are also loaded from the website server.
Here you can see the relevant loading times in more detail:
The first request started at time 0.772 seconds. The last request ended at time 0.775 seconds + 270 milliseconds (Time to first byte) +1 millisecond (Content Download) = 1.046 seconds.
The relevant total loading time for the first call for local Google fonts was therefore 1.046 – 0.772 seconds = 274 milliseconds.
The follow-up call was evaluated in the same way. It was roughly as fast as the initial call-off.
Result of the speed test
The best way to see the result is to compare them.
| Criterion | External Google Fonts | Local Google Fonts |
|---|---|---|
| Loading time 1st call | 114 ms | 211 ms |
| Loading time 2nd call | 91 ms | 225 ms |
External Google fonts are slightly faster than the local integration. If you look at the total loading time of the website, the following statistics emerge (the total loading times are given as the denominator of the fractions, all figures in milliseconds):
| Share of charging time in total charging time | 1st call-off | 2nd call-off |
|---|---|---|
| External Google Fonts | 114 / 2432 = 4,7% | 91 / 2469 = 3,7% |
| Local Google Fonts | 211 / 2482 = 8,5% | 217 / 2426 = 8,9% |
The total loading time was 3.8% faster with external Google fonts compared to locally integrated fonts when the website was first called up and 5.2% faster on subsequent calls.
The optimization measures for my website have shown that improving page load time can be achieved through entirely different measures much more effectively. Examples: Enable caching on the level of file htaccess, further compress images, deactivate unnecessary plugins.
Incidentally, the test was carried out with this website. It is certainly not academically usable because the number of tests is too small and the fluctuation in loading times in several tests is a few percent. Based on the results and the arguments and facts mentioned, everyone can form their own opinion.
Anyone still relying on the speed argument for external Google fonts must prove that
- a few milliseconds on the first visit to the website are business-critical,
- no GDPR-compliant CDN is available (although this is still not an argument),
- own CDN, in the simplest case also File Server named, is not possible (this will be difficult to show)
- all other measures have really been exhausted (good luck!)
- no data is transferred to insecure third countries when retrieving external fonts
- Google does not use the traffic data received for its own purposes and does not pass it on to third parties (third parties are all those who are unlike Google Ireland Ltd.).
Load local fonts faster
If you load more than one font file (typical file extension: woff or woff2), you should load each font file separately and use non-blocking loading. This can be achieved by:
<link rel="stylesheet" href="font1.css" type='text/css' media="none" onload="if(media!='all')media='all'"><link rel="stylesheet" href="font1.css">
This line of code loads a font file asynchronously. The designation media="none" ensures this. After the font file has been loaded, the media attribute is set to media="all" in the JavaScript instruction within the _onload-_event, so that the font is applied for the current rendering.
The noscript-instruction ensures that the font is loaded correctly even for browsers where JavaScript has been disabled.
Set up your own fast file server
You don't need a Content Delivery Network (CDN) for your own websites. A CDN is primarily necessary because so many web pages are connected to it.
A private CDN, which is used for only a few own websites, can also be called a fast file server. Who wants more, builds himself a server infrastructure with load balancing. When retrieving multiple font files, several CDN servers are switched on.
A such File Server is a server with fast internet connection and as few restrictions as possible regarding data transfer volume. For this there are some offers from German providers that are very cheap. Also CDNs with load balancing are available from purely European providers. Who needs a superspeedy website (and also relies on it), will have to tolerate paying a few euros per month for a web hosting offer, in order to be able to load the beloved Google fonts faster.
My name is Klaus Meffert. I have a doctorate in computer science and have been working professionally and practically with information technology for over 30 years. I also work as an expert in IT & data protection. I achieve my results by looking at technology and law. This seems absolutely essential to me when it comes to digital data protection. My company, IT Logic GmbH, also offers consulting and development of optimized and secure AI solutions.