Heutzutage ist es sehr einfach, eigene Schriften in ein eigenes Theme einzubinden. Doch gibt es ein paar Dinge, die man beachten sollte, um das Ganze auch performant zu halten. Insbesondere auf Mobilgeräten, die mittlerweile oft mehr als 50 % der Aufrufe einer Website durchführen, ist jede gewonnene Zehntelsekunde ein Mehrwert. Daher werde ich nachfolgend ein paar Performance-Vorschläge machen, die jeder schnell umsetzen kann, der sich ein wenig mit Theme-Anpassungen auskennt.

Lokal einbinden

Wie ich in meinem Beitrag Warum ein Theme keine Google Fonts verwenden sollte bereits beschrieben habe, ist die Nutzung externer Schriften generell schlecht für die Performance. Dies gilt außerdem nicht nur für Google Fonts – für diese vermutlich sogar nicht mit am wenigsten, da Google sehr schnelle Server besitzt – sondern für alle externen Schriften. Eine gute Alternative dazu ist die Einbindung über den eigenen Webserver, also auf dem jeweiligen System, auf dem auch das WordPress läuft. Das würde bedeuten, dass die Schrift beispielsweise unter /wp-content/themes/my-theme/assets/fonts/my-font.woff2 zu finden ist und sie manuell über CSS einbindet, beispielsweise so:

@font-face {
	font-family: 'My Font';
	src: local('My Font'), local(MyFont), url(/wp-content/themes/my-theme/assets/fonts/my-font.woff2) format('woff2');
}Code-Sprache: CSS (css)

font-display: swap;

Über font-display hat man die Möglichkeit, selbst per CSS zu bestimmen, wie sich die Schrift im Browser verhält, solange die über @font-face eingebundene Schrift noch nicht geladen ist. Insbesondere über Mobilgeräte hat man normalerweise eine längere Wartezeit, bis die eigentliche Schrift geladen wurde. Bis zu diesem Zeitpunkt wird vom Browser die Schrift noch gar nicht gerendert, sodass man nur das Layout ohne Text angezeigt bekommt. Mit font-display: swap; rendert der Browser den Text in dieser Zeit mit der eingestellten Fallback-Schrift und wechselt diese dann zu der eigentlichen eingebundenen Schrift, sobald diese verfügbar ist. Der Vorteil liegt hier klar auf der Hand: Selbst wenn das Laden der Schrift lange dauert oder sogar ganz fehlschlägt, kann man dennoch immer sämtliche Texte auf der Website lesen. Außerdem ist es nur eine CSS-Zeile, welche noch dazu von allen modernen Browsern unterstützt wird (wenn Edge ist kein moderner Browser ist, was ich für diese Aussage voraussetze).

Eigenes <style>-Tag

Für eine schöne Darstellung im Browser ist es sehr wichtig, dass die eingesetzte Schriftart schnellstmöglich geladen wird. Daher kann es sinnvoll sein, den im ersten Tipp genannten CSS-Code in ein eigenes <style>-Tag auszulagern, um es unabhängig von der style.css des Themes zu laden. Dabei wäre es natürlich noch am besten, wenn dieses <style>-Tag dann auch noch vor jedem anderen CSS-Code steht, sodass die Schriftart immer als erstes geladen wird. Das geht dabei recht einfach, da man einfach eine Priorisierung angeben kann, wann ein eigener Code über einen Hook eingebunden wird. In diesem Fall sieht das dann so aus:

/**
 * Include My Font with high priority.
 */
function include_my_font() {
	?>
<style>
	@font-face {
		font-family: 'My Font';
		src: local('My Font'), local(MyFont), url(/wp-content/themes/my-theme/assets/fonts/my-font.woff2) format('woff2');
	}
</style>
<?php
}

add_action( 'wp_head', 'include_my_font', 1 );
Code-Sprache: PHP (php)

Dieser Code muss dann nur noch in die functions.php deines Themes geladen werden.

Optimierte Dateitypen verwenden

Es gibt einige verschiedene Dateitypen für Webfonts. Nachfolgend alle, die mir bekannt sind:

  • TTF – TrueType Font
  • OTF – OpenType Font
  • EOT – Embedded OpenType
  • SVG – Scalable Vector Graphics
  • WOFF/WOFF2 – Web Open Font Format

