Auf einer typischen Artikelseite wiegt die Schrift ein Vielfaches des Textes, den sie darstellt. Ein Beitrag mit 800 Wörtern besteht aus rund 5 KB reinem Text. Eine unbearbeitete Schriftfamilie mit vier Schnitten plus Kursiven kommt leicht auf 300 KB. Das Verhältnis liegt damit bei etwa 1 zu 60: Für jedes Byte Inhalt werden sechzig Byte Darstellung übertragen. Bei keiner anderen Ressource ist das Missverhältnis zwischen Nutzen und Gewicht so eklatant, und bei kaum einer lässt es sich so einfach korrigieren.
Die drei Erfolgskriterien von Guideline 2.11
Vorinstallierte Schriften: Nutze Systemschriften oder andere bereits installierte Schriften, um Schrift-Downloads zu reduzieren und die Performance zu verbessern.
Optimierung von Webschriften: Begrenze Anzahl und Komplexität der geladenen Schriften. Beschränke bei variablen Schriften die unterstützten Achsen und Wertebereiche auf das, was das Projekt tatsächlich benötigt, um die Dateigröße zu senken. Nutze die leistungsfähigsten verfügbaren Schriftformate und stelle geeignete Ersatzschriften bereit, damit Lesbarkeit und Performance während des Ladens oder bei nicht ladbaren Schriften erhalten bleiben.
Subsetting von Webschriften: Entferne ungenutzte Schriftstile, Schnitte und Zeichensätze. Bilde Teilmengen anhand der ausdrücklich unterstützten Sprachen, Schriftsysteme und Unicode-Bereiche des Projekts. Wo Du die vollständige Kontrolle über Eingaben und Ausgaben hast, beschränke die Schrift auf die relevanten Unicode-Bereiche oder Zeichensätze. Bei dynamischen Inhalten oder nutzergenerierten Eingaben stelle eine breitere Zeichenabdeckung bereit und nutze Incremental Font Transfer (IFT), um benötigte Schriftsegmente bei Bedarf nachzuladen.
Meine Einordnung
Das erste Kriterium ist die konsequenteste Lösung: gar keine Schrift laden. Der System-Schriftstapel kostet null Byte, es gibt keinen Ladezustand, keinen Textsprung und keine Abhängigkeit von einem Server. Die W3C-Fassung liefert sogar ein fertiges Beispiel dafür mit.
In der Beratung erlebe ich allerdings regelmäßig, dass dieser Weg nicht gangbar ist. Wenn eine Marke ihre Hausschrift über Jahre aufgebaut hat, ist der Verzicht darauf keine technische, sondern eine strategische Entscheidung. Ich halte das für legitim. Nur folgt daraus eben nicht, dass man die Schrift so einbinden muss, wie sie vom Anbieter kommt.
Genau hier liegt der praktikable Mittelweg, den ich selbst gehe: eine variable Schrift mit bereinigtem Zeichensatz und auf die tatsächlich benötigten Achsen beschränkt. Das Ergebnis ist deutlich kleiner als das Original und behält die Gestaltung vollständig. Eine variable Schrift lohnt sich dabei nicht immer: Brauchst Du nur einen oder zwei Schnitte, sind einzelne statische Instanzen oft leichter. Ab etwa drei Schnitten dreht sich das Verhältnis, weil in der variablen Datei die gemeinsame Zeichenkontur nur einmal gespeichert wird.
Das dritte Kriterium ist das mit dem größten Hebel. Eine Schrift, die alle unterstützten Sprachen abdeckt, enthält tausende Zeichen, von denen eine deutschsprachige Website vielleicht zweihundert braucht. Der Rest wird trotzdem übertragen. Subsetting reduziert hier nicht um Prozente, sondern um ein Vielfaches.
Wo ich weiter gehe
Zwei Punkte, bei denen ich präziser werde als die Guideline.
Erstens das Format. „Das leistungsfähigste verfügbare Format“ heißt heute WOFF2, und zwar ausschließlich. WOFF2 ist seit 2018 offizielle W3C-Recommendation und liegt im Schnitt rund 30 Prozent unter WOFF. Ein zusätzlicher WOFF-Fallback bedient nur noch Browser, die seit einem Jahrzehnt nicht mehr aktualisiert wurden. Er verdoppelt Deinen Speicherbedarf, verlängert jeden @font-face-Block und bringt praktisch keinen einzigen zusätzlichen Nutzer. Weglassen.
@font-face {
font-family: "Marke";
src: url("/fonts/marke-subset.woff2") format("woff2");
font-weight: 300 700;
font-display: swap;
unicode-range: U+0000-00FF, U+2000-206F, U+20AC, U+2082;
}
Zweitens das Subsetting, und hier ist Vorsicht geboten.
Die Antwort der Guideline auf dieses Problem ist Incremental Font Transfer: Der Browser lädt nur die Schriftsegmente nach, die eine Seite tatsächlich benötigt. Das ist die technisch saubere Lösung für mehrsprachige oder nutzergenerierte Inhalte, aber noch jung. Bis sie überall greift, ist mein pragmatischer Weg: eng schneiden für alles, was ich selbst schreibe, und einen breiteren Zeichensatz für Bereiche mit fremden Eingaben.
Und unabhängig davon gilt: Solange die Schrift lädt, muss die Seite lesbar sein. font-display: swap sorgt dafür, dass sofort die Systemschrift erscheint. Mit size-adjust lässt sich diese so anpassen, dass beim Umschalten nichts springt.
Dein erster Schritt heute
Du brauchst keine neue Schrift. Du brauchst die Liste der Schnitte, die Du wirklich benutzt.
Wenn Du danach noch Zeit hast, subsette Deine Hauptschrift auf Latein plus Interpunktion plus die Sonderzeichen, die Du wirklich verwendest. Prüfe anschließend eine Seite mit Umlauten, Anführungszeichen und CO₂ auf korrekte Darstellung.
Die sparsamste Schrift ist die, die schon auf dem Gerät liegt. Die zweitsparsamste ist die, aus der Du alles entfernt hast, was Du nicht brauchst.
Quelle: W3C-Fassung von Guideline 2.11