Grundlagen der Font-Loading-Performance

Font-Loading-Performance läuft auf drei Hebel hinaus: weniger Font-Dateien anfordern, jede Datei kleiner machen und steuern, was der Browser anzeigt, während die Dateien unterwegs sind. In der Praxis heißt das: ein disziplinierter Satz an Schriftfamilien und Schriftstärken, WOFF2 als einziges Format auf der Leitung, font-display: swap, damit Text nie unsichtbar ist, und ein Preload für die ein, zwei Dateien, die zuerst gerendert werden.

Die Reihenfolge zählt mehr, als die meisten Ratgeber vermuten lassen. Formate und Preload-Hinweise sind Feinschliff; der größte Hebel sitzt weiter oben, im Design: ein Schriftsystem, das weniger Schriften braucht. Ein Werkzeug, das Schriftsysteme komponiert, hat hier keine Performance-Werkzeuge zu bieten — Scale Composer schon gar nicht —, aber ein System aus zwei Familien und vier Stärken muss schlicht weniger laden als eine Seite, die ihre Schriften Entscheidung für Entscheidung angesammelt hat, und kein noch so guter Feinschliff schließt diese Lücke. Dieser Artikel ist Teil unseres Typografie-Leitfadens.

Was passiert, während ein Webfont lädt?

Text, der mit einer noch nicht eingetroffenen Schrift gesetzt ist, bringt den Browser in eine unangenehme Lage, und historisch hat er darauf auf eine von zwei Arten reagiert. FOIT — ein Aufblitzen unsichtbaren Texts (flash of invisible text) — verbirgt den Text, bis die Schrift eintrifft; das Layout ist stabil, aber man starrt auf eine leere Fläche. FOUT — ein Aufblitzen ungestylten (genauer: Fallback-)Texts — zeigt den Text sofort in einer Fallback-Schrift und tauscht ihn aus, sobald der Webfont ankommt; man kann sofort lesen, aber der Austausch kann das Layout verschieben, weil Fallback und Webfont unterschiedlich viel Platz einnehmen.

Beide sind Symptome derselben Lücke zwischen dem ersten Rendern und dem Eintreffen der Schrift. In der Praxis des Font-Loadings geht es immer darum, diese Lücke zu verkleinern — oder bewusst zu wählen, was sie füllt.

Was macht font-display: swap — und was kostet es?

font-display: swap wählt bewusst das zweite Verhalten: den Text sofort im Fallback zeigen und austauschen, sobald der Webfont geladen ist. Das ist die Standardantwort, weil unsichtbarer Text fast immer das schlimmere Übel ist — wer Fallback-Text lesen kann, hat nichts verloren außer etwas Feinschliff.

Der Preis ist der Austausch selbst. Sind die Buchstaben des Fallbacks breiter oder schmaler als die des Webfonts, bricht der Austausch das Layout neu um — die Verschiebung, die Nutzer als mitten im Lesen springenden Text wahrnehmen. Die moderne Gegenmaßnahme ist Metric Matching: Mit dem CSS-Deskriptor size-adjust und seinen Geschwistern kannst du eine Fallback-Schrift so skalieren, dass ihre gerenderten Breiten denen des Webfonts nahekommen, was den Austausch nahezu unsichtbar macht. Einen metrisch abgestimmten Fallback zu deklarieren, wird zunehmend Standard — und zunehmend von Werkzeugen erzeugt statt von Hand.

Warum ist „weniger Schriften“ die größte Optimierung?

Weil bei statischen Schriftfamilien — anders als bei Variable Fonts, die viele Schriftstärken in einer Datei tragen — jede Kombination aus Familie × Stärke × Stil, die du verwendest, eine eigene Datei und eine eigene Anfrage ist. Die Zahl wächst unbemerkt: Ein Team fügt für eine Marketingseite eine dritte Familie hinzu, ein anderes ergänzt eine 300 für einen Hero, und schon fordert die Seite ein Dutzend Dateien an, bevor der erste Absatz steht.

Ein diszipliniertes Budget, in echten Zahlen:

Vier Dateien, die zusammen meist deutlich unter 150 KB bleiben — die Größen schwanken mit dem Glyphen-Umfang, nimm die Bereiche also eher als Größenordnung denn als feste Werte. Die undisziplinierte Variante — drei Familien in je vier Stärken, plus ein paar Kursive — sind vierzehn Dateien, oft mehrere Hundert Kilobyte, für eine Seite, die nicht besser aussieht.

Der Grund, warum vier Stärken genügen, ist das Argument des Schriftsystems: Hierarchie entsteht aus einer Schriftgrößenskala — Größenstufen und Stärke-Stufen im Zusammenspiel — nicht daraus, Schriften hinzuzufügen. Eine Skala plus zwei Familien plus insgesamt vier Stärken deckt die meisten Produkte ab.

Sieh dir ein komplettes System mit diesem Budget in Scale Composer an — jede Ebene von Caption bis Display, gezogen aus zwei Familien und vier Stärken, in den Größen einer echten Skala. Das ist die gesamte Font-Rechnung für die Seite.

Was gehört sonst noch auf die Checkliste?

Die übrigen Punkte sind mechanisch. Der Leitfaden zu Font Best Practices von web.dev behandelt jeden im Detail; hier die praxistauglichen Kurzfassungen:

2. Nur WOFF2. Jeder aktuelle Browser unterstützt es, und es komprimiert spürbar besser als WOFF. Es gibt 2026 keinen Grund mehr, TTF, OTF oder EOT an einen Browser auszuliefern.
3. Lade die ein, zwei kritischen Dateien vor. <link rel="preload" as="font" type="font/woff2" crossorigin> für die Fließtext-Schrift (und vielleicht die Überschriften-Schrift) startet diese Downloads, bevor das CSS geparst wird. Alles vorzuladen macht den Sinn zunichte — Preload ist ein Prioritätsanspruch, und Priorität für sechs Dateien zu beanspruchen heißt, sie für keine zu beanspruchen.
4. Selbst hosten oder über Google hosten: beides ist in Ordnung. Das klassische Argument für Googles CDN — dass eine auf einer Website gecachte Schrift auf deiner wiederverwendet würde — verfiel, als Browser ihre HTTP-Caches pro Website partitionierten. Selbst-Hosting bringt dir Versionskontrolle, Same-Origin-Preloads und eine Drittanbieter-Abhängigkeit weniger; Google-Hosting bringt dir Bequemlichkeit und automatisches Subsetting. Entscheide nach Kontrolle oder Bequemlichkeit, nicht nach dem Cache-Mythos.
5. Subsetting, wenn deine Toolchain es zulässt. Eine Font-Datei, die Schriftsysteme mitträgt, die dein Produkt nie rendert, ist totes Gewicht. Googles CSS-API liefert bereits Subsets pro Schriftsystem über unicode-range; wenn du selbst hostest, wird Subsetting deine Aufgabe — und dafür gibt es Werkzeuge.

Weniger laden durch straffere Gestaltung

Arbeite die Checkliste der Reihe nach ab, und der erste Punkt erledigt den Großteil der Arbeit: weniger Familien und Stärken ist eine Design-Entscheidung mit größerem Ertrag als jede Build-Step-Optimierung danach. Das straffste Budget von allen — abgesehen davon, gar keine Schrift zu laden — ist eine einzige Familie. Probiere die Ein-Familien-Variante des Systems — eine komplette Hierarchie aus einer einzigen Familie und vier Stärken, getragen allein von Größe und Stärke: die kleinste Font-Rechnung, in die ein vollständiges Schriftsystem passt.