Font display in Lighthouse: Was das Insight beanstandet und wie du es behebst

Schadet die font-display-Warnung deinem Score?

Lighthouse markiert jeden Webfont, der mit font-display: block, auto oder fallback lädt, über das Insight „Font display“ („Consider setting font-display to swap or optional“) – vor Lighthouse 13 hieß der Audit „Ensure text remains visible during webfont load“. Das hat kein Gewicht in deinem Score. Wenn aber eine Überschrift dein LCP-Element ist, verzögert unsichtbarer Text den LCP auf Mobilgeräten. Setze swap für Schriften ein, die Besucher zuerst sehen, und passe den Fallback mit Metrik-Overrides an.

Was prüft das Insight „Font display“?

In Lighthouse 13 und PageSpeed Insights lautet der Hinweis: „Consider setting font-display to swap or optional to ensure text is consistently visible. swap can be further optimized to mitigate layout shifts with font metric overrides.“ Vor Lighthouse 13 hieß der Audit „Ensure text remains visible during webfont load“.

Lighthouse liest den Chrome-eigenen Trace des Ladevorgangs aus. Für jeden Webfont, den die Seite herunterlädt, erfasst der Trace den genutzten font-display-Wert. Das Insight beanstandet drei Werte:

• block: Der Text bleibt bis zu 3 Sekunden unsichtbar, während der Font lädt.
• auto: Gar kein Wert angegeben. Google Fonts liefert das ohne &display= aus, und ältere Themes, Font Awesome 4 sowie Material Icons nutzen es.
• fallback: Der Text ist nur für 100 ms unsichtbar. Lighthouse 13 bemängelt das trotzdem.

Nur zwei Werte bestehen die Prüfung: swap und optional. Das hat sich mit Lighthouse 13 geändert. Der alte Audit akzeptierte block und fallback. Websites, die das Problem vor Jahren mit fallback „behoben“ haben, erhalten die Warnung jetzt wieder. WordPress-Block-Themes nutzen standardmäßig fallback, Font Awesome 5 und 6 setzen auf block.

„Est savings“ ist die Dauer des Font-Requests im Trace, gedeckelt bei 3.000 ms. PageSpeed Insights zeichnet diesen Trace ungedrosselt auf. Deshalb siehst du dort oft eine kleine Zahl. Der folgende Bericht stammt von einer Testseite – der Produktseite eines Outdoor-Shops mit einer schmalen Headline-Schrift –, gemessen auf einem Smartphone mit DevTools-Drosselung (Slow 4G). Dort brauchte der Body-Font mehr als 3 Sekunden, und die Tabelle zeigt das Limit. Diese Zeit holst du so oder so nicht wieder rein: Mit fallback versteckt ein Font den Text höchstens 100 ms lang, und bei auto wartet Chrome maximal 2 Sekunden nach Beginn der Navigation.

Neben der Beschreibung zeigt Lighthouse zwei Labels. FCP ist die Metrik, bei der Lighthouse ein Einsparpotenzial sieht. Unscored bedeutet Gewichtung 0: Das Insight selbst verändert deinen Score nie. Ein Block-Font wirkt sich erst über den Speed Index und den LCP auf deinen Score aus.

Eine ungenutzte @font-face-Regel löst die Warnung nie aus. Und weil Lighthouse den Trace auswertet, tauchen jetzt auch Schriften auf, die du nicht selbst eingebunden hast – etwa ein Typekit-Kit oder die Google-Fonts-Datei eines Plugins. Der alte Audit gab bei Schriften externer Domains noch „unable to check“ aus.

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

Der Browser kann einen Font erst anfordern, wenn er weiß, dass ein sichtbares Element ihn braucht. Er braucht das HTML, dann das CSS und schließlich eine Style-Berechnung mit dem Ergebnis: „Diese Überschrift nutzt Barlow Condensed.“ Erst dann startet der Font-Request. Auf einem gedrosselten Smartphone war das bei 0,74 s, nachdem HTML und CSS da waren. Ein Font wird immer spät entdeckt. Ein Preload zieht diesen Start nur nach vorne: Schriften erhalten ohnehin schon die höchste Priorität.

