Drei Techniken für performanten Einsatz von benutzerdefinierten Schriftarten

Es gibt viele gute Nachrichten in der Welt der Webfonts!

1. Die kommende Version von Microsoft Edge wird endlich implementieren unicode-range, als letzter moderner Browser.
2. Preload und font-display landen in Safari und Firefox.
3. Variable Fonts sind überall verfügbar.

Die performante Nutzung von benutzerdefinierten Schriftarten wird immer einfacher. Schauen wir uns einige Dinge an, die wir bei der Verwendung benutzerdefinierter Schriftarten tun können, um sicherzustellen, dass wir so performant wie möglich sind.

1) Dateigröße reduzieren

Viele Schriftarten enthalten nicht nur Zahlen, das lateinische Alphabet und gebräuchliche Satzzeichen, sondern unterstützen auch mehrere Sprachen und umfassen *Tausende* zusätzlicher Glyphen, was die Dateigröße erheblich erhöht.

In diesen Fällen ist **Subsetting** (Teilmengenbildung) nützlich. Subsetting ist das Entfernen von Zeichen, die Sie nicht benötigen. Dies können Sie mit dem Kommandozeilen-Tool pyftsubset tun, das als Teil von FontTools heruntergeladen werden kann. (Die Website FontSquirrel bietet eine grafische Benutzeroberfläche für Subsetting. Sie ist eine beliebte Alternative, die ebenfalls erwähnenswert ist – aber seien Sie sich bewusst, dass sie nicht mit variablen Schriftarten kompatibel ist). Die einfachste Methode, die gewünschten Zeichen anzugeben, ist die Verwendung von Unicode. Unicode ist ein Standard, der jedem Zeichen aus den Sprachen der Welt einen eindeutigen Code zuweist.

Dem pyftsubset-Befehl folgt der Name Ihrer Schriftartdatei und die Unicode-Angabe Ihres gewählten Unicode-Bereichs. Das Folgende ist eine Teilmenge, die für die englische Sprache gedacht ist.

pyftsubset SourceSansPro.ttf --unicodes="U+0020-007F"

Sie können die Größe der Schriftart weiter reduzieren, indem Sie sie in das woff2-Dateiformat komprimieren. Dies können Sie mit einem separaten Kommandozeilen-Tool von Google tun oder einfach einige zusätzliche Optionen beim Ausführen des pyftsubset-Befehls hinzufügen.

pyftsubset SourceSansPro.ttf --unicodes="U+0020-007F" --flavor="woff2" --output-file="SourceSansPro.woff2"

Wenn Sie sicher sind, dass Sie keine der aus der Schriftart entfernten Zeichen verwenden werden, ist dies alles, was Sie tun müssen – Sie haben die Größe der Schriftart drastisch reduziert und können sie nun wie gewohnt in @font-face verwenden. Aber was ist, wenn einige Seiten Ihrer Website zusätzliche Glyphen verwenden, die aus der Schriftart entfernt wurden? Sie möchten vermeiden, dass Zeichen mit einer Fallback-Schriftart angezeigt werden. Um dieses potenzielle Problem zu lösen, notieren Sie sich den Bereich, den Sie beim Erstellen Ihrer Teilmenge mit pyftsubset verwenden. Sie möchten ihn innerhalb des @font-face-Blocks angeben.

@font-face {
  font-family: 'Source Sans Pro';
  src: url('/fonts/SourceSansPro.woff2') format('woff2');
  unicode-range: U+0020-007F; /* The bare minimum for the English Language */
}

Der obige unicode-range gibt Zeichen an, die wahrscheinlich auf allen Seiten der Website verwendet werden. Diese Schriftart wird daher auf jeder Seite heruntergeladen.

Ich werde auch eine weitere Datei mit pyftsubset erstellen. Diese wird keine Zeichen aus der ersten Datei wiederholen. Vielmehr wird sie *nur* Glyphen enthalten, die auf der Website selten verwendet werden.

pyftsubset SourceSansPro.ttf --unicodes="U+00A0-00FF,U+0100-017F" --output-file="SourceSansProExtra.ttf"

