Zurück zum Blog
Webentwicklung

Warum ich Google Fonts nicht für Kundenprojekte nutze

Helge DrewsVeröffentlicht am Aktualisiert am Lesezeit: 7 Min.
Web-EngineeringDatenschutzDSGVOPerformanceNext.js
Vergleich auf der Titelkarte „Google Fonts selbst hosten“: externes CDN über drei Domains gegen lokales Hosting über next/font auf einer Domain

Wenn ein neues Webprojekt startet, dreht sich die Diskussion schnell um das visuelle Erscheinungsbild. Typografie prägt den Charakter einer Marke: Klare serifenlose Schriften vermitteln Modernität und Struktur, Schriften mit ausgeprägten Serifen schaffen Eleganz und Tradition. Bei der technischen Umsetzung greifen viele Agenturen und Webdesigner reflexartig zu Google Fonts. Eine Zeile HTML im Kopfbereich der Website genügt, und schon stehen hunderte freie Schriftarten auf Knopfdruck bereit.

In meinen Projekten setze ich dieses Verfahren grundsätzlich nicht ein. Wenn ich Websites für Kunden entwickle, verlässt beim Laden der Typografie keine einzige Anfrage den eigenen Server. Keine Schriftdatei wird dynamisch über die Rechenzentren von Google nachgeladen. Das ist keine theoretische Prinzipienreiterei, sondern eine bewusste handwerkliche Entscheidung. Externe Schrift-Einbindungen belasten die Ladezeit, erzeugen unnötige Abhängigkeiten und setzen Website-Betreiber vermeidbaren rechtlichen Risiken aus.

Was das Urteil des Landgerichts München I bedeutet

Um zu verstehen, warum die dynamische Einbindung von Google Fonts problematisch ist, lohnt ein Blick in das Urteil des Landgerichts München I vom 20. Januar 2022 (Az. 3 O 17493/20). Das Gericht verurteilte eine Website-Betreiberin zur Unterlassung und sprach dem Kläger einen immateriellen Schadenersatz in Höhe von 100 Euro nach Art. 82 Abs. 1 der Datenschutz-Grundverordnung (DSGVO) zu.

Der Kern der Entscheidung betrifft die IP-Adresse. Sobald ein Besucher eine Seite aufruft, die Schriften dynamisch über fonts.googleapis.com oder fonts.gstatic.com einbindet, baut der Browser des Besuchers im Hintergrund eine direkte Verbindung zu den Servern von Google auf. Dabei wird die dynamische IP-Adresse des Nutzers übertragen. Nach gefestigter Rechtsprechung des Europäischen Gerichtshofs (EuGH, Urteil vom 19.10.2016, Az. C-582/14) stellen dynamische IP-Adressen personenbezogene Daten dar, weil sie die Bestimmbarkeit der Person ermöglichen.

Die Beklagte versuchte vor Gericht, sich auf ein berechtigtes Interesse nach Art. 6 Abs. 1 lit. f DSGVO zu berufen. Schließlich gehe es lediglich um eine einheitliche und optisch ansprechende Darstellung der Website. Dieser Argumentation erteilten die Richter eine deutliche Absage. Das Gericht stellte klar, dass die Weiterleitung der IP-Adresse an Server in den USA nicht erforderlich ist. Schriften lassen sich ohne nennenswerten Aufwand lokal auf dem eigenen Webserver speichern und ausliefern. Wenn ein identisches visuelles Ergebnis ohne Datenweitergabe an Dritte erreichbar ist, entfällt jede Rechtfertigung für die externe Übertragung.

Die Abmahnwelle und ihre Folgen für Unternehmen

Im Spätsommer und Herbst 2022 erlebte Deutschland eine der größten automatisierten Abmahnwellen der vergangenen Jahre. Ein Rechtsanwalt und sein Mandant durchsuchten das Web mit automatisierten Skripten nach Websites, die Google Fonts dynamisch einbanden. Zehntausende Freiberufler, Handwerksbetriebe, Praxen und mittelständische Unternehmen erhielten standardisierte Zahlungsaufforderungen. Gefordert wurden Beträge zwischen 170 und 200 Euro, um ein gerichtliches Verfahren abzuwenden.