TrueType und OpenType wurden von Apple und Microsoft entwickelt und bieten eine Vielzahl an Möglichkeiten. Sie kommen schon sehr lange in allen möglichen Betriebssystemen zum Einsatz und sind dort der Quasi-Standard für Schriftformate. Das Problem ist jedoch, durch ihre großen Möglichkeiten und den eigentlichen Einsatzzweck, immer lokal eingesetzt zu werden, sind sie nicht komprimiert und haben daher eine sehr große Dateigröße.

Embedded OpenType wurde von Microsoft speziell für die Nutzung im Web konzipiert und entwickelt. Dabei werden TrueType-/OpenType-Schriften durch ein Werkzeug komprimiert und verschlüsselt, um sie gegen Missbrauch zu schützen. Allerdings funktionieren diese Schriften nur im Internet Explorer.

Da jede normale Schrift über Pfade definiert wird und damit frei skaliert werden kann, ist der Einsatz als SVG naheliegend. Allerdings gibt es hierbei keine Möglichkeiten, ein und demselben Zeichen mehrere Eigenschaften mitzugeben. Es wird immer genau so angezeigt, wie in der SVG-Datei vorgesehen. Bis iOS 4.1 war es die einzige Möglichkeit, auf iOS-Geräten eine individuelle Schriftart zu nutzen. Mittlerweile können aber auch diese Geräte normale Webfonts nutzen.

Das Web Open Font Format (WOFF) wurde 2009 entwickelt und ist die offizielle Empfehlung vom W3 Konsortium. Mittlerweile gibt es bereits das Format WOFF2, welches eine Weiterentwicklung ist und im Vergleich zu allen anderen Formaten eine sehr geringe Dateigröße aufweist. Während WOFF sogar noch vom Internet Explorer 9 und ab Android 4.4 unterstützt wird, funktioniert WOFF2 erst mit Microsoft Edge. Allerdings ist meiner Meinung nach die Kombination von WOFF und WOFF2 heutzutage absolut ausreichend, um die meisten Geräte abzudecken.

System Font Stack

Das System Font Stack ist eine Möglichkeit, eine schöne Schrift auf allen möglichen Geräten zu verwenden. Dabei wird dem System ermöglicht, eine auf diesem immer vorinstallierte Schriftart zu nutzen, ohne erst eine herunterladen zu müssen. Auch WordPress nutzt ein solches System Font Stack im Backend. Das sieht dann so aus:

body {
	font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen-Sans, Ubuntu, Cantarell, "Helvetica Neue", sans-serif;
}Code-Sprache: CSS (css)

Je nach Betriebssystem wird dann eine andere Schriftart gewählt, die auf diesem standardmäßig verwendet wird.

Fazit

Es braucht nicht viel, um Webfonts selbst performant einzubinden. Natürlich sollte man sich immer darüber im klaren sein, je mehr Schriftschnitte oder Schriftarten notwendig sind, desto mehr Dateien müssen auch geladen werden. Hier ist weniger mehr. ⚡

2 Kommentare

  1. Den CSS-Code mittels style-Tag im Head-Bereich zu platzieren ist eine gute Idee. Danke für den Hinweis! Für einen Semi-Noob wie mich ist das Einbinden von Webfonts ein schwieriges Thema.

    Die unzähligen DSGVO-Checklisten für WP, die kurz vor dem Wirksamen-Werden der Verordnung ins Netz gestellt wurden, sind dabei keine Hilfe. Sie gehen meist nur oberflächlich ans Thema heran. Performance spielt darin keine Rolle. Das Komplettpaket an Formaten, das z. B. der Google Webfonts Helper anbietet, führte aber in meinem Blog zu einem „flash of invisible text”-Effekt. Deshalb beschränke ich mich auf woff und woff2.

    Eine Frage habe ich noch an die Profis: Wie sinnvoll ist es, mittels Leverage browser caching (bei mir wegen des Apache-Servers in der htaccess-Datei) auf die Speicherdauer Einfluss nehmen zu wollen? Ich habe nach einer Vorlage Folgendes festgelegt:

    ExpiresByType font/woff “access plus 1 month”
    ExpiresByType application/font-woff2 “access plus 1 month”

    Mir fehlen Mittel und Kenntnisse, den Erfolg einer solchen Maßnahme zu messen.

    1. Gerade bei Schriften ist es sehr sinnvoll, das Caching so lang wie möglich zu halten. Diese Dateien ändern sich eigentlich so gut wie nie und wenn, kann man immer noch überlegen, ob man nicht einfach einen anderen Dateinamen nutzt. Je länger der Cache ist, desto seltener muss ein einzelner Benutzer die Dateien auch erneut herunterladen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert