Nachteile von Web Fonts: Lösungsansätze

Fangen wir mit der naheliegendsten Optimierung an.

Die Nutzung von Web Fonts ist meiner Meinung nach nur gerechtfertigt, wenn sie zu einer deutlichen Verbesserung der User-Experience und/oder dem Erfolg der Webseite beitragen. Ich würde argumentieren, dass Web Fonts (für Text) nur gerechtfertigt sind, wenn sie für das Branding der Webseite oder der damit verbunden Produkte/Unternehmen von Bedeutung sind. Eine etwas ausbalanciertere Entscheidungshilfe bietet dieser erhellende Blogpost von David Gilbertson.

Ein häufiger Einwand gegen System Fonts ist, dass unterschiedliche Fonts auf den verschiedenen Systemen verwendet werden können. Mit einer guten Fallback Strategie kann man diese Unterschiede aber minimieren. Modern Font Stacks gibt eine Übersicht über ähnliche Fonts, die auf verschiedenen Systemen zum Einsatz kommen. Wenn man nun noch @font-face Deskriptoren (mehr dazu in Optimierung 4.1) wählt, kann man ein nahezu identisches Aussehen zwischen den Systemen erzeugen. Das bedeutet natürlich erstmal etwas Mehrarbeit, aber erspart uns andererseits Arbeit mit den Nachteilen 2, 3 und 4, die im Folgenden behandelt werden.

Variable Web Fonts erlauben es mehrere Fonts einer Familie mit nur einem Request runterzuladen. Das reduziert die Datenlast. Da Variable Web Fonts größer sind als die normalen, lohnt es sich aber erst, wenn ein variabler Web Font mindestens zwei normale Web Fonts ersetzt.

Obwohl die Technologie noch recht neu ist, wird sie von den meisten Browsern unterstützt⁴ und ein beachtlicher Anteil der gesendeten Web Fonts ist variable⁵. Dies liegt vor allem an Google Fonts, die bisher fast alle variablen Web Fonts im Netz gesendet haben.

Lassen wir die BesucherInnen entscheiden, ob Fonts geladen werden, können wir zusätzlich Daten sparen. Kommen die BesucherInnen mit schlechter Internetverbindung auf unsere Webseite oder signalisieren uns, dass sie Daten sparen möchten,⁶ können wir auf Web Fonts verzichten. (Diese Optimierung lässt sich natürlich auch auf andere Ressourcen anwenden.) So machen wir unsere Webseite inklusiver.

window.navigator.connection⁷gibt uns Auskunft über die Konnektivität der BesucherInnen in JS, inklusive saveData Attribut.

Sollten die Web Fonts auf unserem eigenen Server liegen (siehe Optimierung 2.1 and 4.2), sollten wir diese möglichst aggressiv cachen. Web Fonts ändern sich in der Regel nicht und sollten wir doch Angst davor haben, dass wir sie eines Tages ändern, können wir einen Hash des Fonts (z.B. als GET Parameter) in dessen URL integrieren.

Werden Web Fonts erst nach User-Interaktion / Scrolling sichtbar, so können wir sie nachladen (lazyloading). Beim Scrolling bietet sich die IntersectionObserver API an, um das Laden zu triggern.⁸ Bei User-Interaktion, können entsprechende Event-Listener das Laden auslösen.

Browser laden Fonts generell nicht, so lange diese nur in Elementen benötigt werden, die durch display: none versteckt sind, da diese Elemente nicht Teil des “Render Baums” sind.⁹ visibility: hidden und content-visibility: auto|hidden bieten diesen positiven Nebeneffekt leider nicht. Wenn ihr den display: none Trick nicht verwenden könnt, müsst ihr selbst einen lazyload-Word-Around implementieren.

Font Formate sind im Laufe der Jahre deutliche effizienter geworden. Unkomprimierte Formate wie OTF oder TTF sind 2–3-mal so groß wie WOFF (gzip Kompression) und WOFF2 (brotli Kompression). Wobei WOFF2 nochmal deutlich stärker komprimiert ist.¹⁰ Es ist sinnvoll nur noch WOFF2 Kompression zu verwenden, da Browser Support seit einigen Jahren schon fantastisch ist.¹¹

Web Fonts decken meist alle unicode Zeichen ab. Das ist weit mehr als wir gewöhnlich auf unseren Webseiten brauchen. Zum Glück lassen sich Web Fonts in Teilbereiche aufteilen, so dass wir nur die benötigten Zeichen zur Verfügung stellen können. Welche Ranges wir auf unserer Webseite verwenden werden müssen ist natürlich schwierig von Hand zu bestimmen. Glücklicherweise gibt es Tools wie subfont on GitHub, mit denen wir benötigte Untermengen (Subsets) auf Seitenebene bestimmen und generieren können. Liebe geht raus.

