Webfonts optimieren: Ladezeit und Layout Shifts reduzieren

Webfonts können eine Website ausbremsen, obwohl Bilder, Caching und JavaScript bereits optimiert sind. Häufige Ursachen sind unnötige Schriftschnitte, doppelte Einbindungen, große Zeichensätze oder eine Ladestrategie, die Text zu lange verbirgt. Gute Font-Optimierung besteht deshalb nicht aus einer einzelnen CSS-Regel: Du misst zuerst die tatsächlich geladenen Dateien und stimmst danach Format, Umfang, Priorisierung und Fallbacks aufeinander ab.

Dieser Leitfaden zeigt Dir einen systematischen Ablauf: vom Font-Audit in den Browser-Entwicklertools über WOFF2 und Subsetting bis zu font-display, Preload und angepassten Fallback-Metriken. Ziel ist nicht die kleinstmögliche Datei um jeden Preis, sondern eine stabile, gut lesbare Website ohne unnötige Requests und sichtbare Layoutverschiebungen.

Mit einem Font-Audit die tatsächlichen Downloads ermitteln

Beginne nicht mit dem Konvertieren einzelner Dateien, sondern mit einer Bestandsaufnahme. CSS-Deklarationen allein reichen nicht aus: Ein Stylesheet kann viele @font-face-Regeln enthalten, von denen der Browser auf einer konkreten Seite nur einen Teil anfordert. Umgekehrt können Theme, Plugin, Page Builder und eigenes CSS dieselbe Schrift unabhängig voneinander laden.

Öffne die Website in den Chrome DevTools, wechsle zum Tab „Network“, aktiviere während der Prüfung „Disable cache“ und lade die Seite neu. Filtere nach „Font“ beziehungsweise nach .woff2 und .woff. Dokumentiere Dateiname, Domain, übertragene Größe, Ladezeit und Initiator. Der Initiator zeigt häufig, welches Stylesheet oder Script die Datei angefordert hat. Prüfe zusätzlich im Bereich „Computed“ beziehungsweise „Rendered Fonts“, welche konkrete Font-Datei und welcher Schnitt ein Textelement tatsächlich rendert.

Ein einfacher Diagnosepfad spart Zeit: Führt eine Anfrage zu einer externen Domain, prüfst Du zuerst ihren Initiator und deaktivierst die Einbindung testweise an der Quelle. Haben vermeintlich gleiche Dateien abweichende URLs, suchst Du nach CDN-Pfaden, Query-Parametern oder doppelten Build-Ausgaben. Werden ungenutzte Schnitte geladen, bereinigst Du @font-face-Regeln und die Font-Konfiguration von Theme oder Builder.

Prüfe außerdem verschiedene Viewports und Zustände. Eine mobile Navigation, ein erst später geöffnetes Modal oder ein Formular kann weitere Fonts laden. Ein Audit nur auf der Desktop-Startseite übersieht solche Anfragen. Die Coverage-Funktion der DevTools hilft ergänzend bei der Suche nach ungenutztem CSS, misst aber nicht zuverlässig, welche einzelnen Glyphen einer Font-Datei benötigt werden. Die offizielle Chrome-Anleitung zur Coverage-Funktion beschreibt den Prüfablauf.

Wie Webfonts FCP, LCP und CLS beeinflussen

Fonts wirken nicht automatisch auf jede Performance-Kennzahl gleich. Beim First Contentful Paint, kurz FCP, ist entscheidend, ob der Browser Text früh mit einer Ersatzschrift darstellen darf oder ihn während einer Blockphase unsichtbar hält. Ein längerer unsichtbarer Zustand wird als FOIT bezeichnet: „Flash of Invisible Text“.

Für den Largest Contentful Paint, kurz LCP, sind Webfonts besonders relevant, wenn das größte sichtbare Element eine Überschrift oder ein großer Textblock ist. Sie können den LCP auch indirekt verschlechtern, wenn viele Font-Downloads früh mit dem LCP-Bild oder kritischem CSS um Bandbreite konkurrieren. Wie die Kennzahlen zusammenhängen, erklärt der Überblick zu den Core Web Vitals.

Beim FOUT, dem „Flash of Unstyled Text“, erscheint zunächst die Ersatzschrift und wird später ausgetauscht. Das ist meist besser als lange unsichtbarer Text, kann aber Überschriften umbrechen, Buttons verbreitern oder nachfolgende Inhalte verschieben. Kritisch ist nicht jeder sichtbare Schriftwechsel, sondern vor allem eine geometrische Veränderung des Layouts.

