Webfonts sind auf den meisten Websites immer noch der einfachste Performance-Gewinn

Das Muster, das immer wieder auftaucht

Wenn Sie heute zehn zufällige Produktionswebsites auditieren, finden Sie auf den meisten ungefähr dieselbe Schrift-Situation:

• Sechs bis zehn Schriftdateien werden auf der Startseite geladen
• Alle davon in WOFF2 (gut), aber ohne font-display-Strategie (schlecht)
• Mehrere Gewichte und Stile, die nirgendwo auf der Seite verwendet werden
• Der gesamte Stack wird von einer Drittanbieter-Domain ausgeliefert (meist Google Fonts), mit allen DNS-, TLS- und Datenschutzkosten, die das mit sich bringt
• Kein Subsetting per unicode-range, sodass jeder Besucher kyrillische und griechische Glyphen herunterlädt, selbst wenn die Seite auf Englisch ist

Das ist kein Problem, das nur kleine Websites betrifft. Viele gut finanzierte Marketingseiten laden immer noch 600 KB Schriften, bevor der erste Absatz gezeichnet werden kann. Sobald man das Muster einmal bemerkt, kann man es nicht mehr übersehen.

Die Lösung ist nicht exotisch. Es sind ein paar gut verstandene Techniken, die seit Jahren in Browsern verfügbar sind.

Verwenden Sie eine Variable Font statt sechs statischer Dateien

Wenn Sie Inter Regular, Inter Medium, Inter SemiBold, Inter Bold und die jeweiligen Kursivschnitte laden, laden Sie grob sechsmal mehr Bytes herunter als nötig. Eine einzelne Variable Font von Inter deckt die gesamte Gewichtsachse ab (und in manchen Builds auch die Neigung), in einer Datei, die kaum größer ist als zwei statische Gewichte.

Die Browserunterstützung ist seit Jahren geklärt — Variable Fonts funktionieren überall, wo es relevant ist. Die verbleibende Zurückhaltung ist meist nur erlernte Gewohnheit aus der Ära statischer Schriften.

Eine praktische Faustregel: eine Variable-Font-Datei pro Schriftsystem und Familie. Latein in einer Datei, Kyrillisch in einer zweiten, Griechisch in einer dritten, bedingt geladen mit unicode-range. Das ist alles.

Setzen Sie ein sinnvolles font-display

Das Standardverhalten, während eine benutzerdefinierte Schrift noch lädt, ist: nichts anzeigen — unsichtbarer Text — für bis zu drei Sekunden. Das ist der schlechteste mögliche Default. Nutzer sehen eine leere Seite und gehen davon aus, dass etwas kaputt ist.

Fügen Sie dies jeder @font-face-Regel hinzu:

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter-var.woff2') format('woff2-variations');
  font-weight: 100 900;
  font-display: swap;
}

swap zeigt die Fallback-Schrift sofort an und tauscht sie gegen die benutzerdefinierte Schrift aus, sobald diese geladen ist. Der Nutzer kann die Seite ab Millisekunde null lesen. Der Kompromiss ist eine kurze Layoutverschiebung beim Austausch, die Sie mit der nächsten Technik abmildern.

Stimmen Sie Ihre Fallback-Metriken ab

Ein Flash of Unstyled Text wirkt nur dann störend, wenn Fallback- und benutzerdefinierte Schrift sehr unterschiedliche Metriken haben. Modernes CSS löst das mit size-adjust, ascent-override und verwandten Eigenschaften:

@font-face {
  font-family: 'Inter Fallback';
  src: local('Arial');
  size-adjust: 107%;
  ascent-override: 90%;
  descent-override: 22%;
  line-gap-override: 0%;
}

Mit abgestimmten Fallback-Metriken ist der Austausch kaum wahrnehmbar — Wörter nehmen vor und nach dem Laden der benutzerdefinierten Schrift denselben horizontalen Raum ein.

Googles Arbeit an --allow-fallback-font-metrics gehört inzwischen zur Baseline-Browserunterstützung, und es gibt Tooling-Pipelines (die Bibliothek fontaine und ähnliche), die Ihnen die richtigen Werte in Sekunden berechnen.

Selbst hosten

Google Fonts ist bequem, kostenlos und bringt zwei echte Kosten mit sich:

1. Einen zweiten TLS-Handshake. Selbst mit HTTP/3 und Connection Coalescing ist ein zusätzlicher Origin selten kostenlos.
2. Eine Datenschutz- und Compliance-Frage. Mehrere europäische Gerichte haben entschieden, dass das Laden von Google Fonts von fonts.gstatic.com die Übermittlung personenbezogener Daten (der IP-Adresse) an einen Dritten darstellt. Selbsthosting beseitigt diese Frage vollständig.

Die Download-und-Hosting-Pipeline lautet:

1. Die WOFF2-Datei beschaffen (den variablen Build, falls vorhanden)
2. Auf die Schriftsysteme subsetten, die Ihre Zielgruppe tatsächlich nutzt
3. Vom selben Origin ausliefern wie den Rest Ihrer Website, mit langem Cache-Control: max-age=31536000, immutable
4. Das kritischste Gewicht vorladen: <link rel="preload" as="font" type="font/woff2" href="/fonts/inter-var.woff2" crossorigin>

Das ist die ganze Pipeline. Für eine bestehende Website dauert es einen Nachmittag, und man geht fast nie zurück.

Wann man benutzerdefinierte Schriften ganz weglassen sollte

Es lohnt sich, das klar auszusprechen: Nicht jede Website braucht eine benutzerdefinierte Schrift. Der System-Font-Stack ist inzwischen auf jedem Betriebssystem wirklich schön:

font-family: system-ui, -apple-system, 'Segoe UI', Roboto, Inter, sans-serif;

Das Gewicht stimmt, die Metriken stimmen, das Rendering ist auf das Gerät abgestimmt, und die Kosten in übertragenen Bytes liegen bei genau null. Für eine Tool-Website, eine interne App, ein Portfolio, das Inhalte priorisiert, oder alles, was sich an Nutzer in langsamen Netzen richtet, ist der System-Stack die richtige Antwort.

<!-- tool-cta:start -->

💡 Probieren Sie das aus: Konvertieren Sie Ihre TTF- oder OTF-Dateien mit einsatzbereitem CSS in modernes WOFF2 mithilfe des Webfont Generator, was der im Beitrag empfohlene Formatwechsel ist.

<!-- tool-cta:end -->

Die ehrliche Zusammenfassung

Für eine typische kleine Website decken vier Schritte die gesamte Performance-Geschichte von Webfonts ab:

1. Eine Variable Font pro Familie und Schriftsystem
2. font-display: swap mit abgestimmten Fallback-Metriken
3. Selbst gehostet mit langen Cache-Headern und einem preload für das kritische Gewicht
4. Oder Schriften ganz weglassen und den System-Stack verwenden

Machen Sie das einmal, und Sie gewinnen mehrere hundert Kilobyte auf der Startseite zurück, verbessern die wahrgenommene Performance um einige hundert Millisekunden und entfernen nebenbei eine Drittanbieter-Abhängigkeit. Nur wenige Änderungen haben ein besseres Verhältnis von Aufwand zu Ertrag.