Ab diesem Moment bestimmt der font-display-Wert, was Besucher sehen. Das sind die Timings im Browser-Quellcode:

Safari und Firefox blenden Text bei block und auto ebenfalls für bis zu 3 s aus. Firefox wartet 1,5 s länger, wenn 75 % des Fonts bereits geladen sind. Beide verstecken Text für 100 ms bei fallback und optional. Firefox tut das auch bei swap.

In Chrome ist block langsamer als auto: auto hat das 2-Sekunden-Limit, block nicht. Und optional hat in Chrome keine 100-ms-Schonfrist. Ohne Preload schafft es der Font praktisch nie in den ersten Render – selbst bei einem schnellen Server nicht. Mit Preload klappt es, wenn der Font innerhalb von rund 100 ms nach dem Moment eintrifft, an dem die Seite rendern könnte. Aus dem Cache auf der Folgeseite klappt es immer.

Die Produktseite beim ersten Paint, 0,9 s auf einem gedrosselten Smartphone. Der dunkle Kasten ist das Foto, das in beiden Fällen noch lädt. Testseite auf corewebvitals.io, Chrome 155, Smartphone mit 412 px Breite, Slow 4G und 4x CPU-Drosselung.

Bei block zeigt der erste Paint den Header, die Breadcrumbs und die Sternebewertung – und eine leere Lücke an der Stelle des Produktnamens. Der Headline-Font ist klein (15 kB) und trifft nach 1,7 s ein. Der Body-Font ist 344 kB groß und lädt noch, wenn Chrome nach 3,7 s das Warten aufgibt. Bis dahin bleibt der Bereich unter dem Foto leer. Bei swap sind Produktname und Beschreibung ab dem ersten Paint lesbar.

Dieselbe Seite nach 3 s: Headline-Font und Foto sind da, der Body-Font noch nicht.

Beeinflusst font-display LCP, CLS und FCP?

LCP

Unsichtbarer Text kann nicht das LCP-Element sein. Bei block oder auto wird ein Text-LCP erst erfasst, sobald der Text sichtbar wird: wenn der Font eintrifft oder die Block-Phase endet. Auf Seiten, auf denen das LCP-Element eine Überschrift oder ein Absatz ist, kann block den LCP um bis zu 3 Sekunden nach hinten schieben. Chrome verzögert bei auto weniger und zeigte diesen Text bei Slow 4G sogar sofort in Arial an. Bei swap gilt der Paint in der Fallback-Schrift als LCP. Der spätere Wechsel zum Webfont erzeugt keinen neuen LCP-Eintrag, selbst wenn der Text mit dem Webfont größer ausfällt.

Auf der obigen Produktseite ist das Foto in jeder Version das LCP-Element. Deshalb hat font-display den LCP dort nicht verändert. Das solltest du auf deinen eigenen Seiten zuerst prüfen: Ist das LCP-Element Text oder ein Bild? Das Insight „LCP breakdown“ im selben Lighthouse-Bericht nennt es.

CLS

Jeder Swap, der den Platzbedarf des Textes ändert, verschiebt alle nachfolgenden Elemente. Das passiert auch bei block und auto: Unsichtbarer Text nimmt den Platz der Fallback-Schrift ein, und der Wechsel zum Webfont führt zum selben Sprung. Die Versionen mit block, auto und swap kamen alle auf einen CLS von 0,031 – genau in dem Moment, als der Headline-Font eintraf.

Mit einfachem swap schrumpft die Überschrift von drei auf zwei Zeilen, sobald Barlow Condensed nach 1,7 s eintrifft. Alles darunter rutscht um 39 px nach oben: CLS 0,031. Die gestrichelte Linie markiert die vorherige Position des Fotos.

Dieselbe Seite mit einer Fallback-Schriftart, die Arial Bold auf die Breite von Barlow skaliert (size-adjust: 68.32%). Die Überschrift belegt vom ersten Paint an zwei Zeilen und nichts verschiebt sich: CLS 0.