Bewerte deshalb nicht nur einen einzelnen PageSpeed-Wert. Zeichne im Performance-Panel einen Seitenaufruf auf und untersuche, wann Fonts geladen werden und ob beim Austausch Layout-Shift-Ereignisse entstehen. Ergänze Labormessungen durch reale Nutzerdaten aus PageSpeed Insights, sofern sie für die geprüfte URL verfügbar sind.

Systemfonts, lokale Webfonts oder externe Dienste wählen

Die schnellste Font-Datei ist diejenige, die gar nicht übertragen werden muss. Ein System-Font-Stack greift auf bereits installierte Schriften zurück und eignet sich für Projekte, bei denen Ladezeit, Robustheit und eine native Darstellung wichtiger sind als eine plattformübergreifend identische Typografie. Das Erscheinungsbild kann sich jedoch zwischen Betriebssystemen unterscheiden.

Selbst gehostete Webfonts bieten mehr Kontrolle über Dateien, Cache-Header, Subsets und Ladeverhalten. Externe Font-Dienste reduzieren teilweise den Einrichtungsaufwand, verursachen jedoch zusätzliche Verbindungen und geben Dir weniger Kontrolle über Auslieferung und Änderungen. Datenschutz und Lizenzbedingungen müssen unabhängig von der Performance geprüft werden.

Unabhängig von der Quelle solltest Du die typografische Auswahl reduzieren. Viele Websites benötigen im Fließtext nur Regular und Bold. Ein Semibold-Schnitt für Überschriften kann sinnvoll sein; Thin, Light, ExtraBold und mehrere Kursivvarianten bleiben dagegen oft ungenutzt. Ob browserseitig simulierte Fett- oder Kursivdarstellung akzeptabel ist, entscheidest Du anhand einer visuellen Prüfung.

Bei variablen Fonts liegen mehrere Gewichte oder andere Achsen in einer Datei. Das kann viele einzelne Dateien ersetzen, ist aber nicht pauschal kleiner. Benötigst Du nur zwei feste Schnitte, können zwei gezielt reduzierte statische Dateien effizienter sein. Vergleiche daher die tatsächlich übertragenen Bytes statt nur die Anzahl der Requests.

WOFF2, Subsetting und Zeichenbereiche richtig einsetzen

Für moderne Websites ist WOFF2 das bevorzugte Auslieferungsformat. Es wurde speziell für komprimierte Webfonts entwickelt und zielt laut W3C-Spezifikation auf eine bandbreiteneffiziente Übertragung. Alte Formate wie TTF oder OTF sollten nicht allein deshalb öffentlich ausgeliefert werden, weil sie als Quelldatei vorliegen. Ob Du zusätzliche Fallback-Formate brauchst, hängt von den unterstützten Browsern Deines Projekts ab.

Subsetting entfernt nicht benötigte Glyphen aus einer Schriftdatei. Das ist besonders wirkungsvoll bei Fonts mit vielen Schriftsystemen. Ein zu aggressives Latin-Subset kann jedoch Umlaute, typografische Zeichen, Währungen oder Buchstaben internationaler Namen verlieren. Dann zeigt der Browser einzelne Zeichen aus einer anderen Schrift an oder erzeugt auffällige Lücken im Schriftbild.

Mit unicode-range kannst Du mehrere Subsets derselben Familie definieren. Der Browser lädt dann nur die Datei, deren Zeichenbereich für den Seiteninhalt benötigt wird. Die Bezeichnungen von Font-Anbietern sind nicht immer einheitlich: Deutsche Umlaute liegen technisch im Bereich U+00A0-00FF, der je nach Anbieter im Latin- oder erweiterten Subset enthalten sein kann. Entscheidend ist daher nicht der Dateiname, sondern der tatsächlich deklarierte Zeichenbereich und Dein Testtext.

Das folgende Beispiel trennt einen Grundzeichensatz von zusätzlichen lateinischen Zeichen. Es ist nur sinnvoll, wenn die Dateien wirklich passend erstellt wurden und beide Dateien dieselbe Familie, Gewichtung und Stilvariante abbilden:

