Webfonts und Ladezeit: Was jede zusätzliche Schrift kostet

Die meisten Websites laden ihre Schriften aus dem Internet: Der Web Almanac 2024 fand Webfonts auf rund 87 % der Websites. Jede davon ist eine Datei, die der Browser finden, herunterladen und anwenden muss, bevor der Text so aussieht, wie der Designer es wollte, und bis sie da ist, versteckt der Browser den Text oder zeigt ihn in einer anderen Schrift. Was das kostet, hängt davon ab, wie viele Schriften du nutzt und wie du sie lädst, und die meisten Ratschläge dazu sind Faustregeln oder ein einzelner Testlauf. Also haben wir gemessen. Wir haben eine Seite gebaut und sie nur mit Systemschriften geladen, dann mit einer, zwei, drei, vier und fünf Webfont-Familien und schließlich mit zwei Familien auf vier verschiedene Arten: per Preload, mit font-display: block, mit optional und direkt von Google Fonts. Jede Variante wurde 12-mal in gemischter Reihenfolge auf einem emulierten Mittelklasse-Smartphone über langsames 4G geladen. Dieser Leitfaden zeigt die Ergebnisse, erklärt jede Lademethode und endet mit der Frage, wie viele Schriften eine Website wirklich nutzen sollte.

Was Webfonts in unserem Test kosten (Median aus 12 Ladevorgängen, emuliertes Smartphone über langsames 4G)

Unser Test vom 10. Oktober 2026: eine Seite, Chrome mit Smartphone-Emulation, 150 ms Round-Trip, 1,6 Mbit/s Download, 4-fach verlangsamte CPU, Cache deaktiviert, 12 Ladevorgänge pro Zeile in gemischter Reihenfolge. „Haupttext sichtbar“ ist der Largest Contentful Paint; „Alle Schriften da“ ist der Moment, in dem die letzte Schriftdatei fertig geladen war; die Layoutverschiebung ist der schlechteste der 12 Durchläufe, Googles Grenze für „gut“ liegt bei 0,1. Selbst gehostete Zeilen nutzten font-display: swap, sofern nicht anders angegeben. Mit optional nutzte der Browser die Schriften nur, wenn sie fast sofort bereit waren; über diese Verbindung waren sie das nicht, also blieb beim ersten Aufruf die Ersatzschrift.

Wie ein Webfont auf den Bildschirm kommt

Ein Webfont ist nicht Teil der Seite. Der Browser lädt zuerst das HTML, dann das CSS, und erst wenn er weiß, welcher Text welche Schrift braucht, fordert er die Schriftdateien an. Damit gehören Schriften zu den letzten Ressourcen, die überhaupt geladen werden, und der Text, den sie gestalten, ist meist das Wichtigste auf der Seite.

Solange die Datei unterwegs ist, hat der Browser zwei Möglichkeiten: den Text verstecken und warten oder ihn in einer Ersatzschrift zeigen und tauschen, sobald der Webfont da ist. Welche er wählt, entscheidet die CSS-Eigenschaft font-display, und sie ist die wichtigste Zeile in jedem Schrift-Setup. Versteckter Text heißt „Flash of Invisible Text“; Text, der beim Lesen die Schrift wechselt, heißt „Flash of Unstyled Text“, und wenn beide Schriften unterschiedlich viel Platz brauchen, springt die Seite.

Was jede zusätzliche Schrift kostet: unsere Messung

Mit font-display: swap haben zusätzliche Schriften nicht verzögert, wann der Text erscheint, sondern wann die Seite aufhört, sich zu verändern. Der Haupttext war in jeder Variante nach 0,54 bis 0,58 Sekunden sichtbar, von Systemschriften bis zu fünf Familien, weil der Browser ihn sofort in der Ersatzschrift gezeichnet hat. Was wuchs, war die Zeit, bis jeder Webfont angekommen war: 0,63 Sekunden mit einer Familie, 0,85 mit zwei, 1,06 mit drei, 1,22 mit vier und 1,74 mit fünf.

Die Größe zählte mehr als die Anzahl. Jede Familie nach der ersten fügte etwa 0,2 Sekunden hinzu, bis die fünfte, Merriweather mit 95 KB und doppelt so groß wie jede andere Familie im Test, allein eine halbe Sekunde brachte. Die Schriftdaten wuchsen von 42 KB mit einer Familie auf 260 KB mit fünf, auf einer Seite, deren HTML und CSS 3 KB wogen.