swap besteht das Font-display-Insight, behält aber den Layout Shift. 0,031 liegt zwar unter 0,1. Auf einer echten Produktseite summiert sich das jedoch schnell: ein zweiter, später ladender Font, ein Preis in einer anderen Schriftart oder eine Sticky Bar. Metrik-Overrides für den Fallback verhindern diesen Shift.

Lighthouse führt dich hier nicht zur Schrift. In der Swap-Version schiebt „Layout shift culprits“ die Schuld auf das Foto – als „Unsized image element“. Dabei hat das Bild width und height. Verschoben wurde es durch den Headline-Font, der genau in diesem Moment ankam. Gleiche den Zeitpunkt eines Shifts mit deinen Font-Requests ab, bevor du nach Maßen suchst, die längst da sind.

FCP

Lighthouse weist das Einsparpotenzial beim FCP aus. Auf den meisten Seiten entscheidet aber etwas anderes über den FCP: Auf der Produktseite nutzen Header und Versandhinweis eine Systemschrift. Sie rendern bei block und swap gleichermaßen bei 0,8 s. In meinem eigenen Test mit reinem Webfont-Text auf der Seite meldete Chrome 155 den FCP trotzdem schon nach 112 ms, obwohl der Text noch unsichtbar war. Chrome stuft den Text als gezeichnet ein und überspringt lediglich die Glyphen. Die Zeit, die Lighthouse als FCP-Ersparnis anzeigt, wirst du in deinem FCP also nicht wiederfinden. Was du mit block verlierst, sind der LCP eines Textelements, der Speed Index und das, was Besucher tatsächlich sehen.

Wie viele Websites erhalten den Hinweis, und wann kannst du ihn ignorieren?

State of CWV analysiert die @font-face-Regeln auf den Startseiten von 170.706 Websites, die Webfonts einbinden. Die Hälfte dieser Regeln würde das Insight auslösen, wenn der Font lädt: 39,7 % haben keinen Wert (auto), 9,6 % nutzen block und 0,9 % fallback. Nur 471 Websites setzen überhaupt auf den Wert optional.

Websites mit gutem LCP auf Smartphones, gruppiert nach der Anzahl der geladenen Font-Dateien auf der Startseite und den font-display-Werten in ihren @font-face-Regeln. State of CWV, Oktober 2026: 170.706 Websites mit Webfonts, CrUX p75 auf Smartphones, ein guter LCP liegt bei 2,5 s oder weniger.

Bei ein oder zwei Font-Dateien macht es kaum einen Unterschied: 88 % der Websites mit reinem swap oder optional erreichen einen guten LCP auf Mobilgeräten, gegenüber 87 % der Websites mit block, auto oder fallback. Bei sechs bis zehn Font-Dateien wächst die Lücke auf 6 Prozentpunkte, bei elf oder mehr auf 9. Websites, die beide Varianten mischen, schneiden am schlechtesten ab. Sie deklarieren deutlich mehr Schriften – im Median 44 @font-face-Regeln gegenüber 18. Das deutet auf Theme-Font plus Plugin-Font plus Icon-Font hin. Beim CLS unterscheiden sich die Gruppen kaum.

Das ist eine Korrelation. Websites, die auf ihre Schriften achten, optimieren meist auch alles andere. Zusammen mit dem obigen Browser-Verhalten lautet meine Regel: Erst Font-Dateien reduzieren, dann font-display setzen.

Du kannst den Hinweis ignorieren, wenn:

• der Font nur Text below the fold rendert, etwa im Footer oder bei Bewertungen;
• dein LCP-Element ein Bild ist und der Font keinen Shift verursacht.

Wie siehst du Font-Probleme in deinen Field Data?

Lighthouse liefert dir einen einzelnen Ladevorgang auf einem simulierten Smartphone. Deine Besucher nutzen alle denkbaren Verbindungen, und wiederkehrende Besucher haben den Font bereits im Cache. In CoreDash zeigen dir zwei Aufschlüsselungen, ob Schriften dich Performance kosten.

