Optimieren Sie Webfonts, indem Sie nur benötigte Glyphen und Stile laden, Text während des Downloads lesbar halten und eine passende Ersatzschrift wählen. WOFF2, Subsets und gezielter Preload verbessern Übertragung und Entdeckung. font-display und Ersatzschriftmetriken steuern die Darstellung. Messen Sie frühe Lesbarkeit und Layoutstabilität gemeinsam: Ein schneller Download verhindert allein keinen verschiebenden späten Schriftwechsel.
Finden Sie die Verzögerung vor dem Schriftwechsel
Webfonts werden üblicherweise über CSS entdeckt. Der Browser muss Stylesheet und @font-face verarbeiten und den benötigten Schriftschnitt bestimmen, bevor er ihn anfordert. Ein langsames Stylesheet oder eine Importkette kann deshalb eine kleine Schriftdatei verzögern.
Filtern Sie Schriftanfragen im Network-Panel und prüfen Sie deren Initiator. Notieren Sie das auslösende Stylesheet und ob die Schrift im ersten Viewport gebraucht wird. Kontrollieren Sie in DevTools tatsächlich dargestellte Schriften, statt die erste CSS-Familie für alle Zeichen anzunehmen.
Ein Satz kann mehrere Ersatzschriften verwenden, wenn Glyphen fehlen. Das betrifft Satzzeichen, Währungen, Namen und gemischte Sprachen. Ein korrekter lateinischer Absatz beweist keine vollständige koreanische oder hebräische Abdeckung.
Beobachten Sie einen langsamen Aufruf ohne Cache. Unsichtbarer Text deutet auf die Darstellungsstrategie, wechselnde Breite auf unpassende Metriken und eine späte Anfrage auf Entdeckung hin. Nutzen Sie den LCP-Leitfaden bei großem Text als LCP-Element und den CLS-Leitfaden bei Verschiebungen.
Begrenzen Sie Schriftschnitte und Glyphen
WOFF2 ist ein üblicher Ausgangspunkt für moderne Browser. Behalten Sie Quelldateien im Build, liefern Sie alte Formate aber nur bei tatsächlichem Kompatibilitätsbedarf. Prüfen Sie die Lizenz vor Selbsthosting, Änderungen und Subsetting. Ein herunterladbarer Font erlaubt nicht automatisch die Verbreitung einer Ableitung.
Inventarisieren Sie Familien, Gewichte und Stile. Das Design benötigt möglicherweise nicht jeden verfügbaren Schnitt. Entfernen Sie unnötige Deklarationen und Anfragen an der Quelle. Kontrollieren Sie anschließend Fett- und Kursivtext, damit der Browser keine unerwarteten synthetischen Stile erzeugt.
Subsetting erstellt kleinere Dateien mit bestimmten Glyphen und nötigen Darstellungstabellen. unicode-range beschreibt die Codepunkte eines Schriftschnitts, entfernt aber keine Glyphen aus der Datei. Für weniger Übertragungsbytes muss die referenzierte Datei selbst ein geeignetes Subset sein.
Diese beispielhafte lateinische Deklaration setzt eine vorhandene Datei mit der angegebenen Zeichenabdeckung voraus.
@font-face {
font-family: "Editorial Sans";
src: url("/fonts/editorial-sans-latin-regular.woff2") format("woff2");
font-style: normal;
font-weight: 400;
font-display: swap;
unicode-range: U+0000-00FF;
}
body {
font-family: "Editorial Sans", Arial, sans-serif;
}Der Bereich ist keine vollständige mehrsprachige Strategie. Er lässt viele Zeichen aus und eignet sich nicht als einziges Subset für diese sechs Sprachen. Prüfen Sie Formung, Satzzeichen und erforderliche Markierungen im Build. Eine deklarierte Abdeckung erzeugt keine fehlenden Glyphen.
Halten Sie die Grenzen wartbar. Ein winziger Font pro Artikel kann lokal sparen, aber Wiederverwendung zwischen Seiten und Pflege verschlechtern. Für wechselnde redaktionelle Inhalte sind stabile Sprach- oder Schriftsubsets oft ein handhabbarer Einstieg. Messen Sie tatsächliche Anfragen, bevor Sie weiter aufteilen.
Wählen Sie font-display als Lesestrategie
font-display ist ein Deskriptor innerhalb von @font-face. Er steuert Text, solange dieser Schnitt fehlt. Eine Angabe auf body konfiguriert keinen Schriftschnitt. Die Wahl beeinflusst sofortige Lesbarkeit, spätere Verwendung der Wunschschrift und sichtbaren Austausch.
Die Zeitfenster werden vom Browser bestimmt und sind keine überall exakten Zeitgarantien.
| Wert | Praktisches Verhalten | Hauptkompromiss |
|---|---|---|
auto |
Browser entscheidet | Weniger ausdrückliche Kontrolle am Anfang |
block |
Kurze Blockphase, unbegrenzte Austauschphase | Text kann zunächst unsichtbar bleiben |
swap |
Extrem kurze Blockphase, unbegrenzter Austausch | Frühe Lesbarkeit, möglicher später Sprung |
fallback |
Sehr kurze Blockphase, kurze Austauschphase | Wunschschrift wird nach dem Fenster eventuell nicht eingesetzt |
optional |
Sehr kurze Blockphase ohne Austauschphase | Ersatzschrift kann für den Besuch bleiben |
swap lässt die Wunschschrift später erscheinen, löst CLS aber nicht automatisch. Andere Zeichenbreiten und Zeilenmetriken können Umbrüche und nachfolgenden Inhalt verschieben. optional kann einen späten Austausch vermeiden; das Design muss dann in der Ersatzschrift überzeugen.
Ein dekorativer Schriftzug und ein langer Artikel können unterschiedliche Entscheidungen verlangen. Machen Sie Fließtext nicht für eine Markenpräferenz unlesbar. Prüfen Sie tatsächliche Inhalte und Geräte. Was mit gecachter Schrift gut wirkt, kann beim ersten Besuch stören.
Die Referenz zu font-display beschreibt die Auswahl. Testen Sie anschließend normale und blockierte Schriftanfragen, damit der Ersatz bewusst gestaltet ist.
Laden Sie nur wirklich kritische Schriften vor
Preload kann die Anfrage gegenüber normaler CSS-Entdeckung vorziehen. Er beansprucht aber frühe Bandbreite, um die HTML, CSS und LCP-Bild konkurrieren. Alle Gewichte und Sprachsubsets vorzuladen unterläuft die bedarfsgesteuerte Auswahl.
Hier wird ein im ersten Viewport benötigter Schnitt mit exakt derselben URL in CSS vorgeladen.
<link rel="preload"
href="/fonts/editorial-sans-latin-regular.woff2"
as="font" type="font/woff2" crossorigin>
<style>
@font-face {
font-family: "Editorial Sans";
src: url("/fonts/editorial-sans-latin-regular.woff2") format("woff2");
font-style: normal;
font-weight: 400;
font-display: swap;
}
</style>Font-Preloads benötigen den passenden CORS-Modus, auch beim Selbsthosting. Bei fremdem Ursprung muss zusätzlich die Antwort die Anfrage erlauben. Stimmen URL, Typ und Modus überein, kann der Browser den Preload statt eines zweiten Downloads nutzen.
Preload wendet die Schrift nicht an. Prüfen Sie zeitnahe Nutzung und Warnungen über ungenutzte Preloads in der Konsole. Vergleichen Sie Wasserfälle vorher und nachher. Eine frühere Schrift kann ein schlechter Tausch sein, wenn sie ein wichtigeres Bild verzögert.
Bei externen Diensten prüfen Sie Stylesheet- und Fontursprung getrennt. Gezieltes Preconnect kann den Verbindungsaufbau verkürzen, beseitigt aber weder CSS-Entdeckung noch garantiert es einen Vorteil. Verbinden Sie nicht vorsorglich jede externe Domain.
Passen Sie Ersatzschriftmetriken an
Ähnlich aussehende Schriften können verschieden viel Platz beanspruchen. Vergleichen Sie Zeichenbreiten, x-Höhe, Ober- und Unterlängen sowie Zeilenabstand. Ein zusätzlicher Zeilenumbruch ist häufig wichtiger als eine kleine Formabweichung, weil er den gesamten Folgeinhalt verschiebt.
size-adjust skaliert Konturen und Metriken. ascent-override, descent-override und line-gap-override passen vertikale Werte an. Ermitteln Sie Werte für das konkrete Schriftpaar; universelle Prozentwerte gibt es nicht.
Das folgende Beispiel demonstriert Syntax mit illustrativen Werten, keine kalibrierte Anpassung an eine reale „Editorial Sans“. Ersetzen Sie sie nach Messung Ihrer Schriften.
@font-face {
font-family: "Editorial Fallback";
src: local("Arial");
size-adjust: 100%;
ascent-override: 90%;
descent-override: 22%;
line-gap-override: 0%;
}
.article-body {
font-family: "Editorial Sans", "Editorial Fallback", sans-serif;
line-height: 1.6;
}Die lokale Ersatzschrift muss auf dem Gerät vorhanden sein. Behalten Sie eine generische Familie am Ende und testen Sie Systeme ohne die benannte Schrift. Metriküberschreibungen verringern Unterschiede, garantieren aber keine identischen Umbrüche für jede Zeichenfolge.
Prüfen Sie Überschriften, lange Navigationslabels, Zahlen, Satzzeichen und Absätze. Verwenden Sie übersetzte Inhalte statt überall dieselbe englische Probe. Explizite Zeilenhöhe stabilisiert den Rhythmus, verhindert aber keine Umbrüche durch andere Glyphenbreiten.
Vergleichen Sie variable Fonts mit Ihrem Bedarf
Ein variabler Font kann Gewichtsbereiche oder andere Achsen in einer Datei abbilden und mehrere statische Schnitte ersetzen. Er ist deshalb nicht immer kleiner als die tatsächlich benötigten ein oder zwei statischen Dateien. Vergleichen Sie ausgelieferte Subsets und Achsen.
Diese Deklaration stellt Gewichte von 100 bis 900 bereit, sofern die Datei diesen Bereich unterstützt.
@font-face {
font-family: "Editorial Variable";
src: url("/fonts/editorial-variable-latin.woff2") format("woff2");
font-style: normal;
font-weight: 100 900;
font-display: swap;
}
h1 { font-family: "Editorial Variable", sans-serif; font-weight: 650; }Deklarieren Sie keine nicht vorhandenen Achsenbereiche. Prüfen Sie Kursivschrift gesondert und beachten Sie die dokumentierte Verwendung. Wenn Buildwerkzeuge Achsen beschneiden, kontrollieren Sie Darstellung und Funktion. Eine entfernte Achse kann das Design unauffällig verändern.
Planen Sie Koreanisch, Hebräisch und Systemschriften
Koreanisch benötigt breitere Glyphenabdeckung als eine rein lateinische Oberfläche. Eine umfassende CJK-Datei kann groß sein; aggressive Seitensubsets können dynamische Inhalte, Namen und neue Beiträge auslassen. Erwägen Sie stabile Subsets, dokumentierte Dienstsegmentierung oder einen getesteten Systemstack. Prüfen Sie koreanische Seiten mit lateinischen Kürzeln und Zahlen.
Hebräisch benötigt passende Zeichen, Satzzeichen und unterstützte Markierungen sowie lateinische technische Begriffe. Eine Schrift setzt nicht die Dokumentrichtung. Trennen Sie RTL- und bidirektionales Verhalten von der Ladeeinstellung und testen Sie Codelabels, Zahlen und Satzzeichen im Zusammenhang.
Selbsthosting kontrolliert URLs, Cachepolitik und Aktualisierung. Ein Dienst kann Formate und Segmentierung übernehmen, ergänzt aber Stylesheets und Ursprünge. Keine Variante ist immer schneller. Vergleichen Sie reale Abhängigkeiten, Betriebsverantwortung und Datenschutzanforderungen.
Systemschriften sind eine vollwertige Designentscheidung. Sie vermeiden einen eigenen Download und können früh erscheinen, unterscheiden sich aber je Plattform in Aussehen und Metriken. Gestalten Sie einen bewussten Stack und testen Sie alle Schriften. Der eingesparte Download hilft nur bei weiterhin guter Lesbarkeit, Hierarchie und Zeichenabdeckung.
Prüfen Sie eine Änderung in realen Zuständen
Beginnen Sie mit einer Seite, deren erster Viewport durch Fonts beeinflusst wird. Dokumentieren Sie Anfragen, Beginn der Lesbarkeit und Textbewegung. Wiederholen Sie mit kaltem und warmem Cache sowie blockierten Fonts. Prüfen Sie bei entsprechenden Ausgaben mindestens eine koreanische und eine hebräische Seite.
Suchen Sie nach Änderungen an Schnitten, Subsets oder Preloads nach doppelten Downloads, fehlenden Glyphen und synthetischen Gewichten. Prüfen Sie Aufzeichnung und sichtbares Layout gemeinsam. Eine kleinere Datei ist ein Zwischenergebnis; lesbarer und stabiler Text ist das Ziel.
Notieren Sie Dateien und Darstellungsstrategie in der Performance-Checkliste. Bleibt die Entdeckung spät, folgen Sie der Analyse renderblockierender Ressourcen. Verankern Sie den Test in der Ladezeitoptimierung, damit spätere Designs keine unnötigen Schnitte oder instabilen Ersatzschriften zurückbringen.
