Responsives Web Font Loading: Eine gerätebewusste Strategie

Responsive Font-Display & responsive Preloading-Strategie

Als Spezialist für Core Web Vitals sehe ich jeden Tag verschiedene kreative Lösungen. Die meisten ergeben nicht viel Sinn, aber ab und zu stoße ich auf eine Strategie, die so einfach und elegant ist, dass sie für bestimmte Websites tatsächlich Sinn ergibt.

Laut dem Web Almanac 2025 verwenden 88 % der Websites Webfonts und laden im Median 4 Schriftartdateien pro Seite. Dennoch nutzen nur 12 % der Websites einen Preload für Schriftarten und nur magere 0,5 % verwenden font-display: optional. Die meisten Websites behandeln das Laden von Schriftarten als Einheitslösung. Dieser Artikel erklärt einen intelligenteren Ansatz: das unterschiedliche Laden von Schriftarten für Desktop und Mobile.

Die Strategie kombiniert responsives Preloading mit font-display: optional auf dem Desktop (was den Flash Of Unstyled Text eliminiert) und font-display: swap auf Mobilgeräten (was schnelles Text-Rendering gegenüber visueller Konsistenz priorisiert).

Zuletzt überprüft von Arjen Karel im März 2026

Tipp: Diese Strategie funktioniert gut für Websites mit einem größeren Critical Rendering Path, das heißt Websites, die mehrere Schriftarten, Stylesheets und Skripte vor dem LCP-Element laden. Wenn Ihre Website eine einzelne, leichtgewichtige Schriftart lädt, lohnt sich die zusätzliche Komplexität nicht.

Das Problem mit dem frühen Laden von Schriftarten

Bei der Optimierung der Core Web Vitals gilt immer eine einfache Regel:
"Alles, was Sie vor dem Largest Contentful Paint tun, verlangsamt diesen Largest Contentful Paint".

Dieses Prinzip gilt auch für Webfonts. Die Priorisierung des Ladens von Webfonts während des Seitenaufbaus kann die User Experience verbessern, aber wenn Ihre Website Schwierigkeiten hat, die Schwellenwerte der Core Web Vitals zu erreichen, insbesondere für bestimmte Gerätetypen, müssen Sie möglicherweise die UX gegen die Verbesserung des LCP abwägen.

Das Performance-Kapitel des Web Almanac 2025 zeigt, dass Text auf fast 24 % der mobilen Seiten das LCP-Element ist. Wenn Text das LCP-Element ist, wirkt sich die Font-Loading-Strategie direkt auf Ihren LCP-Score aus. Auf den restlichen 76 % der Seiten, auf denen ein Bild das LCP-Element ist, konkurrieren Schriftarten immer noch um frühe Netzwerkbandbreite und können das Laden des Bildes nach hinten verschieben.

Betrachten wir das folgende Beispiel einer niederländischen Zeitungswebsite. Auf einem Mobilgerät werden 3 Schriftarten vor dem LCP-Element eingereiht. Dadurch konkurrieren die 3 Schriftarten um frühe Netzwerkressourcen und verzögern das Timing des Bildes.

Verständnis von font-display: optional vs. swap

Bevor wir uns mit der responsiven Strategie befassen, müssen Sie die beiden font-display-Werte verstehen, auf denen sie basiert. Für einen breiteren Überblick über font-display, siehe wie man sicherstellt, dass Text während des Ladens von Webfonts sichtbar bleibt.

font-display: swap zeigt die Fallback-Schriftart sofort an und tauscht die benutzerdefinierte Schriftart aus, sobald sie geladen ist. Dies ist großartig für den LCP, da der Text von Anfang an sichtbar ist. Der Nachteil: Wenn die benutzerdefinierte Schriftart eintrifft und das Fallback ersetzt, können die unterschiedlichen Schriftmetriken eine sichtbare Layoutverschiebung verursachen, die Ihrem CLS-Score schadet. Etwa 50 % der Websites verwenden swap, was ihn zum mit Abstand beliebtesten Wert macht.