• LCP nach Element. Ist das LCP-Element auf Mobilgeräten eine Überschrift oder ein Absatz, verzögert ein Font mit block oder auto den LCP bei jedem Aufruf, der auf die Schrift warten muss. Ist es ein Bild, berührt der Font deinen LCP nicht.
• CLS nach Element. Ein Font-Swap verschiebt alles unter dem Text: das Foto, den nächsten Abschnitt, den Kaufen-Button. CoreDash benennt das verschobene Element. Es sagt nicht explizit, dass ein Font die Ursache war: Wenn das verschobene Element direkt unter einer Überschrift oder einem Absatz liegt und eine Breite sowie Höhe besitzt, ist ein Font-Swap der wahrscheinlichste Grund.

CrUX liefert dir dieselben Metriken als p75 für deinen Origin oder eine URL über die letzten 28 Tage – allerdings ohne die Zuordnung zum Element.

LCP nach Element

CLS nach Element

CoreDash bei einem Beispiel-Shop, acme-pagespeed.com, mobile, p75. Der Produkttitel ist bei mehr Sessions das LCP-Element als jedes andere Element, mit einem LCP von 3,28 s. Wenn das Produktfoto das LCP-Element ist, liegt der LCP bei 2,21 s. In der CLS-Tabelle steht dieses Foto direkt unter dem Titel an oberster Stelle: 0,07 bei 1.214 Sessions. Zwar noch als gut eingestuft, aber kein anderes Element verschiebt sich bei so vielen Sessions.

Wie findest du den beanstandeten Font in den DevTools?

Öffne die Seite in Chrome, wechsle in das Performance-Panel, stelle das Netzwerk auf Slow 4G sowie die CPU auf 4x Drosselung und zeichne das Neuladen auf. Die Insights-Seitenleiste listet „Font display“ mit allen beanstandeten Schriften auf. Klickst du darauf, markiert DevTools die Font-Requests im Network-Track.

Schau dann, wo die einzelnen Font-Requests enden, wo der LCP-Marker liegt und ob der Track „Layout shifts“ direkt nach dem Ende eines Fonts einen Shift anzeigt.

Um jede @font-face-Regel zu finden, die auf eine beanstandete Datei verweist: Öffne Sources, durchsuche alle Dateien nach dem Dateinamen (Strg+Umschalt+F, Cmd+Option+F auf dem Mac) und setze den Wert in jeder gefundenen Regel.

Wie behebst du das Font-display-Insight?

Die Font-URL in der Lighthouse-Tabelle verrät dir die Herkunft. Davon hängt ab, wo du font-display setzt – oder ob das überhaupt möglich ist.

Dein eigenes @font-face

Ein Font auf deiner eigenen Domain ohne /wp-content/, /cdn/fonts/ oder /_next/ in der URL stammt aus deinem eigenen CSS. Ergänze font-display: swap in jeder @font-face-Regel für diesen Font – auch in Kopien in weiteren Stylesheets. Die Ausnahme bilden Icon-Fonts, siehe unten.

@font-face {
  font-family: "Barlow Condensed";
  src: url(/fonts/barlow-condensed-700.woff2) format("woff2");
  font-weight: 700;
  font-display: swap;
}

Google Fonts

Die Tabelle zeigt zwar fonts.gstatic.com, die Einstellung gehört aber in den Link zu fonts.googleapis.com/css2, der den Font lädt. Hänge dort &display=swap an:

<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Barlow+Condensed:wght@700&display=swap">

Noch schneller: Hoste den Font selbst. Das spart einen zusätzlichen Verbindungsaufbau und du behältst die volle Kontrolle über den Preload.

Adobe Fonts

Schriften auf use.typekit.net beziehen ihr font-display aus dem Webprojekt auf fonts.adobe.com: Wähle „Projekt bearbeiten“ und stelle es in der Seitenleiste ein. Adobes Standardwert ist auto; ein Parameter in der URL bewirkt nichts.

WordPress

Theme-Fonts enthalten /wp-content/themes/ in ihrer URL. In einem Block-Theme definierst du fontDisplay pro Schriftschnitt in der theme.json:

