Webfonts optimieren: WOFF2, Subsetting und lokales Hosting
Webfonts kosten Requests, Datenvolumen und Renderzeit. Eine sparsame Einbindung lädt nur die genutzten Familien, Schnitte und Zeichen. WOFF2, Subsetting, definiertes Ladeverhalten und Fallback-Schriften bilden den technischen Kern.
Die schlankeste Lösung bleibt eine Systemschrift. Verlangen Markenbild oder Lesbarkeit einen Webfont, plant das Team den Umfang anhand des realen Einsatzes.
Font-Inventar vor dem Umbau erfassen
Zuerst dokumentierst du, welche Schriftdateien eine Seite lädt und wo sie erscheinen.
| Prüffeld | Frage |
|---|---|
| Familie | Welche Schriftfamilien erscheinen auf der Seite? |
| Schnitt | Braucht das Design Regular, Medium, Bold und Italic? |
| Zeichensatz | Welche Sprachen und Sonderzeichen nutzt die Website? |
| Quelle | Lädt der Browser lokal oder von einer fremden Domain? |
| Format | Liegt WOFF2 vor? |
| CSS | Welche @font-face-Regeln und Fallbacks greifen? |
| Messung | Wann startet der Request, wie groß ist die Datei, verschiebt sich das Layout? |
Browser-Entwicklungswerkzeuge zeigen Request, Dateigröße, Cache und Zeitpunkt. Lighthouse liefert technische Hinweise. Der Beitrag Core Web Vitals und mobile Nutzbarkeit trennt Labor- und Felddaten.
Nur benötigte Familien und Schnitte laden
Jede zusätzliche Schriftdatei verlangt einen eigenen Abruf oder vergrößert eine variable Datei. Pro Schriftschnitt prüfst du:
- →Welche Komponente nutzt den Schnitt?
- →Verlangt das Design diese Unterscheidung?
- →Deckt eine variable Achse mehrere Gewichte ab?
- →Ist Kursivschrift als eigener Schnitt erforderlich?
Synthetisch gefettete oder schräg gestellte Schriften weichen von gestalteten Schriftschnitten ab. Die Auswahl verbindet Design und Performance.
Statische und variable Fonts vergleichen
Ein statischer Font enthält meist einen festen Schnitt. Ein Variable Font kann mehrere Werte einer Achse in einer Datei bündeln, etwa Gewicht oder Breite.
Ein Variable Font ist nicht automatisch kleiner. Die Wahl hängt davon ab, wie viele Schnitte das Design nutzt und welche Glyphen die Datei enthält.
| Einsatz | Prüfregel |
|---|---|
| ein einzelner Schriftschnitt | statische Datei kann kleiner sein |
| mehrere Gewichte derselben Familie | variable Datei gegen Summe der statischen Dateien messen |
| mehrere Achsen | nur Achsen und Werte einsetzen, die das Design nutzt |
| breite Sprachabdeckung | Umfang vor und nach Subsetting vergleichen |
Du vergleichst beide Varianten auf denselben Seiten, Cache-Zuständen und Testgeräten.
WOFF2 als Webformat einsetzen
WOFF2 komprimiert Fontdaten für die Auslieferung im Web. Der Standard beschreibt Container und Kompression, nicht die lizenzrechtliche Erlaubnis zur Konvertierung oder zum Hosting.
@font-face {
font-family: "Example Sans";
src: url("/fonts/example-sans.woff2") format("woff2");
font-style: normal;
font-weight: 400;
font-display: swap;
}
Die Browsermatrix des Projekts entscheidet, ob ein weiteres Format erforderlich ist. Festgelegte Jahreszahlen ersetzen diese Prüfung nicht.
Zeichensätze mit Subsetting begrenzen
Subsetting entfernt ungenutzte Glyphen und Tabellen. Das reduziert die Dateigröße. Der Vorgang verlangt eine saubere Zeichenliste.
Die Liste erfasst Buchstaben, Satzzeichen, Währungszeichen, geschützte Leerzeichen, Akzente, Symbole und Eingabezeichen aus Formularen.
Sprachgruppen getrennt ausliefern
Das CSS-Attribut unicode-range ordnet Schriftdateien definierten Zeichenbereichen zu. Der Browser lädt die Datei, wenn die Zeichen auf der Seite erscheinen.
@font-face {
font-family: "Example Sans";
src: url("/fonts/example-sans-latin.woff2") format("woff2");
unicode-range: U+0000-00FF;
font-weight: 400 700;
font-display: swap;
}
Das Beispiel deckt einen Ausschnitt ab. Du leitest den Zeichenbereich aus den Inhalten und Sprachen der Website ab.
Lizenz vor dem Umbau prüfen
Nicht jede Schriftlizenz erlaubt Selbsthosting, Konvertierung oder Subsetting. Das Team dokumentiert Lizenz, Version und Bezugsquelle vor dem Build.
Rendering mit font-display steuern
font-display steuert, wie der Browser Text während des Abrufs anzeigt. Mögliche Werte sind swap, fallback und optional.
swap blendet direkt eine Ersatzschrift ein und tauscht sie nach dem Laden aus. Das vermeidet leere Flächen, kann jedoch Layout-Verschiebungen auslösen. optional erlaubt dem Browser, bei der Ersatzschrift zu bleiben. Die Wahl richtet sich nach Gestaltung, Lesbarkeit und Messdaten.
Fallback metrisch abstimmen
Fallback und Webfont verlangen abgestimmte Zeichenmaße. CSS-Eigenschaften wie size-adjust, ascent-override, descent-override und line-gap-override gleichen Abweichungen an.
Du prüfst die Darstellung an Überschriften, Fließtext, Buttons und Formularen. Schätzungen ersetzen den Test am Bildschirmelement nicht.
Preload nur für kritische Dateien nutzen
Ein Preload zieht den Abruf vorab genutzter Schriftdateien vor.
<link rel="preload" href="/fonts/example-sans.woff2" as="font" type="font/woff2" crossorigin>
Preload konkurriert mit anderen Laderessourcen. Du lädst nur Schriftdateien vor, die in der ersten Bildschirmansicht erscheinen. Pfad, CORS-Einstellung und @font-face-Quelle müssen exakt übereinstimmen.
Lokales Hosting technisch und rechtlich einordnen
Lokales Hosting belässt Schriftdatei, Cache-Regel und Auslieferung beim Betreiber. Es vermeidet Verbindungen zu externen Font-Servern. Die Ladezeit hängt von Cache, CDN und Protokoll ab.
Externe Font-Anbieter bauen Verbindungen zu Dritten auf. Das berührt Datenschutz und Einwilligungspflichten. Eine technische Anleitung ersetzt keine Rechtsberatung.
Bei lokalen Schriftdateien versionierst du Dateinamen und setzt Cache-Header. Lange Cache-Zeiten verlangen eigene URLs je Dateiversion.
Wirkung messen
Du prüfst die Ladezeit vor und nach dem Umbau unter identischen Bedingungen.
| Messpunkt | Aussage |
|---|---|
| Anzahl der Fontrequests | wie viele Schriftdateien der Browser abruft |
| übertragene Bytes | wie groß der Font-Payload im Test ausfällt |
| Start und Ende der Requests | wann Schriftdateien das Netzwerk belegen |
| Largest Contentful Paint (LCP) | ob das Hauptinhaltselement später erscheint |
| Cumulative Layout Shift (CLS) | ob der Schriftwechsel Layout-Verschiebungen erzeugt |
| Darstellung je Sprache | ob alle Zeichen im Zeichensatz vorliegen |
| Cache-Test | ob wiederkehrende Aufrufe Dateien erneut laden |
Ein geringerer Font-Payload senkt den Datentransfer der Schriftdatei. Aussagen zu Energieverbrauch oder Emissionen verlangen eine eigene Messmethode und Systemgrenze.
Abnahmecheck für Webfonts
- →Nur genutzte Familien, Schnitte und Achsen sind eingebunden.
- →Lizenz und Bezugsquelle sind dokumentiert.
- →WOFF2-Dateien funktionieren in der festgelegten Browsermatrix.
- →Das Subset deckt alle vorgesehenen Sprachen und Zeichen ab.
- →Fallback und Webfont erzeugen keine Layout-Verschiebung.
- →Preloads beschränken sich auf die erste Bildschirmansicht.
- →Cache-Header und Versionierung sind getestet.
- →Vorher- und Nachhermessung nutzen identische Testbedingungen.
Häufige Fragen zur Webfont-Optimierung
Ist ein Variable Font immer kleiner?
Nein. Ein Variable Font kann mehrere statische Schnitte ersetzen, enthält aber eigene Achsen und Glyphen. Ein Dateivergleich vor dem Einsatz schafft Klarheit.
Verhindert font-display: swap jeden Layout Shift?
Nein. swap blendet Text direkt ein, verändert beim Schriftwechsel jedoch oft die Zeilenmaße. Abgestimmte Fallback-Metriken mindern dieses Risiko.
Ist lokales Hosting immer schneller?
Nein. Lokales Hosting vermeidet externe Serveraufrufe und gibt Kontrolle über Cache und Dateien. Die Ladezeit hängt von der Gesamtauslieferung ab.
Sind kleinere Fonts automatisch nachhaltiger?
Nein. Sie reduzieren den Datentransfer der Datei. Aussagen zur Nachhaltigkeit verlangen eine eigene Messmethode.
Nächster Schritt
Der Hub Technisches SEO: Infrastruktur, Architektur und Jamstack ordnet Schriften in Auslieferung und Rendering ein. OLDSCHOOLSEO berücksichtigt Schriftdateien, Rendering und Cache beim Bau einer Jamstack-Website ab 224 €.
Projektanfrage per E-Mail senden · Erstgespräch mit Sandra buchen
▋
Sandra Krone ist Partnerin und Gründerin von OLDSCHOOLSEO. Ihre Arbeit beginnt bei der Analyse der Nutzerintention und der Content-Strategie, um daraus die Anforderungen für die redaktionelle und technische Umsetzung abzuleiten.