⚡ Wie man Webfonts ohne Geschwindigkeitsverlust lädt und die Textdarstellung beschleunigt
Wenn eine Website 3 Sekunden zum Laden braucht und dann noch eine weitere Sekunde benötigt, um sämtlichen Text neu aufzubauen, springen Besucher ab. Nicht zur Konkurrenz, sie schließen einfach den Tab. Das Problem ist fast immer dasselbe: Webfonts, die ohne Rücksicht auf Performance eingebunden wurden.
Laut HTTP-Archive-Daten für 2025 setzen rund 84% der Websites eigene Webfonts ein, und die durchschnittliche Site stellt 5 Anfragen an Font-Dateien mit einem Gesamtvolumen von etwa 400 KB. Bei einer schlechten Verbindung bedeutet das 2 bis 3 Sekunden Render-Blockierung, während Nutzer einen leeren Bildschirm sehen. Google berücksichtigt zudem den Cumulative Layout Shift durch Font-Austausch in den Core Web Vitals.
Die folgenden vier Schritte sind keine Theorie. Es handelt sich um das praktische Minimum, das die allermeisten Performance-Probleme mit Webfonts behebt. Jeder Schritt dauert 5 bis 15 Minuten.
💡 Kurzer Überblick:
- Entscheiden Sie sich für Formate: woff2 als primäres Format und woff als Fallback genügen für alle modernen Browser.
- Hinterlegen Sie einen Preload für kritische Schriften, damit der Browser sofort mit dem Download beginnt, statt auf das CSS zu warten.
- Prüfen Sie Ihre font-face-Deklaration: local(), korrekte src-Reihenfolge, unicode-range für lateinische Zeichen.
- Setzen Sie font-display: swap, und Besucher sehen Text sofort, auch während die Schrift noch lädt.
Schritt 1: woff2 und woff verwenden, mehr braucht es nicht
Es gibt viele Webfont-Formate: EOT, TTF, OTF, SVG. Doch im Jahr 2026 benötigen Sie tatsächlich nur zwei.
woff2 ist der moderne Standard. Dateien sind bei gleicher Qualität rund 30% kleiner als woff, weil sie Brotli-Kompression anstelle von gzip nutzen. Die Browser-Unterstützung umfasst alle Evergreen-Browser, einschließlich Mobile Safari und Samsung Internet. Weltweit sind das über 98% der Nutzer.
woff ist der Fallback für einen kleinen Anteil älterer Browser (Safari auf iOS 11 und älter, seltene Unternehmensumgebungen). Auch dieses Format ist komprimiert und funktioniert ab IE9+. Setzen Sie es in src an die letzte Stelle, dann nimmt der Browser woff2, sofern er kann, andernfalls greift er auf woff zurück.
Verzichten Sie 2026 auf EOT (Internet Explorer 8 und älter) oder TTF (Rohformat, keine Kompression). Der Anteil solcher Browser ist statistisches Rauschen, und jedes zusätzliche Format in src vergrößert das CSS und verwirrt den Browser.
Wenn Sie Dateien als TTF oder OTF vorliegen haben, konvertieren Sie sie mit einem Online-Generator. Transfonter erzeugt woff2 und woff in einem Durchlauf und zeigt eine Glyphenvorschau sowie die endgültige Dateigröße an. Eine Alternative ist der Font Squirrel Webfont Generator.
Schritt 2: Kritische Schriften vorladen
Der Browser erfährt von Schriften über das CSS, und das CSS liest er nach dem HTML. Bis er dort ankommt, sind bei einer durchschnittlichen Verbindung 500 bis 800 ms vergangen. Preload eliminiert diese Verzögerung: Der Browser startet den Download der Schrift, sobald er auf das Tag im <head> trifft, ohne auf das CSS zu warten.
Minimales funktionierendes Tag:
1 <link rel="preload" as="font" 2 href="/fonts/open-sans.woff2" 3 type="font/woff2" 4 crossorigin="anonymous">
Entscheidend ist crossorigin="anonymous". Ohne dieses Attribut ignoriert der Browser die vorgeladene Schrift und lädt sie erneut herunter. Der Grund: Schriften werden anonym abgerufen (CORS), ein Preload ohne crossorigin erzeugt jedoch eine reguläre Anfrage. Der Browser betrachtet dies als unterschiedliche Ressourcen und führt sie nicht zusammen.
Was vorgeladen werden soll. Nicht jede Schrift auf der Site. Nur diejenige, die für den Haupttext oberhalb des Falzes (above the fold) verwendet wird: Überschrift, Fließtext, Navigation. Der Rest kann warten. 4 bis 5 Dateien vorzuladen bringt abnehmende Erträge und entzieht kritischen Inhalten Bandbreite.
Wichtiger Hinweis zu Google Fonts und CDN. Wenn Sie Schriften von Google Fonts nutzen, werden die Dateien regelmäßig aktualisiert, und ein Preload-Link auf eine veraltete Version führt zu doppeltem Download (alt + neu). Verwenden Sie für CDN-Schriften anstelle von Preload <link rel="preconnect"> zur Font-Domain. Das beschleunigt den Handshake, ohne das Risiko eines Versionskonflikts:
1 <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
Prefetch für sekundäre Schriften. rel="prefetch" teilt dem Browser mit: „Diese Ressource wird später benötigt, lade sie, wenn der Hauptinhalt bereit ist." Geeignet für Schriften auf internen Seiten oder Icon-Fonts im Footer. Die Priorität ist niedrig, es wird keine Bandbreite blockiert.
Eine aktuelle Anleitung zur Ressourcen-Priorisierung finden Sie in der web.dev-Dokumentation.
Schritt 3: @font-face korrekt schreiben
Auf den ersten Blick ist @font-face einfach. In der Praxis gibt es vier subtile Bereiche, die sich jeweils auf die Geschwindigkeit auswirken.
Beispiel für eine korrekte Deklaration:
1 @font-face { 2 font-family: 'Open Sans'; 3 font-weight: 400; 4 font-style: normal; 5 font-display: swap; 6 unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, 7 U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, 8 U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, 9 U+FEFF, U+FFFD; 10 src: local('Open Sans'), 11 url('/fonts/open-sans.woff2') format('woff2'), 12 url('/fonts/open-sans.woff') format('woff'); 13 }
Aufschlüsselung im Einzelnen:
local(): als Erstes in src. Wenn der Nutzer die Schrift bereits auf seinem System installiert hat (Roboto auf Android, Segoe UI auf Windows, San Francisco auf macOS), nimmt der Browser die lokale Kopie und lädt null Byte. Setzen Sie local() immer als erste Zeile in src. Entnehmen Sie den Namen der Schriftdatei selbst: local('Open Sans') und local('Roboto Regular').
Format-Reihenfolge. Der Browser geht src von links nach rechts durch und nimmt das erste Format, das er versteht. Daher: local() → woff2 → woff. Kein EOT/TTF/SVG am Ende, es sei denn, Sie haben eine spezifische Zielgruppe mit alten Browsern, dann kommen diese NACH woff (nicht davor).
unicode-range: nur die benötigten Glyphen laden. Für lateinische Zeichen genügt der Bereich U+0000-00FF (Basic Latin + Latin-1 Supplement). Das sind rund 250 Glyphen gegenüber mehreren Tausend im vollen Satz. Die tatsächliche Dateigröße sinkt um das Drei- bis Fünffache. Überfrachten Sie den Bereich nicht: Jeder zusätzliche Unicode-Block fügt Glyphen hinzu, die niemand zu Gesicht bekommt. Für kyrillische Sites ergänzen Sie U+0400-04FF.
Reihenfolge der @font-face-Blöcke. Wenn Sie mehrere Schnitte haben (normal, fett, kursiv), setzen Sie den normalen Schnitt (font-weight: 400) an die erste Stelle. Der Browser beginnt dann mit dessen Download.
Schritt 4: font-display: swap aktivieren und FOIT den Abschied geben
Flash of Invisible Text (FOIT) bedeutet, dass der Browser Text 3 Sekunden lang verbirgt, während er auf die Schrift wartet. Nutzer sehen eine leere Seite. Flash of Unstyled Text (FOUT) bedeutet, dass Text sofort in einer Systemschrift sichtbar ist und anschließend durch die eigene Schrift ersetzt wird. Das Zweite ist immer besser als das Erste.
font-display: swap in @font-face bewirkt genau das: Text wird sofort in einer Systemschrift dargestellt, und wenn die eigene Schrift geladen ist, wird sie eingetauscht. Ideal für Fließtext.
Weitere Werte und wann sie sinnvoll sind:
swap: für Fließtext. Text ist sofort sichtbar, der Austausch erfolgt weich.optional: für dekorative Schriften und Icons. Der Browser entscheidet, ob er die Schrift überhaupt herunterlädt. Bei schlechter Verbindung lehnt er ab und behält die Systemschrift. Die Wartezeit beträgt 100 ms.block: kurze Blockierung (üblicherweise 3 Sekunden), dann wird Text sichtbar, die Schrift wird nach dem Laden eingetauscht. Wird selten verwendet.fallback: ein Kompromiss. Kurze Blockierung, dann wird Text sichtbar, die Schrift wird eingetauscht, wenn sie schnell lädt.
In der Praxis verwenden Sie swap für Fließtext und optional für Icon-Fonts und Dekoration. Das genügt.
Browser-Verhalten ohne font-display. Wenn Sie nichts angeben, verbirgt Chrome Text bis zu 3 Sekunden, Firefox bis zu 3 Sekunden, Safari unbegrenzt und Edge zeigt sofort die Systemschrift. Mit font-display: swap wird dieses Verhalten vereinheitlicht und das Ergebnis ist vorhersagbar.
So überprüfen Sie das Ergebnis
Testen Sie Ihre Site vorher und nachher unter web.dev/measure. Lighthouse zeigt den Prüfpunkt „Sicherstellen, dass Text während des Webfont-Ladevorgangs sichtbar bleibt" als eigene Zeile an. Ist der Audit rot, funktioniert Ihr font-display nicht oder fehlt.
Zur manuellen Prüfung: Öffnen Sie DevTools → Netzwerk, setzen Sie die Drosselung auf „Slow 3G" und laden Sie die Seite neu. Text sollte sofort in einer Systemschrift erscheinen, nicht erst nach 3 Sekunden leerem Bildschirm.
Die folgenden Screenshots zeigen den Unterschied zwischen dem Standardansatz und dem optimierten Vorgehen (Test mit Slow 3G):
Standard: Text wird verborgen, bis die Schrift geladen ist
Optimiertes Verhalten: Text ist sofort in einer Systemschrift sichtbar
Der Unterschied ist mit bloßem Auge erkennbar: Der erste Screenshot zeigt einen weißen Bildschirm, der zweite sofort verfügbaren Inhalt.
Auf der performance.now() 2024-Konferenz behandelt Mandy Michael fortgeschrittene Strategien: inkrementelles unicode-range, Font-Slicing und den Umgang mit Variable Fonts. Für alle, die über die vier Basisschritte hinausgehen möchten.
⁉️🤔 Häufig gestellte Fragen
Warum brauche ich woff, wenn woff2 überall unterstützt wird?
Verbliebene Nutzer von altem iOS Safari (iOS 11 und älter) sowie seltene Unternehmensumgebungen mit abgeschotteten Browsern unterstützen kein woff2. Ohne einen woff-Fallback sehen diese Nutzer eine Systemschrift anstelle Ihrer eigenen. Woff fügt dem Set 15 bis 20 KB hinzu: ein vernachlässigbarer Preis für die Abdeckung des verbleibenden Anteils.
Kann ich nicht einfach Google Fonts nutzen und mir keine Gedanken machen?
Ja, und für die meisten Sites ist das der optimale Weg. Google Fonts liefert modernen Browsern automatisch woff2, nutzt ein geografisch verteiltes CDN und unterstützt
display=swapals URL-Parameter. Nachteile: Abhängigkeit von einem externen CDN (Datenschutzaspekte, DSGVO), keine Kontrolle überunicode-rangeund lokale Schriftinstallation. Wenn Datenschutz und Kontrolle wichtig sind, hosten Sie Ihre Schriften selbst.
Wie erkenne ich, ob Schriften meine Site tatsächlich ausbremsen?
Lighthouse (der Audits-Tab in den Chrome DevTools) zeigt den Audit „Sicherstellen, dass Text während des Webfont-Ladevorgangs sichtbar bleibt" an. WebPageTest liefert ein Wasserfalldiagramm mit Zeitangaben für jede Font-Anfrage. Wenn Schriften später starten als das erste CSS, ist Preload nicht konfiguriert. Liegt der Layout Shift über 0,1, verursacht die Schrift Cumulative Layout Shift, und Google zählt das in den Core Web Vitals.
font-display: swap ruiniert das Design, Text „springt" beim Austausch?
Ja, das ist ein bekannter Nachteil von swap. Begegnen Sie dem mit zwei Techniken. Erstens: Setzen Sie
font-sizeundline-heightfür Text so, dass sie zur System-Fallback-Schrift passen. Der Unterschied in den Metriken wird minimal sein. Zweitens: Nutzen Sie den Font Style Matcher oder die Eigenschaftsize-adjustin@font-face(in modernen Browsern verfügbar), um die Metriken der eigenen Schrift an die Systemschrift anzugleichen. Nach der Anpassung liegt der CLS bei null.
Sollte ich alle Schriften auf der Site vorladen?
Nein. Laden Sie nur kritische Schriften vor: jene, die Text oberhalb des Falzes bilden (die ersten 1 bis 2 Bildschirmseiten). Laden Sie den Rest normal über CSS. Mehr als 5 Schriften vorzuladen verstopft die Bandbreite und verzögert wichtigere Ressourcen in der Warteschlange. In der Praxis decken 1 bis 2 Preload-Links die allermeisten Szenarien ab.
Ob sich der Aufwand lohnt: vier Schritte, vier Minuten
Die Einrichtung von Webfonts ist kein wochenlanges Projekt. Die Konvertierung nach woff2, das Korrigieren von @font-face, Preload und font-display: swap bedeuten 20 bis 30 Minuten Arbeit, selbst wenn Sie es noch nie gemacht haben.
Der Nutzen ist messbar: Text wird bei Slow 3G 1,5 bis 2,5 Sekunden früher sichtbar. Die Core Web Vitals schlagen keinen Layout Shift mehr negativ zu Buche. Und Nutzer springen nicht ab, während sie auf einen weißen Bildschirm starren.
Beginnen Sie mit einer Schrift: der für den Haupttext. Gehen Sie die vier Schritte durch. Prüfen Sie Lighthouse vorher und nachher. Der Unterschied in den Zahlen wird überzeugender sein als jedes Argument.
Ein professionelles Team von Autoren und Redakteuren, das auf die Erstellung hochwertiger Inhalte spezialisiert ist.