Web Fonts ohne Layout Shift und FOUT: So lädst du Schriften richtig

Fast jede moderne Website nutzt eine custom Webfont statt der systeminternen Schriften. Das sieht gut aus, hat aber einen Preis: Wenn der Font nicht rechtzeitig lädt, zeigt der Browser zuerst eine Fallback-Schrift an. Lädt der eigentliche Font nach, springt der Text. Das nennt sich FOUT (Flash of Unstyled Text) und verursacht Cumulative Layout Shift. Hier erfährst du, wie du es richtig machst.

Das Problem verstehen: FOUT und FOIT

Browser haben zwei Strategien, wenn ein Webfont noch nicht geladen ist:

• FOUT (Flash of Unstyled Text): Der Browser zeigt sofort Text mit einem Fallback-Font und tauscht ihn aus, sobald der Webfont lädt. Sichtbarer Shift, aber kein unsichtbarer Text.
• FOIT (Flash of Invisible Text): Der Browser versteckt Text komplett bis der Font geladen ist. Kein Shift, aber unsichtbarer Inhalt für oft mehrere Sekunden. Schlecht für LCP.

Die richtige Strategie liegt irgendwo dazwischen: Text sofort sichtbar machen, Shift minimieren, Font schnell laden.

font-display: die wichtigste CSS-Eigenschaft

Die CSS-Eigenschaft font-display in deiner @font-face-Regel steuert dieses Verhalten:

• font-display: swap: Zeigt sofort den Fallback-Font, tauscht gegen Webfont aus sobald verfügbar. Verursacht einen Shift, aber Text ist immer sichtbar. Gut für LCP, schlechter für CLS.
• font-display: optional: Browser nutzt den Webfont nur wenn er sehr schnell verfügbar ist (innerhalb der ersten 100ms). Kein Shift, kein FOIT. Beste Wahl für CLS, aber der Font wird bei langsamer Verbindung nie gezeigt.
• font-display: fallback: Kompromiss: kurzes Warten, dann Fallback, später noch einmal Versuch. Selten ideal.

Für die meisten KMU-Websites ist font-display: swap der richtige Einstieg. In Kombination mit Preload und gut gewähltem Fallback-Font minimierst du den Shift auf ein Minimum.

Webfonts preloaden

Wenn du den Font vorab mit einem Preload-Link ankündigst, lädt der Browser ihn früh genug, sodass der Shift kaum sichtbar ist:

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

Wichtig: Preload nur für den Font-Schnitt den du auf der wichtigsten Seite wirklich brauchst. Zu viele Preloads schaden der Performance statt sie zu verbessern.

Google Fonts vs. lokale Fonts

Google Fonts ist bequem, hat aber zwei Nachteile: Erstens gibt es eine DNS-Lookup-Latenz zu fonts.googleapis.com. Zweitens können Google Fonts ein Datenschutzproblem sein, da IPs an Google übertragen werden.

Die Lösung: Lade Google Fonts herunter und hoste sie selbst auf deiner Website. Das Tool Google Webfonts Helper macht das in wenigen Klicks möglich. Du bekommst die WOFF2-Dateien und die passende CSS-Deklaration in einem Schritt.

Font Subsetting: Nur die Zeichen laden die du brauchst

Eine vollständige Schriftdatei enthält oft Tausende Zeichen, Kyrillisch, Griechisch, spezielle Symbole. Für eine deutschsprachige Website brauchst du davon einen Bruchteil. Font Subsetting reduziert die Dateigröße drastisch:

• Nutze unicode-range in deiner @font-face-Deklaration um nur die benötigten Zeichenbereiche zu laden
• Tool-Empfehlung: Font Squirrel Webfont Generator erstellt optimierte Subsets
• Google Fonts liefert bei direkter Einbindung automatisch nur den passenden Subset

Den Fallback-Font angleichen

Selbst mit schnellem Laden bleibt ein kleiner Moment in dem der Fallback-Font sichtbar ist. Mit dem size-adjust und ascent-override Deskriptoren kannst du den System-Fallback-Font so anpassen, dass er deinem Webfont sehr ähnlich ist. Das minimiert den sichtbaren Shift auf nahe null. Tools wie Font Style Matcher helfen dabei.

Korrekt geladene Webfonts verbessern sowohl CLS als auch LCP. Im Rahmen unserer Core Web Vitals Optimierung analysiert rocks.optimize dein gesamtes Font-Ladeverhalten und implementiert die optimale Strategie für deine Website.