Die Stabilität des Layouts war der andere Preis. Bis zu drei Familien verschob der Tausch nichts Messbares. Mit vier und fünf erreichte der schlechteste Durchlauf eine Layoutverschiebung von 0,097, knapp unter den 0,1, die Google in seinen Core Web Vitals als gut wertet. Das ist der Tausch selbst: Ersatztext, der neu umbricht, wenn eine Schrift mit anderen Proportionen ihn ersetzt.

font-display: block, swap, fallback und optional

Es gibt fünf Werte. Mit block versteckt der Browser den Text eine kurze Zeit, empfohlen sind etwa drei Sekunden, und zeigt ihn dann in der Ersatzschrift, bis der Font da ist. Mit swap zeigt er die Ersatzschrift sofort und tauscht, sobald der Font ankommt, egal wie spät. Mit fallback versteckt er den Text einen Moment, höchstens etwa 100 Millisekunden, zeigt dann die Ersatzschrift und tauscht nur, wenn der Font innerhalb weniger Sekunden ankommt. Mit optional wartet er denselben Moment und behält dann, was er hat: Ist der Font nicht bereit, bleibt die Ersatzschrift für diesen Seitenaufruf, und der geladene Font wird beim nächsten genutzt. Der fünfte Wert, auto, überlässt die Wahl dem Browser.

Unser Test zeigt den Kompromiss in Zahlen. Mit block wurde der Haupttext nach 0,93 statt nach 0,57 Sekunden sichtbar, rund 360 Millisekunden leere Fläche, wo die Überschrift stehen sollte. Mit optional erschien der Text so schnell wie mit swap, und nichts verschob sich, aber über unsere langsame Verbindung zeigte der erste Aufruf die Webfonts gar nicht.

Für die meisten Websites ist swap der richtige Standard für Fließtext, zusammen mit einer gut angepassten Ersatzschrift, damit der Tausch die Seite nicht verschiebt. Optional ist die bessere Wahl, wenn die Schrift ein Extra ist und Stabilität wichtiger ist, und block gehört nicht in die Nähe von Fließtext. Der Web Almanac fand swap auf 45 % der mobilen Seiten und block auf 23 %, fast ein Viertel des Webs versteckt also noch seinen Text, während Schriften laden.

Google Fonts oder lokal einbinden?

Dieselben zwei Schriften von Google Fonts statt vom eigenen Server zu laden, ließ den Haupttext 0,32 Sekunden später erscheinen, nach 0,89 statt nach 0,57 Sekunden. Die Schriftdateien waren gleich groß. Der Unterschied ist der Weg: Die Seite lädt zuerst ein Stylesheet von fonts.googleapis.com, das das Rendern blockiert, und dann die Schriftdateien von einer zweiten Domain, fonts.gstatic.com, also muss der Browser zwei zusätzliche Verbindungen aufbauen, bevor ein einziger Buchstabe des Webfonts ankommt.

Das alte Argument für Google Fonts war der Cache: Wer Roboto schon auf einer anderen Website gesehen hatte, hatte die Schrift bereit. Das endete 2020 mit Chrome 86, als Chrome begann, seinen Cache nach Website zu trennen, wie es Safari schon tat; eine für eine Website geladene Schrift wird von einer anderen nicht mehr genutzt. Jede Website bezahlt ihre Schriften so oder so selbst.

In der EU gibt es zusätzlich einen rechtlichen Grund. Im Januar 2022 verurteilte das Landgericht München I einen Websitebetreiber zu 100 € Schadenersatz an einen Besucher, weil die Website Google Fonts von Googles Servern lud und damit die IP-Adresse des Besuchers ohne Einwilligung an Google übermittelte. Das Gericht hielt fest, dass sich die Schriften auch ohne diese Übermittlung nutzen lassen, nämlich lokal eingebunden. Das Urteil löste in Deutschland eine Welle von Abmahnungen aus, und wer selbst hostet, hat das Thema erledigt. Die Lizenzen von Google Fonts erlauben es: Dateien herunterladen, auf den eigenen Server legen und im CSS einbinden.

Preload: wann er hilft und wann nicht

Ein Preload-Hinweis sagt dem Browser, einen Font zu laden, bevor er merkt, dass er ihn braucht. Das hilft, wenn Schriften spät entdeckt werden, typischerweise wenn sie in einem externen Stylesheet stehen, das selbst erst geladen und gelesen werden muss. Dann kann ein Preload einen ganzen Round-Trip sparen.