Dieses aggressive Geschäftsmodell flog den Urhebern bald um die Ohren. Die Staatsanwaltschaft Berlin eröffnete ein Ermittlungsverfahren wegen gewerbsmäßigen Bandenbetrugs und versuchter Erpressung. Es folgten Razzien, Beschlagnahmen von Konten und schließlich die Anklage vor der Wirtschaftsstrafkammer des Landgerichts Berlin.

Bei vielen Unternehmern hinterließ dieser Ausgang einen trügerischen Eindruck: Da die Abmahner strafrechtlich verfolgt wurden, schien das Thema erledigt. Das ist ein gefährlicher Trugschluss. Die Berliner Justiz ging gegen den rechtsmissbräuchlichen Charakter der Massenabmahnungen vor, nicht gegen die materielle Rechtslage.

Die Datenschutzbehörden der Bundesländer und die Datenschutzkonferenz (DSK) halten unverändert an ihrer Rechtsauffassung fest. Wer Schriften von Drittanbieter-Servern in den USA nachlädt, ohne eine vorherige, ausdrückliche Einwilligung seiner Besucher einzuholen, verstößt gegen Datenschutzrecht. Aufsichtsbehörden prüfen Websites bei Beschwerden von Kunden oder Mitbewerbern weiterhin und fordern Betreiber zur Nachbesserung auf.

Warum ein Consent-Banner für Schriften die falsche Lösung ist

Nach den Urteilen und Berichten wählten einige Agenturen den scheinbar einfachsten Ausweg: Sie parkten Google Fonts hinter dem Cookie-Banner. Die Schrift wird erst geladen, wenn der Besucher auf „Einverstanden“ klickt.

Aus Sicht der Benutzerfreundlichkeit ist das eine schlechte Lösung. Ein potenzieller Kunde betritt Ihre Website, um sich über Ihre Leistungen zu informieren. Bevor er den Text lesen kann, sieht er entweder eine unformatierte Systemschrift wie Times New Roman, oder der Text bleibt für mehrere Sekunden komplett unsichtbar, bis das Skript reagiert. Klickt der Besucher das Banner weg, springen alle Überschriften und Absätze um.

Solche visuellen Brüche zerstören den ersten Eindruck. Kein Kunde sollte in die Datenverarbeitung einwilligen müssen, nur damit der Text auf einer Unternehmensseite lesbar erscheint. Ein Banner für Schriftarten ist kein Datenschutz, sondern das Eingeständnis eines handwerklichen Mangels. Seriöses Web-Engineering fragt nicht um Erlaubnis für unnötige Datenübertragungen, sondern vermeidet sie an der Wurzel.

Der Performance-Vorteil von lokalem Hosting

Selbst wenn man den Datenschutz für einen Moment ausblendet, spricht die technische Leistungsfähigkeit einer Website klar gegen externe Schrift-CDNs. Google Fonts verlangsamt den Ladevorgang spürbar.

Jede externe Ressource zwingt den Browser zu zusätzlichen Netzwerkschritten. Um eine Schrift von Google darzustellen, muss der Browser zunächst eine CSS-Datei von fonts.googleapis.com abrufen. In dieser CSS-Datei stehen die Verweise auf die eigentlichen Schriftdateien, die wiederum auf einer zweiten Domain liegen: fonts.gstatic.com.

Für beide Server muss der Browser eine DNS-Abfrage ausführen, eine TCP-Verbindung etablieren und einen vollständigen TLS-Handshake zur Verschlüsselung durchlaufen. Erst danach können die Schriftdateien heruntergeladen werden. Über Mobilfunk oder bei unruhigen Netzwerkverbindungen kostet diese Kette wertvolle Zeit.

