Menü-Schriftarten laden: Layout-Verschiebungen und unsichtbaren Text vermeiden

Du hast Stunden damit verbracht, die perfekte Schriftart für deinen Shop auszuwählen. Die Menü-Beschriftungen verwenden eine benutzerdefinierte serifenlose Schrift, die genau deiner Marke entspricht. Aber jedes Mal, wenn du deinen Shop auf Mobilgeräten testest, siehst du einen Blitz unsichtbaren Textes dort, wo das Menü sein sollte, gefolgt von einer Layout-Verschiebung, wenn die Schriftart endlich lädt. Dein CLS-Wert liegt bei 0,18, was Google als „verbessert werden” markiert, und du vermutest, dass die Menü-Schriftart der Schuldige ist.

Das Problem liegt nicht an der Schriftart selbst. Das Problem liegt darin, wie der Browser die Schriftart lädt. Standardmäßig verstecken die meisten Browser Text, bis benutzerdefinierte Schriftarten heruntergeladen sind, was auf einer langsamen Mobilverbindung 300 bis 800 Millisekunden dauern kann. Der Menü-Bereich bleibt leer, die Seite sieht beschädigt aus, und wenn die Schriftart endlich erscheint, verschiebt sie alles darunter. Dies beeinträchtigt sowohl LCP (weil bedeutsamer Inhalt verzögert wird) als auch CLS (weil sich das Layout bewegt).

Dieser Artikel erklärt die fünf font-display-Strategien, welche für Navigationsmenüs am besten geeignet ist, und wie man Schriftarten-Laden implementiert, das weder deine Marke noch deine Core Web Vitals beschädigt.

Die zwei Probleme beim Schriftarten-Laden: FOIT und FOUT

Wenn ein Browser auf eine benutzerdefinierte Web-Schriftart stößt, muss er entscheiden, was mit Text geschieht, der diese Schriftart verwendet, während die Schriftart-Datei noch heruntergeladen wird. Es gibt zwei mögliche Verhalten, jedes mit Vor- und Nachteilen.

Flash of Invisible Text (FOIT)

Der Browser versteckt den Text, bis die Schriftart lädt. Der Textbereich ist reserviert, aber nichts wird angezeigt. Wenn die Schriftart 500 Millisekunden zum Herunterladen braucht, starrte der Benutzer eine halbe Sekunde lang auf leeren Platz. Dies ist das Standardverhalten in den meisten Browsern.

FOIT ist schlecht für LCP, weil bedeutsamer Textinhalt erst dann sichtbar ist, wenn die Schriftart geladen ist. Es ist auch schlecht für die Benutzerfreundlichkeit—Benutzer können das Menü nicht lesen, was sie denken lassen könnte, dass die Seite beschädigt ist.

Flash of Unstyled Text (FOUT)

Der Browser zeigt den Text sofort mit einer Fallback-Schriftart (normalerweise eine Systemschriftart wie Arial oder Helvetica) an und wechselt dann zur benutzerdefinierten Schriftart, sobald sie lädt. Der Text ist sofort lesbar, aber der Wechsel kann eine Layout-Verschiebung verursachen, wenn die Fallback-Schriftart und die benutzerdefinierte Schriftart unterschiedliche Abmessungen haben.

FOUT ist besser für LCP (Text erscheint sofort), kann aber CLS beeinträchtigen, wenn es nicht sorgfältig behandelt wird. Der Schlüssel ist, die Abmessungen der Fallback-Schriftart so nah wie möglich an der benutzerdefinierten Schriftart zu stellen.

Die fünf font-display-Strategien

Die font-display CSS-Eigenschaft kontrolliert, wie Browser die Schriftarten-Ladezeit handhaben. Es gibt fünf mögliche Werte, jede mit unterschiedlichem Timing und Fallback-Verhalten.

Für Navigationsmenüs ist font-display: swap in den meisten Fällen die richtige Wahl. Es macht das Menü sofort lesbar (gut für LCP und Benutzerfreundlichkeit) und wechselt zur Marken-Schriftart, sobald sie lädt (gut für Markenidentität). Das Risiko ist eine Layout-Verschiebung, die wir gleich adressieren werden.

Wie man font-display in deinem Stylesheet verwendet

Wenn deine Schriftart in deinem CSS mit @font-face definiert ist, füge die font-display-Eigenschaft hinzu:

