Reduziere die Schriftarbeit, die jede Route vom Browser verlangt
Erfasse Cold‑Cache‑Font‑Anfragen auf Startseite, Conversion‑Seiten, eingeloggten Ansichten und Templates mit unterschiedlichen Designsystemen. Notiere Familie, Gewicht, Stil, Datei, Herkunft, Übertragungsgröße und Selektor. Eine deklarierte @font-face‑Regel löst nicht automatisch einen Download aus; ein Browser lädt eine Face normalerweise, wenn das aktuelle Layout sie verwendet. Das macht ungenutzte globale Gewichte und Stile zu den ersten Kandidaten für das Entfernen.
Verwende Custom Type dort, wo sie echten Markenwert liefert, häufig in Display‑Überschriften, und erwäge für normalen Fließtext einen System‑Stack, wenn das Design es zulässt. Gehe nicht davon aus, dass eine Variable Font immer kleiner ist: Sie kann mehrere statische Dateien ersetzen, aber größer sein als eine einzelne statische Face. Vergleiche die komprimierten Assets, die die Route tatsächlich anfordert.
Entferne Familien, Gewichte, Kursiven und Icon‑Schriften, die keine getestete, routenbezogene Verwendung haben.
Prüfe vor Änderungen, ob die Lizenz Web‑Auslieferung, Subsetting und Self‑Hosting erlaubt.
Verwende WOFF2 und subsette, ohne benötigte Zeichen zu entfernen
Beginne mit WOFF2 als Basis für moderne Browser. Die W3C‑Empfehlung beschreibt WOFF2 als ein Webfont‑Container mit verbesserter Kompression und schneller Dekompression; er ist in großen Browsern implementiert. Halte andere Formate nur für dokumentierte Legacy‑Browser‑Bedürfnisse vor; sonst ist ein gut gestalteter Fallback der sicherere Kompatibilitätsweg.
Subsetting erzeugt eine kleinere Datei mit ausgewählten Glyphe‑Mengen (Zeichenformen). unicode-range kann Subsets mit Zeichengruppen verknüpfen, sodass der Browser eine relevante Datei wählt, während er Text matched. Baue Subsets aus realen Seiten und den Sprachen, die du unterstützt, inklusive Interpunktion, Währungen, Namen, juristischem Text und nutzergetippten Skripten. Fehlende Glyphen sind ein Korrektheitsproblem, kein vertretbares Einsparziel.
Teste repräsentative lokalisierte Seiten und Formulareingaben, nicht nur englische Designbeispiele.
Stelle sicher, dass unicode-range sowie Gewicht/Style‑Angaben zu der deployten Datei passen.
Falleback und font-display gemeinsam gestalten
Eine Fallback‑Schrift ist das, was Nutzer sehen, wenn die Custom Face noch nicht bereitsteht. Wähle sie nach ähnlichen Proportionen und vergleiche reale Überschriften, mehrzeilige Buttons, Navigation, Tabellen, Formulare und lange lokalisierte Strings. Unterschiedliche Breiten ändern Umbrüche; verschiedene Ascent/Descent oder line‑gap ändern Blockhöhen. Beides kann bereits sichtbare Inhalte verschieben.
font-display definiert das Rendering‑Verhalten, solange eine Face nicht verfügbar ist. optional hat eine sehr kurze Block‑Periode und keine Swap‑Periode und eignet sich daher für Fließtext, wenn ein stabiler Fallback auf der ersten Ansicht wichtiger ist. swap zeigt schnell einen Fallback und kann später die Webfont anwenden, sollte aber nur dort verwendet werden, wo ein späteres Ersetzen keinen störenden Reflow verursacht. Block oder fallback sollten aus einem getesteten Design‑Grund eingesetzt werden, nicht als globale Vorgabe. CSS size-adjust kann helfen, Metriken eines Fallbacks zu justieren, aber prüfe jede unterstützte Schrift und Viewport visuell.
Lass Zahlungs-, Wiederherstellungs-, Konto-, Sicherheits‑ oder Navigations‑Texte nicht von einer verspäteten Custom Font abhängig sein.
Ein ersetzender Buchstabe kann die falsche Bedeutung vermitteln; SVG‑Icons sind für Interface‑Symbole in der Regel sicherer.
Verbessere Discovery, aber zügele Preload und prüfe Datenflüsse
Eine Face, die nur in einem externen Stylesheet deklariert ist, kann erst entdeckt werden, nachdem dieses Stylesheet geladen und geparst wurde. Wartbares, früh kritisches CSS kann notwendige Deklarationen früher sichtbar machen; inlined die Font‑Binärdatei nicht, das macht das Dokument größer. Für eine Third‑Party‑Quelle kann preconnect die Verbindung früher aufbauen. Font‑Requests sind CORS‑Ressourcen, daher benötigen cross‑origin Auslieferung und Preloads korrektes crossorigin‑Handling.
Preload ist eine Prioritätsüberschreibung, kein universeller Geschwindigkeitshebel. Es kann mit anderer kritischer Arbeit konkurrieren und eine Face herunterladen, die eine Route nie benötigt; es umgeht außerdem unicode-range‑Selektion. Behebe späte Discovery zuerst, preload dann höchstens eine nachgewiesene First‑View‑Datei mit der exakten URL, as=font und crossorigin. Google Fonts erklärt, dass API‑Anfragen die Besucher‑IP, die angeforderte URL, HTTP‑Header und Referer enthalten; außerdem gibt Google an, dass die API keine Cookies setzt oder protokolliert und die gesammelten Informationen nicht für Profile oder zielgerichtete Werbung nutzt. Self‑Hosting verhindert, dass Google diese Daten für diese Loads erhält. Beurteile Auslieferung, Datenschutzhinweis, Rechtsraum, Verträge und ziehe bei Bedarf qualifizierte Beratung hinzu.
Vergleiche Cold‑Cache‑Traces und bestätige, dass die vorgeladene Datei auf der Route verbraucht wird.
Bewerte Connection‑Setup, Cache-/CDN‑Fähigkeiten, Asset‑Wartung und Besucher‑Datenflüsse.
Versioniere Font‑Assets und bewahre eine getestete CSS‑Fallback‑Konfiguration.
Teste gerendertes Verhalten und betreibe Schriften als Resilienz‑Abhängigkeit
Untersuche bei Cold‑Cache mit den Browser‑Netzwerktools die Kette von CSS‑zu‑Font‑Anfragen, Timing, Herkunft, Caching und Fehler. Wiederhole die Prüfung auf einer eingeschränkten Verbindung, dann throttle oder blockiere die Schrift. Erfolg bedeutet: lesbarer Text, nutzbare Controls, korrekte Symbole und kohärentes Layout bevor die Custom Face erscheint. Teste realistische schmale und Desktop‑Layouts, lange Strings, Fehlermeldungen, Consent‑Texte, Preise und alle unterstützten Skripte.
In Chromium zeichne ein Reload im Performance‑Panel auf und untersuche die Layout Shifts‑Spur; DevTools identifizieren verschobene Elemente und animieren die Verschiebung. Font‑Loading ist ein bekannter Verursacher, aber ein verschobenes Element ist nicht zwangsläufig die Wurzelursache, daher korreliere das Trace mit dem Zeitpunkt der Font‑Anwendung. Die Layout Instability API ist Chromium‑exklusiv, daher sind visuelle Checks in mehreren Browsern wichtig. Beziehe Font‑Assets, CORS‑Verhalten, Cache‑Policy, Fallbacks und Rollback in die Release‑Review ein. Der angestrebte Degradierungsmodus ist lesbarer Text, nicht leere Inhalte oder gebrochene Navigation.
Ein warmer Cache kann die initiale Anfrage und das Rendering‑Problem verschleiern.
Wiederhole die Prüfung, wenn Dateien, CMS‑Texte, Templates, Provider oder CDN‑Regeln sich ändern.