font-display: optional gibt dem Browser etwa 100 ms Zeit, um die Schriftart zu laden. Wenn die Schriftart rechtzeitig eintrifft (normalerweise aus dem Cache oder durch einen schnellen Preload), wird sie verwendet. Wenn nicht, wird die Fallback-Schriftart für das gesamte Laden der Seite verwendet und es findet nie ein Austausch statt. Das bedeutet null Layoutverschiebungen, aber die benutzerdefinierte Schriftart wird beim ersten Besuch möglicherweise nicht angezeigt. Nur 0,5 % der Websites verwenden optional, obwohl es die sicherste Option für den CLS ist.

Seit Chrome 83 blockiert die Kombination von font-display: optional mit <link rel="preload"> den First Paint für bis zu ~100 ms (mit einem absoluten Maximum von 1500 ms) und wartet darauf, dass die Schriftart eintrifft. Wenn die Schriftart im Preload ist, trifft sie fast immer innerhalb dieses Zeitfensters ein. Das Ergebnis: formatierter Text beim First Paint, null FOUT, null Layoutverschiebungen. Aus diesem Grund funktioniert die Desktop-Seite der responsiven Strategie so gut.

Responsive Font-Strategie zur Rettung!

In Fällen wie diesem, in denen es früh viel Netzwerk-Konkurrenz gibt, ist es sinnvoll, zwischen Gerätetypen zu unterscheiden. In der Regel können schnellere Desktop-Geräte an kabelgebundenen (und schnelleren Netzwerkverbindungen) mehr frühe Netzwerkressourcen auf einmal bewältigen und es ist absolut sinnvoll, einige kritische Schriftartdateien per Preload zu laden.

Mobilgeräte hingegen werden möglicherweise auf dem Weg zur Arbeit unter nicht optimalen Netzwerkbedingungen genutzt. Mobilgeräte haben im Vergleich zu Desktops oft auch langsamere CPUs und weniger verfügbaren Arbeitsspeicher. Diese Einschränkungen bedeuten, dass es sinnvoll sein kann, das Laden von Schriftarten je nach Gerätetyp unterschiedlich zu behandeln.

• Desktop: Das Preloading von Schriftarten verbessert die Rendering-Performance auf Geräten mit besserer Bandbreite und Rechenleistung. Verwenden Sie font-display: optional, um Probleme mit dem Font-Swapping zu beseitigen. In Kombination mit einem Preload blockiert Chrome kurzzeitig das Rendering (bis zu ~100 ms), um auf die Schriftart zu warten, wodurch Sie formatierten Text beim First Paint mit null CLS erhalten.
• Mobile: Laden Sie die Schriftart aufgrund der Netzwerk-Konkurrenz nicht per Preload. Verwenden Sie font-display: swap für ein schnelleres Text-Rendering. Dieser Ansatz zeigt Fallback-Schriftarten sofort an, während die benutzerdefinierte Schriftart im Hintergrund weitergeladen wird, was eine bessere User Experience auf weniger leistungsstarken Geräten bietet.

Implementierung mit <link rel="preload"> und Media Queries

Anstatt die Schriftart universell zu laden, können Sie das media-Attribut im HTML-<link>-Tag zusammen mit CSS verwenden, um je nach Gerätetyp unterschiedliche Font-Strategien anzuwenden.

Komplette Implementierung

