So hosten Sie Schriftarten lokal, statt Google Fonts zu verwenden

Warum Google Fonts selbst hosten?

Google Fonts hat gute Typografie einfach gemacht. Ein Stylesheet einbinden, ein paar Schriftschnitte auswählen, die Seite veröffentlichen. Für kleine Teams war das jahrelang die vernünftige Standardeinstellung.

Der Kompromiss besteht darin, dass der Browser jedes Besuchers einen Drittanbieterdienst kontaktiert, um Font-CSS und Font-Dateien abzurufen. Das hat zwei Folgen.

Erstens entsteht eine externe Abhängigkeit beim Rendering. Wenn das Font-CSS langsam, blockiert oder in der Region oder im Netzwerk eines Nutzers nicht verfügbar ist, wartet Ihre Seite oder fällt auf Ersatzschriften zurück.

Zweitens entsteht eine Datenschutzfrage. Eine Font-Anfrage kann die IP-Adresse des Nutzers, den User-Agent, den Kontext der Referrer-Policy und Zeitinformationen an einen Dritten übermitteln. Google Fonts gibt an, über die Fonts API keine Cookies zu setzen, aber „keine Cookies“ ist nicht dasselbe wie „keine personenbezogenen Daten“. Unter der DSGVO kann eine IP-Adresse im Kontext weiterhin ein personenbezogenes Datum sein.

Fonts selbst zu hosten ist nicht automatisch für jede Website erforderlich, und dies ist keine Rechtsberatung. Aber für europäische Websites, öffentliche Einrichtungen, Gesundheitswesen, Bildung, Finanzen oder jedes Team, das unnötige Drittanbieteranfragen reduzieren möchte, ist lokales Hosting in der Regel die sauberere Wahl.

Oft ist es auch ein Performance-Gewinn, wenn es gut umgesetzt wird. Der entscheidende Punkt ist „gut umgesetzt“. Sechs Font-Dateien nach /assets/fonts/ zu kopieren und sie auf jeder Seite alle zu laden, kann schlechter sein als die Nutzung des gehosteten Dienstes. Wenn Sie den breiteren Performance-Kontext möchten, behandelt unser früherer Beitrag dazu, warum Webfonts auf den meisten Websites immer noch der einfachste Performance-Gewinn sind, die typischen Muster von Verschwendung.

Was sich beim Self-Hosting ändert

Wenn Sie Google Fonts auf die übliche Weise verwenden, macht Ihre Seite Folgendes:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Inter:wght@400;600&display=swap" rel="stylesheet">

Der Browser fordert zuerst CSS von fonts.googleapis.com an und lädt anschließend Font-Dateien von fonts.gstatic.com herunter.

Wenn Sie selbst hosten, sollte Ihre Seite sowohl das CSS als auch die Font-Dateien von Ihrer eigenen Domain anfordern:

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-latin-400.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

Damit entfällt die Font-Anfrage an den Drittanbieter. Gleichzeitig sind Sie dafür verantwortlich, Dateiformate, Cache-Header, Fallback-Schriften und Updates auszuwählen.

Diese Verantwortung sollte man ernst nehmen. Fonts liegen auf dem kritischen Rendering-Pfad. Eine schlechte Font-Konfiguration kann zu unsichtbarem Text, Layout-Verschiebungen und langsamem ersten Rendern führen.

Schritt 1: Prüfen, was Sie tatsächlich verwenden

Bevor Sie etwas herunterladen, listen Sie die Schriftfamilien, Schnitte, Stile und Zeichensätze auf, die Ihre Website wirklich benötigt.

Eine typische Marketing-Website braucht vielleicht:

• Regular 400 für Fließtext
• Semibold 600 oder Bold 700 für Überschriften und Buttons
• Italic 400 nur, wenn das Design tatsächlich Kursivschrift verwendet
• Nur den lateinischen Zeichensatz, sofern die Website keine weiteren Sprachen unterstützt

Seien Sie skeptisch gegenüber alten Design-System-Standards. Viele Websites laden 300, 400, 500, 600, 700, Kursivvarianten und mehrere Schriftsysteme, weil sie irgendwann einmal in einem Font-Auswahldialog aktiviert wurden.