"fontFace": [{
  "fontFamily": "Barlow Condensed",
  "fontWeight": "700",
  "fontStyle": "normal",
  "fontDisplay": "swap",
  "src": ["file:./assets/fonts/barlow-condensed-700.woff2"]
}]

In einem klassischen Theme fügst du der Google-Fonts-URL in wp_enqueue_style den Parameter &display=swap hinzu oder trägst font-display in die @font-face-Regeln des Themes ein. Fonts unter /wp-content/plugins/ gehören zu einem Plugin oder Page Builder: Suche dort zuerst nach einer Schrift-Einstellung. Bei Google Fonts, die ein Page Builder lädt, findest du Elementors Option unter Elementor, Einstellungen, Erweitert: Google Fonts laden. OMGF hostet Google Fonts lokal und kann swap für sie erzwingen. Alle weiteren Font- und CSS-Optimierungen findest du im WordPress-Leitfaden.

Shopify

Shopify-Theme-Fonts enthalten /cdn/fonts/ in der URL auf der Domain deines Shops. Sie werden über den Filter font_face in der theme.liquid eingebunden. Fehlt font_display, gibt Shopify auch kein font-display aus:

{{ settings.type_header_font | font_face: font_display: 'swap' }}

Dawn setzt das bereits standardmäßig.

Next.js

next/font nutzt standardmäßig display: 'swap', lädt den Font per Preload und erstellt einen Fallback mit Metrik-Overrides (adjustFontFallback). Diese Schriften haben /_next/static/media/ in ihrer URL. Wird ein Font mit diesem Pfad bemängelt, wurde ihm beim next/font-Aufruf ein anderer Wert mitgegeben (display: 'block'): Ändere ihn dort. Ein bemängelter Font ohne diesen Pfad wurde auf anderem Weg geladen: über ein <link> zu Google Fonts im Layout oder über die CSS-Datei einer Komponentenbibliothek.

Schriften, die du nicht ändern kannst oder solltest

• Ein Icon-Font (fa-solid-900.woff2, bootstrap-icons.woff2, eicons.woff2): Mit swap erscheinen Buchstaben oder leere Kästchen anstelle der Icons. Ersetze Icon-Fonts wenn möglich durch SVGs, ansonsten belasse sie auf block.
• Ein Plugin oder eine App ohne Schrift-Einstellung (ein WordPress-Plugin, eine Schrift aus einer Shopify-App): Bitte die Entwickler, swap zu hinterlegen.
• Ein Drittanbieter-Skript, das eine Schrift auf deine Seite lädt (auf der Domain des Anbieters): Darauf hast du keinen Zugriff. Lade das Skript erst nach dem Rendern der Seite, oder ignoriere die Zeile im Bericht.

Weniger Font-Dateien laden

Entferne Schriftschnitte und Stile, die du nicht brauchst, und nutze einen variablen Font anstelle von sechs statischen Dateien. Jede eingesparte Font-Datei bedeutet einen Request weniger, einen Swap weniger und eine Zeile weniger in diesem Insight.

swap oder optional: Welcher Wert?

Nutze swap für markenprägende Schriften wie Headlines oder das Logo – kombiniert mit einem angepassten Fallback. Nutze optional für Fließtext, wenn die Systemschrift ausreicht, und lade diese Schrift per Preload, damit sie schon auf der ersten Seite eine Chance hat:

<link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin>
<style>
@font-face {
  font-family: "Inter";
  src: url(/fonts/inter-var.woff2) format("woff2");
  font-weight: 100 900;
  font-display: optional;
}
</style>

Das Attribut crossorigin ist Pflicht, selbst bei Schriften auf der eigenen Domain: Ohne das Attribut lädt der Browser den Font doppelt herunter. Ein Font-Preload kann in Chrome das erste Rendern um bis zu 100 ms verzögern. Lade deshalb nur ein oder zwei Schriften per Preload, niemals alle. Bei Slow 4G trafen die per Preload geladenen Schriften trotzdem erst nach dem ersten Paint ein, und die Seite blieb beim Fallback.

