Google Fonts on a landing page: the GDPR risk and the speed you gain by self-hosting

Published on 20 August 2026 · 8 min read

The typeface on a landing page deserves careful thought: it carries the brand's personality before a single word is read, as our guide on choosing a font for a landing page explains. But between choosing a font and loading it sits a technical decision almost nobody makes consciously: the <link href="https://fonts.googleapis.com/…"> line pasted straight from Google Fonts. It's free, it works in two seconds, and it has two consequences most page owners never think about: it exposes every visitor's IP address to a third-party server, and it delays your text from appearing. Here's what you need to decide with your eyes open.

What that pasted Google Fonts line actually does

When a visitor opens your page, their browser reads the <head>, finds the link to fonts.googleapis.com, and goes off to fetch a stylesheet from that domain. That stylesheet in turn tells it to download the font files from fonts.gstatic.com. Two connections to a third-party domain, then, before a single letter renders in the right typeface. And with each of those connections, the browser sends what it always sends: the visitor's IP address, their user-agent, and the page that triggered the request. This isn't a hidden tracker — it's how the web normally works. But it is a transfer of personal data to a third party, triggered without the visitor asking for it or agreeing to it.

The legal side: what the Munich court ruled

On 20 January 2022, the Regional Court of Munich I (LG München I, case 3 O 17493/20) ordered a website operator to pay €100 in damages to a visitor, on the grounds that dynamically embedding Google Fonts had transmitted their IP address to Google without consent. The court rejected the legitimate-interest argument: since fonts can perfectly well be hosted on the site's own server, nothing justified imposing that transfer on the visitor. The decision went on to fuel a wave of warning letters across Germany.

Two honest caveats. First, a first-instance German judgment is not French case law and does not settle the question elsewhere. Second, the reasoning itself rests on the GDPR — the same text on both sides of the border — and on a principle regulators have applied for years: an IP address is personal data. In other words, the exact legal exposure is debatable, but the defence is weak — it's hard to argue necessity when the alternative takes an hour to implement and costs nothing. The same reasoning we apply to your forms in our article on GDPR-compliant landing page forms.

What the research says about the underlying problem

The issue reaches well beyond fonts. In their landmark measurement "Online Tracking: A 1-million-site Measurement and Analysis" (Steven Englehardt and Arvind Narayanan, ACM CCS, 2016), the authors crawled the top million websites and showed just how pervasive — and how concentrated in a few hands — third-party resources have become: scripts, fonts and stylesheets alike, each call amounting to a point of contact with a domain the visitor never chose to reach. Fonts appear twice over in this literature: the study "Cookieless Monster: Exploring the Ecosystem of Web-Based Device Fingerprinting" (Nick Nikiforakis and colleagues, IEEE Symposium on Security and Privacy, 2013) documented that the list of fonts installed on a machine is itself used as a fingerprinting signal to identify a browser without cookies. None of this accuses Google Fonts of spying on your visitors; it does explain why regulators and courts look closely at third-party calls, fonts included.

On the legibility side, the work of Michael Bernard and his team, "A comparison of popular online fonts: Which size and type is best?" (Usability News, 2002), remains one of the most cited comparisons of on-screen reading: size and familiarity drive reading speed and preference far more than a typeface's originality. The practical translation: giving up an exotic font for a system or self-hosted one costs you almost nothing in reading efficiency, while the technical gain is immediate.

The performance cost: two requests before your first word

The privacy argument convinces the cautious; the speed argument convinces everyone. An external font inserts two network round trips into the critical rendering path: DNS resolution plus a TLS handshake to fonts.googleapis.com, then the same again for fonts.gstatic.com. On an average mobile connection, that's hundreds of milliseconds added before your headline appears — exactly what Google measures as LCP, detailed in our article on LCP on a landing page, and a direct drag on conversion as shown in our piece on page load speed.

FOIT, FOUT and the shift that costs you the click

