Machen Webfonts die Website langsam? Leitfaden für schnelle Schriften

Wir, Talha Aslan und unser Team, sehen in Projekten immer wieder dasselbe Muster. Eine Designerin wählt eine schöne Schrift aus. Danach bindet ein Entwickler die komplette Familie ein, und niemand prüft die Dateigröße. Folglich sehen Besucher kurz leere Überschriften, oder der Text springt plötzlich. Dieser Leitfaden zeigt Ihnen einen praktischen Weg für Webfonts. Das heißt: Wir erklären, was jede Einstellung löst und was Sie verlieren, wenn Sie einen Schritt auslassen.

In welcher Reihenfolge lädt der Browser eine Schriftdatei?

Der Browser holt Webfonts also nicht sofort. Zunächst liest er das HTML und findet das Stylesheet. Dann lädt er die CSS Datei und entdeckt die @font-face Regeln. Dann prüft er, ob sichtbarer Text diese Schrift wirklich braucht. Erst danach fordert er die Schriftdatei an. Deshalb stehen Schriften ziemlich weit hinten in der Ladekette.

Die Kette sieht so aus:

1. Das HTML Dokument kommt an, und der Browser findet den Verweis auf das Stylesheet.
2. Danach lädt die CSS Datei, und die Schriftangaben liegen dem Browser vor.
3. Danach verbindet der Browser DOM und Stile und entscheidet, welche Schriften er braucht.
4. Erst jetzt startet die Anfrage für die Schrift. Liegt die Datei auf einer anderen Domain, baut der Browser zuerst eine neue Verbindung auf.
5. Sobald die Datei da ist, zeichnet der Browser den Text mit der neuen Schrift neu.

Jeder Schritt wartet auf den vorherigen. Zum Beispiel kommen bei einer Schrift auf einer fremden Domain noch DNS Abfrage sowie TCP und TLS Handshake hinzu. Also geht es bei der Schriftoptimierung im Kern um Wartezeit. Sie können die Datei verkleinern, sie früher anfordern und festlegen, was der Besucher in der Zwischenzeit sieht. Das sind somit die drei wichtigsten Hebel.

Welche Core Web Vitals beeinflussen Webfonts?

Webfonts wirken vor allem auf zwei Kennzahlen: Largest Contentful Paint (LCP) und Cumulative Layout Shift (CLS). Das größte Element einer Seite ist oft eine Überschrift oder ein Textblock. Bleibt dieser Text unsichtbar, solange die Schrift lädt, verschlechtert sich der LCP. Konkret erklärt unser Leitfaden zum LCP die Kennzahl ausführlich.

Beim CLS liegt die Sache dagegen anders, denn hier zählt Bewegung. Der Browser zeichnet den Text zunächst in einer Ersatzschrift. Sobald der Webfont ankommt, zeichnet er alles neu. Unterscheiden sich beide Schriften in Breite oder Zeilenhöhe, wachsen oder schrumpfen Absätze. Somit verschieben sich Buttons und Bilder darunter. Wie der Browser diese Verschiebung misst, beschreibt unser Artikel zum CLS.

Die Interaktionskennzahl INP hängt nur indirekt mit Schriften zusammen. Viele Schriftdateien können zusätzliche Renderarbeit im Hauptthread auslösen. In der Praxis sehen Sie die größten Gewinne allerdings beim LCP und beim CLS. Einen Überblick über alle drei Kennzahlen gibt unser Beitrag zu den Core Web Vitals.

Warum ist die Dateigröße von Webfonts so wichtig?

Jede Schriftdatei ist eine Ressource im Netz, und ihre Größe verwandelt sich direkt in Wartezeit. Innerhalb einer Schriftfamilie liegt jeder Schnitt in einer eigenen Datei: Regular, Bold, Italic und Bold Italic. Zudem enthalten viele Pakete Hunderte oder sogar Tausende Zeichen, sogenannte Glyphen. Selbst wenn Ihre Website nur auf Deutsch erscheint, laden Sie womöglich griechische, kyrillische oder vietnamesische Zeichen mit.