@font-face {
  font-family: 'BrandFont';
  src: url('/fonts/brandfont.woff2') format('woff2');
  font-display: swap;
}

.menu-link {
  font-family: 'BrandFont', -apple-system, BlinkMacSystemFont, 'Segoe UI', Arial, sans-serif;
}

Der font-family-Stack ist wichtig. Liste deine benutzerdefinierte Schriftart zuerst auf, dann Systemschriftarten als Fallbacks. Dies stellt sicher, dass der Menü-Text sofort in einer Systemschriftart erscheint und dann zu deiner benutzerdefinierten Schriftart wechselt, wenn sie lädt.

Wenn deine Schriftart von Google Fonts geladen wird, füge den display=swap-Parameter zur URL hinzu:

<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Inter:wght@400;600&display=swap">

Google Fonts wird automatisch font-display: swap in die generierte CSS einfügen.

Layout-Verschiebung mit Fallback-Schriftarten-Anpassung verhindern

Das Problem mit font-display: swap ist, dass, wenn die Fallback-Schriftart und die benutzerdefinierte Schriftart unterschiedliche Größen oder Abstände haben, der Text umfließt, wenn der Wechsel stattfindet, was zu einer Layout-Verschiebung führt. Dies ist besonders in Navigationsmenüs bemerkenswert, wo selbst eine kleine Verschiebung den gesamten Seiten-Inhalt bewegen kann.

Die Lösung ist, die Fallback-Schriftart an die Abmessungen der benutzerdefinierten Schriftart anzupassen, indem man die size-adjust-, ascent-override- und descent-override-Eigenschaften verwendet. Dies sind relativ neue CSS-Funktionen (seit 2024 in allen modernen Browsern unterstützt), mit denen du eine Fallback-Schriftart anpassen kannst, um einer benutzerdefinierten Schriftart zu entsprechen.

Hier ist ein Beispiel:

@font-face {
  font-family: 'BrandFont';
  src: url('/fonts/brandfont.woff2') format('woff2');
  font-display: swap;
}

@font-face {
  font-family: 'BrandFont Fallback';
  src: local('Arial');
  size-adjust: 107%;
  ascent-override: 95%;
  descent-override: 25%;
}

.menu-link {
  font-family: 'BrandFont', 'BrandFont Fallback', Arial, sans-serif;
}

Die size-adjust-Eigenschaft skaliert die Fallback-Schriftart, so dass ihre x-Höhe der benutzerdefinierten Schriftart entspricht. Die ascent-override- und descent-override-Eigenschaften passen den vertikalen Abstand an.

Die richtigen Werte zu finden erfordert Tests. Tools wie Fallback Font Generator von Simon Hearne automatisieren diesen Prozess. Du gibst deine benutzerdefinierte Schriftart ein, und das Tool berechnet die optimalen Override-Werte für häufige Systemschriftarten.

Das Anpassen von Fallback-Schriftarten auf diese Weise reduziert CLS von Schriftarten-Wechseln auf nahezu Null. Der Text wechselt immer noch von der Fallback zur benutzerdefinierten Schriftart, aber das Layout verschiebt sich nicht, da die Abmessungen identisch sind.

Systemschriftarten: Die kostenlose Alternative

Die schnellste Schriftart ist gar keine Schriftart—oder besser gesagt, eine Systemschriftart, die bereits auf dem Gerät des Benutzers installiert ist. Systemschriftarten haben Null Download-Kosten, Null Parse-Kosten und Null Layout-Verschiebungsrisiko.

Hier ist ein moderner Systemschriftarten-Stack, der auf allen Plattformen gut aussieht:

.menu-link {
  font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Oxygen, Ubuntu, Cantarell, 'Helvetica Neue', Arial, sans-serif;
}

Dies gibt dir:

• San Francisco auf macOS und iOS
• Segoe UI auf Windows
• Roboto auf Android
• Plattformgerechte Standards auf Linux

Systemschriftarten sind nicht so charakteristisch wie benutzerdefinierte Schriftarten, aber sie sind sauber, lesbar und für ihre Plattformen optimiert. Viele hochfrequentierte Websites (GitHub, Medium, WordPress.com) verwenden Systemschriftarten aus Leistungsgründen.