<head>
  <!-- Viewport-Meta-Tag MUSS vor den bedingten Media-Preloads stehen -->
  <meta name="viewport" content="width=device-width, initial-scale=1">

  <!-- Preload der Schriftart nur für Desktop -->
  <link rel="preload" href="/fonts/custom-font.woff2"
        as="font" type="font/woff2" crossorigin
        media="(min-width: 768px)">

  <style>
    /* Mobile: swap sorgt für schnelles Text-Rendering */
    @font-face {
        font-family: 'CustomFont';
        src: url('/fonts/custom-font.woff2') format('woff2');
        font-display: swap;
    }

    /* Desktop: optional + Preload = formatierter Text beim First Paint */
    @media (min-width: 768px) {
        @font-face {
            font-family: 'CustomFont';
            src: url('/fonts/custom-font.woff2') format('woff2');
            font-display: optional;
        }
    }

    body {
        font-family: 'CustomFont', sans-serif;
    }
  </style>
</head>

Einige wichtige Details zu dieser Implementierung:

1. Reihenfolge des Viewport-Meta-Tags: Das <meta name="viewport">-Tag muss vor dem Preload-Link erscheinen. Der Preload-Scanner des Browsers wertet das media-Attribut aus, bevor er andere Meta-Tags parst. Wenn der Viewport nicht gesetzt ist, wird die Media Query auf Mobilgeräten mit den falschen Abmessungen ausgewertet.
2. Vollständige @font-face-Deklarationen: Jeder @font-face-Block muss sowohl font-family als auch src enthalten. Im Gegensatz zu regulären CSS-Eigenschaften werden @font-face-Deskriptoren nicht kaskadiert. Sie können nicht einfach nur font-display in einem zweiten Block überschreiben, ohne das gesamte Font-Face neu zu deklarieren. Der Browser verwirft eine unvollständige @font-face-Regel.
3. Das crossorigin-Attribut: Schriftarten, die ohne crossorigin per Preload geladen werden, werden zweimal abgerufen. Fügen Sie es bei Font-Preloads immer ein, auch bei Same-Origin-Schriftarten.
4. Übereinstimmende Breakpoints: Das media-Attribut beim Preload (768px) muss mit der CSS-Media-Query (768px) übereinstimmen. Wenn sie nicht übereinstimmen, laden Sie bei einem Breakpoint per Preload und wenden beim anderen das falsche font-display an.

Reduzierung von Layoutverschiebungen auf Mobilgeräten durch Fallback-Font-Matching

Die mobile Strategie verwendet font-display: swap, was bedeutet, dass es einen kurzen Flash Of Unstyled Text gibt, wenn die benutzerdefinierte Schriftart das Fallback ersetzt. Sie können diesen visuellen Sprung minimieren, indem Sie CSS-Font-Metric-Overrides verwenden:

@font-face {
    font-family: 'CustomFont Fallback';
    src: local('Arial');
    ascent-override: 105%;
    descent-override: 25%;
    size-adjust: 97%;
}

body {
    font-family: 'CustomFont', 'CustomFont Fallback', sans-serif;
}

Mit den Deskriptoren ascent-override, descent-override und size-adjust können Sie die Abmessungen der Fallback-Schriftart an die benutzerdefinierte Schriftart anpassen. Wenn der Austausch (Swap) stattfindet, bewegt sich der Text kaum noch. Diese Deskriptoren werden von allen modernen Browsern unterstützt. Bibliotheken wie Capsize können die richtigen Override-Werte für Ihre spezifischen Schriftarten automatisch berechnen.

Vorteile dieses Ansatzes

• Desktop-UX: Der Desktop wird beim First Paint mit dem Webfont gerendert, was sowohl FOUT als auch FOIT verhindert. Null Layoutverschiebungen durch das Laden von Schriftarten.
• Mobile Performance: font-display: swap stellt sicher, dass Nutzer Text sofort sehen, auch wenn die benutzerdefinierte Schriftart noch nicht geladen ist. Kein Preload bedeutet, dass Schriftarten nicht mit dem LCP-Bild um Bandbreite konkurrieren.
• Deklarative Einfachheit: Reines HTML und CSS. Kein JavaScript, keine Font-Loading-Bibliotheken, keine Framework-Abhängigkeiten. Das bedeutet auch, dass es mit jeder Ressourcen-Priorisierungsstrategie funktioniert, die Sie bereits implementiert haben.

