Google Fonts selbst hosten: die halbe Stunde, die einen Fremdzugriff spart

Am 24. August 2026 habe ich meinen eigenen Blog einmal durchgemessen: privates Fenster, Entwicklerwerkzeuge, mehrere Seitentypen. Cookies fand ich an diesem Tag keine — ein Nachtrag dazu steht weiter unten. Dafür etwas anderes. Bei jedem einzelnen Seitenaufruf lädt bloggen.xyz ein Stylesheet von fonts.googleapis.com und daraus zwei Schriftdateien von fonts.gstatic.com. Alle drei Aufrufe mit HTTP 200, sauber ausgeliefert, völlig unauffällig. Und trotzdem heißt das: Jeder Besucher spricht beim Lesen mit einem Server, der mir nicht gehört, und teilt ihm dabei seine IP-Adresse mit.

Das lässt sich abstellen, und zwar in ungefähr einer halben Stunde. Ohne Serverkonfiguration, ohne Umbau, der dir das Layout zerlegt. Du misst, was geladen wird, lädst genau diese Schriftschnitte herunter, legst sie ins Kindtheme, schreibst ein paar Zeilen CSS und meldest die alte Einbindung ab. Danach ist ein Fremdzugriff pro Seitenaufruf weg, und die Seite wird nebenbei eher schneller, weil eine DNS-Auflösung und eine zusätzliche Verbindung entfallen. Ich zeige dir jeden Schritt so, wie ich ihn gegangen bin, samt der Stelle, an der es bei jedem Theme anders aussieht.

Was meine Seite bei jedem Aufruf zu Google schickt

Drei Aufrufe, gemessen am 24. August 2026

Angefangen hat die Sache als Cookie-Zählung; aufgeschrieben habe ich sie in meinem Beitrag darüber, wie du Cookies selbst messen kannst. Die Antwort dort war: keine. Die Ausbeute lag im Netzwerk-Reiter. Das ist die Liste, die dort für Google stand:

Die aufgerufene Adresse war https://fonts.googleapis.com/css?family=Lora:400,700|Oswald:400. Wer genau hinsieht, bemerkt eine Unstimmigkeit: Angefordert werden drei Schnitte, heruntergeladen wurden zwei Dateien. Das ist kein Messfehler. Ein solches Stylesheet beschreibt alle angeforderten Schnitte, der Browser holt sich aber nur die Dateien, die auf der Seite tatsächlich vorkommen — der fette Lora-Schnitt kam dort nicht vor. Beschaffen würde ich trotzdem alle drei: Das Stylesheet fordert den Schnitt an, also kann er auf einer Seite auftauchen, die ich nicht gemessen habe. Ob er irgendwo tatsächlich verwendet wird, sagt die Messung dagegen nicht — genau das ist ja der Fall, den der Absatz hier beschreibt.

Der zweite Befund war die Herkunft: Die Einbindung stammt nicht aus einem Plugin, sondern aus dem Theme selbst — einem Kindtheme auf Basis des Genesis-Frameworks. Gut, weil ich an einer klar benannten Stelle eingreifen kann, statt eine Plugin-Liste durchzuprobieren.

Kein Cookie — und trotzdem eine Übertragung

Ein Punkt, der mich beim Messen überrascht hat: Bei diesen drei Aufrufen wurde kein einziges Cookie gesetzt. Mehr sagt meine Messung auch nicht — sie ist eine Momentaufnahme von zwei Hosts an einem Tag und keine allgemeine Aussage darüber, wie sich der Dienst überall und immer verhält. Wer seine Seite ausschließlich mit einem Cookie-Scanner abklopft, bekommt hier eine blitzsaubere Rückmeldung und lehnt sich zufrieden zurück. Genau das ist die Falle. Übertragen wird trotzdem etwas, nämlich die IP-Adresse des Besuchers, und zwar zwangsläufig — ohne Absender funktioniert keine Anfrage im Netz. Der Vorgang passiert außerdem, bevor der Besucher irgendetwas anklicken konnte.

Speichern und Übertragen sind eben zwei verschiedene Dinge. Ein Cookie legt etwas auf dem Endgerät ab. Eine eingebettete Schriftart tut das nicht — sie schickt eine Anfrage an einen fremden Server. Diese Unterscheidung ist der Grund, warum ich beim Aufräumen mit den Schriften angefangen habe und nicht mit einem Consent-Banner.

