Ihre Website lädt Schriften von Google und Sie wollen das abstellen. Der Weg dorthin ist kurz: Schriftdateien einmal herunterladen, auf den eigenen Server legen, im CSS die Adressen austauschen. Eine halbe Stunde Arbeit, auch ohne Entwickler.
Nur stimmt die Anleitung nicht mehr, die im Netz überall dafür steht. Fast alle verweisen auf den Google Webfonts Helper unter google-webfonts-helper.herokuapp.com, und diese Adresse antwortet seit dem Ende der kostenlosen Heroku-Dynos mit einem nackten 404. Ohne Weiterleitung, ohne Hinweis.
Hier stehen beide Wege: der schnelle über den Nachfolger und der, der ohne fremdes Werkzeug auskommt. Dazu die Frage, die dabei fast immer aufkommt, nämlich ob man die Schriften am Ende nicht doch wieder bei Google holt.
Was mit dem Webfonts Helper passiert ist
Das Projekt von Mario Ranftl gibt es weiter, es ist nur umgezogen. Die neue Adresse lautet gwfh.mranftl.com und funktioniert wie früher. Alte Links darauf laufen ins Leere, weil unter der Heroku-Adresse nichts mehr steht, was weiterleiten könnte.
Ein Detail aus der Projektbeschreibung sollte man kennen, bevor man eine Anleitung auf diesen Dienst stützt: Der Entwickler schreibt selbst, der Service laufe „mostly on life-support", der Code und die Abhängigkeiten seien größtenteils veraltet. Das ist kein Vorwurf, sondern ein ehrlicher Hinweis von jemandem, der ein nützliches Werkzeug seit über zehn Jahren kostenlos betreibt. Für die eigene Website heißt es trotzdem: Der zweite Weg unten ist der haltbarere.
Ob Ihre Seite überhaupt betroffen ist, klärt sich in zehn Sekunden: Unser Google Fonts Checker liest den Quelltext aus und zeigt jede Verbindung zu Googles Servern, ohne Anmeldung.
Weg 1: über den Nachfolger
Auf gwfh.mranftl.com suchen Sie die Schriftfamilie, wählen die Zeichensätze und Schnitte aus und laden das ZIP. Die Seite zeigt darunter fertiges CSS mit den passenden @font-face-Regeln.
Zwei Punkte, an denen dabei oft etwas schiefgeht. Erstens: Wählen Sie nur die Schnitte, die Sie wirklich verwenden. Jede zusätzliche Stärke ist eine eigene Datei, die geladen werden will. Für die meisten Websites reichen Regular und Bold, oft noch Italic. Zweitens: Beim Zeichensatz genügt fast immer latin. Wer latin-ext, cyrillic und greek mitnimmt, lädt Zeichen aus, die auf einer deutschen Seite nie erscheinen.
Das Formular bietet unten mehrere Varianten des CSS an. Nehmen Sie „Modern Browsers", das liefert reines WOFF2. Die älteren Formate EOT, TTF und SVG brauchen Sie nur, wenn Sie den Internet Explorer bedienen müssen.
Weg 2: ohne fremdes Werkzeug
Für den Download brauchen Sie gar kein fremdes Werkzeug. Google liefert das passende CSS selbst aus, über dieselbe Schnittstelle, die auch jeder Browser anfragt.
Der einfachste Weg führt über die Adresszeile. Tippen Sie diese Adresse in den Browser, mit Ihrer Schrift statt Inter:
https://fonts.googleapis.com/css2?family=Inter:wght@400;700&display=swapWas Sie dann sehen, ist fertiges CSS: ein @font-face-Block je Zeichensatz, jeweils mit einer Adresse auf fonts.gstatic.com. Diese Adressen rufen Sie einzeln auf und speichern die Schriftdateien. Danach kommt der entscheidende Schritt, dazu gleich mehr.
Wer lieber auf der Kommandozeile arbeitet, erledigt dasselbe in einer Zeile:
curl -A "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) \
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36" \
"https://fonts.googleapis.com/css2?family=Inter:wght@400;700&display=swap" \
> fonts.cssDer -A-Teil ist wichtiger, als er aussieht. Er gibt sich als aktueller Browser aus, und nur dann liefert Google WOFF2. Nennt man stattdessen einen alten Browser, kommt TTF zurück. Daher stammt der Satz, den man in vielen Anleitungen liest, bei Google gebe es nur TrueType.
Der Vorteil dieses Weges: Sie hängen an keinem Dienst, der irgendwann abgeschaltet wird. Der Nachteil: ein Arbeitsschritt mehr, weil die Dateien einzeln geholt werden.
Aber hole ich die Schriften dann nicht doch bei Google?
Doch. Einmal. Genau darin liegt der Unterschied.
Im Münchner Urteil ging es nicht darum, dass die Schriften von Google stammen. Es ging darum, dass der Browser jedes Besuchers bei jedem Aufruf eine Verbindung zu Google aufbaut und dabei dessen IP-Adresse mitschickt. Tausend Besucher, tausend fremde IP-Adressen, und geradestehen müssen Sie dafür.
Laden Sie die Dateien einmal selbst herunter, gibt es genau eine Verbindung, und die kommt von Ihrem Rechner. Ihre eigene IP-Adresse ist Ihre Sache. Danach liegen die Dateien auf Ihrem Server, und kein Besucher spricht je wieder mit Google.
Denken Sie an einen Bäcker. Sie können hundert Brötchen kaufen und in Ihren Laden legen, dann hat der Bäcker nur Sie gesehen. Oder Sie schicken jeden Kunden einzeln hin, dann sieht er jeden Einzelnen. Das Brötchen ist beide Male dasselbe.
Erlaubt ist es ausdrücklich. Google schreibt im eigenen Schriften-Repository: „Since all the fonts available here are licensed with permission to redistribute, subject to the license terms, you can self-host."
Der Google Webfonts Helper macht übrigens nichts anderes. Er holt die Dateien bei Google und reicht sie weiter, nur von seinem Server statt von Ihrem Rechner.
Der eine Fehler, der alles zunichtemacht
Im CSS, das Google ausliefert, stehen vollständige Adressen auf fonts.gstatic.com. Wer diesen Block ins eigene Stylesheet kopiert und die Adressen stehen lässt, hat nichts gewonnen. Der Besucher lädt weiter bei Google, nur über eine andere Adresse.
Fertig ist die Umstellung erst, wenn in Ihrem CSS keine einzige Google-Adresse mehr steht. Wie das aussieht, zeigt der nächste Abschnitt.
Die @font-face-Regel
So sieht ein fertiger Block aus, nachdem die Adressen ersetzt wurden:
@font-face {
font-family: 'Inter';
font-style: normal;
font-weight: 400;
font-display: swap;
src: url('/fonts/inter-400.woff2') format('woff2');
unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC,
U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193;
}Die Zeile unicode-range ist der Grund, warum man das Google-CSS nicht kürzen sollte. Sie sagt dem Browser, welche Zeichen in dieser Datei stecken. Steht auf der Seite kein einziges kyrillisches Zeichen, lädt der Browser die kyrillische Datei gar nicht erst. Wer die Zeile streicht, verschenkt genau diese Ersparnis.
font-display: swap sorgt dafür, dass der Text sofort mit einer Ersatzschrift erscheint und beim Nachladen umgeschaltet wird. Ohne die Angabe bleibt der Text bis zu drei Sekunden unsichtbar. Welche Kompromisse dabei zwischen unsichtbarem und springendem Text bestehen, steht ausführlich im Beitrag über Font Loading und FOUT.
Ein Preload lohnt sich für die eine Schrift, die im sichtbaren Bereich steht, also meist die Regular-Variante der Fließtextschrift:
<link rel="preload" href="/fonts/inter-400.woff2" as="font"
type="font/woff2" crossorigin>Mehr als eine oder zwei Dateien sollten Sie nicht vorladen. Jeder Preload konkurriert mit dem Stylesheet um Bandbreite, und drei vorgeladene Schnitte machen die Seite langsamer statt schneller.
WordPress: wo die Fonts wirklich herkommen
Bei WordPress liegt die Einbindung selten im eigenen Code. Themes laden Schriften über wp_enqueue_style, Page Builder bringen eigene Bibliotheken mit, und einzelne Plugins holen sich für ein paar Symbole eine komplette Schriftfamilie. Der Checker zeigt, welche URL geladen wird, aber nicht, wer sie angefordert hat.
Der schnellste Weg zur Quelle führt über die Suche im Dateisystem des Themes und der Plugins nach fonts.googleapis.com. Was Sie dort finden, verrät den Verursacher. In vielen Themes gibt es dafür einen Schalter im Customizer, bei Elementor und Divi sitzt er in den Performance-Einstellungen.
Nach dem Abschalten laden Sie Ihre Schriften über eine eigene CSS-Datei nach, die im Child-Theme liegt. Wer das nicht selbst anfassen will, findet die weiteren Fallstricke im Beitrag über WordPress und DSGVO.
Prüfen Sie nach jedem Theme- oder Plugin-Update erneut. Updates setzen die Einstellung gerne zurück, und niemand merkt es, weil sich optisch nichts ändert. Der Google Fonts Checker erlaubt zehn Prüfungen pro Minute, das reicht für eine Runde über die wichtigsten Seiten.
TYPO3, Joomla, Shopware
Bei TYPO3 stehen die Schriften meist im Site-Package, entweder im TypoScript unter page.includeCSS oder direkt im Fluid-Layout. Joomla-Templates binden Google Fonts häufig in index.php des Templates ein, Cassiopeia zusätzlich über die Template-Optionen. Shopware 6 erwartet die Dateien im Theme unter src/Resources/app/storefront/dist/assets, eingebunden über die SCSS-Variablen des Themes.
In allen drei Fällen gilt dasselbe wie bei WordPress: erst die Quelle finden, dann abschalten, dann lokal nachladen. Die Reihenfolge umzudrehen führt dazu, dass beide Varianten parallel laden.
Kontrolle: hat es funktioniert?
Nach der Umstellung gehört ein zweiter Blick dazu, denn ein Cache kann die alte Version noch ausliefern. Zwei Prüfungen genügen. Im Browser öffnen Sie die Entwicklerwerkzeuge, laden die Seite neu und filtern die Netzwerkanfragen nach google. Es darf keine Zeile übrig bleiben.
Der zweite Blick geht auf die Unterseiten. Erfahrungsgemäß ist die Startseite sauber, während ein Kontaktformular oder eine Buchungsseite noch die alte Einbindung mitbringt. Genau diese Seiten sind es, die später jemandem auffallen. Warum daran auch die Haftung hängt, steht im Beitrag über Google Fonts und die DSGVO.
