Die Schrift gehört uns: Marken-Fonts selbst gehostet

Worum es geht

Wir haben unser Design-System auditiert und einen unangenehmen Befund gemacht: Alle Web-Apps benennen „Inter” als Schrift — aber keine einzige lud sie tatsächlich. Es gab keinen Font, der ausgeliefert wurde. Gerendert wurde mit dem, was zufällig auf dem Gerät lag: auf dem einen Mac Helvetica-nah, auf Windows etwas anderes, auf Android wieder etwas anderes. Eine Marke, die auf jedem Bildschirm anders aussieht, ist keine Marke.

Die Frage war also nicht „welche Schrift”, sondern „wie liefern wir sie aus”. Und genau da fängt es an, eine Vereins-Entscheidung zu sein.

Vier Wege, eine Schrift auszuliefern

1. Gar nichts laden — nur System-Schriften benennen. Null Bytes, aber das Betriebssystem bestimmt das Aussehen. (Unser Ist-Zustand.)
2. Google Fonts per CDN — die Bytes kommen von Googles Servern.
3. Selbst hosten — die Schrift-Dateien liegen auf unserer eigenen Domain, der Browser holt sie von dort.
4. System-Stack bewusst — wie 1, aber ehrlich deklariert.

Warum „selbst hosten” gewinnt — dreifach

Das Schöne an dieser Entscheidung: alle drei Maßstäbe, die uns wichtig sind, zeigen auf dieselbe Antwort.

• Performance. Google Fonts galt lange als schnell, weil Browser einen geteilten Cache hatten. Das ist seit 2020 vorbei — alle Browser trennen ihren Cache pro Website. Heute heißt Google Fonts: zwei zusätzliche fremde Server-Verbindungen, bevor der erste Buchstabe kommt. Selbst gehostet ist messbar schneller — gleiche Domain, eine Verbindung weniger.
• Unabhängigkeit. Selbst gehostet hängt nur an unserer eigenen Infrastruktur. Kein Dritter, der ausfallen, seine Bedingungen ändern oder unsere Nutzer:innen beobachten kann. Das ist dieselbe Logik, mit der wir Mail, Registry, Sync und Auth selbst betreiben.
• Datenschutz. Das dynamische Einbinden von Google Fonts überträgt die IP-Adresse der Besucher:innen an Google — ohne Einwilligung. Das Landgericht München hat das 2022 als Rechtsverstoß eingestuft. Für einen Verein, der Datensouveränität ins Zentrum stellt, ist das kein Schönheitsfehler, sondern ein Ausschlusskriterium.

Drei Achsen, ein Ergebnis. Wo es sonst Abwägung braucht, gibt es hier keinen Kompromiss: das Richtige ist auch das Schnellste.

Was sich geändert hat

In unserem Theme-Paket (@mana/themes) liegen jetzt drei Schriften als moderne, komprimierte Web-Fonts:

• Inter für Fließtext,
• JetBrains Mono für Code und Zahlen,
• Source Serif 4 für Überschriften — eine echte Serife füllt eine Lücke, die wir bisher hatten: Apps, die eine Serife wollten (Lesen, Pflanzen-Tagebuch, Zitate), fielen vorher auf eine beliebige System-Serife zurück.

Technisch sauber gemacht: nur die nötigen Zeichensätze (inklusive deutscher Umlaute), font-display: swap, sodass Text sofort sichtbar ist und die Marken-Schrift nahtlos nachrückt. Und — das ist der Trick fürs ganze Ökosystem — die Schriften hängen an der gemeinsamen Theme-Basis. Jede Verein-App erbt sie automatisch beim nächsten Build, ohne eine Zeile eigenen Code. Der Verein-Hub (hub.mana.how) ist der erste Live-Stand.

Offene Punkte

• Die übrigen Apps ziehen nach, sobald sie das nächste Mal gebaut und ausgerollt werden — bis dahin laufen sie auf dem alten Stand weiter.
• Eine letzte Performance-Politur (das Vorab-Laden der Hauptschrift) setzen wir pro App nach Bedarf.

Was kommt

Der Rest des App-Ökosystems wird auf die selbst gehosteten Schriften nachgezogen. Eine kleine Sache — aber eine, an der die Haltung des Vereins gut sichtbar wird: Was wir versprechen, liefern wir auch selbst aus. Bis ins Detail der Schrift.