Nachtrag. Der Befund oben ist auf den 24. August 2026 datiert und inzwischen in einem Punkt überholt: Auf bloggen.xyz läuft mittlerweile ein Einwilligungsbanner, das Plugin Pressidium Cookie Consent. Es setzt ein Cookie namens pressidium_cookie_consent mit einer Laufzeit von 182 Tagen — allerdings erst, wenn im Banner eine Auswahl getroffen wurde. Wer die Seite nur aufruft und das Banner stehen lässt, bekommt weiterhin kein Cookie. An den Schriftaufrufen ändert das nichts; sie sind der Grund für diesen Beitrag und laufen unabhängig von jedem Banner.

Die halbe Stunde: messen, beschaffen, einbauen

Schritt 1 bis 3: herausfinden, herunterladen, ablegen

Schritt 1 — herausfinden, was überhaupt geladen wird. Lade deine Seite in einem privaten Fenster neu, öffne die Entwicklerwerkzeuge und wirf in der Konsole diese Zeile ab. Sie liest die Performance-API des Browsers aus und filtert alles heraus, was nicht nach Google aussieht:

performance.getEntriesByType('resource').map(r => r.name).filter(n => /googleapis|gstatic/.test(n))

Heraus kommt eine Liste vollständiger URLs. In der Adresse zu fonts.googleapis.com steht hinter family= alles, was du wissen musst: die Schriftfamilien und die angeforderten Schnitte. Notiere sie dir wörtlich — bei mir Lora in 400 und 700 sowie Oswald in 400. Wiederhole die Messung auf mehreren Seitentypen, denn manche Einbindung taucht nur auf einer Unterseite auf. Ist das Ergebnis leer, bist du bereits fertig.

Schritt 2 — die Schriften beschaffen. Die Familien lassen sich bei fonts.google.com direkt herunterladen. Wichtig ist hier die Disziplin: nur die Schnitte, die du in Schritt 1 notiert hast. Jeder zusätzliche ist eine zusätzliche Datei, die deine Besucher übertragen — und der Reiz, die ganze Familie sicherheitshalber mitzunehmen, ist erstaunlich groß.

Wichtig ist, was dabei herauskommt: Der Download-Knopf liefert ein ZIP-Archiv mit TrueType-Dateien, also Dateien mit der Endung .ttf. Das ist das Format, in dem die Schriften im Katalog liegen — im offiziellen Repository von Google Fonts steht ausdrücklich, dass jedes Familienverzeichnis die ttf-Dateien enthält. Eine fertige woff2-Datei bekommst du dort also nicht.

Der Schritt, den viele Anleitungen unterschlagen: aus ttf wird woff2. Die @font-face-Regel in Schritt 4 verweist auf eine Datei im Format woff2, und das aus gutem Grund — woff2 ist eigens fürs Web gemacht und stärker komprimiert als dieselbe Schrift als ttf. Zwischen Download und Einbau liegt deshalb eine Umwandlung: Jede ttf-Datei, die du behalten willst, wandelst du in eine woff2-Datei um. Werkzeuge dafür gibt es, im Browser wie auf der Kommandozeile; ich nenne dir hier bewusst keines, weil ich für diesen Beitrag keines davon geprüft habe. Am Ende soll pro Schnitt genau eine woff2-Datei übrig bleiben, die ttf-Dateien aus dem Archiv brauchst du daneben nicht.

Und noch etwas gehört in diesen Schritt: die Lizenz. Wer eine fremde Schrift selbst ausliefert, verbreitet sie — und was dabei erlaubt ist, steht in der Lizenz der jeweiligen Schrift und nirgends sonst. Die Schriften im Google-Fonts-Katalog stehen nicht alle unter derselben Lizenz; im Repository heißt es dazu ausdrücklich, man solle die Lizenz jeder Schrift lesen, die man benutzt, und zu jeder Familie liege die passende Lizenzdatei bei. Auf der Seite der jeweiligen Schrift ist die Lizenz ebenfalls ausgewiesen. Wirf einen Blick darauf, bevor du die Dateien auf deinen Server legst — es dauert eine Minute.

Schritt 3 — ins Kindtheme legen. Ich habe im Kindtheme einen Ordner fonts/ angelegt und die Dateien dort abgelegt. Kindtheme, nicht Elternthema: Alles, was du im Elternthema anfasst, ist beim nächsten Update weg. Wer noch nie per FTP im Theme-Verzeichnis unterwegs war, findet den Ablauf im Kleinen in meinem Beitrag über das Anlegen einer PHP-Info-Datei.