Er hilft nicht, wenn der Browser die Schriften ohnehin früh findet, und er kann schaden. In unserem Test standen die Font-Regeln direkt in der Seite, der Browser fand sie also sofort. Beide Familien per Preload zu laden, brachte die Schriften nur 0,05 Sekunden früher und schob den ersten Paint von 0,57 auf 0,74 Sekunden. Lade eine oder zwei Dateien vor, die oberhalb des sichtbaren Bereichs genutzt werden und in einem externen Stylesheet stehen, nicht jede Schriftstärke, die du besitzt. Der Web Almanac fand Font-Preloads auf 11 % der Seiten. Sie brauchen das Attribut crossorigin, selbst auf der eigenen Domain, sonst lädt der Browser die Datei doppelt.

Jede Datei kleiner machen: WOFF2, Subsets und Variable Fonts

Nutze WOFF2, das komprimierte Schriftformat, das jeder aktuelle Browser unterstützt; der Web Almanac fand es auf 78 % der mobilen Websites. Dann bilde Subsets: Eine Schrift mit Latein, Kyrillisch, Griechisch und Vietnamesisch trägt Tausende Zeichen, die eine deutsche oder englische Seite nie braucht. Google Fonts teilt Familien schon mit dem Deskriptor unicode-range nach Schriftsystem auf, sodass der Browser nur die Teile lädt, die eine Seite braucht.

Variable Fonts sind die andere große Ersparnis. Ein Variable Font enthält jede Schriftstärke in einer Datei, und Google Fonts liefert für viele Familien inzwischen genau das: In unserem Test kamen Normal und Fett von Roboto, und ebenso bei allen fünf Familien, aus jeweils einer einzigen Datei. Eine Datei mit 42 KB ersetzte, was früher eine Datei pro Schriftstärke war. Der Web Almanac fand Variable Fonts auf etwa einem Drittel der Seiten.

Unsere eigene Website ist ein Beispiel aus der Praxis. Google lieferte unsere Schrift, Inter, als zwei Dateien: eine lateinische mit 47 KB und eine für erweitertes Latein mit 83 KB, die zweite auf jeder Seite geladen wegen sechs rumänischer Buchstaben. Wir haben ein Subset gebaut, das Latein plus genau die erweiterten Zeichen enthält, die wir nutzen: 55 KB in einer Datei, selbst gehostet und per Preload geladen. Jede Seite trägt jetzt 55 KB Schrift statt 131 KB.

Die Schriften nutzen, die schon auf dem Gerät sind

Der schnellste Webfont ist der, den du nicht lädst. Jedes Betriebssystem bringt eine gut gestaltete Oberflächenschrift mit: Segoe UI unter Windows, San Francisco auf Apple-Geräten, Roboto unter Android. Die generische CSS-Familie system-ui fragt genau danach, ohne eine davon zu nennen; die CSS-Spezifikation beschreibt sie als die Standard-Oberflächenschrift der Plattform, gedacht, damit sich eine Seite „in das Aussehen des nativen Betriebssystems einfügt“. Eine typische Angabe ist font-family: system-ui, -apple-system, "Segoe UI", Roboto, sans-serif, wobei die genannten Schriften Rückfallebenen für ältere Browser sind.

Die Vorteile sind genau die Kosten aus unserer Tabelle, nur gestrichen. Keine Schriftdateien, also nichts zu laden und keine zusätzliche Anfrage. Kein Tausch, also keine Layoutverschiebung und kein Text, der die Schrift wechselt. Der Text erscheint beim ersten Paint, in einer Schrift, die das Gerät gut darstellt, weil sie für diesen Bildschirm gemacht wurde. Unsere Variante mit Systemschriften trug 0 KB Schriften auf einer Seite mit 3 KB.

Der Preis ist Kontrolle. Die Seite sieht unter Windows, auf einem Mac und auf einem Smartphone leicht unterschiedlich aus, und du kannst keine Schrift als Teil deiner Marke einsetzen. Damit sind Systemschriften ideal für Fließtext, Admin-Bereiche, Dashboards und Apps und eine vernünftige Wahl für Fließtext, selbst wenn Überschriften eine Markenschrift nutzen. Sie sind die moderne Form der „websicheren Schriften“ wie Arial und Georgia, mit dem Unterschied, dass sich system-ui jedem Gerät anpasst, statt allen dieselbe Schrift aufzuzwingen.

Verhindern, dass der Tausch die Seite verschiebt

Die Layoutverschiebung in unseren Läufen mit vier und fünf Familien kam von Ersatztext, der anders viel Platz brauchte als der Webfont. CSS löst das mit vier Deskriptoren in einem @font-face für die Ersatzschrift: size-adjust skaliert ihre Buchstaben, und ascent-override, descent-override und line-gap-override passen ihre Zeilenhöhe an. Stellst du sie so ein, dass zum Beispiel Arial genauso viel Platz einnimmt wie dein Webfont, ändert der Tausch das Aussehen der Buchstaben, ohne etwas zu verschieben.