Öffnen Sie in den Browser DevTools das Network-Panel, filtern Sie nach „font“, laden Sie die Seite neu und prüfen Sie, welche Dateien angefordert werden. Untersuchen Sie anschließend Ihr CSS auf die Verwendung von font-weight. Wenn Ihr CSS nie 300 verwendet, hosten Sie nicht 300.

Wenn Sie die Auswirkungen später bewerten, kann Lighthouse helfen, aber behandeln Sie den Score nicht als die ganze Wahrheit. Nutzen Sie es als Diagnosewerkzeug, nicht als Urteil. Wir haben einen separaten Leitfaden zum Lesen eines Lighthouse-Berichts ohne Panik, der bei der Priorisierung von Font-Korrekturen hilfreich ist.

Schritt 2: Die richtigen Font-Dateien herunterladen

Google Fonts bietet Open-Source-Schriftarten an. Sie können sie über die Google Fonts-Website oder aus dem jeweiligen Projekt-Repository der Schrift herunterladen. Prüfen Sie die Lizenz, aber die meisten Google Fonts werden unter offenen Lizenzen wie der SIL Open Font License oder der Apache License verbreitet.

Für das Web sollten Sie WOFF2 bevorzugen. Es wird von modernen Browsern breit unterstützt und ist meist deutlich kleiner als TTF oder OTF. Im Jahr 2026 ist es für öffentliche Websites nur selten gerechtfertigt, TTF direkt an Browser auszuliefern.

Eine sinnvolle Verzeichnisstruktur sieht so aus:

/public
  /fonts
    inter-latin-400.woff2
    inter-latin-600.woff2
    inter-latin-700.woff2

Verwenden Sie aussagekräftige Dateinamen. Sechs Monate später wird font.woff2 lästig sein. inter-latin-600.woff2 ist langweilig und nützlich.

Wenn Ihre Website ein Build-System nutzt, bewahren Sie die Quell-Fonts an einem klaren Ort auf und lassen Sie die Build-Pipeline optimierte Dateien in das öffentliche Asset-Verzeichnis kopieren.

Schritt 3: Fonts bei Bedarf subsetten

Subsetting bedeutet, Zeichen zu entfernen, die Sie nicht benötigen. Eine vollständige Schrift kann Latein, Kyrillisch, Griechisch, Vietnamesisch, Symbole und viele OpenType-Funktionen enthalten. Wenn Ihre englischsprachige Landingpage nur lateinische Zeichen braucht, kann ein Subset drastisch kleiner sein.

Es gibt zwei gängige Ansätze:

1. Ein vorgefertigtes Subset des Font-Anbieters oder Repositorys verwenden.
2. Ein eigenes Subset mit einem Font-Tool wie pyftsubset aus fonttools erzeugen.

Für viele Teams reichen vorgefertigte Latin-Subsets aus. Eigenes Subsetting ist nützlich, wenn Sie sehr eng begrenzte Seiten haben, etwa eine einzelne Kampagnenseite mit wenig Text oder eine Produktoberfläche mit vorhersehbarer Zeichenabdeckung.

Seien Sie bei mehrsprachigen Websites vorsichtig. Fehlende Glyphen führen zu Mischungen mit Fallback-Schriften, die kaputt wirken und die Lesbarkeit beeinträchtigen können. Wenn Sie mehrere Sprachen unterstützen, ordnen Sie Font-Subsets Sprachrouten zu, statt überall ein einziges winziges Subset zu erzwingen.

Schritt 4: Ihre @font-face-Regeln schreiben

Eine minimale lokale Konfiguration sieht so aus:

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-latin-400.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-latin-600.woff2") format("woff2");
  font-weight: 600;
  font-style: normal;
  font-display: swap;
}

body {
  font-family: "Inter", system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
}

Einige Details sind hier wichtig.

Verwenden Sie für die meisten Content-Websites font-display: swap. Damit weist der Browser schnell Fallback-Text aus und tauscht ihn gegen den Webfont aus, sobald dieser verfügbar ist. Das vermeidet die schlimmste Variante von FOIT: Flash of Invisible Text.