Schritt 4: die font-face-Regeln schreiben

Jetzt muss dem Browser gesagt werden, wo die Schriften liegen. Das erledigt eine @font-face-Regel pro Schnitt, die du oben in die style.css deines Kindthemes schreibst. So sieht sie für einen einzelnen Schnitt vollständig aus:

@font-face {
  font-family: 'Lora';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url('fonts/lora-400.woff2') format('woff2');
}

Diese Regel wiederholst du für jeden weiteren Schnitt und passt drei Dinge an: font-family auf den Familiennamen, font-weight auf den Schnitt — 700 für fett — und den Dateinamen in src. Der Pfad ist relativ zur style.css, in der die Regel steht; liegt der Ordner fonts/ daneben, stimmt er genau so.

Zwei Angaben verdienen einen eigenen Satz. format('woff2') sagt dem Browser, was ihn erwartet, damit er nichts herunterlädt, das er nicht lesen kann. Und font-display: swap sorgt dafür, dass dein Text sofort in einer Ersatzschrift erscheint und beim Eintreffen der Datei ausgetauscht wird, statt kurz unsichtbar zu bleiben. Was die einzelnen Werte bewirken, beschreibt die Dokumentation zu font-display bei MDN.

Die alte Einbindung abmelden — und das Handle finden

Schritt 5: abmelden, aber unter welchem Namen?

Jetzt liegen die Schriften lokal — und der Aufruf zu Google läuft trotzdem weiter, weil ihn niemand abbestellt hat. WordPress verwaltet Stylesheets in einer Warteschlange, und jedes hat darin einen Namen, das sogenannte Handle. Beim Genesis-Framework wird das Google-Fonts-Stylesheet an einem solchen Handle registriert, das im Kindtheme vergeben wird. Hier scheitern die meisten Anleitungen im Netz: Das Handle heißt bei jedem Theme anders. Ich schreibe dir deshalb bewusst keinen Namen hin, den du kopierst und der bei dir ins Leere greift. Du musst ihn ermitteln, und dafür gibt es zwei Wege.

Der erste ist der schnellere: Durchsuche die Dateien deines Kindthemes — allen voran die functions.php — nach den Zeichenketten wp_enqueue_style und fonts.googleapis. Der erste Parameter des Aufrufs ist das Handle. Meistens ist die Sache damit in zwei Minuten erledigt.

Der zweite hilft, wenn die Suche nichts findet: Lass dir alle Handles ausgeben, die tatsächlich in der Warteschlange stehen. Diese Zeilen kommen vorübergehend in die functions.php des Kindthemes und schreiben die Liste als Kommentar in den Quelltext:

add_action( 'wp_enqueue_scripts', function () {
    echo '<!-- ' . implode( ', ', $GLOBALS['wp_styles']->queue ) . ' -->';
}, 999 );

Seite aufrufen, Quelltext anzeigen, den Kommentar suchen. Dort stehen die Handles nebeneinander, die auf dieser Seite tatsächlich in der Warteschlange stehen, und in aller Regel springt dir das richtige sofort ins Auge. Auf die Unterscheidung kommt es hier an: $GLOBALS['wp_styles']->queue enthält die eingereihten Handles, also die Stylesheets, die auf dieser Seite auch ausgegeben werden — alle angemeldeten Handles stünden dagegen in ->registered, und darunter sind auch solche, die gerade gar nicht ausgeliefert werden. Diese Zeilen sind ein Werkzeug, keine Dauerlösung — nimm sie wieder heraus, sobald du das Handle notiert hast.

Mit dem Namen in der Hand ist das Abmelden unspektakulär. Die Funktion hängt an wp_enqueue_scripts mit später Priorität, damit sie nach der Registrierung durch das Theme läuft — meldest du zu früh ab, ist noch gar nichts da, was du abmelden könntest:

add_action( 'wp_enqueue_scripts', 'bx_google_fonts_abmelden', 100 );

function bx_google_fonts_abmelden() {
    wp_dequeue_style( 'HIER-DEIN-HANDLE' );
    wp_deregister_style( 'HIER-DEIN-HANDLE' );
}

wp_dequeue_style() nimmt das Stylesheet aus der Ausgabewarteschlange, wp_deregister_style() entfernt zusätzlich die Registrierung, sodass es nicht als Abhängigkeit eines anderen Stylesheets wieder hereinkommt. Beides steht in der Funktionsreferenz bei developer.wordpress.org, ebenso der Zeitpunkt, an dem der Hook wp_enqueue_scripts feuert.

