In einem Satz
Font-Subsetting und -Konvertierung ist wie Packen für einen Wochenendtrip: Anstatt einen 6.000-Zeichen-Koffer voller kyrillischer Schriften und Dingbats mitzuschleppen, die du eh nie benutzt, packst du nur exakt die Buchstaben, die du brauchst, in einen hochkomprimierten, web-tauglichen Rucksack.
Welches Problem es löst
Wenn du 2005 Websites gebaut hast, glich deine typografische Palette im Grunde einer Geiselnahme. Du hattest Arial, Times New Roman, Georgia, Verdana und vielleicht Comic Sans, wenn du die Welt brennen sehen wolltest. Das waren „web-safe“ Fonts – was hieß, wir haben die Daumen gedrückt und gehofft, dass sie schon auf dem Betriebssystem des Users installiert waren.
Dann kam die @font-face-Revolution. Plötzlich konnten Designer jede Custom-Schriftart einbetten, die sie wollten. Das Web wurde wunderschön, aber eben auch unfassbar langsam.
Standard-Desktop-Fonts (TrueType oder OpenType) sind für den Printbereich und universellen Sprachsupport designt. Eine einzige .ttf-Datei enthält locker Tausende von Glyphen, die Englisch, Griechisch, Vietnamesisch, spezielle Mathe-Symbole und zwanzig Varianten des Kaufmanns-Und (Ampersand) unterstützen. Für ein Textverarbeitungsprogramm ist das fantastisch, aber für einen Webbrowser in einem wackeligen 3G-Netz eine Katastrophe. Das Herunterladen eines 400KB großen Font-Files blockiert das Rendering und sorgt für den gefürchteten „Flash of Unstyled Text“ (FOUT) oder schlimmer noch, den „Flash of Invisible Text“ (FOIT).
Wir brauchten zwei Dinge, um diese typografische Fettleibigkeit zu heilen:
- Bessere Compression, speziell fürs Web entwickelt (daher Formate wie WOFF und WOFF2).
- Subsetting, die chirurgische Entfernung jedes einzelnen Zeichens und jeder Sprachtabelle, die eine spezifische Website eigentlich gar nicht braucht.
Wie es unter der Haube funktioniert
Um zu kapieren, wie wir Fonts schrumpfen, musst du verstehen, was so ein Font-File überhaupt ist. Ein moderner Font (wie TTF oder OTF) ist nicht einfach nur ein Ordner mit Vektorzeichnungen. Es ist eine komplexe binäre Datenbank, die auf dem SFNT-Containerformat basiert.
Die Anatomie eines Fonts
Innerhalb eines SFNT-Containers sind die Daten in spezifischen Tabellen organisiert:
glyfoderCFF: Die eigentlichen Vektorzeichnungen (die Kurven und Linien der Buchstaben).cmap: Die Character-Map, die einen Unicode-Point (wieU+0041für 'A') auf die spezifische Zeichnung in derglyf-Tabelle mappt.GSUB/GPOS: Fortgeschrittene OpenType-Features wie Ligaturen (die Verbindung von 'f' und 'i') und Kerning (der Abstand zwischen bestimmten Buchstabenpaaren).name: Metadaten wie Font-Name, Copyright und Infos zum Designer.
Die Magie des Subsettings
Wenn du einen Font subsettest, knackt ein Parser diesen SFNT-Container auf. Du gibst ihm eine Liste mit Zeichen – sagen wir, nur das englische Standardalphabet, Zahlen und gängige Satzzeichen.
Der Parser löscht dabei nicht einfach nur ungenutzte Vektorzeichnungen aus der glyf-Tabelle. Er muss die gesamte Datenbank penibel neu aufbauen. Er schreibt die cmap neu, um die verwaisten Unicode-Points zu entfernen. Er durchkämmt die GSUB- und GPOS-Tabellen und wirft Kerning-Paare für Buchstaben raus, die nicht mehr existieren, damit die Datei nicht kaputtgeht. Zu guter Letzt berechnet er die Memory-Offsets für die File-Header neu.
Ein standardmäßiger 300KB-Font schrumpft gerne mal auf 15KB zusammen, wenn er auf die lateinischen Standardzeichen gesubsettet wird.
Der Format-Krieg: WOFF und WOFF2
Sobald der Font gesubsettet ist, wird komprimiert.
| Format | Compression-Tech | Das Urteil |
|---|---|---|
| TTF / OTF | Keine (Meistens) | Super für Desktop-Design-Apps. Grauenhaft für die Web-Auslieferung. |
| WOFF | Zlib | Das originale Web Open Font Format. Gut, aber veraltet. |
| WOFF2 | Brotli | Der moderne Standard. Transformiert Font-Tabellen vor dem Komprimieren. |
WOFF2 ist der unangefochtene König der Web-Fonts. Es nimmt nicht einfach ein TTF und zippt es. WOFF2 transformiert die SFNT-Tabellen physisch – es gruppiert insbesondere ähnliche Datentypen zusammen –, damit der zugrundeliegende Brotli-Kompressionsalgorithmus längere sich wiederholende Muster finden kann. Das Ergebnis sind Dateigrößen, die bis zu 30 % kleiner sind als bei WOFF1 und in Kombi mit Subsetting potenziell 95 % kleiner als das Original-TTF.
Alles zusammenfügen mit CSS
Wenn du dein hochkomprimiertes, gesubsettetes WOFF2-File hast, musst du dem Browser noch per CSS davon erzählen. Die unicode-range-Property ist hier entscheidend. Sie sagt dem Browser: „Lade diese Datei nur runter, wenn ein Zeichen auf der Seite auch wirklich in diese Range fällt.“
@font-face {
font-family: 'MyCustomFont';
/* Load the highly compressed WOFF2 format */
src: url('mycustomfont-subset.woff2') format('woff2');
/* Only trigger the download if the page uses basic Latin characters */
unicode-range: U+0000-00FF, U+0131, U+0152-0153;
font-display: swap;
}
Storys aus dem echten Leben
Die „Nur-ein-Ampersand“-Katastrophe
Eine Boutique-Designagentur baute eine Landingpage für ein High-End-Restaurant. Die Headline-Typografie sah fantastisch aus, vor allem, weil sie exklusiv für das Ampersand (&) im Restaurantnamen („Salt & Ash“) einen wunderschönen, verschnörkelten Cursive-Font benutzten.
Die Lighthouse Performance-Scores waren allerdings tiefrot. Die Devs merkten, dass sie die User dazu zwangen, ein 250KB großes TTF-File runterzuladen, nur um ein einziges Zeichen zu rendern. Indem sie den Font durch einen Subsetter jagten und nur das &-Zeichen (Unicode U+0026) extrahierten, generierten sie ein WOFF2-File, das lächerliche 800 Bytes auf die Waage brachte.
Die Lektion: Lade niemals eine ganze Font-Family für dekorative Drop-Caps, Icons oder einzelne Zeichen. Mach aggressives Subsetting.
Das mehrsprachige Megabyte
Eine SaaS-Company lokalisierte ihre Marketing-Site für User in Japan und Südkorea. Um das Branding konsistent zu halten, betteten sie einen sehr angesehenen CJK-Font (Chinese, Japanese, Korean) ein. CJK-Fonts sind bekanntermaßen massiv, weil sie Zehntausende von Ideogrammen enthalten. Das File war 4,5MB groß.
Plötzlich warteten die User in den USA und Europa sekundenlang darauf, dass Text auftauchte, weil der Browser 4,5MB an asiatischen Zeichen runterlud, die sie nie zu Gesicht bekämen. Das Dev-Team fixte das, indem sie den Master-Font in mehrere kleinere „Chunks“ (Teilstücke) subsetteten (ein WOFF2 für Basic Latin, eines für Hiragana/Katakana etc.) und diese mit @font-face-Blöcken und strikten unicode-range-Deskriptoren einbanden. Für englischsprachige User luden die Browser jetzt nur noch den 15KB kleinen Latin-Chunk.
Die Lektion: Nutze Subsetting und unicode-range, um typografische Chunks dynamisch auszuliefern – basierend auf den tatsächlichen sprachlichen Bedürfnissen des Users.
Häufige Fehler und Fallen
- Aus Versehen das Leerzeichen löschen: Wenn Devs die exakten Zeichen abtippen, die sie subsetten wollen (z. B.
abcdefghijklmnopqrstuvwxyz), vergessen sie oft das Leerzeichen (U+0020). Ohne das fällt dein sorgfältig ausgewählter Custom-Font bei jeder Lücke zwischen Wörtern auf Arial zurück. Das Ergebnis ist eine gruselige Erpresserbrief-Ästhetik. - Völlig unnötig Legacy-Formate ausliefern: Viele Entwickler generieren und servieren in ihren CSS-Stacks immer noch EOT-, TTF- und SVG-Fonts, „nur um sicherzugehen“. Lass es. WOFF2 wird weltweit von über 97 % der Browser unterstützt. Liefere WOFF2 aus, biete vielleicht noch WOFF als Fallback für uralte Browser an und gut ist.
- Wichtige OpenType-Features rausschmeißen: Aggressive Subsetting-Tools bieten manchmal an,
GSUB- undGPOS-Tabellen zu entfernen, um ein paar Extra-Kilobytes zu sparen. Wenn dein Font auf komplexe Ligaturen (wie die Verwandlung von->in einen Pfeil) oder stark auf Kerning angewiesen ist, um nicht furchtbar auszusehen, ruiniert das Entfernen dieser Tabellen deine Typografie. font-display: swapvergessen: Selbst ein winziges, gesubsettetes 12KB-WOFF2 braucht ein paar Millisekunden zum Laden. Wenn dufont-display: swapin deinem CSS weglässt, verstecken moderne Browser deinen Text komplett, bis der Font eintrifft. Gib deinen Usern Systemtext zum Lesen, während der Custom-Font auf dem Weg ist.
Warum du das auf dem Radar haben solltest
Web-Fonts gehören historisch gesehen zu den schlimmsten Übeltätern, wenn es darum geht, die Web Vitals zu ruinieren. Wenn dir Largest Contentful Paint (LCP) oder Cumulative Layout Shift (CLS) wichtig sind, musst du dich um die Font-Auslieferung kümmern.
Du solltest in dem Moment an Font-Subsetting und Konvertierung denken, in dem du ein .ttf- oder .otf-File von einem Designer bekommst oder von einer Foundry runterlädst. Nackte Desktop-Fonts im Web auszuliefern, ist so, als würdest du ein rohes, unkomprimiertes 10MB-Bitmap-Bild statt eines WebP servieren.
Indem du nach WOFF2 konvertierst und die Tausenden von ungenutzten Glyphen rausschmeißst, senkst du Bandbreitenkosten, verringerst den CO2-Fußabdruck deiner App und stellst sicher, dass deine Site exakt in der Millisekunde lesbar ist, in der ein User auf deinen Link klickt.
Tiefer einsteigen
- MDN Web Docs: @font-face - Die absolute Bibel darüber, wie man Custom-Fonts implementiert und
unicode-rangein CSS korrekt nutzt. - W3C WOFF2 Specification - Die offizielle Tech-Spec, die genau erklärt, wie WOFF2 SFNT-Tabellen transformiert und komprimiert.
- RFC 7932: Brotli Compressed Data Format - Die IETF-Doku zum Kompressionsalgorithmus, der WOFF2 seine Superkräfte verleiht.
- Web.dev: Optimize WebFonts - Googles maßgeblicher Guide zur Minimierung von Web-Font-Payloads und zur Vermeidung von Layout Shifts.
- Google Fonts Knowledge: What is a font? - Ein Deep Dive in die SFNT-Tabellenstruktur und wie Glyphen unter der Haube gespeichert werden.