Durch erneute Angabe eines unicode-range innerhalb einer weiteren @font-face-Deklaration stellen wir sicher, dass die Datei nur dann heruntergeladen wird, wenn sie benötigt wird – wenn ein Zeichen auf der Seite mit dem angegebenen Bereich übereinstimmt.

@font-face {
  font-family: 'Source Sans Pro';
  src: url('/fonts/SourceSansProExtra.woff2') format('woff2');
  unicode-range: U+00A0-00FF, U+0100-017F; /* additional glyphs */
}

Sie sollten den Bereich an Ihre eigenen Bedürfnisse anpassen. Wenn Sie ungewöhnliche Satzzeichen oder Buchstaben in Ihrer Kopf- oder Fußzeile haben, stellen Sie sicher, dass Sie diese in Ihre Hauptschriftartdatei aufnehmen, sonst werden beide Dateien *immer* heruntergeladen. Auf der Website, auf der ich arbeite, habe ich zum Beispiel das ©-Symbol (U+00A) in die Hauptteilmenge aufgenommen, da es am Ende jeder Seite enthalten ist. Eine hilfreiche Liste der Unicode-Zeichen finden Sie auf Wikipedia.

2) Wichtige Schriftartdateien so früh wie möglich laden

Wow.https://#/6CfAK6mjYs CSS hat 100 verschiedene @​font-face-Blöcke.

Das sind, nun ja… das ist viel. pic.twitter.com/jj2NFS4vd5

— Zach “Fancy Letters” Leatherman (@zachleat) 25. Juni 2016

Stellen Sie sich vor, das einzige CSS in Ihrem Stylesheet wären hundert @font-face-Deklarationen und die folgenden Codezeilen

* {
  font-family: 'Lora';
  font-style: italic;
  font-weight: bold;
}

Wie viele Schriftarten würde der Browser herunterladen? Hundert? Die Antwort ist:
nur eine. Schriftarten werden standardmäßig per Lazy Loading geladen. Das ist ein kluger Schachzug von Browserherstellern – nur herunterladen, was *tatsächlich benötigt* wird. Es gibt jedoch einen Nachteil. Um zu wissen, welche Schriftartvarianten verwendet werden, muss der Browser *den gesamten HTML-Code* und *das gesamte CSS* parsen. Erst danach werden Schriftartdateien angefordert. Wenn wir schneller starten wollen, müssen wir **Preloading** (Vorabladen) nutzen.

Preloading ist so einfach wie das Hinzufügen eines Link-Tags in den Head des Dokuments

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

Es ist keine gute Idee, zu viele Ressourcen vorab zu laden oder Ressourcen vorab zu laden, die möglicherweise nicht auf der Seite verwendet werden. Aus diesem Grund lade ich nur die Datei mit normaler Dickte und ohne Kursivschrift vorab. Ich mache mir weniger Sorgen um eine spät ladende fette oder kursive Datei, da diese Stile seltener auf der Website verwendet werden. Ein *Flash of Unstyled Text* (FOUT) für diese Schriftartdateien ist weniger störend als ein FOUT für die normale römische Schriftart, die den Großteil des Textes ausmacht. Wenn Sie eine variable Schriftart verwenden, ist dies kein Problem. Das Vorabladen von variablen Schriftarten stellt jedoch derzeit ein eigenes Problem dar.

Sollten Sie eine variable Schriftart vorab laden?

Es ist offensichtlich Verschwendung, dem Browser eine Ressource zu senden, die er nicht verwenden kann. Deshalb fügen wir ein type-Attribut hinzu, das den MIME-Typ der Ressource angibt. Wenn die Ressource vom Browser nicht unterstützt wird, wird sie nicht heruntergeladen. Im Fall von Schriftarten geben wir type="font/woff2" an. Edge, Safari und Firefox implementieren sowohl variable Schriftarten als auch Preload gleichzeitig, sodass es für diese Browser kein Problem gibt. Chrome und Opera unterstützen Preload jedoch seit 2016. Variable Schriftarten sind eine brandneue Ergänzung, während woff2 seit 2014 unterstützt wird. Aus diesem Grund zwingt das Vorabladen einer variablen woff2 ältere Versionen von Chrome und Opera zum Herunterladen einer Ressource, mit der sie nichts anfangen können.

