Jahrelang lief der Ablauf gleich ab: Schriftart beim Google Webfonts Helper aussuchen, ZIP herunterladen, CSS-Schnipsel kopieren, fertig. Genau dieser Weg funktioniert nicht mehr. Die Adresse google-webfonts-helper.herokuapp.com antwortet seit dem Ende der kostenlosen Heroku-Dynos mit einem nackten 404, ohne Weiterleitung, ohne Hinweis. Wer heute einer der vielen Anleitungen im Netz folgt, landet auf einer leeren Fehlerseite.
Diese Anleitung zeigt beide Wege: den schnellen über den Nachfolger und den, der ohne fremdes Werkzeug auskommt.
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
Google liefert das passende CSS selbst aus, und zwar über dieselbe Schnittstelle, die auch der Browser anfragt. Der Trick liegt im User-Agent: Fragt ein aktueller Browser an, kommt WOFF2 zurück, fragt ein alter an, kommt TTF.
Auf der Kommandozeile sieht das so aus:
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.cssIn fonts.css stehen jetzt fertige @font-face-Blöcke, einer je Zeichensatz, jeweils mit einer Adresse auf fonts.gstatic.com. Diese Dateien laden Sie herunter, legen sie neben Ihr Stylesheet und ersetzen die Google-Adressen durch Ihre eigenen Pfade. Wenn Sie den Weg ohne Kommandozeile gehen wollen: Dieselbe URL im Browser aufrufen liefert dasselbe Ergebnis, weil der Browser den passenden User-Agent ohnehin mitschickt.
Der Vorteil liegt darin, dass Sie an keinem Dienst hängen, der irgendwann abgeschaltet wird. Der Nachteil ist ein Arbeitsschritt mehr, weil die Dateien einzeln geholt werden müssen.
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.
