FlowingDev

@font-face erklärt: Wie du Browsern deine Typografie beibringst

Meistere die CSS-Regel @font-face, um Custom Web Fonts effizient auszuliefern – mit font-display, Preloading, unicode-ranges und Variable Weights.

Tool ausprobieren: @font-face Generator

In einem Satz

@font-face ist die CSS-Regel, die es dem Webbrowser erlaubt, maßgeschneiderte Typografie herunterzuladen und zu rendern – und Designer endlich von der Tyrannei des halben Dutzends "web-sicherer" Schriften befreit, die auf jedem Rechner vorinstalliert sind.

Welches Problem es löst

Wenn du in den späten 90ern oder frühen 2000ern Websites gebaut hast, war Web-Typografie eine trostlose, öde Einöde. Du warst dem ausgeliefert, was zufällig auf dem Betriebssystem des Users herumlag. Du hast font-family: Arial, Helvetica, sans-serif; getippt und gebetet. Wenn dir ein Designer ein Photoshop-Mockup mit einer wunderschönen, maßgeschneiderten Serifenschrift für die Headlines rüberschob, hattest du drei furchtbare Optionen:

  1. Der Image-Hack: Die Headline in Photoshop slicen und als <img>-Tag ausliefern. SEO hasste es. Screenreader waren blind dafür. Später machten Retina-Displays daraus einen unscharfen Brei.
  2. sIFR (Scalable Inman Flash Replacement): Ein dämonischer Workaround. JavaScript suchte den Text, versteckte ihn und bettete stattdessen einen winzigen Adobe Flash-Film ein, der exakt denselben Text in der Custom Font renderte. Es war heavy, buggy und ließ Laptop-Akkus schmelzen.
  3. Cufón: Eine JavaScript-Library, die Font-Pfade in Vektorgrafiken umwandelte und auf einem <canvas> renderte. Wunderschön, aber man konnte den Text nicht mehr einfach markieren oder kopieren.

Das W3C hatte @font-face eigentlich schon in CSS2 (1998) vorgeschlagen, aber die Browser wurden sich bei den Font-Formaten nicht einig und die Foundries (Schriftgießereien) hatten panische Angst vor Piraterie (legst du eine .ttf-Datei auf den Server, kann sie sich jeder ziehen).

Erst in den 2010er Jahren, mit der weiten Verbreitung des Web Open Font Formats (WOFF) – einem Format, das speziell für das Web komprimiert und angepasst wurde – wurde @font-face zur praktischen Realität. Heute lädt @font-face nicht einfach nur Fonts herunter; es dirigiert einen komplexen Tanz aus Network Requests, Caching, Subsetting und Rendering-Strategien, um deine Seite rasend schnell zu halten und trotzdem exakt so aussehen zu lassen, wie der Designer es sich vorgestellt hat.

Wie es unter der Haube funktioniert

Im Kern ist @font-face ein Set von Instruktionen. Es mappt einen von dir ausgedachten Namen auf eine Datei, die irgendwo auf einem Server liegt.

Die Anatomie der Regel

Eine moderne, production-ready @font-face-Deklaration sieht ungefähr so aus:

@font-face {
  font-family: 'MyAwesomeFont';
  src: local('MyAwesomeFont Regular'), 
       url('/fonts/myawesomefont.woff2') format('woff2');
  font-weight: 400;
  font-style: normal;
  font-display: swap;
  unicode-range: U+0000-00FF;
}

Dröseln wir die Magie in diesem Block mal auf.

Formate und das WOFF2-Monopol

Achte auf das format('woff2'). Im dunklen Zeitalter mussten Developer einen gigantischen "bulletproof" Stack aus .eot (für uralte Internet Explorer), .ttf (für ältere Safari/Android), .svg (für Legacy-iOS) und .woff bereitstellen.

Heute läuft das Web auf WOFF2. Es nutzt Brotli-Kompression, was zu Dateigrößen führt, die rund 30% kleiner sind als beim Vorgänger WOFF. Da WOFF2 mittlerweile einen fast universellen Browser-Support genießt (weltweit über 97%), musst du in der Regel nur eine einzige .woff2-Datei ausliefern. Vielleicht noch mit einem Standard-WOFF-Fallback, falls du für uralte Enterprise-Kisten entwickelst.

Den Flash kontrollieren (font-display)

Wenn ein Browser auf Text stößt, der mit einem Custom Font gestylt ist, die Datei aber noch nicht fertig heruntergeladen ist, muss er eine Entscheidung treffen. Zeigt er den Text in einer Fallback-Font? Oder versteckt er den Text, bis die Custom Font da ist?

Das führt zu zwei berühmt-berüchtigten Akronymen: FOUT (Flash of Unstyled Text) und FOIT (Flash of Invisible Text). Der Descriptor font-display lässt dich dieses Verhalten diktieren.