Idealerweise könnten wir die Ressource als variable Schriftart im type-Attribut angeben, aber das ist weitgehend unnötig. Chrome ist *immer aktuell*. Es gibt alle sechs Wochen eine neue Version und sie aktualisiert sich automatisch im Hintergrund. Relativ wenige Besucher werden eine uralte Version verwenden. Sobald variable Schriftarten in Chrome seit mehreren Versionen verfügbar sind, ist das Vorabladen sicher.

3) FOUT und FOIT verwalten

Bisher haben wir uns mit der Beschleunigung des Schriftartladens befasst. Eine gute Benutzererfahrung hängt nicht nur von der Ladezeit einer Seite oder einer Schriftart ab – es geht darum, wie Benutzer die Website *während des Ladens* erleben. Wenn Sie möchten, dass Benutzer bleiben, müssen Sie über die *wahrgenommene* Leistung nachdenken. Die verschiedenen Browser sind nicht konsistent darin, wie sie das Laden von Schriftarten verwalten. Wir können die Ladestrategie jetzt selbst mithilfe der CSS-Eigenschaft font-display entscheiden.

Die Eigenschaft font-display wird innerhalb eines @font-face-Blocks definiert.

@font-face {
  font-family: ExampleFont;
  src: url(/fonts/SourceSansPro.woff2) format('woff2');
  font-display: fallback;
}

Die verfügbaren Optionen sind block, optional, swap und fallback. Welche sollten Sie wählen?

Der Wert optional *klingt* nach einer guten Wahl – Schriftarten sind eine nette Ergänzung, aber keine zwingende Notwendigkeit. In der Praxis habe ich festgestellt, dass es eine schlechte Wahl ist. Das Ändern der Schriftart einer Seite bei Navigation oder Neuladen ist für Benutzer unerwartet und etwas beunruhigend. Das Zeitfenster für das Laden der benutzerdefinierten Schriftart ist *unglaublich klein*. Wenn Sie die Schriftart vorab laden, wird sie wahrscheinlich innerhalb dieses engen Zeitrahmens geladen. Wenn nicht, werden Benutzer oft die Fallback-Schriftart des Webbrowsers erleben – *selbst bei einer guten Verbindung mit einem teuren Computer*. Das ist nicht gut für die Markenkonsistenz. Wenn Sie viel Zeit in die Suche nach einer ähnlichen Fallback-Schriftart investiert haben, könnte dies eine akzeptable Option sein, aber wenn sie *so ähnlich* ist und die Leistung oberste Priorität hat, sollten Sie vielleicht überdenken, warum Sie überhaupt eine benutzerdefinierte Schriftart verwenden.

Der Wert swap ist eine bessere Option. Die web-sichere Fallback-Schriftart wird sofort angezeigt und durch die benutzerdefinierte Schriftart ersetzt, sobald diese geladen ist. Leider ist die Tauschperiode unendlich, sodass bei einer langsamen Verbindung die Schriftart geändert werden könnte, nachdem der Benutzer bereits in den Text vertieft ist, was eine ruckelige und beunruhigende Erfahrung schafft.

Der Wert fallback ist ähnlich dem Standardverhalten der meisten Browser – eine kurze Blockierungszeit unsichtbaren Textes, gefolgt von einer Fallback-Schriftart, falls die benutzerdefinierte Schriftart immer noch nicht geladen wurde. Im Gegensatz zu swap gibt es eine Zeitüberschreitung. Wenn die benutzerdefinierte Schriftart nicht innerhalb von drei Sekunden geladen wird, ändert sich die Schriftart nicht – der Benutzer bleibt bei der Fallback-Schriftart. Sie können einen ganzen Artikel auf CSS-Tricks über font-display lesen und entscheiden, welche Option für Sie am besten geeignet ist.

Zusammenfassend

Text macht den Großteil des Inhalts auf den meisten Websites aus. Das Laden von Schriftarten ist daher ein wichtiger Teil des Leistungspuzzles. Wenn Sie über die Entwicklungen beim Laden von Schriftarten auf dem Laufenden bleiben möchten, hat Zach Leatherman gerade einen Newsletter zu diesem Thema gestartet.