Der Leitfaden von web.dev zu Schriften nennt für lateinische Schriften etwa 100 bis 1.000 Glyphen. CJK Schriften für Chinesisch, Japanisch und Koreanisch können mehr als 10.000 Glyphen enthalten. Kurz gesagt: Ungenutzte Glyphen mitzuschicken gleicht einem Buch, das Sie nie aufschlagen und trotzdem ständig herumtragen.

Beispielrechnung: Eine Website nutzt vier Schnitte, und jeder komprimierte Schnitt wiegt etwa 40 KB. Zusammen ergibt das also 160 KB. Reduziert dieselbe Website auf zwei Schnitte und nutzt ein Subset, sinkt die Summe spürbar. Diese Werte sind nur eine Beispielrechnung; echte Größen hängen von der Schrift ab. Entscheidend ist, dass Sie Ihre eigenen Dateien einzeln in den Entwicklertools des Browsers prüfen.

Brauchen Sie neben WOFF2 noch ein anderes Format?

Für die meisten aktuellen Projekte lautet die Antwort nein. WOFF2 (Web Open Font Format 2) ist ein komprimiertes Format für die Auslieferung von Schriften und nutzt Brotli. Laut web.dev ist WOFF2 das neueste Format und hat die breiteste Browserunterstützung. Außerdem komprimiert es etwa 30 Prozent besser als WOFF. Ein im selben Leitfaden zitierter Experte empfiehlt sogar, nur noch WOFF2 einzusetzen.

In älteren Projekten finden wir oft dieselbe Altlast. Das CSS listet EOT, TTF, SVG und WOFF nacheinander auf. Diese Liste ist allerdings Altcode, der heute niemandem mehr hilft. Zudem liegen zusätzliche Dateien auf dem Server, und die Pflege wird aufwendiger. Daher vereinfacht eine einzige WOFF2 Quelle den Code und beseitigt das Risiko, dass ein falsches Format lädt.

Haben Sie nur TTF oder OTF Dateien, erzeugen Open Source Konverter daraus WOFF2. Prüfen Sie allerdings zuerst die Lizenz. Manche kommerziellen Lizenzen verbieten die Umwandlung oder das Neuverpacken für das Web. Deckt die Lizenz die Webnutzung ausdrücklich ab, bereitet die Umwandlung meist keine Probleme. Sind Sie unsicher, fragen Sie daher beim Schriftanbieter nach.

Was bedeutet font-display und welchen Wert sollten Sie wählen?

font-display ist ein CSS Deskriptor innerhalb der @font-face Regel. Er legt fest, was der Browser tut, bis die Schrift ankommt. Laut MDN besteht die Zeitleiste der Schriftanzeige aus drei Phasen: Block, Swap und Failure.

In der Blockphase zeichnet der Browser den Text mit einer unsichtbaren Ersatzschrift. Während der Swapphase zeigt er eine sichtbare Ersatzschrift und tauscht sie aus, sobald die Schrift fertig geladen ist. In der Failurephase wertet der Browser die Schrift als gescheitert und bleibt bei der Ersatzschrift. Anders gesagt: Jeder Wert verteilt die Länge dieser drei Phasen unterschiedlich.

Unsere Faustregel ist einfach. Muss die Markenschrift auf jeden Fall erscheinen, wählen Sie swap. Der Text erscheint sofort und wechselt, sobald die Schrift da ist. Stehen Tempo und Stabilität an erster Stelle, wählen Sie optional. Kommt die Schrift dann nicht sehr schnell, bleibt der Browser für diesen Seitenaufruf bei der Ersatzschrift. Für Fließtext funktionieren optional oder fallback in den meisten Projekten gut. Für Überschriften empfehlen wir swap zusammen mit einer abgestimmten Ersatzschrift.

Die Werte von font-display im Vergleich

Die folgende Tabelle fasst die Beschreibungen von MDN und web.dev zusammen. Genaue Zeiten unterscheiden sich je nach Browser, deshalb nutzen wir relative Angaben statt Millisekunden.