font-display Verhalten Wann man es nutzt
auto Browser-Standard (blockiert das Rendering meistens für bis zu 3 Sekunden). Niemals, wenn dir Performance wichtig ist.
swap Zeigt sofort die Fallback-Font (FOUT) und tauscht sie gegen die Custom Font (swap), sobald diese bereit ist. Body-Text, Artikel, UI-Elemente. User können sofort anfangen zu lesen.
block Versteckt den Text (FOIT) für eine kurze Zeit, zeigt dann den Fallback und tauscht später. Icons oder Logos, bei denen eine Fallback-Font wie kaputter Kauderwelsch aussieht.
fallback Kurzer Block, kurze Swap-Periode. Dauert es zu lange, wird die Custom Font für diesen Page Load komplett abgebrochen. Dekorativer Text bei langsamen Verbindungen.
optional Extrem kurzer Block. Wenn die Font nicht gecached ist oder nicht unglaublich schnell lädt, gibt der Browser komplett auf. "Nice to have"-Fonts, bei denen Layout-Stabilität an oberster Stelle steht.

Subsetting mit unicode-range

Eine komplette Font-Datei, die lateinische, kyrillische, griechische und komplexe CJK-Glyphen (Chinesisch, Japanisch, Koreanisch) enthält, kann Megabytes auf die Waage bringen.

Die Property unicode-range ist ein geniales Tool zur Optimierung. Es sagt dem Browser: "Diese Font-Datei deckt nur diese spezifischen Zeichen ab." Wenn du unicode-range: U+0000-00FF (Basic Latin) setzt, parst der Browser dein HTML. Findet er keine lateinischen Zeichen, wird er die Font-Datei nicht einmal herunterladen. So kannst du massive Fonts in winzige, mundgerechte Sprach-Häppchen aufteilen (Subsetting) und nur das laden, was der User wirklich braucht.

Variable Fonts

Früher musstest du vier separate .woff2-Dateien laden, wenn du Regular, Italic, Bold und Bold Italic haben wolltest.

Variable Fonts bündeln eine komplette Schriftfamilie in einer einzigen Datei, indem sie "Axes of Variation" (Variationsachsen) definieren. Statt statischer Gewichte (Weights) wie 400 oder 700 kann eine Variable Font auch mit einem Weight von 432 oder 781 gerendert werden. 

@font-face {
  font-family: 'MyVariableFont';
  src: url('/fonts/myfont-var.woff2') format('woff2');
  font-weight: 100 900; /* Akzeptiert jedes Weight zwischen 100 und 900 */
}

Base64 Embedding vs. Preloading

Manchmal ist der Network Request selbst der Flaschenhals. Hier hast du zwei fortgeschrittene Strategien:

  1. Preloading: Fügt man <link rel="preload" href="/fonts/myfont.woff2" as="font" type="font/woff2" crossorigin> im HTML <head> ein, sagt das dem Browser, er soll die Font sofort fetchen, noch bevor er das CSS herunterlädt.
  2. Base64 Embedding: Du kannst die binäre Font-Datei in einen gigantischen Text-String umwandeln und ihn direkt in die url() deiner @font-face-Regel pasten. Das eliminiert den Network Request komplett, erhöht die Größe der CSS-Datei aber um ca. 33%. Es blockiert das Rendering der gesamten Seite, bis das CSS heruntergeladen ist. Deshalb ist das strikt für winzige, hyper-optimierte Subset-Fonts reserviert (wie ein Custom-Logo).

Geschichten aus dem echten Leben

Der unsichtbare E-Commerce-Button

Eine Boutique-E-Commerce-Seite entschied sich für eine Custom Icon Font in ihrem User Interface. Sie nutzten eine Standard-@font-face-Deklaration ohne font-display. Im schnellen Büro-WLAN sah alles fantastisch aus.

Mobile User im 3G-Netz sprangen jedoch mit Rekordraten ab. Als die Devs ein langsames Netzwerk simulierten, fanden sie den Schuldigen: Der Browser wartete darauf, dass die Icon Font lud, bevor er den "In den Warenkorb"-Button renderte. Das Ergebnis war ein 4-sekündiger Flash of Invisible Text (FOIT). Die User konnten buchstäblich den Button nicht sehen, mit dem sie dem Unternehmen ihr Geld geben wollten. Einfach font-display: swap; für Text hinzuzufügen und die Icon Font zu preloaden, rettete ihre Conversion Rate.

Die Multi-Megabyte-Typografie-Tragödie

Ein beliebter Tech-Blog beschloss, Internationalisierung zu supporten. Damit ihre schicke Typografie konsistent blieb, banden sie eine massive Noto Sans Font ein, die komplette CJK-Zeichen (Chinesisch, Japanisch, Koreanisch) abdeckte. Die Font-Datei war knapp 6MB groß.