Layout Shifts mit Metrik-Overrides stoppen

Passe die Fallback-Schrift an die Dimensionen des Webfonts an. Das erreichst du über eine zweite @font-face-Regel, die auf eine lokale Schrift verweist und sie skaliert:

@font-face {
  font-family: "Barlow Fallback Arial";
  src: local("Arial Bold"), local("Arial-BoldMT");
  font-weight: 700;
  size-adjust: 68.32%;
  ascent-override: 146.37%;
  descent-override: 29.27%;
  line-gap-override: 0%;
}
h1 {
  font-family: "Barlow Condensed", "Barlow Fallback Arial", Arial, sans-serif;
}

size-adjust ist die Textbreite im Webfont, geteilt durch die Breite im Fallback. ascent-override und descent-override sind Ascent und Descent des Webfonts, geteilt durch denselben size-adjust-Wert. Tools wie Fontaine und Capsize berechnen sie direkt aus den Font-Dateien.

Dasselbe gilt für den Body-Font. Hier misst du direkt an deinem eigenen Text – bei Smartphone-Breite und in der genutzten Schriftgröße. Inter ändert seine Breite mit der Schriftgröße: von etwa 98 % der Arial bei Überschriften bis zu rund 105 % bei 18 px. Ein size-adjust von 97,6 % brach die Produktbeschreibung im Fallback auf fünf Zeilen um, während es bei Inter sechs waren – der Kaufen-Button verschob sich trotzdem. Bei 101 % ist der Zeilenumbruch identisch. Zum Testen blockierst du die Font-Datei in den DevTools (Network, Rechtsklick, Block request URL), lädst die Seite in Smartphone-Breite neu und vergleichst die Umbrüche mit dem normalen Ladevorgang. Passe size-adjust an, bis sie übereinstimmen.

local() findet nur Schriften, die auf dem Gerät installiert sind: Arial existiert unter Windows, macOS und auf iPhones; Android-Geräte nutzen Roboto. Für Android-Besucher ergänzt du eine zweite Fallback-Schrift für Roboto mit eigenen Werten:

h1 {
  font-family: "Barlow Condensed", "Barlow Fallback Arial", "Barlow Fallback Roboto", sans-serif;
}

local() überspringt Schriften, die nicht installiert sind. Jedes Gerät wählt also die erste verfügbare Option. Safari unterstützt zwar size-adjust, bislang aber keine Overrides für Ascent und Descent: Die Breite stimmt dort überein, bei line-height: normal kann die Zeilenhöhe jedoch leicht abweichen. WordPress und Shopify bieten dafür keine Einstellungen. Dafür braucht es einen Entwickler.

Wie prüfst du, ob der Fix funktioniert hat?

Starte Lighthouse erneut für Mobilgeräte: Font display wandert zu den bestandenen Insights. Auf der Produktseite stieg der Score von 97 auf 98, rein über die bewerteten Metriken: Der Speed Index sank von 1,9 s auf 1,3 s, weil der Text früher sichtbar ist, und der CLS fiel dank der Overrides von 0,031 auf 0. Prüfe danach den CLS in deinem eigenen Bericht: Wenn sich die Seite beim Eintreffen eines Fonts noch immer verschiebt, braucht der Fallback Metrik-Overrides.

Lighthouse 13.5.0, mobile, DevTools-Drosselung.

Hast du optional gewählt, zeigt der Lighthouse-Screenshot meist die Fallback-Schrift. Lighthouse lädt die Seite mit leerem Cache – hier tut optional genau das, was es soll.

CoreDash zeigt den Effekt pro Gerät ab dem nächsten Besuch. CrUX und die Search Console bilden die letzten 28 Tage ab: Zwei Wochen nach dem Fix stammt die Hälfte der Daten also noch von der alten Version.

Möchtest du wissen, ob eine Schrift deinen mobilen LCP oder CLS im roten Bereich hält? In einer Core-Web-Vitals-Power-Hour analysieren wir gemeinsam deine Field Data und einen Trace deiner Seite. Danach weißt du genau, welche Font-Regel du in deinem Theme anpassen musst.