Aktualisiert: Marz 2026 · Lesezeit: 11 Min.
Webfonts machen Websites schoner. Das bestreitet niemand. Aber seit dem Google-Fonts-Urteil von 2022 ist klar: Schonheit darf nicht auf Kosten des Datenschutzes gehen. Und ehrlich gesagt: Das muss sie auch nicht. Man kann Webfonts nutzen und trotzdem DSGVO-konform sein. Man muss es nur richtig machen.
Dieser Leitfaden geht uber das reine "Google Fonts lokal einbinden" hinaus. Ich zeige, wie Sie Webfonts von Anfang an so einsetzen, dass Datenschutz und Performance stimmen. Das ist das, was ich bei jedem neuen Projekt mache — und was ich meinen Entwickler-Kollegen empfehle.
Die DSGVO-Problematik bei Webfonts lasst sich auf eine einfache Formel reduzieren: Jeder HTTP-Request an einen fremden Server ubertragt die IP-Adresse. Die IP ist ein personenbezogenes Datum. Also brauchen Sie fur jeden solchen Request eine Rechtsgrundlage.
Bei Webfonts fallt "berechtigtes Interesse" weg, weil es eine zumutbare Alternative gibt: lokales Hosting. Bleibt die Einwilligung — aber die haben Sie beim ersten Seitenaufruf typischerweise noch nicht.
Also: Fonts von Ihrem eigenen Server laden. Keine CDNs, keine Cloud-Dienste, keine Drittanbieter-Server. Zumindest nicht ohne vorherige Einwilligung.
Nach drei Jahren Erfahrung mit DSGVO-konformen Font-Setups hat sich bei mir ein klarer Workflow herausgebildet. Hier ist er komplett.
Die meisten Websites brauchen maximal zwei Schriften: eine fur Uberschriften, eine fur Fliesstext. Jede zusatzliche Schrift bedeutet mehr Dateien, mehr Ladezeit, mehr Komplexitat.
Noch besser: Nur eine Schrift in verschiedenen Gewichten. Roboto in Regular und Bold, oder Inter in 400 und 700 — das reicht fur 95% aller Websites aus. Und es spart enorm Bandbreite.
Brauchen Sie wirklich Light (300), Regular (400), Medium (500), SemiBold (600), Bold (700) und ExtraBold (800)? Wahrscheinlich nicht. Jeder Schriftschnitt ist eine separate Datei. Begrenzen Sie sich auf das, was Sie tatsachlich verwenden.
Meine Faustregel: Regular (400) fur Fliesstext, Bold (700) fur Uberschriften und Hervorhebungen. Optional Italic fur Zitate. Das sind drei Dateien — uberschaubar.
WOFF2 wird von allen modernen Browsern unterstutzt (98%+ globaler Support). Es ist 30% kleiner als WOFF und 50% kleiner als TTF. Sie brauchen kein anderes Format.
Ausnahme: Wenn Sie aus irgendeinem Grund IE11 unterstutzen mussen (und ja, es gibt immer noch Unternehmen, die das verlangen), brauchen Sie WOFF als Fallback. Aber wirklich nur dann.
Das ist der Trick, den die meisten ubersehen. Eine typische Google-Fonts-Datei enthalt Glyphen fur Lateinisch, Griechisch, Kyrillisch, Vietnamesisch und mehr. Wenn Sie eine deutschsprachige Website betreiben, brauchen Sie nur den Latin-Subset — plus die deutschen Umlaute.
Mit dem Tool glyphhanger konnen Sie genau die Zeichen extrahieren, die Ihre Website tatsachlich verwendet:
# Installieren npm install -g glyphhanger # Analysieren, welche Zeichen Ihre Seite nutzt glyphhanger https://ihre-website.de --spider # Font auf diese Zeichen reduzieren glyphhanger --whitelist="U+0000-00FF,U+00C4,U+00D6,U+00DC,U+00E4,U+00F6,U+00FC,U+00DF,U+20AC" \ --subset="roboto-regular.woff2" --formats=woff2
Das Ergebnis: Statt 40-60 KB pro Schriftdatei haben Sie 15-20 KB. Bei drei Schnitten sparen Sie locker 100 KB. Das macht sich bemerkbar.
Die font-display-Eigenschaft steuert, was passiert, wahrend die Schrift ladt. swap zeigt sofort eine Fallback-Schrift an und tauscht sie aus, sobald die Webfont geladen ist. Das ist fast immer das, was Sie wollen.
@font-face {
font-family: 'Inter';
font-style: normal;
font-weight: 400;
font-display: swap; /* IMMER setzen */
src: url('/fonts/inter-v12-latin-regular.woff2') format('woff2');
}
Ohne font-display (oder mit dem Wert auto) riskieren Sie den beruchtigten FOIT — 3 Sekunden unsichtbarer Text, wahrend der Browser auf die Font wartet. Ihre Besucher sehen: nichts. Und verlassen die Seite.
Mit Preload-Hints teilen Sie dem Browser mit, dass er die Schriftdateien so fruh wie moglich laden soll — noch bevor das CSS geparst wird:
<head>
<link rel="preload" href="/fonts/inter-v12-latin-regular.woff2"
as="font" type="font/woff2" crossorigin>
<link rel="preload" href="/fonts/inter-v12-latin-700.woff2"
as="font" type="font/woff2" crossorigin>
<!-- ... rest of head -->
</head>
Das crossorigin-Attribut ist Pflicht, auch wenn die Fonts vom selben Server kommen. Ohne es ladt der Browser die Font doppelt — einmal durch den Preload-Hint und nochmal durch die @font-face-Regel. Klassischer Anfangerfehler, passiert mir auch hin und wieder.
Ich hab das auf einer typischen WordPress-Seite gemessen. Gleiche Fonts, gleiche Schnitte, nur die Quelle anders:
Externes Google Fonts CDN:
Lokales Hosting mit Preload:
Fast 300ms Unterschied. Das ist keine akademische Spielerei — das sind echte Millisekunden, die Google in den Core Web Vitals misst. Und die Ihre Besucher spuren.
Auch wenn Sie Fonts lokal hosten: Erwahnen Sie es in Ihrer Datenschutzerklarung. Nicht weil Sie mussten (bei lokalen Fonts werden keine personenbezogenen Daten an Dritte ubertragen), sondern weil es Vertrauen schafft und eventuelle Nachfragen verhindert.
Ein Muster-Absatz:
Webfonts Diese Website nutzt Webfonts, die lokal auf unserem Server gehostet werden. Es wird keine Verbindung zu externen Font-Diensten (wie Google Fonts, Adobe Fonts o.a.) hergestellt. Es werden keine personenbezogenen Daten an Dritte ubertragen.
Die Umstellung ist gemacht, aber der Browser-Cache, der WordPress-Cache und der CDN-Cache liefern noch die alte Version mit externen Fonts aus. Immer alle Cache-Ebenen leeren.
Ein Theme-Update stellt die externe Einbindung wieder her. Deshalb: Immer ein Child-Theme verwenden oder ein Plugin wie OMGF, das die Einstellung persistent halt.
Nicht nur Google Fonts sind betroffen. Font Awesome, Material Icons, Adobe Fonts — alles prufen.
Lokale Fonts ohne font-display: swap konnen zu unsichtbarem Text fuhren. Immer setzen.
6 Schriftschnitte in 2 Schriften = 12 Dateien = 500+ KB. Das killt die Performance. Begrenzen Sie sich.