Der Leitfaden von web.dev empfiehlt optional für die Performance. Für Text, der schnell erscheinen und trotzdem den Webfont nutzen soll, schlägt er swap vor. Unsere eigene Erfahrung mit Webfonts zeigt zudem in dieselbe Richtung.

Wie verkleinern Sie eine Schrift mit Subsetting?

Subsetting bedeutet, aus einer Schriftdatei alle Glyphen zu entfernen, die Ihre Website nie nutzt. Übrig bleibt eine kleinere Datei mit genau den Buchstaben, Ziffern und Zeichen, die Sie brauchen. Der Leitfaden von web.dev nennt dafür Open Source Werkzeuge wie subfont und glyphhanger.

Für ein deutschsprachiges Subset sollten Sie diese Zeichen nie vergessen:

• Die Umlaute ä, ö, ü in Klein und Großschreibung sowie das ß.
• Das Eurozeichen, das Prozentzeichen und das Gradzeichen.
• Deutsche Anführungszeichen, Apostroph und Gedankenstrich.
• Zeichen weiterer Sprachversionen, etwa türkisch ğ, ş und ı.
• Sonderzeichen, die Nutzer in Formulare oder Kommentare tippen könnten.

Der häufigste Fehler ist ein Subset, das nur englische Grundbuchstaben abdeckt. Dann holt der Browser fehlende Zeichen aus der Ersatzschrift. Infolgedessen sehen einzelne Buchstaben mitten im Wort anders aus. Testen Sie das Subset deshalb auf einer Seite, die alle erwarteten Zeichen enthält. Zeigt Ihre Website Inhalte von Nutzern, halten Sie das Subset außerdem etwas breiter.

Wie funktioniert unicode-range auf mehrsprachigen Websites?

unicode-range ist ein Deskriptor, der dem Browser mitteilt, welche Zeichen eine Schriftdatei abdeckt. Enthält die Seite kein Zeichen aus diesem Bereich, lädt der Browser die Datei gar nicht. Zum Beispiel können Sie statt einer großen Datei zwei kleine anbieten: Basic Latin und erweitertes Latein.

Für manche Sprachen gibt es dabei einen Haken. Basic Latin enthält weder die deutschen Umlaute noch das ß; diese Zeichen liegen im Bereich Latin 1 Supplement. Türkische Buchstaben wie ş liegen dann sogar im erweiterten Bereich. Kommen solche Zeichen auf fast jeder Seite vor, lädt die zweite Datei ohnehin fast immer. Trotzdem lohnt sich die Aufteilung wirklich auf mehrsprachigen Websites mit kyrillischen oder griechischen Versionen.

Der Leitfaden von web.dev weist zudem auf ein wichtiges Detail hin: Preload ignoriert unicode-range Angaben. Laden Sie eine Subsetdatei per Preload vor, kommt sie auch dann, wenn die Seite keines ihrer Zeichen nutzt. Setzen Sie Preload daher nur für die Datei ein, die tatsächlich auf jeder Seite vorkommt.

Wann helfen Preload und Preconnect wirklich?

Preload ist ein Ressourcenhinweis, der den Browser bittet, eine Datei früh zu holen, ohne auf das CSS zu warten. Da Schriften spät in der Kette stehen, kann ein Preload der wichtigsten Schrift den LCP verbessern. Allerdings warnt web.dev, dass Preload anderen Ressourcen Bandbreite wegnimmt. Laden Sie jede Schrift per Preload vor, verzögern Sie stattdessen Bilder und Stile.

Preconnect dagegen bereitet die Verbindung vor, nicht die Datei. Liegt die Schrift auf einer anderen Domain, erledigt der Browser DNS, TCP und TLS im Voraus. Bei Google Fonts kommen Stylesheet und Schriftdateien von zwei verschiedenen Domains. Laut web.dev laden Schriftdateien über CORS. Folglich braucht der Preconnect Hinweis für die Schriftdomain das Attribut crossorigin.