Genau das macht unsere eigene Website: Unser @font-face für „Inter Fallback“ verweist auf das Arial, das schon auf dem Gerät ist, und setzt size-adjust auf 107,89 %, ascent auf 89,79 % und descent auf 22,36 %, Werte aus Inters eigenen Metriken. Frameworks können diese Werte für dich erzeugen, und sie lohnen sich immer, wenn du swap nutzt.

Wie viele Schriften sollte eine Website nutzen?

Für die meisten Websites lautet die Antwort: eine Webfont-Familie, höchstens zwei, und jede weitere kostet mehr, als sie bringt. In unserem Test fügte jede Familie nach der ersten rund 0,2 Sekunden hinzu, bis die Seite zur Ruhe kam, und ab vier Familien näherte sich die Layoutverschiebung Googles Grenze. Eine variable Familie deckt Überschriften, Fließtext und Buttons in jeder Schriftstärke ab, die du brauchst.

Willst du eine zweite Familie für Überschriften, nimm einen Variable Font, bilde ein Subset und lade ihn mit swap und angepasster Ersatzschrift oder mit optional, wenn er dekorativ ist. Hoste beide selbst. Erwäge Systemschriften für den Fließtext und behalte die Markenschrift nur für Überschriften. Und miss deine eigenen Seiten, statt einem einzelnen Wert zu vertrauen: PageSpeed 100 erreichen erklärt, was ein einzelner Lighthouse-Lauf aussagen kann und was nicht, und was dein Server mit PageSpeed macht behandelt Komprimierung und Caching, die auch für Schriftdateien gelten.

Trägt deine Website mehr Schriften, als sie braucht, misst eine Technische Analyse, was jede davon auf deinen echten Seiten kostet, und gibt dir die Reihenfolge, in der du sie behebst.

Quellen und Methode

Unser Test lief am 10. Oktober 2026: eine HTML-Seite mit fünf Schriftrollen (Fließtext, Überschriften, Navigation, Zitat, Fußzeile), jede zusätzliche Familie übernahm eine Rolle. Die Schriftdateien waren die lateinischen Subsets, die Google Fonts an diesem Tag an aktuelles Chrome auslieferte, selbst gehostet auf einem lokalen Server, sofern nicht anders angegeben. Chrome mit Smartphone-Emulation (412×823), 150 ms Round-Trip, 1,6 Mbit/s Download, 750 Kbit/s Upload, 4-fach verlangsamte CPU, Cache deaktiviert; 10 Varianten × 12 Ladevorgänge, pro Runde in gemischter Reihenfolge; angegeben sind Mediane.

• HTTP Archive — Web Almanac 2024, Fonts ↗

  Webfonts auf rund 87 % der Websites; font-display swap auf 45 % und block auf 23 % der mobilen Seiten; Font-Preload auf 11 % der Seiten; Variable Fonts auf etwa einem Drittel; WOFF2 auf 78 % der mobilen Websites; Google Fonts auf 48 % der mobilen Websites.

• MDN — font-display ↗

  Definitionen von auto, block, swap, fallback und optional über Block- und Swap-Phase.

• Chrome for Developers — Controlling font performance with font-display ↗

  Empfohlene Dauer: eine kurze Block-Phase von 3 Sekunden für block, eine extrem kurze Block-Phase von 100 ms oder weniger für fallback und optional und eine kurze Swap-Phase von 3 Sekunden für fallback.

• W3C — CSS Fonts Module Level 4, system-ui ↗

  system-ui stellt Text in der Standard-Oberflächenschrift der Plattform dar, damit sich Webinhalte in das Aussehen des nativen Betriebssystems einfügen.

• web.dev — CSS size-adjust for @font-face ↗

  Wie size-adjust und die Overrides für ascent, descent und line-gap eine Ersatzschrift an einen Webfont angleichen, damit der Tausch das Layout nicht verschiebt.

• Chrome for Developers — Gaining security and privacy by partitioning the cache ↗

  Ab Chrome 86 ist der HTTP-Cache nach Website und URL getrennt, eine für eine Website zwischengespeicherte Ressource wird von einer anderen nicht genutzt.

• IHK — LG München I, Urteil vom 20. Januar 2022, 3 O 17493/20 ↗

  Das Landgericht München I sprach 100 € Schadenersatz nach Art. 82 DSGVO zu, weil das Laden von Google Fonts von Googles Servern die IP-Adresse eines Besuchers ohne Einwilligung an Google übermittelte.