Wenn deine Marken-Richtlinien eine benutzerdefinierte Schriftart erfordern, erwäge, Systemschriftarten für das Navigationsmenü zu verwenden und die benutzerdefinierte Schriftart für Überschriften, Hero-Text oder Body-Text zu reservieren, wo sie mehr visuellen Einfluss hat. Das Menü ist funktionale UI. Es muss die Marke nicht so stark tragen wie eine Überschrift.

Schriftarten Preloading, um FOUT-Dauer zu reduzieren

Selbst mit font-display: swap gibt es eine Verzögerung zwischen dem Erscheinen des Fallbacks und dem Wechsel zur benutzerdefinierten Schriftart. Bei einer langsamen Verbindung kann dies 500 Millisekunden oder mehr sein. Das Preloading der Schriftart-Datei teilt dem Browser mit, sie mit hoher Priorität früh beim Seiten-Laden zu holen, was die Wechsel-Verzögerung reduziert.

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

Das crossorigin-Attribut ist erforderlich, auch wenn die Schriftart auf deinem eigenen Domain gehostet wird, da Schriftarten mit CORS-Modus abgerufen werden.

Preloading eliminiert FOUT nicht, reduziert aber die Dauer. Wenn deine Menü-Schriftart klein ist (unter 50KB) und für die Marke entscheidend, kann Preloading die wahrgenommene Performance verbessern.

Vorsicht: Preloading konkurriert mit anderen kritischen Ressourcen wie CSS und JavaScript. Lade nur Schriftarten vor, die über dem Falz verwendet werden und wirklich notwendig sind. Zu viele Ressourcen vorzuladen kann das anfängliche Rendering verlangsamen.

Icon-Schriftarten vs Inline SVG

Viele Navigationsmenüs verwenden Icon-Schriftarten (Font Awesome, Remix Icon, Material Icons) für Pfeile, Such-Icons und Hamburger-Icons. Icon-Schriftarten sind einfach Schriftarten, daher haben sie dieselben Lade-Charakteristiken wie Text-Schriftarten: standardmäßig FOIT, Layout-Verschiebungsrisiko und Download-Kosten (oft 50-150KB für eine vollständige Icon-Schriftart).

Inline SVG ist eine bessere Wahl für Menü-Icons. Ein Inline SVG ist Teil des HTML, daher erscheint es sofort ohne Netzwerk-Anfrage und ohne Schriftarten-Lader-Verzögerung. Es skaliert auch perfekt und unterstützt CSS-Styling.

Hier ist ein Beispiel:

<button class="menu-toggle" aria-label="Open menu">
  <svg width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2">
    <line x1="3" y1="12" x2="21" y2="12"></line>
    <line x1="3" y1="6" x2="21" y2="6"></line>
    <line x1="3" y1="18" x2="21" y2="18"></line>
  </svg>
</button>

Dieses Hamburger-Icon ist 200 Bytes. Eine vollständige Icon-Schriftart mit 2.000 Icons, die du nie verwenden wirst, ist 150KB. Inline SVG eliminiert auch das FOIT-Problem—das Icon erscheint sofort, da es Teil des HTML ist.

Moderne Menü-Apps wie Navi+ verwenden Inline SVG für alle Icons, was einer der Gründe ist, warum sie die Layout-Verschiebungs-Probleme vermeiden, die Icons-Schriftarten-basierte Menüs plagen.

Shopify-spezifisches Schriftarten-Laden

Shopify-Themes laden normalerweise Schriftarten auf eine von drei Arten: von Google Fonts, von Shopifys CDN (über den Theme-Settings-Schriftarten-Picker) oder von benutzerdefinierten Schriftart-Dateien im Theme-Assets-Ordner.

Google Fonts

Wenn dein Theme Google Fonts verwendet, stelle sicher, dass der display=swap-Parameter in der URL ist. Überprüfe theme.liquid auf eine Zeile wie diese:

<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Inter:wght@400;600">

Ändere es zu:

<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Inter:wght@400;600&display=swap">

Shopify CDN-Schriftarten

Wenn dein Theme Shopifys eingebauten Schriftarten-Picker verwendet (Einstellungen > Typografie), bedient Shopify die Schriftarten von seinem CDN und schließt automatisch font-display: swap ab 2023 ein. Du musst nichts tun.

Benutzerdefinierte Schriftart-Dateien