Eine Möglichkeit wäre, BesucherInnen erst um Erlaubnis zu fragen. Dies könnte als Teil der “Cookie Notice” geschehen. Wie praktikabel diese Lösung für unser Projekt ist, müssen wir dann im Einzelfall abschätzen. Wenn die NutzerInnen nur notwendige Cookies akzeptieren, müssen wir in Anbetracht des oben genannten Urteils in Kauf nehmen, dass keine Web Fonts von Dritten geladen werden.

Wir können Web Fonts auf unseren eigenen Servern hosten, aktuell können wir einen Trend dazu beobachten. Das erspart uns Probleme mit der Privatsphäre und sollte uns auch Performance Vorteile bringen, da wir keine Verbindung zu einem anderen Server aufbauen müssen und Download von Fonts durch link[rel=preload] schneller initiieren können (Optimierung 3.2) . In der Praxis zeigt sich aber, dass Webseiten mit selbst-gehosteten Fonts nicht besser performen als Webseiten mit Google Fonts.¹⁴

Woran liegt das? Mir fallen hierzu mehrere Gründe ein:

1. Einige Webseiten benutzen keinen CDN, sodass Google Fonts schneller beim Benutzer ankommen können (zumindest bei internationalem Publikum).
2. Caching ist nicht ausreichend optimiert oder wird ganz vergessen. (Optimierung 1.4)
3. Für die selbst-gehosteten Fonts werden keine Untermengen (Subsets) angeboten, so dass immer die größte Datei benutzt wird. (Optimierung 1.7)
4. Selbst-hostete Fonts werden einmal aufgesetzt und danach nicht weiter optimiert, so dass sie nicht die aktuellsten Formate benutzen. (Optimierung 1.6)

Es bleibt also festzuhalten, dass man beim Selbst-hosten auch andere Optimierungen berücksichtigen muss, um einen Performance Boost als positiven Nebeneffekt mitzunehmen.

Noch erwähnenswert: Die verlinkte Statistik, die zeigt, dass Webseiten mit Google Fonts schneller laden, ist aus dem Dezember 2020. Chrome hatte da gerade die Möglichkeit eliminiert, lokal gespeicherte (Caching) Ressourcen für unterschiedliche Domains wiederzuverwenden.¹⁵ Es wäre spannend zu sehen, wie sich die Statistik seitdem entwickelt hat.

Der font-display¹⁶ Deskriptor lässt uns steuern, was passiert, bis die Web Fonts geladen werden. Wenn die Zeit zum ersten sichtbaren Text die Hauptpriorität ist, dann ist swap die Option unserer Wahl. Lasst uns aber auf die Details schauen:

• Der default Wert block wartet bis zu drei Sekunden (Chrome, Firefox) auf die Ankunft des angegebenen Web Fonts, bevor es überhaupt entsprechenden Text darstellt. Dies resultiert in “Flashes of invisible Text” (FOIT) und sollte besser vermieden werden, da es einerseits den Text verspätet anzeigt und andererseits für Layout Shift sorgen kann.
• swap eliminiert diese Wartezeit und zeigt Text sofort mit dem Fallback Font an, um diesen gegen den Web Font auszutauschen, sobald dieser zur Verfügung steht. Dies resultiert in “Flashes of unstyled Text” (FOUT) und sollte daher mit Vorsicht verwender werden (siehe Optimierung 4.1).
• optional wartet sehr kurz (höchstens 100ms) bis der angegebene Web Font zur Verfügung steht, und benutzt den Fallback Font, wenn die Wartezeit vorbei ist. Auch hier besteht die Gefahr auf FOIT und damit Layout Shift, wenn man nicht entsprechende Vorkehrungen trifft (siehe Optimierung 4.2). Der Browser könnte auch entscheiden einen Font nicht runterzuladen oder dem Runterladen eine niedrige Priorität zu geben, wenn die Wahrscheinlichkeit, dass der Font am Ende benutzt wird zu gering ist.
• fallback ist ähnlich wie optional. Der Browser wartet sehr kurz (bis zu 100ms) auf den angegebenen Font. Bis dahin wird der Fallback benutzt. Wenn der Font innerhalb von ~3 Sekunden zur Verfügung steht, werden die Fonts getauscht. Leider kann das in FOIT und FOUT resultieren.