Schritt 6 und 7: nachmessen und Datenschutzerklärung

Schritt 6 — nachmessen. Der Teil, den man am liebsten überspringt, und genau der ist der wichtigste. Lade die Seite im privaten Fenster neu und wirf dasselbe Schnipsel wie in Schritt 1 in die Konsole:

performance.getEntriesByType('resource').map(r => r.name).filter(n => /googleapis|gstatic/.test(n))
// erwartetes Ergebnis nach dem Umbau: []

Ein leeres Array ist der Beleg. Kommt noch etwas zurück, hast du entweder das falsche Handle erwischt, oder eine zweite Einbindung sitzt woanders — in einem Plugin oder in einem eingebetteten Element. Prüfe auf mehreren Seitentypen, nicht nur auf der Startseite. Und schau gleich, ob die Schriften noch richtig aussehen: Erscheint plötzlich alles in der Systemschrift, stimmt der Pfad in src nicht.

Schritt 7 — Datenschutzerklärung anpassen. Dort steht oft ein Absatz zu Google Fonts, meist aus einem Generator übernommen. Sobald die Einbindung weg ist, beschreibt er einen Vorgang, den es nicht mehr gibt. Ein Dokument, das etwas Falsches behauptet, hilft niemandem — auch dann nicht, wenn das Falsche zu deinen Gunsten falsch ist.

Was das bringt — und was es nicht erledigt

Eine Verbindung weniger, ein Abhängiger weniger

Der Nebeneffekt wird meist unterschätzt. Damit ein Browser eine Datei von fonts.gstatic.com holen kann, muss er erst den Namen auflösen, dann eine Verbindung aufbauen und absichern — alles, bevor das erste Byte der Schrift fließt. Fällt der fremde Host weg, entfällt dieser Vorlauf: Die Schrift liegt auf demselben Server wie der Rest der Seite. Wie viele Millisekunden das bei dir ausmacht, hängt von Verbindung, Gerät und Standort ab; ich nenne keine Zahl, die ich nicht auf deiner Seite gemessen habe. Die Richtung ist aber eindeutig.

Dazu kommt die Unabhängigkeit. Bei derselben Messung fand ich ein Werbebanner, das mit HTTP 503 antwortete: Der fremde Server war nicht bereit, das Bild kam nie an, der Fremdzugriff fand trotzdem statt. Jede Einbindung von außen ist ein Stück deiner Seite, über das du nicht bestimmst — und solche Kleinigkeiten findet man nur, wenn man den eigenen Laden gelegentlich von außen betrachtet, wie in meiner Liste der SEO-Fehler im eigenen Blog.

Und ja, es gibt Plugins, die dir den Umbau abnehmen: Schriften erkennen, herunterladen, lokal ausliefern, die Einbindung umbiegen. Namen nenne ich bewusst keine, weil ich für diesen Beitrag keines davon geprüft habe. Wenn du diesen Weg gehst, gilt Schritt 6 unverändert: nachmessen. Ein Plugin, das im Backend meldet, es sei alles erledigt, ist kein Beleg — das leere Array in der Konsole ist einer. Was ich sonst benutze, steht bei den Blogger-Tools.

Der rechtliche Teil, kurz gehalten

Ein Absatz dazu, mehr nicht, und ausdrücklich vorweg: Das ist keine Rechtsberatung. In diesem Blog schreibe ich als Blogbetreiber, nicht in beruflicher Eigenschaft; dieser Beitrag beschreibt einen technischen Vorgang und nimmt keine rechtliche Bewertung eines Einzelfalls vor. Über die Einbindung von Schriften über einen fremden Server wird seit Jahren diskutiert, es gibt dazu Rechtsprechung, und ich nenne hier weder Aktenzeichen noch Beträge — wer wissen will, was das für seinen eigenen Fall bedeutet, braucht eine Prüfung dieses Falls und keinen Blogbeitrag. Was ich ohne Verrenkung sagen kann: Solange die Einbindung läuft, findet eine Übertragung an einen Dritten statt, und solange gehört sie in die Datenschutzerklärung. Und umgekehrt behaupte ich nicht, dass Selbsthosten alle rechtlichen Fragen abschließend erledigt. Es beseitigt einen konkreten, messbaren Vorgang. Nicht mehr, aber eben auch nicht weniger — und das für eine halbe Stunde Arbeit.

Häufige Fragen zu Google Fonts

Fragen zum Umbau

Fragen zu Technik und Wirkung