While the font is on its way, the browser has to pick a side: show invisible text until it arrives (FOIT, flash of invisible text) or show a fallback font immediately and swap it later (FOUT, flash of unstyled text). The second is almost always preferable — but if the fallback doesn't share the same proportions, the swap moves your layout at the very moment the visitor was about to click. That's CLS, the visual-stability metric explained in our dedicated article, and one of the quietest causes of missed taps on mobile.

The fix: self-host your fonts in five steps

Download the files from Google Fonts ("Get font" then "Download all"): Google's fonts are open-licensed, and self-hosting is explicitly allowed.
Convert them to WOFF2 and drop every other format: it's the only format current browsers need, and the most compact.
Keep only the weights you actually use. Two weights (400 and 700) cover 90% of landing pages; every extra weight is one more file to download.
Subset the character set to latin + latin-ext for a Western-language page: there's no reason to ship Cyrillic and Greek.
Declare them with @font-face and font-display: swap, serve them from your own domain, and add a fallback with close proportions to the font-family stack.

The result: no third-party call at all, one fewer request on the critical path, files served from the same domain as the rest of the page (so over a connection that's already open), and a font that appears without shifting the layout.

With Next.js, it happens at build time

If your page is built with Next.js, the next/font/google module settles the question for you: font files are downloaded at build time and then served from your own domain, with generated CSS that automatically includes fallback font metrics to neutralise layout shift. No request to Google is ever made from the visitor's browser at runtime. That's exactly how the LanderKit templates load their typography — one more argument for a modern technical base, compared with page builders in our article Next.js or WordPress for a landing page.

What if I keep the Google Fonts link?

The temptation is then to add fonts to the consent banner: the visitor declines, the font doesn't load. Bad idea, for two reasons. First, you make your design conditional on a click — half your visitors will see a page in a system font you never designed for. Second, every extra toggle in a banner adds to a friction we document in our article on cookie banners. The right reflex is the opposite: take the font out of consent scope altogether by hosting it yourself, the same way you'd favour cookieless analytics to avoid the banner rather than to fill it.

Three checks to run today

Open your page, switch to the "Network" tab in your browser's developer tools, filter on "font": if any domain other than your own shows up, this applies to you.
Check your themes and plugins too: on WordPress and page builders alike, the Google Fonts link is often injected by the theme, not by you.
Finally, look at icon libraries (Font Awesome and friends) loaded from a CDN: the problem and the fix are exactly the same.

A landing page that loads its typography from its own domain renders faster, shifts nothing under the visitor's thumb, and stays out of a legal debate nobody wants to be the test case for. Our ten templates — from Coach & Consultant to SaaS Waitlist, each browsable as a live demo before you buy — ship with this already handled, Next.js source code included, at €89 each or €229 for the full bundle of ten. One less hour spent on something your visitors will never notice, unless you neglect it.

FAQ

Frequently asked questions

Is Google Fonts banned in Europe?

No — no law or ruling bans it. The issue isn't the typeface but the fact that loading it from Google's servers transmits the visitor's IP address to a third party without consent. A German court sanctioned that practice in 2022; the safest position remains hosting the files on your own domain, which removes the question entirely.

Am I allowed to download Google's fonts and host them myself?

Yes. Nearly all fonts in the Google Fonts catalogue are published under an open licence (usually the SIL Open Font License), which explicitly permits downloading, hosting and redistributing them within a site. Just check the licence shown on the page of the font you're using.

Won't self-hosting slow my page down without a CDN?

No — in practice it's the opposite. The old "shared cache across sites" argument no longer holds: since 2020 browsers partition their cache per site, so a font loaded on another site is never reused on yours. Serving the file from your own domain also saves an extra DNS lookup and TLS handshake.

What if my WordPress theme loads Google Fonts without asking me?

That's the most common case. Many themes and page builders now offer a "host fonts locally" option in their performance settings; failing that, dedicated plugins download the files and rewrite the calls. Verify the result in your browser's Network tab: no request should go to fonts.googleapis.com or fonts.gstatic.com any more.

How many fonts and weights should a landing page load?

Two families at most, and two to three weights in total. Every extra file joins the critical rendering path for a visual benefit that drops off fast. Choosing the families themselves is covered in our article on picking a font for a landing page that converts.