Web-Font-Performance: Ladezeit durch Schriften senken
Schriften sind das vergessene Performance-Problem. Während Bilder, JavaScript und CSS regelmäßig optimiert werden, laufen Web-Fonts oft unbeachtet mit – obwohl sie laut HTTP Archive auf rund 68 Prozent (HTTP Archive Web Almanac, 2024) aller Seiten geladen werden und im Median mehrere Schriftdateien pro Seite ausmachen. Eine einzelne unsubsettete Schriftdatei im TTF-Format kann 200 bis 400 KB (Projekterfahrung) wiegen, und weil Text ohne geladene Schrift in vielen Browsern zunächst unsichtbar bleibt (Flash of Invisible Text, FOIT), verzögern Schriften direkt das, was der Nutzer als Ladezeit wahrnimmt. Hinzu kommt der Layout-Shift: Tauscht der Browser die Fallback-Schrift gegen die Web-Font aus, springt der Text – ein klassischer CLS-Verursacher. Dieser Artikel zeigt, wie Sie mit font-display, Preload, Subsetting, WOFF2 und angeglichenen Fallback-Metriken die Schrift-bedingte Ladezeit und den Layout-Shift systematisch senken – ohne das Design zu verändern.
Warum Web-Fonts die Performance ausbremsen
Eine Web-Font ist eine externe Ressource, die der Browser laden, dekodieren und auf den Text anwenden muss, bevor er die finale Typografie darstellen kann. Anders als ein Bild blockiert die Schrift dabei keinen einzelnen
Das Standardverhalten der Browser verschärft das Problem. Ohne explizite Steuerung verwenden viele Browser für Web-Fonts eine Blockierungsperiode von bis zu drei Sekunden (Quelle: Google web.dev, 2024): Solange die Schrift nicht geladen ist, bleibt der Text unsichtbar. Erst danach wird – falls die Schrift immer noch fehlt – die Fallback-Schrift gezeigt. Dieses Verhalten heißt Flash of Invisible Text (FOIT) und ist für den Nutzer die schlechteste aller Varianten, weil Inhalt sichtbar wäre, aber bewusst zurückgehalten wird.
Die zweite Variante ist der Flash of Unstyled Text (FOUT): Der Browser zeigt sofort die Fallback-Schrift und tauscht sie aus, sobald die Web-Font geladen ist. Der Inhalt ist dabei früh lesbar, aber der Tausch verschiebt Text, wenn sich die Schriftmetriken unterscheiden – das verschlechtert den CLS. Die Kunst der Web-Font-Optimierung besteht darin, FOIT zu vermeiden und den FOUT-Sprung so klein zu machen, dass er kaum auffällt. Beide Mechanismen erklären, warum Schriften sowohl in den Core Web Vitals als auch in der gefühlten Frontend-Performance eine größere Rolle spielen, als ihr Dateivolumen vermuten lässt.
FOIT - unsichtbarer Text
Der Browser hält den Text bis zu drei Sekunden (Google web.dev) zurück, während die Schrift lädt. Inhalt wäre da, wird aber bewusst verborgen.
FOUT - springender Text
Fallback zuerst, dann Tausch gegen die Web-Font. Unterschiedliche Metriken verschieben den Text und erzeugen Layout-Shift (CLS).
Drittanbieter-Anfragen
Externe Schrift-CDNs erzeugen zusätzliche DNS-Auflösung und Verbindungsaufbau - ein vermeidbarer Roundtrip auf dem kritischen Pfad.
Grosse Dateien
Unsubsettete TTF/OTF-Dateien mit allen Glyphen und Sprachen können 200 bis 400 KB (Projekterfahrung) je Schnitt erreichen.
Zu viele Schnitte
Regular, Bold, Italic, Light: jeder Schnitt ist eine eigene Datei. Vier Schnitte können schnell über 500 KB Schriftdaten bedeuten.
LCP-Abhängigkeit
Ist das LCP-Element ein Textblock, hängt der LCP-Wert direkt davon ab, wann die Schrift verfügbar ist - Schrift wird zum Flaschenhals.
font-display: FOIT vermeiden, Swap kontrollieren
Die wichtigste einzelne Stellschraube ist die CSS-Deskriptor-Eigenschaft font-display innerhalb der @font-face-Regel. Sie steuert, wie sich der Browser während der Ladephase einer Schrift verhält, und unterscheidet drei Phasen: einen Block-Zeitraum (Text unsichtbar), einen Swap-Zeitraum (Fallback sichtbar, Tausch erlaubt) und einen Fehler-Zeitraum (Fallback bleibt). Die gewählte Strategie bestimmt die Länge dieser Phasen.
font-display: swap setzt den Block-Zeitraum auf nahezu null. Der Browser zeigt sofort die Fallback-Schrift und tauscht sie aus, sobald die Web-Font geladen ist. Damit ist FOIT eliminiert und der Text von Anfang an lesbar – der Preis ist ein potenzieller FOUT-Sprung. swap ist für die meisten Body-Texte die richtige Wahl, weil Lesbarkeit wichtiger ist als ein perfekt stabiler Schriftwechsel.
font-display: optional geht einen Schritt weiter: Es gewährt der Schrift nur ein sehr kurzes Zeitfenster von rund 100 Millisekunden (Quelle: Google web.dev, 2024). Lädt die Schrift nicht rechtzeitig, bleibt dauerhaft die Fallback-Schrift – und es findet kein späterer Tausch statt. Das eliminiert den Font-Swap-Layout-Shift vollständig (CLS-Beitrag praktisch null) und ist ideal für Seiten, bei denen Stabilität über exakter Markentypografie steht. Beim wiederholten Besuch liegt die Schrift dann meist im Cache und wird sofort verwendet.
@font-face {
font-family: 'Inter';
font-style: normal;
font-weight: 400;
font-display: swap; /* FOIT vermeiden, Text sofort lesbar */
src: url('/fonts/inter-regular.woff2') format('woff2');
unicode-range: U+0000-00FF; /* Subset: nur Latin-Glyphen laden */
}
/* Fallback-Schrift an die Web-Font angleichen, um CLS zu minimieren */
@font-face {
font-family: 'Inter Fallback';
src: local('Arial');
size-adjust: 107%;
ascent-override: 90%;
descent-override: 22%;
line-gap-override: 0%;
}
body {
font-family: 'Inter', 'Inter Fallback', system-ui, sans-serif;
}Empfehlung für die Praxis
font-display: swap für Body-Text, der unbedingt sofort lesbar sein soll, und font-display: optional für Headlines oder Marken-Schriften, bei denen ein stabiles Layout wichtiger ist als der sichere Schriftwechsel beim ersten Besuch. So vermeiden Sie FOIT und halten den CLS-Beitrag der Schriften niedrig.WOFF2 und Subsetting: Schriftdaten drastisch reduzieren
Das Schriftformat hat einen unmittelbaren Einfluss auf das Datenvolumen. WOFF2 ist das moderne Web-Font-Format und nutzt eine an Schriften angepasste Brotli-Kompression. Im Vergleich zu unkomprimiertem TTF/OTF reduziert WOFF2 die Dateigröße auf etwa 30 Prozent (Google web.dev, 2024) – eine 300-KB-TTF-Datei wird so zu rund 90 KB. WOFF2 wird von allen aktuellen Browsern unterstützt (Quelle: MDN Web Docs, 2024); ein zusätzliches WOFF-Fallback ist heute in den meisten Projekten verzichtbar.
Noch größer ist der Hebel beim Subsetting. Eine vollständige Schriftdatei enthält oft tausende Glyphen für Dutzende Sprachen, Symbole und seltene Sonderzeichen. Eine deutschsprachige Website benötigt davon meist nur die lateinischen Buchstaben, Umlaute, Ziffern und gängige Satzzeichen. Durch Subsetting werden alle nicht benötigten Glyphen entfernt, was die Dateigröße zusätzlich um bis zu 70 Prozent (Projekterfahrung) senken kann. Werkzeuge wie fonttools/pyftsubset (Open Source) oder der unicode-range-Deskriptor in @font-face ermöglichen es, gezielt nur die tatsächlich verwendeten Zeichenbereiche auszuliefern.
Subsetting lässt sich auch nach Sprache aufteilen: Über mehrere @font-face-Regeln mit unterschiedlichem unicode-range lädt der Browser nur die Subsets, die für den tatsächlich dargestellten Text gebraucht werden. Eine Seite mit ausschließlich lateinischem Text fordert dann keine kyrillischen oder griechischen Glyphen an. Diese Technik ist besonders bei mehrsprachigen Shops wirkungsvoll und fester Teil unseres Vorgehens bei der Schrift-Optimierung.
| Format / Methode | Relative Größe | Browser-Support | Empfehlung |
|---|---|---|---|
| TTF / OTF (unkomprimiert) | ~100 % | Universell, aber gross | Für Web vermeiden |
| WOFF | ~60 % | Alle älteren Browser | Nur als Notfall-Fallback |
| WOFF2 | ~30 % (Google web.dev) | Alle aktuellen Browser (MDN) | Standardformat für das Web |
| WOFF2 + Subset | oft unter 25 % (Projekterfahrung) | Alle aktuellen Browser | Optimal für einsprachige Seiten |
| Variable Font (WOFF2) | 1 Datei statt vieler Schnitte | Moderne Browser (MDN) | Bei mehreren Gewichten effizient |
Preload und Self-Hosting: den kritischen Pfad verkürzen
Selbst die kleinste Schriftdatei nützt wenig, wenn der Browser sie spät entdeckt. Standardmäßig findet der Browser eine Schrift erst, wenn er das CSS geparst und festgestellt hat, dass ein sichtbares Element diese Schrift verwendet – das ist spät im Ladeprozess. Mit im HTML-Head wird die kritische Schrift früh und mit hoher Priorität angefordert, noch bevor das CSS vollständig verarbeitet ist.
<head>
<!-- Kritische Schrift fruehzeitig und priorisiert laden -->
<link rel="preload"
href="/fonts/inter-regular.woff2"
as="font"
type="font/woff2"
crossorigin>
<!-- Stylesheet wie gewohnt -->
<link rel="stylesheet" href="/styles.css">
</head>Preload mit Bedacht einsetzen
crossorigin-Attribut ist bei Schriften Pflicht, sonst lädt der Browser die Datei doppelt.Ein zweiter entscheidender Hebel ist das Self-Hosting. Werden Schriften über ein externes CDN geladen, fällt zusätzlich eine DNS-Auflösung und ein Verbindungsaufbau zu einem dritten Host an – ein vermeidbarer Roundtrip auf dem kritischen Pfad. Werden die Schriften stattdessen vom eigenen Server unter derselben Domain ausgeliefert, entfällt diese Drittverbindung, die Schrift profitiert von einer bereits offenen HTTP/2- oder HTTP/3-Verbindung und der schnellen Server-Antwortzeit der eigenen Infrastruktur.
Self-Hosting hat neben der Performance einen rechtlichen Vorteil: Das Laden von Schriften über externe Dienste überträgt die IP-Adresse der Besucher an Dritte. Ein deutsches Landgericht hat diese Praxis 2022 als Verstoß gegen die DSGVO eingestuft und einem Kläger Schadenersatz zugesprochen (Quelle: LG München I, Urteil 3 O 17493/20, 2022). Lokales Hosting der Schriften ist damit zugleich eine Datenschutz- und eine Performance-Maßnahme – ein Punkt, den wir in der technischen Analyse jeder Website prüfen.
Layout-Shift durch Font-Swap auf null bringen
Der Cumulative Layout Shift (CLS) ist eine der drei Core Web Vitals; Google bewertet einen Wert von unter 0,1 (Google web.dev, 2024) als gut. Ein erheblicher Teil unerwarteter Layout-Shifts entsteht durch den Schriftwechsel: Wenn die Fallback-Schrift schmaler, breiter, höher oder niedriger ist als die Web-Font, verschiebt der Tausch den umgebenden Text und damit alle darunterliegenden Elemente. Bei einer langen Textseite kann ein einziger Font-Swap mehrere kleine Shifts auslösen.
Die Lösung sind angeglichene Fallback-Metriken. Mit den CSS-Deskriptoren size-adjust, ascent-override, descent-override und line-gap-override lässt sich eine lokale Fallback-Schrift (etwa Arial oder eine System-Schrift) so anpassen, dass sie nahezu denselben Platz einnimmt wie die Web-Font. size-adjust skaliert die Glyphen-Breite und -Höhe, die Override-Deskriptoren passen die vertikalen Metriken an. Ist die Fallback-Schrift exakt an die Web-Font angeglichen, fällt der spätere Tausch kaum noch ins Gewicht – der CLS-Beitrag des Font-Swaps geht gegen null.
Die richtigen Override-Werte lassen sich messen oder mit Open-Source-Werkzeugen automatisch berechnen. Das Projekt fontaine etwa generiert angeglichene Fallback-@font-face-Regeln automatisch zur Build-Zeit; einige Frameworks haben diese Optimierung bereits eingebaut. Wer die Werte manuell ermittelt, vergleicht die units-per-em, ascent und advance widths von Web-Font und Fallback und berechnet daraus die Override-Prozente. Diese Technik kombiniert sich ideal mit der Optimierung von Interaktionsreaktivität (INP), weil stabile Layouts auch das Reflow-Verhalten bei Interaktionen verbessern.
Die drei Hebel mit der größten Wirkung
Variable Fonts: mehrere Schnitte in einer Datei
Klassische Schriftfamilien bestehen aus separaten Dateien je Schnitt: Regular, Bold, Italic, Light und so weiter. Lädt eine Seite vier dieser Schnitte, sind das vier HTTP-Anfragen und schnell über 500 KB Schriftdaten (Projekterfahrung). Variable Fonts lösen das, indem sie ein ganzes Gewichtsspektrum – und teils auch Breite und Stil – in einer einzigen Datei kodieren. Über die CSS-Achse font-weight lassen sich dann beliebige Zwischenwerte ansprechen, ohne weitere Dateien zu laden.
Ob eine Variable Font effizienter ist, hängt vom konkreten Einsatz ab. Werden tatsächlich viele Gewichte und Stile genutzt, spart die einzelne Variable-Datei gegenüber mehreren statischen Schnitten Anfragen und oft auch Gesamtvolumen. Wird hingegen nur ein einziges Gewicht gebraucht, ist ein statisches, subsettetes WOFF2 in der Regel kleiner, weil die Variable Font die Interpolationsdaten für alle Achsen mitliefert. Die Entscheidung sollte also auf einer realistischen Bedarfsanalyse beruhen – ein typischer Bestandteil unserer Performance-Arbeit an Shopware-Shops und anderen Systemen.
Auch Variable Fonts lassen sich subsetten und im WOFF2-Format ausliefern. Wer eine Variable Font einsetzt, sollte zusätzlich prüfen, welche Achsen wirklich gebraucht werden: Beschränkt man die Achsen-Bereiche (etwa nur font-weight 400 bis 700 statt 100 bis 900), lässt sich auch hier Volumen sparen. In Kombination mit font-display und Preload bleibt die Optimierungslogik dieselbe wie bei statischen Schriften.
Umsetzung in Shopware und CMS-Systemen
In der Praxis stammen ineffiziente Schriften häufig aus Themes und Plugins, die externe Schrift-CDNs einbinden oder vollständige Schriftfamilien mit allen Sprachen ausliefern. Bei einem Shopware-Shop auf Basis der Open-Source-Edition lassen sich die Schriften über das Theme-Build-System steuern: Die Schriftdateien werden lokal abgelegt, im Theme-SCSS über @font-face mit font-display und unicode-range eingebunden und die kritische Schrift über einen Preload-Hint im Storefront-Template angefordert.
Bei klassischen CMS und Page-Buildern ist der häufigste Hebel, externe Schrift-Einbindungen zu deaktivieren und durch lokal gehostete, subsettete WOFF2-Dateien zu ersetzen. Viele Themes bieten dafür Einstellungen oder lassen sich über ein Child-Theme anpassen. Wichtig ist, nach der Umstellung sorgfältig zu prüfen, dass alle verwendeten Zeichen – inklusive Umlaute, Anführungszeichen und Sonderzeichen – im Subset enthalten sind, damit keine Ersatzglyphen oder Tofu-Kästchen erscheinen.
- Externe Schrift-CDNs durch lokal gehostete WOFF2-Dateien ersetzen (Performance + DSGVO)
- Schriften auf benötigte Zeichenbereiche subsetten (unicode-range, pyftsubset)
- font-display: swap für Body-Text, optional für Headlines/Markenschrift setzen
- Nur die kritische Above-the-Fold-Schrift per Preload mit crossorigin laden
- Fallback-Metriken mit size-adjust und Overrides angleichen, um CLS zu senken
- Anzahl der Schnitte reduzieren oder eine subsettete Variable Font prüfen
- Nach der Umstellung Umlaute, Sonderzeichen und alle Sprachen visuell prüfen
Messung: Schrift-Performance sichtbar machen
Ob die Optimierung wirkt, lässt sich messen. In den Chrome DevTools zeigt die Network-Leiste, welche Schriftdateien geladen werden, wie groß sie sind und wann sie eintreffen. Der Filter auf Font-Ressourcen offenbart unsubsettete Riesendateien und externe Drittanfragen auf einen Blick. Die Performance-Leiste markiert Layout-Shift-Ereignisse und macht sichtbar, ob ein Font-Swap den Text verschiebt.
Auf Ebene der Kennzahlen schlägt sich die Optimierung in mehreren Werten nieder: Der First Contentful Paint sinkt, weil Text durch font-display: swap früher erscheint; der LCP verbessert sich, wenn das LCP-Element ein Textblock ist; und der CLS fällt, sobald der Font-Swap durch angeglichene Fallbacks neutralisiert ist. Gängige Performance-Messwerkzeuge weisen render-blockierende und ineffiziente Schriften in eigenen Audits aus, und die Field-Daten in der Google Search Console zeigen den realen Trend über die Zeit.
Wichtig ist, Lab- und Field-Daten zu kombinieren. Eine synthetische Lab-Messung zeigt das Verhalten unter definierten Bedingungen, aber erst die echten Nutzerdaten (Field) zeigen, wie sich Schriften über verschiedene Geräte, Netzwerke und Cache-Zustände auswirken. Ein kontinuierliches Performance-Monitoring deckt Regressionen auf – etwa wenn ein Theme-Update wieder eine externe Schrift einbindet oder ein neues Schriftgewicht ungesubsettet hinzukommt.
Schriften sind der Teil der Performance, der am häufigsten übersehen wird - und gleichzeitig einer der wenigen, bei denen eine einzige CSS-Zeile wie font-display den gefühlten Seitenaufbau spürbar verbessert.
Web-Font-Optimierung ist selten ein isoliertes Projekt. Sie greift in die Frontend-Optimierung, in die Core-Web-Vitals-Arbeit und in die Server-Konfiguration. Genau dieser ganzheitliche Blick – von der Schriftdatei über den kritischen Pfad bis zur Layout-Stabilität – macht den Unterschied zwischen einer marginalen und einer spürbaren Verbesserung der Ladezeit. Wer sein Projekt analysieren lassen möchte, findet den Einstieg über unsere Leistungen oder direkt über den Kontakt.