Unsere kurze Regel: Hosten Sie Webfonts selbst, können Sie auf Preconnect verzichten, denn die Verbindung besteht bereits. Dann genügt meist ein einziger Preload für die Überschriftenschrift im ersten sichtbaren Bereich. Nutzen Sie einen Drittanbieter, setzen Sie Preconnect und entscheiden über Preload erst nach einer Messung.

Ist lokales Hosting schneller als Google Fonts?

Einen allgemeinen Sieger gibt es dennoch nicht. Der Leitfaden von web.dev sagt klar, dass selbst gehostete Schriften nicht immer schneller sind als Schriften von Drittanbietern. Er empfiehlt, zuerst ein CDN (Content Delivery Network) und HTTP/2 sicherzustellen. Danach sollten Subsetting und WOFF2 folgen.

Früher hatten Schriften von Drittanbietern einen Vorteil. Hatte ein Besucher dieselbe Schrift schon auf einer anderen Website geladen, kam sie aus dem Cache. Moderne Browser trennen den Cache jedoch nach Website, sodass dieser Vorteil weitgehend verschwunden ist. Somit ist die zusätzliche Verbindung zu einer fremden Domain zu einem deutlicheren Kostenfaktor geworden.

In der Praxis hosten wir Webfonts bei den meisten Unternehmenswebsites lokal. Sie sparen eine zusätzliche Verbindung, bestimmen die Cachedauer selbst und bauen das Subset genau nach Bedarf. Außerdem bleiben Sie außerhalb der Datenschutzdebatte, die wir im nächsten Abschnitt behandeln. Ist Ihr Server jedoch langsam und fehlt ein CDN, messen Sie vor der Entscheidung.

Worum geht es in der Debatte um Google Fonts und DSGVO?

Der Kern der Debatte ist zunächst schnell erklärt. Laden Sie eine Schrift von einem fremden Server, verbindet sich der Browser des Besuchers mit diesem Server. Dabei erreichen technische Daten wie die IP Adresse den Anbieter. Nach der Datenschutzgrundverordnung (DSGVO) kann eine IP Adresse als personenbezogenes Datum gelten. Deshalb stand die Rechtsgrundlage dieser Übermittlung in Europa und besonders in Deutschland stark in der Diskussion.

Es handelt sich um eine Frage der rechtlichen Auslegung, und dieser Text ist keine Rechtsberatung. Bitte wenden Sie sich für Ihren Fall an eine Anwältin, einen Anwalt oder eine Fachperson für Datenschutz. Technisch gibt es eine saubere Lösung: Sie liefern die Schriften vom eigenen Server aus. Dann verbindet sich der Besucher für Schriften mit keinem Drittanbieter. Weitere Schritte beschreibt unser Leitfaden für eine datenschutzkonforme Website.

Außerdem verdient ein weiterer Punkt Aufmerksamkeit. Sie glauben vielleicht, Ihre Schriften lokal zu hosten, während ein Plugin, ein Theme oder eine Kartenkomponente dieselbe Schrift weiterhin extern abruft. Filtern Sie daher im Netzwerktab der Entwicklertools nach Schriften und prüfen Sie, von welcher Domain jede Anfrage stammt. Solche versteckten Aufrufe finden wir häufig, zum Beispiel auf WordPress Websites.

Sind variable Fonts die bessere Wahl für Webfonts?

Ein variabler Font bündelt mehrere Schnitte in einer Datei und erlaubt fließende Übergänge zwischen ihnen. Der Leitfaden von web.dev zu variablen Fonts nennt fünf registrierte Achsen: Gewicht (wght), Breite (wdth), Neigung (slnt), optische Größe (opsz) und Kursiv (ital). Schriftgestalter können außerdem eigene Achsen ergänzen.

Der Vorteil hängt davon ab, wie viele Schnitte Sie nutzen. Verwendet Ihre Website sechs Gewichte, ersetzt eine variable Datei sechs einzelne Anfragen. Allerdings betont derselbe Leitfaden, dass ein variabler Font oft größer ist als ein einzelner statischer Schnitt. Eine Website, die nur Regular und Bold braucht, bleibt mit zwei statischen Dateien womöglich leichter.

Stellen Sie sich vor der Entscheidung diese Fragen:

• Wie viele Gewichte und Breiten nutzt die Website tatsächlich?
• Braucht das Design Zwischenstufen wie 450 oder 650?
• Ist die komprimierte variable Datei kleiner als alle statischen Dateien zusammen?
• Können Sie die variable Datei per Subset verkleinern?

Beantworten Sie die meisten Fragen mit ja, ist ein variabler Font sinnvoll. Sonst sind zwei statische WOFF2 Dateien die klügere Wahl.

Wie verringern Ersatzschrift und size-adjust die Layoutverschiebung?

Eine Ersatzschrift ist die Systemschrift, die der Browser nutzt, bis der Webfont ankommt, oder wenn er nie ankommt. Die Layoutverschiebung entsteht aus dem Größenunterschied zwischen beiden. Um diese Lücke zu verkleinern, nutzen Sie den Deskriptor size-adjust innerhalb von @font-face. Der Leitfaden von web.dev empfiehlt ihn ausdrücklich, um die Verschiebung zwischen Ersatzschrift und Webfont zu verringern.

Die Methode in Kürze: Sie schreiben eine zweite @font-face Regel, die auf eine verbreitete lokale Schrift wie Arial verweist. Dann skalieren Sie diese Ersatzschrift mit size-adjust, bis ihre Breite dem Webfont nahekommt. Bei Bedarf gleichen ascent-override und descent-override auch die Zeilenhöhe an. So bleiben Absätze beim Schriftwechsel nahezu an ihrem Platz.

Beispielszenario: Die Überschriftenschrift ist schmal, die Ersatzschrift dagegen breit. Auf dem Smartphone wird eine zweizeilige Überschrift mit der Ersatzschrift dreizeilig. Sobald die Schrift lädt, springt sie zurück auf zwei Zeilen. Folglich hüpft der Button darunter jedes Mal. Verschmälern Sie die Ersatzschrift mit size-adjust, bleibt die Überschrift von Anfang an zweizeilig. Das sind nur wenige Zeilen CSS, trotzdem kann der Unterschied beim CLS deutlich ausfallen.

Wann ist ein System Font Stack sinnvoller?

Ein System Font Stack ist eine font-family Angabe, die Schriften auflistet, die auf dem Gerät des Besuchers bereits installiert sind. Keine Datei lädt, also ist er die schnellste Option überhaupt. Für Adminbereiche, interne Werkzeuge und dichte Datentabellen ist er oft die richtige Wahl.

Systemschriften tragen jedoch keinen Markencharakter und sehen auf jedem Gerät anders aus. Daher empfehlen wir meist einen Mittelweg. Nutzen Sie die Markenschrift für Überschriften und eine Systemschrift für den Fließtext. Auf diese Weise bleibt das Markengefühl erhalten, und der Bereich mit dem meisten Text erscheint ohne Wartezeit.

Diese Entscheidung hängt außerdem mit der Lesbarkeit zusammen. Worauf Sie bei der Auswahl einer Schrift achten sollten, erklären wir in unserem Leitfaden zur Webtypografie. Hier betonen wir nur eines: Sie müssen sich nicht zwischen Tempo und Marke entscheiden. Die richtige Aufteilung schützt also beides.

Warum verursachen Iconfonts und ungenutzte Schnitte Probleme?

Zunächst zur Technik: Ein Iconfont speichert Symbole als Zeichen in einer Schriftdatei. Die meisten Pakete enthalten Hunderte Icons, während eine typische Website nur eine Handvoll nutzt. Zudem zeigt der Bildschirm leere Kästchen oder zufällige Buchstaben, wenn der Iconfont ausfällt. Auch Screenreader lesen diese Zeichen womöglich falsch vor.

Aus diesem Grund funktionieren eingebettete SVG Grafiken oder einzelne SVG Dateien für Icons meist besser. Sie liefern nur die Symbole aus, die Sie wirklich nutzen, und können jedem einen sinnvollen barrierefreien Namen geben.