Wenn du benutzerdefinierte Schriftart-Dateien in deinen Theme-Assets-Ordner hochgeladen hast, füge font-display: swap zur @font-face-Deklaration in deinem CSS hinzu.

Messung von Schriftarten-Lade-Auswirkungen

Verwende Chrome DevTools, um zu sehen, wie Schriftarten dein LCP und CLS beeinflussen.

Überprüfung auf FOIT

Öffne DevTools, gehe zur Netzwerk-Registerkarte, filtere nach „Schriftart” und lade die Seite neu. Beobachte den Menü-Bereich. Wenn der Menü-Text für einen merklichen Zeitraum unsichtbar ist, bevor er erscheint, hast du FOIT. Füge font-display: swap hinzu, um es zu beheben.

Überprüfung auf Layout-Verschiebung

Öffne DevTools, gehe zur Leistungs-Registerkarte, klicke auf Aufzeichnung, lade die Seite neu und stoppe die Aufzeichnung. Schaue dir die Experience-Sektion auf rote „Layout Shift”-Balken an. Klicke auf einen, um zu sehen, welche Elemente verschoben wurden. Wenn der Menü-Text aufgelistet ist, verursachte der Schriftarten-Wechsel eine Layout-Verschiebung. Verwende Fallback-Schriftarten-Anpassung, um es zu beheben.

CLS messen

Führe einen Lighthouse-Test aus (in DevTools oder PageSpeed Insights). Schaue dir den CLS-Wert und die „Vermeide große Layout-Verschiebungen”-Diagnose an. Wenn Schriftarten als Ursache aufgelistet sind, brauchst du bessere Fallback-Anpassung oder solltest Systemschriftarten in Betracht ziehen.

Schneller GewinnWenn dein Menü eine benutzerdefinierte Schriftart verwendet und du siehst CLS-Probleme, versuche, zu einem Systemschriftarten-Stack als Test zu wechseln. Führe Lighthouse erneut aus. Wenn CLS deutlich sinkt, war die benutzerdefinierte Schriftart das Problem. Du kannst dann entscheiden, ob der Markenwert der benutzerdefinierten Schriftart die Performance-Kosten wert ist, oder implementiere Fallback-Anpassung, um beides zu bekommen.

Wie gutes Menü-Schriftarten-Laden aussieht

Ein optimiertes Navigationsmenü behandelt Schriftarten auf eine von zwei Arten.

Option 1: Systemschriftarten. Keine benutzerdefinierten Schriftarten, Null Download-Kosten, Null FOIT, Null Layout-Verschiebung. Das Menü erscheint sofort mit systemeigenen aussehenden Text.

.menu-link {
  font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Arial, sans-serif;
}

Option 2: Benutzerdefinierte Schriftart mit Swap und Fallback-Anpassung. Der Menü-Text erscheint sofort in einer Systemschriftart, wechselt dann zur benutzerdefinierten Schriftart ohne Layout-Verschiebung.

@font-face {
  font-family: 'BrandFont';
  src: url('/fonts/brandfont.woff2') format('woff2');
  font-display: swap;
}

@font-face {
  font-family: 'BrandFont Fallback';
  src: local('Arial');
  size-adjust: 107%;
}

.menu-link {
  font-family: 'BrandFont', 'BrandFont Fallback', Arial, sans-serif;
}

Beide Ansätze führen zu einem Menü, das in der ersten Sekunde des Seiten-Ladens lesbar ist, das ist das, was LCP misst. Der erste Ansatz ist einfacher und schneller. Der zweite Ansatz bewahrt Markenidentität mit minimalen Performance-Kosten.

Für Icons verwende Inline SVG statt Icon-Schriftarten. Die Icons erscheinen sofort, skalieren perfekt und kosten ein paar hundert Bytes statt 150KB.

Die meisten Shops, die vom Standard-Schriftarten-Laden (FOIT, keine Fallback-Anpassung) zu einem dieser Muster wechseln, sehen CLS um 0,05 bis 0,15 Punkte sinken und LCP um 200 bis 400 Millisekunden auf Mobilgeräten verbessern. Das Menü sieht für den Benutzer gleich aus, aber der Browser rendert es schneller und reibungsloser.

Dieser Artikel ist Teil des größeren Leitfadens zum Thema Menü und LCP: wie Navigation dein größtes inhaltsreiches Element blockiert.