Wie man Web-Fonts radikal verkleinert, ohne einen einzigen Buchstaben zu verlieren
Font-Dateien gehören oft zu den größten Einzelressourcen einer Webseite, obwohl ein Großteil ihres Inhalts nie zur Anzeige kommt. Mit Font-Subsetting und Variable Fonts lässt sich die übertragene Datenmenge drastisch reduzieren, ohne dass Nutzer einen sichtbaren Unterschied in der Typografie bemerken.
Inhaltsverzeichnis
- 1. Was ist Font-Subsetting
- 2. Warum Font-Dateien so groß werden
- 3. Subsetting-Tools im Build-Prozess
- 4. Variable Fonts Grundlagen
- 5. Variable Fonts vs. statische Schriftdateien
- 6. Kombination mit font-display und Ladestrategie
- 7. Unicode-Range-Aufteilung für mehrsprachige Websites
- 8. Automatisiertes Subsetting in der CI-Pipeline
- 9. Zusammenfassung und Ausblick
- 10. Zusammenfassung
- 11. FAQ
1. Was ist Font-Subsetting
Eine typische Font-Datei enthält tausende Glyphen, damit sie möglichst viele Sprachen, Sonderzeichen, Ligaturen und Symbole abdecken kann. Für eine deutschsprachige Website mit lateinischem Alphabet werden davon in der Praxis oft nur wenige hundert Zeichen tatsächlich benötigt, der Rest bleibt ungenutzter Ballast im Datenstrom. Font-Subsetting ist der Prozess, bei dem aus einer vollständigen Schriftdatei genau die Glyphen extrahiert werden, die auf einer Seite tatsächlich vorkommen, und alles andere entfernt wird.
Das Ergebnis ist eine neue, deutlich kleinere Font-Datei mit exakt demselben visuellen Erscheinungsbild für den verwendeten Zeichensatz. Ein vollständiger Schriftschnitt mit lateinischen, kyrillischen und griechischen Glyphen sowie umfangreichen OpenType-Features kann mehrere Megabyte umfassen, während ein auf die deutsche Sprache reduzierter Subset häufig nur zwanzig bis vierzig Kilobyte groß ist. Dieser Unterschied wirkt sich direkt auf die Ladezeit aus, besonders wenn die Schrift blockierend für den sichtbaren Text eingebunden ist.
2. Warum Font-Dateien so groß werden
Moderne Schriftfamilien, wie sie etwa von Google Fonts oder kommerziellen Foundries angeboten werden, sind meist auf internationale Verwendung ausgelegt und decken dutzende Unicode-Blöcke ab, von lateinischer Basisschrift über kyrillische und griechische Zeichen bis hin zu Sonderzeichen für Währungen, mathematische Symbole und Pfeile. Jede einzelne Glyphe wird als Vektorpfad aus Bezier-Kurven gespeichert, und je mehr Glyphen eine Datei enthält, desto größer wird die zentrale Glyph-Tabelle im Font-Format.
Hinzu kommen OpenType-Features wie Ligaturen, alternative Zeichenformen, Kapitälchen oder Bruchzahlen, die zusätzliche Lookup-Tabellen in der Datei erfordern, selbst wenn eine Website diese Features nie aktiviert. Das komprimierte WOFF2-Format reduziert die Dateigröße zwar erheblich gegenüber unkomprimierten Formaten, kann aber die grundsätzliche Redundanz eines riesigen Zeichenvorrats nicht vollständig kompensieren, weil viele Glyphen strukturell zu unterschiedlich sind, um effizient komprimiert zu werden.
3. Subsetting-Tools im Build-Prozess
Das Referenz-Werkzeug für Subsetting ist pyftsubset aus dem Python-Paket fonttools, das eine Font-Datei anhand einer expliziten Zeichenliste oder eines Unicode-Bereichs reduziert und dabei alle relevanten Font-Tabellen konsistent anpasst. Ergänzend automatisiert das Tool glyphhanger diesen Schritt, indem es HTML-, CSS- und JavaScript-Dateien eines Projekts nach tatsächlich verwendeten Zeichen durchsucht und daraus automatisch die passende Zeichenliste für pyftsubset generiert.
In einem Build-Prozess lässt sich dieser Schritt vollständig automatisieren, sodass bei jedem Deployment ein aktueller, minimaler Subset erzeugt wird, statt manuell gepflegte Zeichenlisten zu riskieren. Das folgende Beispiel zeigt einen typischen Aufruf, der eine Schriftdatei auf den lateinischen Basiszeichensatz reduziert und dabei WOFF2 als Ausgabeformat sowie das layout-relevante Feature für Kerning explizit erhält.
# Subsetting einer Variable-Font-Datei auf lateinischen Basiszeichensatz
pyftsubset Inter-Variable.ttf \
--unicodes="U+0020-007E,U+00A0-00FF,U+2018-201E" \
--layout-features="kern,liga,calt" \
--flavor=woff2 \
--output-file=Inter-Variable.subset.woff2
# Automatische Zeichenerkennung aus dem Projekt heraus
glyphhanger ./dist/*.html \
--subset=./fonts/Inter-Variable.ttf \
--formats=woff2 \
--whitelist=U+20AC
4. Variable Fonts Grundlagen
Ein Variable Font speichert nicht mehr nur einen festen Schriftschnitt, sondern eine ganze Bandbreite von Schnitten entlang definierter Achsen in einer einzigen Datei. Die häufigste Achse ist wght für die Schriftstärke, die stufenlos zwischen einem dünnen und einem fetten Schnitt interpoliert werden kann, hinzu kommen oft wdth für die Laufweite, slnt für die Neigung und opsz für optische Größenanpassung bei unterschiedlichen Schriftgrößen.
Technisch basiert das auf einer Interpolation zwischen sogenannten Master-Outlines, die die Extreme jeder Achse definieren, während Zwischenwerte mathematisch berechnet werden. Über die CSS-Eigenschaft font-variation-settings oder die etablierteren Kurzformen wie font-weight: 375 lässt sich jeder beliebige Punkt auf diesen Achsen direkt im Stylesheet ansteuern, ohne dass dafür eine zusätzliche Font-Datei geladen werden muss.
5. Variable Fonts vs. statische Schriftdateien
Ein klassisches Typografie-Setup mit Regular, Bold, Italic, Bold Italic, Light und Medium benötigt sechs separate Font-Dateien und damit sechs einzelne HTTP-Anfragen, selbst wenn HTTP/2-Multiplexing den Verbindungsaufbau dafür nicht mehr sequenziell erzwingt. Jede dieser Dateien muss dennoch angefordert, übertragen und vom Browser geparst werden, was besonders auf langsamen Mobilfunkverbindungen spürbare Verzögerung verursacht, bevor der Text im finalen Schriftschnitt dargestellt werden kann.
Eine einzelne Variable-Font-Datei ist zwar meist größer als ein einzelner statischer Schnitt, in Summe aber oft kleiner als alle sechs statischen Dateien zusammen, da gemeinsame Glyphdaten nur einmal gespeichert werden. Zusätzlich profitiert der Browser-Cache davon, dass nur eine Datei für beliebig viele Schriftstärken vorgehalten werden muss, was besonders bei Websites mit vielen unterschiedlichen Textgewichten wie Überschriften, Fliesstext und Hervorhebungen einen klaren Vorteil bringt.
6. Kombination mit font-display und Ladestrategie
Subsetting und Variable Fonts entfalten ihre volle Wirkung erst im Zusammenspiel mit einer durchdachten Ladestrategie. Die CSS-Eigenschaft font-display: swap sorgt dafür, dass der Browser zunächst eine Fallback-Schrift anzeigt und erst nach dem Laden der Web-Font austauscht, wodurch Text sofort sichtbar wird, während font-display: optional das Nachladen sogar ganz überspringen kann, wenn die Verbindung zu langsam ist.
Ein <link rel="preload"> mit dem korrekten as="font"-Attribut und passendem type-Wert signalisiert dem Browser zusätzlich, die kleine Subset-Datei so früh wie möglich anzufordern, noch bevor das CSS vollständig ausgewertet wurde. In Kombination mit einem auf wenige Kilobyte reduzierten Subset ist die Zeit bis zur finalen Textdarstellung dadurch oft kaum länger als bei einer reinen Systemschrift.
7. Unicode-Range-Aufteilung für mehrsprachige Websites
Für Websites mit mehreren Sprachversionen bietet sich eine feinere Strategie an als ein einzelner globaler Subset: Der CSS-Deskriptor unicode-range erlaubt es, mehrere @font-face-Regeln für dieselbe logische Schriftfamilie zu definieren, wobei jede Regel nur für einen bestimmten Zeichenbereich zuständig ist. Der Browser lädt dann ausschliesslich die Font-Datei, deren Bereich tatsächlich im gerenderten Text vorkommt, und ignoriert alle anderen Regeln vollständig.
Ein deutscher Besucher der Seite erhält so nur den lateinischen Subset inklusive Umlauten, während ein Besucher einer kyrillischen Sprachversion automatisch die separate kyrillische Font-Datei nachlädt, ohne dass dafür eine explizite Sprach-Erkennung im Code nötig wäre. Dieser Mechanismus funktioniert rein deklarativ über die CSS-Engine des Browsers und spart bei internationalen Projekten erhebliche Datenmengen gegenüber einer einzigen, alle Sprachen abdeckenden Datei.
8. Automatisiertes Subsetting in der CI-Pipeline
In der Praxis lohnt sich ein Build-Schritt, der bei jedem Deployment automatisch alle Templates, gerenderten Seiten und CMS-Inhalte nach vorkommenden Zeichen durchsucht und daraus einen aktuellen Subset erzeugt. Die resultierende Datei wird mit einem Content-Hash im Dateinamen versehen, sodass Änderungen am Zeichensatz automatisch zu einer neuen URL führen und der Browser-Cache korrekt invalidiert wird, ohne dass manuell an Versionsnummern gedacht werden muss.
Ein typischer Fallstrick dabei sind dynamische Inhalte wie CMS-Freitexte oder nutzergenerierte Kommentare, die Sonderzeichen enthalten können, die zum Build-Zeitpunkt noch nicht bekannt waren. Für solche Fälle empfiehlt sich entweder ein bewusst großzügigerer Basis-Subset mit gängigen Sonderzeichen wie Anführungszeichen, Gedankenstrichen und Währungssymbolen, oder ein Fallback auf eine vollständigere Schriftdatei ausschliesslich für die betroffenen dynamischen Bereiche der Seite.
9. Zusammenfassung und Ausblick
Font-Subsetting und Variable Fonts lösen zwei unterschiedliche, aber sich ergänzende Probleme: Subsetting entfernt ungenutzten Zeichenballast, während Variable Fonts die Anzahl der benötigten Dateien für unterschiedliche Schriftschnitte auf eins reduziert. In Kombination mit einer sauberen Ladestrategie über font-display und preload lässt sich die Ladezeit von Web-Fonts oft um mehr als achtzig Prozent gegenüber einer naiven Einbindung reduzieren.
Für die Zukunft zeichnet sich mit inkrementellem Font-Transfer, auch als Progressive Font Enrichment bekannt, ein Ansatz ab, bei dem der Browser einzelne Glyphen erst bei tatsächlichem Bedarf nachlädt, ähnlich wie bei progressiven Bildformaten. Bis diese Technik breite Browser-Unterstützung erreicht, bleiben manuelles oder automatisiertes Subsetting kombiniert mit Variable Fonts die zuverlässigste Methode, um Typografie und Ladezeit in Einklang zu bringen.
| Ansatz | Typische Dateigröße | HTTP-Requests | Einsatzempfehlung |
|---|---|---|---|
| Vollständige Schriftfamilie | 2 bis 5 MB | 1 pro Schnitt (6+) | Nicht empfohlen für Web |
| Statischer Subset (Latein) | 20 bis 40 KB pro Schnitt | 1 pro Schnitt | Einzelner Schriftschnitt, wenige Gewichte |
| Variable Font (ungesubsettet) | 150 bis 400 KB | 1 gesamt | Viele Schriftstärken, internationale Seite |
| Variable Font + Subset | 40 bis 90 KB | 1 gesamt | Beste Praxis für die meisten Projekte |
| Unicode-Range Split | 20 bis 40 KB pro Sprache | 1 pro genutzter Sprache | Mehrsprachige Websites |
Mironsoft
Web Performance, Core Web Vitals und Ladezeit-Optimierung
Ladezeiten, die Nutzer nicht abspringen lassen, bevor die Seite überhaupt sichtbar ist?
Wir prüfen bestehende Webseiten auf langsame Core Web Vitals, aufgeblähte JavaScript-Bundles und ungenutzte Render-Blocker und bauen daraus eine Performance-Grundlage, die messbar bleibt statt nur einmalig gut auszusehen.
Performance-Audit
Core Web Vitals, Ladewasserfall und Render-Blocker systematisch messen und beheben.
Bundle-Optimierung
JavaScript- und CSS-Bundle-Größe sowie Code-Splitting gezielt reduzieren.
Monitoring-Aufbau
Kontinuierliches Performance-Monitoring statt einmaliger Momentaufnahme etablieren.
10. Zusammenfassung
Font-Subsetting und Variable Fonts
Technik
Reduktion auf genutzte Glyphen plus eine Datei für alle Schriftschnitte
Effekt
Oft über achtzig Prozent kleinere Font-Dateien
Tooling
fonttools/pyftsubset und glyphhanger im Build-Prozess
Risiko
Vergessene Sonderzeichen bei dynamischen Inhalten