Legen Sie einen expliziten Fallback-Stack fest. Wenn die benutzerdefinierte Schrift fehlschlägt, sollten Nutzer trotzdem lesbaren Text erhalten. Fallbacks sind kein Nebengedanke; sie sind Teil des Designs. Wenn Sie Größen, Zeilenlängen und Fließtextentscheidungen überdenken müssen, beginnen Sie mit einem praxisnahen Leitfaden zu lesbarer Schrift im modernen Web.

Ordnen Sie Schriftschnitte korrekt zu. Wenn Ihr CSS font-weight: 500 anfordert, Sie aber nur 400 und 700 definieren, kann der Browser einen Zwischenschnitt synthetisieren. Das ist nicht immer schlimm, kann aber uneinheitlich aussehen.

Schritt 5: Die externen Google Fonts-Aufrufe entfernen

Nachdem Sie lokales Font-CSS hinzugefügt haben, entfernen Sie die alten Remote-Aufrufe aus Ihren Templates.

Suchen Sie nach:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?..." rel="stylesheet">

Prüfen Sie außerdem:

• Theme-Einstellungen in CMS-Plattformen
• Typografie-Panels in Page-Buildern
• Drittanbieter-Widgets
• Tag-Manager
• Alte CSS-Imports wie @import url('https://fonts.googleapis.com/...')

Der letzte Punkt ist häufig. CSS @import für Fonts ist meist schlechter für die Performance, weil es die Entdeckung verzögert. Wenn Sie selbst hosten, definieren Sie Fonts direkt in Ihrem Haupt-CSS oder in einer früh geladenen Font-CSS-Datei.

Datenschutzarbeit scheitert oft daran, dass Teams das offensichtliche Template korrigieren, aber Skripte, Widgets und Legacy-Embeds übersehen. Dasselbe Muster zeigt sich bei Consent-Arbeit; unser Leitfaden dazu, was sich 2026 bei Cookies geändert hat, ist eine hilfreiche Ergänzung, wenn Sie die Drittanbieterfläche insgesamt reduzieren.

Schritt 6: Cache-Header setzen

Font-Dateien sind statische Assets. Sie sollten aggressiv gecacht werden, wenn ihre Dateinamen versioniert oder per Content-Hash versehen sind.

Ein guter Produktions-Header ist:

Cache-Control: public, max-age=31536000, immutable

Verwenden Sie langlebiges Immutable-Caching nur, wenn sich die URL ändert, sobald sich die Datei ändert. Zum Beispiel:

inter-latin-400.a8f3c2.woff2

oder ein versionierter Pfad:

/fonts/v2/inter-latin-400.woff2

Wenn Sie /fonts/inter-latin-400.woff2 überschreiben, ohne die URL zu ändern, behalten manche Nutzer die alte Datei möglicherweise sehr lange. Das ist in Ordnung, bis es das nicht mehr ist. Versionierung vermeidet dieses Problem.

Liefern Sie Fonts außerdem mit dem korrekten MIME-Type aus:

Content-Type: font/woff2

Die meisten modernen Hosting-Plattformen erledigen das automatisch, aber eine Überprüfung lohnt sich.

Schritt 7: Nur den kritischen Font vorladen

Preloading kann dem Browser helfen, einen wichtigen Font früher zu entdecken:

<link rel="preload" href="/fonts/inter-latin-400.woff2" as="font" type="font/woff2" crossorigin>

Setzen Sie das sparsam ein. Laden Sie den primären Font für Text above the fold vor, nicht jeden Schriftschnitt. Zu viel Preloading konkurriert mit CSS, Bildern und JavaScript.

Fügen Sie auch bei Same-Origin-Fonts crossorigin zu Font-Preloads hinzu. Font-Fetching verwendet den CORS-Modus, und das Weglassen kann in manchen Setups zu doppelten Downloads führen.

Wenn Sie unsicher sind, testen Sie. Übernehmen Sie Preloads nicht blind, nur weil eine Checkliste es empfiehlt.

Schritt 8: Datenschutz und Performance testen

Das Testen ist unkompliziert.

Öffnen Sie DevTools, laden Sie die Seite mit deaktiviertem Cache neu und filtern Sie das Network-Panel nach:

• fonts.googleapis.com
• fonts.gstatic.com
• .woff2
• font