Plötzlich beschwerten sich User in den USA, die simple englische Artikel lasen, über lahme Ladezeiten. Ihre Browser luden 6MB an japanischen und koreanischen Glyphen herunter, um einen Artikel über JavaScript zu lesen. Das Team implementierte unicode-range. Sie splitteten die Font in ein 30KB Latin-Subset und ein 5.9MB CJK-Subset. Der Browser requestete fortan bei englischen Lesern automatisch nur die 30KB-Datei und heilte den Performance-Drop augenblicklich.

Das zittrige Redesign

Eine Designagentur entwarf ein beeindruckendes Editorial-Layout, das neun verschiedene Weights einer klassischen Sans-Serif-Font nutzte. Der Developer exportierte brav neun verschiedene .woff2-Dateien und schrieb neun @font-face-Regeln.

Da Browser Dateien asynchron herunterladen, stotterte sich die Seite quasi ins Dasein. Das 300er Weight lud, dann das 700er, dann das 400er. Das Layout zuckte aggressiv hin und her und berechnete den Textumbruch vier- oder fünfmal pro Sekunde neu. Der Developer ersetzte die neun Dateien durch eine einzige Variable Font (.woff2-variations). Diese eine Datei war 40% kleiner als alle neun zusammen, lud in einem einzigen Request und renderte die Seite in einem einzigen, smoothe Paint.

Häufige Fehler und Fallen

  • Uralte Font-Formate an moderne Browser ausliefern: Hör auf, .ttf, .eot und .svg Fonts auszuliefern, es sei denn, du hast einen expliziten, datengetriebenen Grund, IE8 oder ein zehn Jahre altes Android-Gerät zu supporten. Bleib bei WOFF2.
  • Das crossorigin beim Preloading vergessen: Wenn du <link rel="preload"> für eine Font nutzt, musst du das crossorigin-Attribut hinzufügen, selbst wenn die Font auf deiner eigenen Domain gehostet wird. Aufgrund von Browser-Security-Spezifikationen werden Fonts im Anonymous-Mode-CORS gefetcht. Lässt du das Attribut weg, lädt der Browser die Font zweimal herunter.
  • Massive Body-Fonts Base64-encoden: Das Einbetten einer 100KB Font direkt in dein CSS bläht deinen CSS-Payload auf und blockiert das Rendering. Encode nur winzige Fonts (wie ein 5KB Subset für ein Logo).
  • font-display ignorieren: Sich auf Browser-Defaults zu verlassen, bestraft fast immer User mit langsamen Verbindungen. Deklariere explizit font-display: swap für Body-Text, um das Lesen gegenüber der Ästhetik zu priorisieren.
  • Jeden Font auf der Seite preloaden: Preloading ist eine High-Priority-Instruktion. Wenn du eine fette, kursive Headline-Font preloadest, die ganz unten auf der Seite lebt, klaust du wertvolle Bandbreite, die eigentlich für das kritische JavaScript und CSS benötigt wird, um den oberen Teil der Seite zu laden (Above the Fold). Preloade nur die "Hero"-Font.
  • Sich zu sehr auf local() verlassen: Ein local('Helvetica') sagt dem Browser, er soll eine lokale Kopie nutzen, falls sie existiert. Allerdings unterscheiden sich die Namenskonventionen für Fonts zwischen Mac, Windows und Linux drastisch. Was du für local('Helvetica Neue Bold') hältst, könnte auf einem anderen Betriebssystem lautlos fehlschlagen.

Warum du das auf dem Radar haben solltest

Webentwicklung ist ein ewiges Tauziehen zwischen Ästhetik und Performance. Du baust eine Brand auf, und Typografie ist die Stimme dieser Brand. Aber du baust auch Software, und für einen User im wackeligen U-Bahn-Netz zählt jedes Kilobyte.

Die perfekte @font-face-Regel zu schreiben, ist notorisch mühselig. Es erfordert ein tiefes Verständnis von Browser-Quirks, MIME-Types, Subsetting-Syntax und Kompressionsformaten. Ein moderner Generator schreibt nicht nur einfach die CSS-Syntax für dich; er verankert Best Practices. Er generiert automatisch die WOFF2-Dateien, strukturiert die Variable-Axes, wendet die korrekten font-display-Fallbacks an und spuckt genau die Base64- oder Preload-Tags aus, die nötig sind, um Netzwerk-Flaschenhälse zu umgehen. Er stellt sicher, dass der Browser auch wirklich weiß, wie er die Wörter aussprechen soll, wenn deine Applikation spricht.

Deep Dive

Theorie erledigt. Zeit, loszulegen — 100 % in deinem Browser.

Tool ausprobieren: @font-face Generator