Font-Subsetting und Variable Fonts für bessere Performance
AI generated
60fps
ms
Web Performance / Fonts
Font-Subsetting und Variable Fonts für bessere Performance
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.

15 Min. Lesezeit Font-Subsetting Variable Fonts

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

11. FAQ: Font-Subsetting und Variable Fonts

1Was ist der Unterschied zwischen Font-Subsetting und Variable Fonts?
Subsetting entfernt ungenutzte Glyphen aus einer Font-Datei, um sie kleiner zu machen. Variable Fonts bündeln mehrere Schriftschnitte wie Regular und Bold in einer einzigen Datei mit interpolierbaren Achsen. Beide Techniken lassen sich kombinieren, indem man einen Variable Font zusätzlich subsettet.
2Wie groß ist der typische Einspareffekt durch Subsetting?
Bei einer auf Deutsch reduzierten Schriftfamilie sind Einsparungen von achtzig bis neunzig Prozent gegenüber der vollständigen internationalen Schriftdatei üblich. Eine Datei von mehreren Megabyte schrumpft dabei oft auf wenige Zehntel Kilobyte.
3Welches Tool eignet sich am besten für automatisiertes Subsetting?
Das Python-Paket fonttools mit dem Kommandozeilenwerkzeug pyftsubset ist der De-facto-Standard für manuelles und skriptbasiertes Subsetting. Für die automatische Erkennung genutzter Zeichen aus HTML-Dateien eignet sich ergänzend glyphhanger.
4Funktionieren Variable Fonts in allen modernen Browsern?
Alle aktuellen Versionen von Chrome, Firefox, Safari und Edge unterstützen Variable Fonts vollständig. Für sehr alte Browser-Versionen kann ein Fallback auf statische Schnitte über Feature-Detection sinnvoll sein, ist bei modernem Traffic aber meist nicht mehr nötig.
5Was passiert, wenn ein Zeichen im Subset fehlt?
Fehlt ein Zeichen im Subset, zeigt der Browser für diese Stelle die nächste im font-family-Stack definierte Fallback-Schrift oder ein Ersatzsymbol wie ein Rechteck an. Deshalb sollte der Subset großzügig genug für alle realistisch vorkommenden Sonderzeichen gewählt werden.
6Wie hilft unicode-range bei mehrsprachigen Websites?
Mit dem CSS-Deskriptor unicode-range können mehrere Font-Dateien derselben Familie für unterschiedliche Zeichenbereiche definiert werden. Der Browser lädt automatisch nur die Datei, deren Bereich im tatsächlich angezeigten Text vorkommt, ohne dass eine explizite Sprachumschaltung im Code nötig ist.
7Sollte man font-display: swap oder optional verwenden?
Swap zeigt sofort eine Fallback-Schrift und tauscht später, was einen kurzen Stilwechsel verursacht, aber Text immer sofort sichtbar macht. Optional erlaubt dem Browser, das Nachladen bei langsamer Verbindung ganz zu überspringen, was einen Stilwechsel vermeidet, aber die Web-Font seltener zum Einsatz bringt.
8Muss Subsetting bei jedem Deployment neu ausgeführt werden?
Wenn sich Inhalte und damit der genutzte Zeichensatz ändern können, empfiehlt sich ein automatisierter Subsetting-Schritt bei jedem Build. Bei statischen Websites mit festem Zeichensatz reicht ein einmaliger manueller Lauf, der nur bei inhaltlichen Änderungen wiederholt wird.
9Kann man Variable Fonts auch teilweise subsetten, also nur bestimmte Achsen behalten?
Ja, pyftsubset erlaubt es, den Wertebereich einzelner Achsen einzuschränken, beispielsweise nur Schriftstärken zwischen 400 und 700 statt des vollen Bereichs zu behalten. Das reduziert die Dateigröße weiter, wenn ohnehin nur ein Teilbereich der Achse verwendet wird.
10Wie testet man, ob ein Subset alle benötigten Zeichen enthält?
Ein einfacher Test ist das Rendern aller Seitenvorlagen mit dem neuen Subset in einer Staging-Umgebung und die visuelle Prüfung auf fehlende Glyphen. Zusätzlich lassen sich automatisierte Vergleiche zwischen dem im Subset enthaltenen Zeichensatz und einer Extraktion aus dem tatsächlichen Seiteninhalt in die CI-Pipeline integrieren.