Auswirkungen in der Praxis

Diese Strategie basiert auf einem Praxisbeispiel, auf das ich bei der Prüfung einer E-Commerce-Website gestoßen bin. Die Website lud 3 benutzerdefinierte Schriftarten: eine Überschriftenschriftart, eine Fließtextschriftart und eine Icon-Schriftart. Auf dem Desktop wurde alles schnell genug geladen, sodass die Schriftarten selten Probleme verursachten. Aber auf Mobilgeräten über 4G konkurrierten die drei Font-Preloads mit dem Hero-Bild und drückten den LCP deutlich über die Schwelle von 2,5 Sekunden.

Nach der Implementierung der responsiven Strategie (Preloading nur auf dem Desktop, Entfernung der Font-Preloads auf Mobilgeräten):

• Desktop: Verbesserter CLS und bessere UX, da formatierte Schriftarten beim First Paint erscheinen. Die Kombination aus Preload und font-display: optional eliminierte alle schriftartenbedingten Layoutverschiebungen.
• Mobile: Schnellerer First Contentful Paint und Largest Contentful Paint, da die Schriftarten nicht mehr um frühe Bandbreite konkurrierten. Das Hero-Bild wurde ohne Konkurrenz geladen.

Untersuchungen von DebugBear bestätigen die Auswirkungen: Font-Preloading kann den LCP um etwa 30 % verbessern (von 1,82 s auf 1,24 s), wenn es richtig angewendet wird. Aber bei übermäßiger Nutzung (eine Website hatte 38 per Preload geladene Schriftarten) macht Preloading die Dinge schlimmer. Der responsive Ansatz bietet Ihnen den Vorteil des Preloadings auf dem Desktop ohne die Nachteile auf Mobilgeräten.

Über die von CoreDash überwachten Websites hinweg bestehen etwa 82 % der mobilen Seitenaufrufe den LCP, wenn Schriftarten strategisch per Preload geladen werden, verglichen mit 70 % bei Seiten, die alle Schriftarten unabhängig vom Gerätetyp auf die gleiche Weise laden. Auf dem Desktop, wo die Kombination aus Preload und optional am besten funktioniert, ist die Lücke noch größer.

Wann Sie diese Strategie anwenden sollten (und wann nicht)

Verwenden Sie diese Strategie, wenn:

• Ihre Website 2 oder mehr benutzerdefinierte Schriftartdateien lädt
• Mobile und Desktop unterschiedliche Core Web Vitals-Leistungsprofile aufweisen (häufig auf Websites, bei denen Mobile mit dem LCP kämpft, während Desktop besteht)
• Schriftarten auf Mobilgeräten mit anderen kritischen Ressourcen (Hero-Bilder, kritisches CSS) konkurrieren
• Sie Ihre Schriftarten selbst hosten (diese Strategie funktioniert mit jedem Font-Hosting, aber das Self-Hosting gibt Ihnen die volle Kontrolle über den Preload-Pfad)

Überspringen Sie diese Strategie, wenn:

• Sie nur eine leichte WOFF2-Schriftart (unter 20 KB) laden. Der Overhead des responsiven Ladens lohnt sich nicht.
• Ihre Website bereits alle Core Web Vitals sowohl auf Mobile als auch auf dem Desktop besteht. Fügen Sie keine Komplexität für ein Problem hinzu, das Sie nicht haben.
• Sie auf Systemschriftarten setzen. Wenn Sie bereits font-family: system-ui, sans-serif verwenden, gibt es nichts zu optimieren.

Nach der Implementierung dieser oder einer anderen Font-Loading-Strategie sollten Sie die Auswirkungen mit Real User Monitoring überwachen, um zu bestätigen, dass die Änderung Ihre Felddaten tatsächlich verbessert hat. Labortests können die Variabilität echter Netzwerkbedingungen übersehen, die diese Strategie überhaupt erst wertvoll macht.