Ungenutzte Schnitte verursachen ein ähnliches Problem. Zum Beispiel definiert die Designdatei Thin, Light, Regular, Medium, Semibold, Bold und Black. Auf der fertigen Website erscheinen allerdings oft nur zwei oder drei davon. Deshalb durchsucht unser Team in jedem Projekt die font-weight Werte im CSS und entfernt Schnitte, die niemand nutzt. Diese einfache Bereinigung halbiert manchmal schon allein die gesamte Schriftgröße; das genaue Verhältnis hängt vom Projekt ab.

Wie messen Sie die Performance von Webfonts?

Optimierung ohne Messung bleibt eine Vermutung, und bei Webfonts gilt das genauso. Beginnen Sie mit dem Netzwerktab der Entwicklertools. Filtern Sie nach Schriften und notieren Sie, wie viele Dateien laden, wie groß sie sind und welche Domain sie ausliefert. Danach erstellen Sie einen Lighthouse Bericht. Wie Sie diesen Bericht lesen, zeigt unser Leitfaden zum Lighthouse Test Schritt für Schritt.

Achten Sie beim Messen auf diese Punkte:

• Wann starten die Anfragen für Schriften im Vergleich zu den Anfragen für den ersten Bildschirm?
• Ist das LCP Element ein Text oder ein Bild?
• Wie lange bleibt Text bei gedrosselter Verbindung unsichtbar?
• Verschiebt sich die Seite, wenn die Schrift ankommt?
• Lädt dieselbe Schrift aus zwei verschiedenen Quellen?

Labormessungen geben eine Richtung vor, aber echte Nutzerdaten treffen die Entscheidung. Der Bericht zu den Core Web Vitals in der Search Console und Felddaten zeigen, ob eine Änderung echten Besuchern hilft. Für einen schnellen allgemeinen Check können Sie außerdem unseren SEO Check nutzen.

Beispielszenario: Wie funktioniert eine Schriftdiät auf einer Unternehmenswebsite?

Der folgende Ablauf ist kein echter Kundenfall. Er ist ein Beispielszenario, das typische Situationen aus unserer Arbeit verbindet. Konkret nutzt eine Unternehmenswebsite zwei Schriftfamilien. Aus der Überschriftenfamilie lädt sie vier Schnitte, aus der Textfamilie fünf. Die Schriften kommen von einem fremden Server, und es gibt keinen Anzeigewert.

1. Zuerst erfasst das Team im Netzwerktab neun Anfragen für Schriften und deren Gesamtgröße.
2. Ein Scan des CSS zeigt, dass nur fünf Schnitte tatsächlich vorkommen.
3. Nach der Prüfung der Lizenz zieht das Team die Schriften als WOFF2 auf den eigenen Server um.
4. Dann baut es ein Subset, das alle Sprachen der Website abdeckt.
5. Die Überschriftenschrift bekommt swap, die Textschrift optional.
6. Für die Überschrift kommt eine mit size adjust abgestimmte Ersatzschrift hinzu.
7. Nur die Überschriftenschrift im ersten sichtbaren Bereich erhält einen Preload.
8. Schließlich vergleicht das Team Lighthouse und Felddaten mit den alten Werten.

In diesem Szenario erwarten Sie weniger Anfragen, eine kleinere Gesamtgröße und ein ruhigeres Layout. Wie groß der Gewinn bei Webfonts ausfällt, hängt von Server, Theme und Inhalt ab. Deshalb versprechen wir hier keine Zahl. Entscheidend ist die Reihenfolge: erst messen, dann aufräumen, zuletzt feinjustieren.

Checkliste für schnelles Laden von Webfonts

Ob Sie eine neue Website bauen oder eine bestehende verbessern: Gehen Sie diese Liste der Reihe nach durch.

