Design vs. Speed: Auf der Suche nach dem perfekten Kompromiss für meinen Blog

4 Min. lesen

2 Kommentare

0

Inhalt

Manchmal führt der Weg zur Perfektion über einen ordentlichen Umweg. Mein Ziel war klar: Ich wollte die Schriftart so weit schrumpfen, dass sie kaum noch ins Gewicht fällt, aber gleichzeitig modernste Features wie das offene »a« bietet. Wer mich kennt, weiß, dass ich bei der Ladezeit keine Gefangenen mache. Doch die Reise durch die Welt der Font-Optimierung hat mich eines Besseren gelehrt. Und ja, ich hätte auch eine Systemschriftart wählen können. Aber ich habe Zeit und starte gerne auch mal komplexere Experimente. Auch in einer Materie, in der nicht gerade zu Hause bin. Wer diesem Experiment also trotz unzähliger Alternativen folgen will – nur zu.

Webfonts
Webfonts

Der Versuch der radikalen Diät

Zuerst war die Idee, den populären variablen Font Inter von Rasmus Andersson (Größe der Schriftart > 320kb) in statische Schnitte zu zerlegen – nur das Nötigste, nur Regular und Bold. Das klingt theoretisch nach einer großen Ersparnis. Doch das Ergebnis war ernüchternd: Die Dateien blieben trotz Reduzierung verhältnismäßig schwer. Wenn ich meinem »Spannmann« trauen darf, hätte ich die von mir gewünschten Features des Fonts teilweise nutzen können, was beim Standardfont Inter nicht funktioniert. Warum also auf die Flexibilität verzichten, wenn der Performance-Gewinn am Ende gar nicht so gewaltig ausfällt?

Zum Vergleich:

  • Original (.ttf): ~815 KB
  • Standard Web-Version (.woff2): ~320 KB (immer noch recht viel für eine Website).
  • Deine optimierte Version: Durch unser Subsetting haben wir sie auf 91 KB gedrückt – das ist eine ordentliche Ersparnis gegenüber dem Original, ohne auf die variablen Gewichte oder Design-Features verzichten zu müssen.

Die Wahrheit über Variable Fonts ist nämlich, dass nicht die Anzahl der Gewichte die Datei primär schwer macht. Es ist der unsichtbare Ballast. Also habe ich die Strategie geändert. Statt die gestalterische Freiheit der Achse von 100 bis 900 zu opfern, habe ich den chirurgischen Schnitt woanders gesetzt: beim Sprachraum und den technischen Altlasten.

Profi-Werkzeuge auf dem iMac: So wird’s gemacht

Um die Inter-Variable auf die optimierten 91 KB zu bringen, nutzen wir die Bordmittel des Macs in Kombination mit spezialisierten Skripten. Da mein System (macOS 26.3) bereits eine hervorragende Grundlage bietet, sind nur wenige Schritte im Terminal nötig.

Zuerst installieren wir Homebrew, den »App Store« für Entwickler. Damit holen wir uns Python, die Basis für unsere Font-Werkzeuge. Im Terminal genügen diese Befehle:

Das Subsetting: Den Ballast abwerfen

Jetzt kommt der chirurgische Teil. Wir nehmen die Originaldatei (z. B. InterVariable.ttf) und sagen dem Computer genau, was wir behalten wollen. Wir »subsetten« die Schrift, indem wir nur die Zeichen für den westeuropäischen Sprachraum extrahieren und unnötige technische Hilfsdaten (Hinting) entfernen. Auf modernen Retina-Displays übernimmt das Betriebssystem die Glättung so perfekt, dass diese zusätzlichen Daten schlichtweg überflüssig sind.

Ich habe die Fonts (.ttf) auf den Desktop gelegt!

Der entscheidende Befehl im Terminal sieht dann so aus: pyftsubset InterVariable.ttf --unicodes="U+0000-00FF,U+0100-017F,U+0180-024F" --layout-features='ss01,ss02,cv11,kern,liga' --flavor=woff2 --no-hinting --output-file=Inter-Optimiert.woff2

Effizienz ohne Kompromisse

Was passiert hier im Hintergrund? Wir behalten nur die Unicodes, die wir wirklich tippen (A-Z, Umlaute, Satzzeichen), retten aber die wichtigen Layout-Features wie das offene »a« (ss02) und das gekreuzte »I« (ss01). Auch die Zahlenästhetik lässt sich vermeintlich korrigieren: Wer die typische Inter-Null mit dem Schrägstrich nicht mag, soll diese per CSS ('cv01' 0) ganz einfach in eine klassische, leere Null verwandeln können. Das hat nun in meinem Fall leider nicht hingehauen.

Das Ergebnis ist der perfekte Kompromiss – für mich. Ich nutze nun die volle Variabilität von Inter, kann Headlines hauchdünn oder extrem fett setzen und behalte dennoch die volle Kontrolle über die Design-Details. Die Datei wiegt nach der Optimierung nur noch knapp über 91 KB. Das ist immer noch ein Bruchteil der ursprünglichen Größe, ohne dass wir die Intelligenz und die unendlichen Gewichte der Schrift verlieren.

Wer sein Projekt typografisch schärfen will, sollte sich mit Werkzeugen wie den FontTools vertraut machen. Es lohnt sich, die Extrameile zu gehen und die Original-Files selbst für den eigenen Bedarf zu optimieren. Performance ist wichtig, aber nicht um jeden Preis. Wer die Technik versteht, muss sich nicht zwischen Schönheit und Geschwindigkeit entscheiden. Dank der Arbeit von Rasmus Andersson und ein wenig Feinschliff im Terminal kann man tatsächlich beides haben.

4 Min. lesen

0

Bisher 462 Mal aufgerufen17 mal davon heute

778 Wörter

2 Gedanken zu „Design vs. Speed: Auf der Suche nach dem perfekten Kompromiss für meinen Blog“

  1. Uuii, da hast du dir ja Arbeit gemacht. Ich habe mir auch schon ähnliche Gedanken zur Verwendung der Google-Fonts gemacht. Ich dachte aber bisher, dass GeneratePress ein eigenes Font-Management mitbringt und nur das (vor)lädt, was gebraucht wird. Ist das nicht so?

Kommentar schreiben


Hier im Blog werden bei Abgabe von Kommentaren keine IP-Adressen gespeichert! Deine E-Mail-Adresse wird NIE veröffentlicht!



🕒 4 Minuten