@font-face {
  font-family: "Markenfont";
  src: url("/fonts/markenfont-regular-latin.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
  unicode-range: U+0000-00FF;
}

@font-face {
  font-family: "Markenfont";
  src: url("/fonts/markenfont-regular-latin-ext.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
  unicode-range: U+0100-024F, U+0259, U+1E00-1EFF, U+2020, U+20A0-20AB;
}

Prüfe nach dem Subsetting Navigation, Preise, Formulare, Fehlermeldungen, rechtliche Seiten und Inhalte aus dem CMS. Ersetze außerdem große Icon-Fonts, wenn nur wenige Symbole daraus verwendet werden. Einzelne optimierte SVGs sind häufig leichter kontrollierbar, benötigen keine private Zeichenbelegung und vermeiden leere Kästchen bei einem fehlgeschlagenen Font-Download.

Preload und font-display passend priorisieren

Ein Font-Preload weist den Browser früh auf eine wichtige Schriftdatei hin. Sinnvoll ist das vor allem für eine WOFF2-Datei, die mit hoher Wahrscheinlichkeit direkt im sichtbaren Bereich gebraucht wird und sonst erst spät über CSS entdeckt würde. Ein typischer Preload für einen kritischen Schnitt sieht so aus:

<link rel="preload"
      href="/fonts/markenfont-regular.woff2"
      as="font"
      type="font/woff2"
      crossorigin>

Die URL muss exakt mit der späteren @font-face-Anfrage übereinstimmen. Auch der CORS-Modus muss konsistent sein, damit der Browser die Ressource nicht doppelt abruft. Teste das Ergebnis im Network-Tab: Ein Preload ist nur sinnvoll, wenn die vorgeladene Datei auf der jeweiligen Seite tatsächlich früh verwendet wird.

Preload ist keine allgemeine Auszeichnung für alle Fonts. Jede vorgeladene Datei konkurriert mit Stylesheets, Bildern und anderen kritischen Ressourcen. Lade daher nicht sämtliche Gewichte, Kursivvarianten und Subsets vor. Häufig genügt ein kritischer Regular-Schnitt oder die Schrift einer sichtbaren Hauptüberschrift. Der Google-Leitfaden zu optimierten Webfonts ordnet Self-Hosting, Formate und Ressourcenpriorisierung gemeinsam ein.

Die tatsächliche Dauer von Block- und Austauschphasen ist browserabhängig. Die Werte sind daher strategische Hinweise, keine garantierten Zeitvorgaben. Für Fließtext ist swap ein robuster Ausgangspunkt, sofern der Fallback metrisch gut passt. Bei markenprägenden Überschriften kann fallback nach einem realen Test sinnvoll sein, löst aber nicht automatisch sichtbare Wechsel oder Layout Shifts.

optional priorisiert Stabilität und Geschwindigkeit stärker, akzeptiert aber, dass der Markenfont bei einem Seitenaufruf möglicherweise nicht erscheint. Icon-Fonts solltest Du nicht über font-display absichern: Fehlen Symbole während des Ladens, kann die Bedienbarkeit leiden. Für einzelne Symbole sind SVGs meist die robustere Alternative. Die genauen Phasen dokumentiert die MDN-Referenz zu font-display.

preconnect kann bei bewusst extern geladenen Fonts den Verbindungsaufbau vorbereiten. Bei lokalen Fonts auf derselben Origin ist es normalerweise nicht erforderlich. Self-Hosting beseitigt außerdem nicht automatisch jedes Performance-Problem: Eine lokale, aber große und unnötig früh geladene Datei bleibt eine große und unnötig früh geladene Datei.

Nutze Preload deshalb erst, nachdem Du unnötige Familien, Gewichte und Quellen entfernt hast. Erst dann lässt sich beurteilen, ob die verbleibende kritische Schrift wirklich einen frühen Prioritätshinweis benötigt.

Fallback-Metriken gegen schriftbedingte Layout Shifts

Ein Fallback sollte dem Webfont nicht nur optisch ähneln. Entscheidend sind Zeichenbreite, x-Höhe, Auf- und Abstieg sowie der Zeilenabstand. Schon geringe Abweichungen können einen Zeilenumbruch verändern. Bei einer großen Überschrift reicht ein zusätzliches Wort in der zweiten Zeile, um alle darunterliegenden Inhalte zu verschieben.

CSS bietet dafür die Deskriptoren size-adjust, ascent-override, descent-override und line-gap-override. Du definierst eine angepasste lokale Ersatzschrift als eigene @font-face-Familie und setzt sie direkt hinter den Webfont:

@font-face {
  font-family: "Markenfont";
  src: url("/fonts/markenfont-regular.woff2") format("woff2");
  font-display: swap;
}

@font-face {
  font-family: "Markenfont Fallback";
  src: local("Arial");
  size-adjust: 98%;
  ascent-override: 92%;
  descent-override: 24%;
  line-gap-override: 0%;
}

body {
  font-family: "Markenfont", "Markenfont Fallback", sans-serif;
}

Die Beispielwerte sind keine allgemeingültige Vorlage. Sie müssen aus den Metriken Deiner konkreten Web- und Fallback-Schrift abgeleitet und anschließend visuell getestet werden. Falsche Werte können Text abschneiden, Abstände verschlechtern oder das Layout stärker verändern als ein unangepasster Fallback.

Teste mindestens große und kleine Schriftgrade, mehrzeilige Überschriften, Buttons, Formulare und lange Fließtexte. Simuliere zusätzlich eine langsame Verbindung oder blockiere die Webfont-Datei vollständig. So erkennst Du, ob die Seite auch dann lesbar und bedienbar bleibt.

Änderungen messen, Fehler finden und dauerhaft absichern

Eine Optimierung ist erst abgeschlossen, wenn Du Vorher- und Nachher-Werte unter vergleichbaren Bedingungen dokumentiert hast. Verwende für Labortests dasselbe Gerät, dieselbe Drosselung und einen geleerten Cache. Notiere nicht nur den Gesamtscore, sondern die Veränderungen, die sich direkt auf die Schriftauslieferung zurückführen lassen.

Die folgende Vorlage hilft, Änderungen pro Seitentyp nachvollziehbar zu bewerten. Sie verhindert, dass eine Verbesserung auf der Startseite Probleme auf Formularen, Artikeln oder Landingpages verdeckt.

Kontrolliere danach PageSpeed Insights beziehungsweise Lighthouse, aber verlasse Dich nicht ausschließlich auf einen Gesamtscore. Prüfe parallel im Network- und Performance-Panel, ob weniger Dateien geladen werden, der kritische Font früher ankommt und beim Austausch keine relevanten Layout Shifts entstehen. Weitere Maßnahmen gehören in eine umfassende Strategie zur Optimierung der Website-Ladezeit.

Bei doppelten Downloads vergleichst Du zuerst URLs und Dateiinhalte. Unterschiedliche Query-Parameter, CDN-Pfade oder Dateinamen können dieselbe Schrift mehrfach referenzieren. Suche anschließend im Quelltext und in geladenen Stylesheets nach Familienname, Dateiname und externem Host. Entferne die Einbindung möglichst an ihrer Quelle, statt sie nur mit zusätzlichem CSS zu überschreiben.

Fehlende Glyphen sprechen meist für ein unvollständiges Subset oder einen fehlerhaften unicode-range. Ein 404-Fehler weist auf falsche Pfade oder ein nicht veröffentlichtes Build-Artefakt hin. CORS-Fehler treten besonders bei Fonts auf, die über eine andere Domain oder ein Content Delivery Network ausgeliefert werden. Prüfe dann Response-Header, Origin und Cache-Konfiguration.

Rolle Änderungen zunächst in einer Testumgebung aus und kontrolliere mehrere Browser, Viewports, Sprachen und Seitentypen. Leere danach Website-, CDN- und Browser-Caches gezielt. Ein abschließender Crawl oder eine Suche nach alten Font-Domains hilft festzustellen, ob veraltete externe Einbindungen zurückgeblieben sind.

Typische Fehlerbilder gezielt zuordnen

• Text bleibt zunächst unsichtbar: font-display, späte CSS-Erkennung und blockierende Font-Anfragen prüfen.
• Schrift wechselt sichtbar und Layout springt: Fallback-Auswahl und Font-Metriken angleichen.
• Dieselbe Schrift wird mehrfach geladen: Initiator, Theme, Plugins, Builder und alte CSS-Bundles untersuchen.
• Font lädt trotz Preload erneut: URL, Formatangabe, CORS-Modus und verwendeten Schriftschnitt vergleichen.
• Optimierung verschwindet nach einem Update: Änderungen nicht in generierten Plugin- oder Theme-Dateien speichern, sondern updatefest konfigurieren.

Lizenz und Rollout nicht übersehen

Bevor Du eine Schrift konvertierst, subsettest oder selbst hostest, musst Du ihre Lizenzbedingungen prüfen. Eine Lizenz zur Nutzung in einer Desktop-Anwendung erlaubt nicht automatisch die Veränderung oder Bereitstellung als Webfont. Relevant sind insbesondere Web-Nutzung, Seitenaufrufe, erlaubte Domains, Konvertierung, Modifikation und Weitergabe.

Dokumentiere Herkunft, Lizenznachweis, Originaldatei, erzeugte Subsets und eingesetzte Version. Für WordPress-spezifische Schritte zur lokalen Einbindung hilft der Leitfaden Google Fonts lokal in WordPress laden. Datenschutz, lokale Bereitstellung und rechtliche Einordnung behandelt ergänzend der Beitrag zur DSGVO-konformen Font-Integration.