• Halten Sie die Zahl der Familien und Schnitte klein; zwei Familien und drei bis vier Schnitte reichen den meisten Websites.
• Liefern Sie nur WOFF2 aus.
• Bauen Sie für jede Sprache ein Subset und testen Sie es.
• Geben Sie jeder @font-face Regel einen bewussten Wert für font-display.
• Hosten Sie die Schriften selbst, wenn die Lizenz es erlaubt.
• Nutzen Sie einen Drittanbieter, ergänzen Sie Preconnect mit crossorigin.
• Laden Sie nur die kritische Schrift für den ersten Bildschirm per Preload.
• Gleichen Sie die Ersatzschrift mit size-adjust an den Webfont an.
• Ersetzen Sie Iconfonts durch SVG Icons.
• Geben Sie Schriftdateien eine lange Cachedauer.
• Suchen Sie im Netzwerktab nach versteckten Schriftaufrufen von Plugins und Themes.
• Vergleichen Sie Lighthouse und Felddaten vor und nach jeder Änderung.

Fehlt Ihnen die Zeit für diese Liste, richtet unser Webdesign Service Schriften von Anfang an mit Blick auf die Ladezeit ein. Teilen Sie uns die Struktur Ihrer Website mit, dann erstellen wir Ihnen ein ausführliches Angebot.

Welche Fehler passieren bei Webfonts am häufigsten?

Die Fehler, die wir in Projekten sehen, ähneln sich. Erstens binden Teams eine komplette Schriftfamilie mit allen Schnitten ein. Zweitens setzen sie für ihre Webfonts keinen Wert für font-display, sodass der Browser allein entscheidet. Drittens laden Theme und Plugin dieselbe Schrift doppelt.

Zudem ist ein vierter Fehler ein Preload für jede Schriftdatei. Statt kritische Ressourcen zu priorisieren, verstopft diese Einstellung die Warteschlange. Fünftens vergessen manche Subsets die Umlaute oder das ß. Sechstens wechseln Teams zum lokalen Hosting, stellen aber keine Cacheheader ein. Dann muss der Browser die Datei bei jedem Besuch erneut prüfen.

Nicht zuletzt ist es ein Fehler, Design und Tempo als getrennte Themen zu behandeln. Teams sollten Schriftentscheidungen am ersten Tag des Designs treffen, zusammen mit einem Performancebudget. Genau deshalb besprechen wir Schrift, Zahl der Schnitte und Ladestrategie im selben Termin.

Wann im Designprozess sollten Sie über Schriften entscheiden?

Der beste Zeitpunkt ist der Tag, an dem das Design beginnt. Denken Sie erst nach der Schriftwahl an Tempo, leidet entweder das Design oder die Ladezeit. Schreiben Sie daher die erlaubte Zahl der Schnitte, die Lademethode und die Ersatzschrift direkt neben die Schrift in Ihren Styleguide. Unser Beitrag zu Schriftarten für Onlineshops betrachtet dieselbe Entscheidung aus Sicht eines Shops.

Design und Entwicklung brauchen deshalb eine gemeinsame Sprache. Wünscht sich eine Designerin zum Beispiel ein weiteres Gewicht, sollte sie wissen, dass das eine weitere Datei bedeutet. Ebenso sollte ein Entwickler mit dem Designteam sprechen, bevor er eine Markenschrift durch eine Systemschrift ersetzt. Somit trifft niemand diese Entscheidungen allein.

Soll Ihre neue Website von Anfang an schnell und stimmig sein, können Sie ein Angebot bei unserem Webdesign Team anfragen. Wir bündeln Entscheidungen zu Schrift, Bild und Code in einem gemeinsamen Performancebudget.

Fazit: Welche Reihenfolge führt zu schnell ladenden Webfonts?

Zusammengefasst sind Webfonts nicht der Feind; unkontrolliertes Laden ist es. Messen Sie zunächst und bestimmen Sie die Schnitte, die Sie wirklich nutzen. Dann verkleinern Sie die Dateien mit WOFF2 und Subsetting. Danach steuern Sie die Wartezeit mit font-display, Preload und einer abgestimmten Ersatzschrift. Zuletzt bewerten Sie die Datenschutzseite und prüfen das lokale Hosting.

Folgen Sie dieser Reihenfolge, bewahren Sie Ihre Markenidentität und zeigen Besuchern nie einen leeren oder springenden Bildschirm. Zudem ist jeder Schritt messbar, also zeigt Ihnen ein Bericht, ob eine Änderung gewirkt hat.