Sie sollten Font-Dateien sehen, die von Ihrer eigenen Domain ausgeliefert werden, und keine Google Fonts-Anfragen.

Testen Sie anschließend mit leerem Cache und mit warmem Cache. Beim ersten Besuch sollten Fonts einmal heruntergeladen werden. Bei späteren Besuchen sollten sie je nach Browser aus dem Memory- oder Disk-Cache kommen.

Prüfen Sie auf Layout-Verschiebungen, wenn der Font ausgetauscht wird. Wenn Überschriften springen, unterscheiden sich die Metriken Ihrer Fallback-Schrift zu stark vom Webfont. Sie können die sichtbare Verschiebung reduzieren, indem Sie eine passendere Fallback-Schrift wählen oder neuere CSS-Font-Metric-Overrides wie size-adjust, ascent-override, descent-override und line-gap-override verwenden. Diese sind fortgeschrittener, aber für ausgefeilte Oberflächen nützlich.

Testen Sie abschließend Seiten im privaten Browsing oder mit aktivierten Content-Blockern. Ein Vorteil des Self-Hostings ist, dass Datenschutztools Ihre Typografie weniger wahrscheinlich versehentlich blockieren.

Häufige Fehler vermeiden

Zu viele Schriftschnitte hosten

Das ist der häufigste Fehler. Zwei Schnitte reichen oft aus. Drei sind meist mehr als genug. Fünf sind ein Design-System-Warnsignal, sofern es keinen starken Grund gibt.

Kursivschriften vergessen

Wenn Ihre Inhalte echte Hervorhebungen verwenden, laden Sie eine echte Kursivdatei. Synthetische Kursivschrift kann schlecht aussehen, besonders in längeren redaktionellen Inhalten.

Den alten Google CSS-Link behalten

Das verfehlt den Zweck. Nach der Migration sollte keine Font-Anfrage an Google gehen, sofern nicht eine andere Komponente sie einfügt.

Fonts ohne langfristiges Caching ausliefern

Self-Hosting gibt Ihnen Kontrolle. Nutzen Sie sie. Fonts sind ideale Kandidaten für lange Cache-Laufzeiten.

Rechtliche und dokumentarische Arbeit ignorieren

Wenn Ihre Datenschutzerklärung zuvor Google Fonts oder das Laden von Fonts über Drittanbieter erwähnt hat, aktualisieren Sie sie nach der Migration. Wenn Sie ein Verzeichnis der Datenverarbeitung pflegen, aktualisieren Sie auch dieses. Die technische Änderung und die Compliance-Dokumentation sollten übereinstimmen.

<!-- tool-cta:start -->

💡 Probieren Sie Folgendes aus: Konvertieren Sie die TTF-Dateien, die Sie von Google Fonts heruntergeladen haben, in selbst hostbares WOFF2 plus CSS mit dem Webfont Generator.

<!-- tool-cta:end -->

Eine einfache Migrations-Checkliste

1. Listen Sie die Schriftfamilien, Schnitte, Stile und Schriftsysteme auf, die Sie tatsächlich verwenden.
2. Laden Sie WOFF2-Dateien herunter und bestätigen Sie die Lizenz.
3. Subsetten Sie Fonts, wenn die Website nur begrenzte Sprachanforderungen hat.
4. Fügen Sie lokale @font-face-Regeln mit font-display: swap hinzu.
5. Entfernen Sie alle Google Fonts-Verweise per link, preconnect und @import.
6. Liefern Sie Fonts von Ihrer eigenen Domain mit langlebigen Cache-Headern aus.
7. Laden Sie nur den wichtigsten above-the-fold Font vor, wenn Tests dafür sprechen.
8. Prüfen Sie in DevTools, dass keine Google Fonts-Anfragen verbleiben.
9. Aktualisieren Sie bei Bedarf Ihre Datenschutzdokumentation.

Fonts selbst zu hosten ist keine glamouröse Arbeit. Es ist die Art kleiner Infrastruktur-Bereinigung, die Abhängigkeitsrisiken reduziert, Ihre Datenschutzposition verbessert und Ihnen vorhersehbareres Rendering gibt. Das ist die ein oder zwei Stunden, die es normalerweise kostet, meist wert.