Wir wollen unseren Content so schnell wie möglich zur Verfügung stellen, daher liegt die Versuchung nahe alle Web Fonts mit einem link[rel=preload] zu versehen und Verbindungen zu externen Domains so schnell wie möglich via link[rel=preconnect] zu initiieren. Aber Vorsicht! Externe Domains, die nicht zum eigenen Netzwerk gehören, sollten erst nach Einwilligung angesteuert werden (see Optimierung 2.1), wodurch das preconnect in vielen Fällen schon disqualifiziert ist. Preload dagegen ergibt eine Menge Sinn für selbst-gehostete Fonts, sogar wenn diese optional sind (see Optimierung 4.2). Allerdings sollten wir dies nur für die wesentlichen Web Fonts tun. Zu aggressives preloading verzögert das Laden und Darstellen anderer wichtiger Ressourcen. Wir sollten weitere Preloads lieber für LCP (Hintergrund-)Bilder oder Ähnliches reservieren.

Sollten @font-face Deklarationen für selbst-gehostete Web Fonts in einer externen CSS-Datei stehen, so ist es besonders effektiv diese Web Fonts mit einem Preload zu versehen. Schwieriger wird’s bei Web Fonts von Drittanbietern, die @font-face Regeln in einer eigenen externen CSS-Datei angeben. Hier können wir nicht sicher sein, ob und wann eine Font URL sich ändert.

Ein anderer Aspekt, den wir beim Preload bedenken müssen, ist, dass wir keine Untermenge angeben können (see Optimierung 1.7).¹⁷ Wir müssen also bestimmen, welche Untermengen wir auf unserer Seite brauchen und können das Management nicht dem Browser überlassen.

Offensichtlich wollen wir für unsere Fallback Fonts solche auswählen, die unseren Web Fonts ähneln. Aber wenn wir nicht gegensteuern, liegen zwischen den Fonts so große Unterschiede, dass es zu Layout Shift kommen kann, etwa wenn ein Text unterschiedlich viele Zeilen einnimmt. Um dieses Risiko zu vermeiden, können wir die folgenden Deskriptoren auf unsere Fallback Fonts anwenden.¹⁸

• Der wichtigste Deskriptor ist size-adjust hiermit lässt sich die Größe eines Fonts justieren ohne die font-size zu verändern. Dies ist nützlich, wenn Web Font und Fallback Font unterschiedlich groß sind.
• Mit ascent-override, descent-override und line-gap-override lassen die Fonts vertikal verschieben.

Die Seite screenspan.net lässt uns die besten Werte für die Deskriptoren je nach Szenario bestimmen.

Natürlich bedeutet dieser Ansatz zusätzliche Arbeit, besonders wenn wir jeden Fallback Font anpassen wollen. Aber die Arbeit lohnt sich, da wir so einen angehmeren Render-Prozess erleben.

Wenn Web Fonts nur eine leichte Verbesserung darstellen, die Webseite aber auch gut ohne sie funktioniert, dann sind optionale Fonts eine klasse Alternative. Hier werden die Web Fonts nur auf der Webseite verwendet, wenn sie schnell genug zur Verfügung stehen (max 100ms nachdem sie gerendert werden sollen, siehe Optimierung 3.1). Andernfalls wird der Fallback Font verwendet.

Insbesondere bei selbst-gehosteten Fonts ist dieser Ansatz sinnvoll, weil wir in Kombination mit einem Preload der Fonts sicherstellen können, dass kein Layout Shift durch FOIT entsteht. ¹⁹

Bei wiederholten Webseiten Aufrufen, wird dann übrigens immer der optionale Web Font benutzt, wenn die BesucherInnen ihren Cache nicht deaktiviert haben und wir unsere Hausaufgaben für selbst-gehostete Fonts gemacht haben (Optimierung 1.4).

In einem Test, den wir bei meinem vorigen Arbeitgeber durchgeführt hatten, sind wir auf folgende interessante Zahlen gekommen. Ein Web Font, den wir selbst-gehostet und mit preload versehen hatten, kam in 80% aller Seitenaufrufe zum Einsatz. 30% aller BesucherInnen bekamen den Fallback Font mindestens einmal zu sehen. Der Test wurde auf einer Webseite durchgeführt, die im Testzeitraum etwa 10.000 überwiegend italienische BesucherInnen hatte und dessen Server in Italien (ohne CDN) stand. Die Zahlen können natürlich je nach Projekt abweichen, für uns war dieses Ergebnis aber gut genug um bei diesem Projekt komplett von Optimierung von 4.1 auf 4.2 umzustellen. (Später hatten wir bei auf dem Projekt bei gleichbleibenden User-Signalen übrigens ganz auf Web Fonts verzichtet, was auch zeigt, dass die Web Fonts in diesem Fall keine wichtige Komponente darstellten, siehe Optimierung 1.1).

Der Nachteil der optionalen Fonts ist, dass alle Stakeholder mit dem Trade-off leben können müssen. Gefällt es DesignerInnen, dass ihr favorisierter Font nur in 80% der Fälle zu sehen ist? Verstehen alle Mitarbeitende ohne großes technisches Verständnis, warum die Webseite nach einem Refresh anders aussieht als beim ersten Laden?