Font-Performance optimieren: So laden Webschriften schneller

Webschriften sind ein zentraler Bestandteil der Markenidentität. Sie sind aber auch ein Grund dafür, dass Websites langsam wirken, Text erst spät erscheint oder Inhalte beim Laden plötzlich springen. Willst du die Font-Performance optimieren, brauchst du vor allem fünf Hebel: das moderne Format WOFF2, eine bewusst gewählte Einstellung für font-display, schlanke Dateien durch Subsetting oder Variable Fonts, Schriften vom eigenen Server statt von Drittanbietern und ein sparsamer Einsatz von Preload.

Warum Schriften die Ladezeit so stark beeinflussen

Jede Webschrift ist eine zusätzliche Datei, die der Browser erst finden, anfordern und herunterladen muss, bevor er den Text in der gewünschten Gestalt darstellen kann. Google beschreibt in seinen Empfehlungen zur Optimierung von Webschriften, dass große Schriftdateien den First Contentful Paint verzögern können und dass eine ungünstige Einstellung für font-display zu unerwünschten Layoutverschiebungen führt. In der Praxis zeigen sich dabei zwei typische Effekte:

• Unsichtbarer Text (FOIT): Der Browser wartet auf die Webschrift und zeigt so lange gar keinen Text. Für Besucher wirkt die Seite leer oder defekt.
• Sichtbarer Schriftwechsel (FOUT): Der Browser zeigt zuerst eine Systemschrift und tauscht sie später gegen die Webschrift. Haben beide Schriften unterschiedliche Maße, verschieben sich Zeilen und Absätze.

Beide Effekte wirken sich auf die Core Web Vitals aus. Ist die größte Überschrift im sichtbaren Bereich das größte Element der Seite, hängt der Largest Contentful Paint direkt an der Schrift. Verschieben sich Inhalte beim Schrifttausch, steigt der Cumulative Layout Shift. Wie stark sich solche Werte auf Sichtbarkeit und Anfragen auswirken, zeigt die Einordnung zu schnelleren Ladezeiten für SEO und Conversions. Schriften sind dabei selten das einzige Problem, aber oft eines, das sich mit überschaubarem Aufwand beheben lässt.

Welche Schriften lädt deine Website wirklich?

Bevor du optimierst, solltest du wissen, was tatsächlich geladen wird. Gerade bei Websites, die über Jahre gewachsen sind, finden wir regelmäßig Schriftfamilien, die im Design gar nicht mehr vorkommen, oder Themes und Page Builder, die Schriften zusätzlich von externen Servern nachladen. So gehst du vor:

1. Öffne deine Website in Chrome oder Firefox und starte die Entwicklertools mit F12.
2. Wechsle in den Tab „Netzwerk“, filtere nach „Font“ und lade die Seite neu, idealerweise mit deaktiviertem Cache.
3. Notiere für jede Datei den Namen, das Format, die Größe und die Herkunft (eigene Domain oder fremder Server).
4. Gleiche die Liste mit deinem Design ab: Welche Schnitte werden wirklich verwendet? Oft werden Light, Medium und Black geladen, obwohl nur Regular und Bold im Einsatz sind.
5. Prüfe zusätzlich mit einem Performance-Test, ob Schriften als renderblockierend oder als Ursache von Layoutverschiebungen gemeldet werden.

Passende Werkzeuge für diesen Schritt haben wir in unserem Überblick über Tools für Analyse und Optimierung zusammengestellt. Allein diese Bestandsaufnahme reduziert die Schriftlast häufig spürbar, weil überflüssige Dateien einfach entfallen.

WOFF2 statt WOFF, TTF und EOT

Die Frage nach dem richtigen Format ist inzwischen eindeutig beantwortet. WOFF2 nutzt den Kompressionsalgorithmus Brotli und erreicht laut den Best Practices für Schriftarten von Google eine um etwa 30 Prozent bessere Komprimierung als WOFF. Da moderne Browser WOFF2 nahezu flächendeckend unterstützen, empfiehlt Google, ältere Formate in der Regel gar nicht mehr einzubinden.

Format	Kompression	Einsatz heute	Empfehlung
WOFF2	Brotli, sehr effizient	Standard für das Web	Immer verwenden
WOFF	zlib, weniger effizient	Nur für sehr alte Browser	In der Regel weglassen
TTF / OTF	unkomprimiert	Desktop-Schriftformat	Nicht im Web ausliefern
EOT	proprietär	Alte Internet-Explorer-Versionen	Nicht mehr nötig