Schriften gehören zu den render-blockierenden Ressourcen. Solange der Browser nicht weiß, wie die Schriftzeichen berechnet werden müssen, kann er den Text nicht fehlerfrei zeichnen. Das verzögert den First Contentful Paint (FCP) und den Largest Contentful Paint (LCP), also jene zentralen Kennzahlen der Core Web Vitals, die für das Suchmaschinen-Ranking und die Verweildauer Ihrer Besucher ausschlaggebend sind.

Hosten Sie die Schriften hingegen auf Ihrem eigenen Webserver, greift ein entscheidender technischer Vorteil: Moderne Server nutzen HTTP/2 oder HTTP/3. Über eine einzige bestehende Verbindung zur eigenen Domain überträgt der Server HTML, CSS und Schriftdateien gleichzeitig im Multiplexing-Verfahren. Zusätzliche Verbindungskosten entfallen vollständig.

Externe CDNs erfordern getrennte Verbindungsaufbauten zu zwei fremden Domains, während lokales Hosting dieselbe HTTP/2- oder HTTP/3-Verbindung ohne zusätzliche Latenz nutzt.

Wie sauberes Font-Hosting in der Praxis aussieht

Die technische Umsetzung von lokal gehosteten Schriften ist im modernen Web-Engineering längst gelöst und erfordert keinen unverhältnismäßigen Aufwand.

In Projekten mit Next.js setzen wir standardmäßig auf das integrierte Paket next/font. Dieses Modul lädt Schriften zur Build-Zeit automatisch herunter und speichert sie als statische Dateien direkt im Projekt. Wenn die Website kompiliert wird, bindet das System die Schriften lokal ein. Im Browser des Besuchers existiert keinerlei Verbindung zu Google-Servern mehr.

Gleichzeitig optimiert das Framework die Auslieferung: Die Schriften liegen im modernen WOFF2-Format vor, das dank Brotli-Kompression extrem schlank ist. Eine typische lateinische Schriftdatei umfasst oft nur 15 bis 30 Kilobyte. Durch gezieltes Subsetting werden nur jene Schriftzeichen ausgeliefert, die auf der Website tatsächlich vorkommen. Exotische Sonderzeichen, die im deutschen Sprachraum niemand benötigt, werden gar nicht erst über das Netzwerk geschickt.

Mit den passenden CSS-Eigenschaften wie font-display: swap und modernen Metrik-Anpassungen (size-adjust) stelle ich sicher, dass während des Bruchteils einer Sekunde, in dem die Schriftdatei geladen wird, eine passende Systemschrift ohne sichtbaren Versatz angezeigt wird. Der gefürchtete Layout-Sprung (Cumulative Layout Shift) wird dadurch auf null reduziert.

Handwerkliche Sorgfalt schützt vor bösen Überraschungen

In meinem Leitfaden Drei Dinge, die ich vor jedem Auftrag kläre habe ich es auf den Punkt gebracht: Digitalprojekte scheitern selten an fehlenden Ideen. Sie scheitern an unsauberen Schnittstellen, fehlender Disziplin und technischen Abkürzungen. Wer bei der Typografie auf Bequemlichkeit setzt und externe Skripte wahllos zusammensteckt, spart beim Setup eine halbe Stunde und erzeugt dafür jahrelange Wartungs- und Haftungsrisiken.

Schriften lokal bereitzustellen, dauert bei einer sauberen Architektur nur wenige Minuten. Es hält den Quellcode unabhängig von externen US-Diensten, befreit Ihre Website von nervigen Schrift-Bannern und sorgt für messbar schnellere Ladezeiten auf allen Endgeräten.

Ein Blick in den Netzwerk-Tab der Entwicklertools zeigt sofort, ob Ihre Website Schriftdateien von fremden Servern bezieht. Gerne werfe ich einen Blick auf Ihr Setup und zeige Ihnen, wie die Umstellung auf lokale Schriften innerhalb eines Tages gelingt: Nutzen Sie für die Anfrage einfach mein Kontaktformular.