In älteren Themes findest du häufig @font-face-Regeln mit vier oder fünf src-Einträgen. Moderne Browser laden zwar nur die erste passende Datei, die langen Fallback-Ketten machen das CSS aber unübersichtlich und verleiten dazu, alte Dateien auf dem Server zu behalten. Liegt dir eine Schrift nur als TTF oder OTF vor, wandelst du sie vor dem Einsatz in WOFF2 um. Prüfe dabei unbedingt die Lizenz: Nicht jede Desktop-Lizenz erlaubt die Nutzung als Webschrift!

font-display: swap, optional und die anderen Werte

Der Deskriptor font-display innerhalb von @font-face legt fest, wie sich der Browser verhält, solange die Webschrift noch nicht geladen ist. Das Chrome-Team beschreibt in seinem Beitrag zu font-display und Schrift-Performance drei Phasen: eine Block-Periode, in der Text unsichtbar bleibt, eine Swap-Periode, in der die Fallback-Schrift angezeigt und bei Bedarf noch getauscht wird, und eine Failure-Periode, in der die Fallback-Schrift endgültig bleibt.

Wert	Block-Periode	Swap-Periode	Geeignet für
block	kurz, etwa 3 Sekunden	unbegrenzt	Icon-Fonts, bei denen Ersatzzeichen stören
swap	nahezu 0 ms	unbegrenzt	Überschriften und Markenelemente
fallback	etwa 100 ms	etwa 3 Sekunden	Kompromiss für Fließtext
optional	etwa 100 ms	keine	Fließtext mit maximaler Stabilität
auto	browserabhängig	browserabhängig	Nicht empfehlenswert, da unberechenbar

Wann swap die richtige Wahl ist

Mit swap erscheint der Text sofort in einer Systemschrift. Sobald die Webschrift geladen ist, wird sie eingesetzt, egal wie lange das dauert. Für die Lesbarkeit ist das gut, denn niemand starrt gerne auf eine leere Fläche. Der Preis ist ein möglicher sichtbarer Wechsel und damit das Risiko von Layoutverschiebungen, wenn die Fallback-Schrift andere Maße hat.

Wann optional besser passt

Mit optional erhält die Webschrift nur ein sehr kurzes Zeitfenster. Ist sie nicht innerhalb von rund 100 Millisekunden verfügbar, bleibt der Browser für diesen Seitenaufruf bei der Systemschrift. Google bezeichnet diesen Ansatz in seinen Best Practices als die leistungsstärkste Strategie. Beim nächsten Seitenaufruf liegt die Schrift meist im Cache und wird dann direkt verwendet.

Unsere Empfehlung

Für die meisten Unternehmenswebsites bewährt sich eine Differenzierung: swap für prominente Markenelemente wie Hauptüberschriften, bei denen das Erscheinungsbild wichtig ist, und optional oder fallback für den Fließtext, bei dem Stabilität und Geschwindigkeit Vorrang haben. Wer Google Fonts über die API einbindet, steuert das Verhalten über den Parameter display=swap in der URL.

Google Fonts lokal hosten

Die dynamische Einbindung von Google Fonts ist bequem: Eine Zeile im Kopfbereich genügt. Technisch bedeutet sie aber, dass der Browser zuerst eine Verbindung zu einem fremden Server aufbauen, das CSS laden und anschließend die Schriftdateien von einem weiteren Host abrufen muss. Google selbst weist in seinen Empfehlungen zur Optimierung von Webschriften darauf hin, dass selbst gehostete Schriften die zusätzliche Verbindung zu Drittanbietern vermeiden.

In Deutschland kommt ein zweites Argument hinzu: Bei der dynamischen Einbindung wird die IP-Adresse deiner Besucher an Google übertragen. Diese Praxis gilt datenschutzrechtlich seit Jahren als heikel und war bereits Gegenstand gerichtlicher Auseinandersetzungen. Ob in deinem konkreten Fall weitere Pflichten bestehen, etwa Hinweise in der Datenschutzerklärung, klärst du am besten mit deiner oder deinem Datenschutzbeauftragten oder einer Fachanwältin für IT-Recht. So stellst du auf lokales Hosting um:

1. Lade die benötigten Schnitte im WOFF2-Format herunter, beschränkt auf die Zeichensätze, die du wirklich brauchst.
2. Lege die Dateien in einem eigenen Verzeichnis ab, zum Beispiel /fonts/ im Theme oder auf deinem Server.
3. Definiere die Schriften per @font-face in deinem CSS.
4. Entferne alle Verweise auf fonts.googleapis.com und fonts.gstatic.com, auch solche, die Theme, Page Builder oder Plugins selbst einfügen.
5. Prüfe im Netzwerk-Tab, dass keine Anfrage mehr an Google-Server geht.

Eine schlanke Definition sieht so aus:

@font-face {
  font-family: "Hausschrift";
  src: url("/fonts/hausschrift-latin.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

Bei WordPress ist Schritt 4 die häufigste Fehlerquelle. Viele Themes laden Google Fonts zusätzlich über eigene Einstellungen nach, und manche Plugins bringen ihre eigenen Schriften mit. Wie du solche Ladeprobleme in WordPress systematisch angehst, beschreiben wir ausführlich in unserem Beitrag WordPress Performance optimieren.

Subsetting: Nur die Zeichen laden, die du brauchst

Viele Schriften enthalten Glyphen für Dutzende Sprachen, etwa Kyrillisch, Griechisch oder Vietnamesisch. Auf einer deutschsprachigen Website werden diese Zeichen nie angezeigt, aber trotzdem mitgeladen, wenn die Datei sie enthält. Beim sogenannten Subsetting exportierst du nur die benötigten Zeichenbereiche. Google erläutert in seinem Beitrag zur Reduzierung der Webfont-Größe, wie sich Schriften über den Deskriptor unicode-range in Teilmengen aufteilen lassen, die der Browser nur bei Bedarf lädt.

Für deutsche Texte ist dabei eine Besonderheit wichtig: Das Subset muss Umlaute, das ß, die deutschen Anführungszeichen „ und “, den Gedankenstrich sowie das Eurozeichen enthalten. Fehlen diese Zeichen, ersetzt der Browser sie durch eine Systemschrift, und im Text tauchen einzelne Buchstaben in einer fremden Gestalt auf. Ein lateinisches Subset mit den Bereichen U+0000 bis U+00FF, den allgemeinen Satzzeichen ab U+2000 und U+20AC für das Eurozeichen deckt deutsche Inhalte in der Regel vollständig ab.

Eine Sonderform bietet die Google Fonts API: Über den Parameter text in der URL forderst du nur exakt die Zeichen an, die du brauchst, etwa für einen Schriftzug in der Kopfzeile. Laut der Dokumentation der Google Fonts API lässt sich die Dateigröße so um bis zu 90 Prozent reduzieren. Für dynamische Inhalte eignet sich das nicht, für feste Schriftzüge aber sehr wohl.

Variable Fonts: Viele Schnitte in einer Datei

Klassische Schriften liefern jeden Schnitt als eigene Datei aus: Regular, Italic, Semibold, Bold. Wer vier oder fünf Schnitte nutzt, lädt entsprechend viele Dateien. Variable Fonts bündeln dagegen Schnitte, Breiten und teilweise weitere Achsen in einer einzigen Datei. Google zeigt im Codelab zur Migration auf variable Schriftarten, wie sich dadurch mehrere Stile mit einer Datei abdecken lassen und welche gestalterischen Möglichkeiten sich daraus ergeben. Ob sich der Umstieg lohnt, hängt von deinem Design ab:

• Lohnt sich: Du verwendest drei oder mehr Schnitte einer Familie, nutzt feine Abstufungen in Überschriften oder möchtest das Gewicht je nach Bildschirmgröße anpassen.
• Lohnt sich eher nicht: Du verwendest nur Regular und Bold. Eine variable Datei ist meist größer als ein einzelner statischer Schnitt, sodass zwei gut optimierte statische Dateien gleichauf oder sogar leichter sein können.

In CSS gibst du bei einer variablen Schrift den unterstützten Bereich an, etwa font-weight: 100 900;. Danach kannst du jedes Gewicht innerhalb dieses Bereichs verwenden, ohne eine weitere Datei zu laden. Auch hier gilt: Subsetting und WOFF2 sind Pflicht, sonst verpufft der Vorteil.

Preload gezielt einsetzen

Schriften werden normalerweise erst entdeckt, wenn der Browser das CSS geladen und ausgewertet hat. Mit einem Preload im Kopfbereich signalisierst du ihm früher, dass eine bestimmte Datei gebraucht wird:

<link rel="preload" href="/fonts/hausschrift-latin.woff2" as="font" type="font/woff2" crossorigin>

Das Attribut crossorigin ist bei Schriften auch dann notwendig, wenn die Datei auf der eigenen Domain liegt. Fehlt es, lädt der Browser die Datei unter Umständen doppelt.

Preload ist allerdings kein Allheilmittel. Google rät in seinen Empfehlungen zur Optimierung von Webschriften ausdrücklich zur Zurückhaltung, weil vorgeladene Schriften Bandbreite belegen, die etwa für das Hauptbild oder kritische Skripte fehlt. Unsere Faustregel: Lade höchstens eine oder zwei Dateien vor, und zwar nur die, die im ersten sichtbaren Bereich ohne Scrollen gebraucht werden. Meist ist das der Schnitt der Hauptüberschrift oder des Fließtexts. Ob der Preload tatsächlich hilft, prüfst du mit einem Vorher-Nachher-Vergleich unter gleichen Bedingungen.

Layoutverschiebungen beim Schrifttausch vermeiden

Wenn die Fallback-Schrift breiter oder schmaler läuft als die Webschrift, verschieben sich beim Tausch Zeilenumbrüche, Buttons und ganze Absätze. Google empfiehlt in den Best Practices für Schriftarten, die Fallback-Schrift in ihren Metriken möglichst eng an die Webschrift anzugleichen.

Dafür stehen dir in @font-face Deskriptoren wie size-adjust, ascent-override, descent-override und line-gap-override zur Verfügung. Du definierst eine eigene Fallback-Familie auf Basis einer lokalen Systemschrift und skalierst sie so, dass sie die Fläche der Webschrift möglichst genau einnimmt:

@font-face {
  font-family: "Hausschrift Fallback";
  src: local("Arial");
  size-adjust: 105%;
  ascent-override: 92%;
}

body {
  font-family: "Hausschrift", "Hausschrift Fallback", sans-serif;
}

Die Werte im Beispiel sind Platzhalter. Die passenden Prozentwerte hängen von deiner Schrift ab und werden am besten mit einem Metrik-Werkzeug ermittelt oder im Browser feinjustiert. Zusätzlich hilft es, bei Elementen mit fester Höhe, etwa Navigationsleisten, ausreichend Raum einzuplanen, damit ein Schrifttausch keine Nachbarelemente verdrängt.

Caching und Auslieferung

Schriftdateien ändern sich selten. Deshalb sollten sie mit langen Cache-Laufzeiten ausgeliefert werden, damit der Browser sie bei Folgebesuchen direkt aus dem Speicher holt. Bewährt hat sich ein Header wie Cache-Control: public, max-age=31536000, immutable in Kombination mit versionierten Dateinamen. Änderst du eine Schrift, bekommt die Datei einen neuen Namen, und der Cache wird automatisch umgangen.

Auch das Hosting spielt eine Rolle: Ein Server mit HTTP/2 oder HTTP/3 kann mehrere Dateien parallel über eine Verbindung ausliefern, was Google ebenfalls in seinen Empfehlungen zur Optimierung von Webschriften nennt. Langsame Antwortzeiten des Servers verzögern dagegen jede Datei, auch die bestens optimierte Schrift. Weitere technische Kriterien, die über Ladezeit und Rankings entscheiden, findest du in unserer technischen SEO-Checkliste.

Typografie im Webdesign: Marke und Performance zusammendenken

Die beste technische Optimierung beginnt bei der Gestaltung. Jede zusätzliche Schriftfamilie und jeder weitere Schnitt ist eine gestalterische Entscheidung mit technischen Folgen. In unseren Projekten hat sich bewährt, die Typografie fürs Web von Anfang an mit klaren Grenzen zu planen:

• Höchstens zwei Familien: eine für Überschriften, eine für Fließtext. Häufig genügt sogar eine einzige Familie mit zwei Gewichten.
• Wenige Schnitte: Regular und Bold decken den Großteil ab. Kursiv nur, wenn es redaktionell wirklich gebraucht wird.
• Systemschriften prüfen: Für Formulare, Tabellen oder Navigation kann ein System-Font-Stack eine gute Wahl sein. Er lädt ohne Verzögerung und wirkt auf jedem Gerät vertraut.
• Lesbarkeit vor Effekt: Ausreichende Schriftgröße, Zeilenhöhe und Kontrast sind nicht nur gut für die Nutzererfahrung, sondern auch ein Baustein digitaler Barrierefreiheit.

Wer diese Grenzen schon im Corporate Design festlegt, spart später Aufwand. Eine Markenschrift, die nur als Desktop-Lizenz vorliegt oder in acht Schnitten eingesetzt werden soll, führt sonst fast zwangsläufig zu Kompromissen bei der Ladezeit.

Checkliste: In dieser Reihenfolge optimierst du deine Schriften

1. Bestandsaufnahme im Netzwerk-Tab: Welche Schriftdateien werden geladen, von wo und in welcher Größe?
2. Ungenutzte Familien und Schnitte entfernen.
3. Alle Schriften auf WOFF2 umstellen und alte Formate aus dem CSS streichen.
4. Google Fonts und andere externe Schriftquellen lokal hosten.
5. Subsetting durchführen, dabei Umlaute, ß, Anführungszeichen und Eurozeichen sichern.
6. Bei drei oder mehr Gewichten den Wechsel auf eine variable Schrift prüfen.
7. font-display festlegen: swap für Markenelemente, optional oder fallback für Fließtext.
8. Höchstens eine oder zwei kritische Schriften per Preload vorladen.
9. Fallback-Schrift mit size-adjust und Override-Deskriptoren angleichen.
10. Lange Cache-Header setzen und das Ergebnis mit einem Performance-Test kontrollieren.

Wenn du noch tiefer einsteigen möchtest, zeigen unsere WordPress Performance Hacks, welche weiteren Stellschrauben neben den Schriften die Ladezeit bestimmen.

Wenn du Unterstützung brauchst

Schriftoptimierung greift in Theme, CSS, Server und Datenschutz zugleich ein. Wenn du dafür keine Zeit hast oder dir die Umsetzung zu riskant erscheint, übernehmen wir das gern für dich: im Rahmen der Erstellung deiner Website, als Teil unserer WordPress Wartung ab 9,90 € im Monat oder auf einem schnellen Server mit unserem Basic Performance Hosting für 10 € im Monat. Du hast dabei einen festen Ansprechpartner, der dir erklärt, was wir ändern und warum.

Häufige Fragen zur Schriftoptimierung

Soll ich font-display: swap oder optional verwenden?

Das hängt davon ab, was dir wichtiger ist. swap zeigt Text sofort an und tauscht später auf die Webschrift, was das Markenbild sichert, aber Layoutverschiebungen verursachen kann. optional verzichtet bei langsamer Verbindung auf die Webschrift und bleibt dafür stabil. Für viele Websites ist swap bei Überschriften und optional beim Fließtext ein guter Kompromiss.

Brauche ich neben WOFF2 noch WOFF als Fallback?

In den allermeisten Fällen nicht. Moderne Browser unterstützen WOFF2 nahezu flächendeckend, und das Format komprimiert deutlich besser. WOFF lohnt sich nur, wenn deine Zielgruppe nachweislich sehr alte Browser nutzt, was du in deiner Webanalyse prüfen kannst.

Ist es Pflicht, Google Fonts lokal zu hosten?

Technisch ist es keine Pflicht, aber die dynamische Einbindung überträgt die IP-Adressen deiner Besucher an Google und gilt in Deutschland als datenschutzrechtlich riskant. Lokales Hosting vermeidet dieses Problem und spart zugleich eine Verbindung zu einem fremden Server. Bei rechtlichen Detailfragen hilft dir deine Datenschutzbeauftragte oder ein Anwalt für IT-Recht weiter.

Sind Variable Fonts immer schneller?

Nein. Eine variable Datei ersetzt mehrere statische Schnitte und spart damit Anfragen, ist aber größer als ein einzelner Schnitt. Nutzt du nur Regular und Bold, sind zwei gut optimierte statische WOFF2-Dateien oft genauso leicht oder leichter.

Wie viele Schriften darf eine Website laden?

Eine feste Obergrenze gibt es nicht, aber zwei Familien mit insgesamt zwei bis vier Schnitten reichen für die meisten Unternehmenswebsites. Wichtiger als die reine Anzahl ist, dass jede Datei als WOFF2, mit passendem Subset und vom eigenen Server ausgeliefert wird.