Niklas Postulart

Ein Artikel von:
Niklas Postulart
npostulart@uandi.com

Eigene Schriften gehören im Web heutzutage schon fast zum guten Ton. Um aus dem Einheitsbrei des Webs hervorzustechen, setzen immer mehr Webdesigner und Entwickler auf die Nutzung verschiedener Schriften, um das Gesamtbild abzurunden. Auch wir von u+i nutzen für unsere einheitliche CI in Web und Print auf einen so genannten Web-Font. Wir zeigen Ihnen in diesem Artikel wie Sie Web-Fonts richtig und performant einbinden und erklären, wie die Browser damit umgehen.

Eine kurze Geschichte der Web-Fonts

Die Möglichkeit, eigene Schriften auf Webseiten einzubinden, wurde bereits mit CSS2 in den W3C Recommendations vom 12. Mai 1998 eingeführt. Zuvor war es nur möglich, bereits auf dem Nutzersystem installierte Schriften für seinen Webauftritt zu verwenden oder eigene Schriften als Bilddateien auf einer Webseite einzubinden. Zwischenzeitlich gab es auch Dienste, die im Browser des Nutzers per JavaScript eine Schriftdatei in entsprechende Bilder umwandelten.

Da die damaligen Browser den neuen Standard aber nicht direkt unterstützten, wurde dieser nicht in die darauf folgenden Recommendations für CSS2.1 aufgenommen. Erst mit CSS3 hat die Implementierung der Web-Fonts und deren Nutzung Anklang gefunden. Heutzutage unterstützt mit Ausnahme von Opera Mini jeder moderne Browser diesen Standard (Quelle: caniuse.com).

Verbreitete Nutzung von Web-Fonts

Sieht man sich die Entwicklung der letzten drei Jahre an, stellt man fest, dass heutzutage ein Großteil der Webseiten bereits Webfonts einsetzt, um das Gesamtbild des Auftritts zu unterstreichen. Mussten Fonts vorher noch in verschiedenen Formaten auf dem eigenen Server vorliegen, erleichtern Dienste wie Google-Fonts, Typekit, Fonts.com und Fontdeck die Nutzung erheblich. Durch das Angebot an kostenlosen Fonts und günstigen Abos ist auch die rechtliche Frage nach der Nutzungslizenz (fast) kein Thema mehr. Anfangs war durchaus unklar, welche Nutzungsrechte der Kauf eines Font mit sich bringt. Mittlerweile ist klar, dass kostenpflichtige, kommerzielle Fonts meistens unterschiedliche Rechte für die Nutzung auf dem eigenen Rechner und im Web vorsehen. So lassen sich bspw. Schriften zu einem Festpreis für den Desktop kaufen, für die Nutzung im Web sind diese dann aber nicht freigegeben.

Anstieg der Nutzung von Custom Fonts im Web

Web-Fonts richtig einbinden

Web-Fonts werden meist entweder über die @font-face-Regel direkt im CSS oder über Font-Anbieter, wie bspw. Google-Fonts, eingebunden.

Die Einbindung eines eigenen Fonts in CSS sieht bspw. so aus:

@font-face {
  font-family: MyFont;
  src: url('myfont.woff2') format('woff2'),
       url('myfont.woff') format('woff');
}

Die src-Eigenschaft kann mehrere kommagetrennte Werte entgegennehmen, dabei wird in url die zur CSS-Datei relative oder absolute URL zu der Font-Datei angegeben. format gibt dem Browser mit, um welchen Typ es sich handelt. Anhand dessen kann der Browser entscheiden, welche Schrift er verwendet. Dabei geht dieser die Liste der Schriften nacheinander durch und nimmt die erste Schrifttype, die er unterstützt.

Die Einbindung von Fonts als Stylesheet-Links von Font-Anbietern ist sogar noch einfacher und bietet bei wiederholtem Seitenaufruf oftmals eine gute Performance, leider wird hierdurch aber das Rendering einer Webseite blockiert.

<link href="https://fonts.googleapis.com/css?family=Lato" rel="stylesheet" type="text/css">

Die Einbindung von Fonts über CSS oder externe Dienste ist sehr einfach, bietet aber keine Kontrolle über die Ladeprozedur und Anzeige der Schrift im Browser.

Wie der Browser Schriften lädt

Die Verwendung der @font-face-Regel im CSS alleine veranlasst den Browser noch nicht dazu, eine Schrift aus dem Web herunterzuladen. Erst wenn in einem CSS-Selektor die benannte Schrift verwendet wird und dieser Selektor auf ein Element im Dokumentbaum zutrifft, lädt der Browser die entsprechende Schrift und zeigt diese nach erfolgtem Laden an. Dieser Lazy Loading Ansatz ist prinzipiell gut und verhindert, dass unnötige Dateien heruntergeladen werden. Leider gibt es keine einheitliche Regel dafür, was in der Zeit zwischen dem Parsen und Rendern des CSS und der Anzeige der vollständig geladenen Schrift passieren soll. Je nach Browser gibt es hier zwei verschiedene Ansätze zur Darstellung.

FOUT

FOUT steht für Flash of unstyled text und beschreibt die Methode, den vorhandenen Text zunächst in einer der auf dem Nutzersystem verfügbaren Fallback-Schriftarten anzuzeigen und nach dem Laden der eigentlich gewünschten Schriftart den Text in dieser neu zu rendern. Abhängig von den gewählten Schriften und deren definierten Fallbacks kann dieser Effekt negativ aufgefasst werden, da sich je nach Schrifthöhe und -schnitt die Aufteilung und allgemeine Darstellung der Seite verändern kann. Zurzeit nutzt lediglich der Internet Explorer diese Art des Renderings.

Um eine zu große Veränderung der Darstellung der Seite aufgrund der unterschiedlichen Schnitte der verwendeten Schriften zu minimieren, sollte man eine möglichst gut passende Fallback-Schrift aussuchen. Bei häufig genutzten Schriften findet man meist über eine schnelle Suche gute Ausweichmöglichkeiten. Da Schriften in den seltensten Fällen die gleiche x-Höhe und Laufweite haben, gibt es zwei einfache Methoden, die Fallback-Schrift und die eigentliche Schrift anzugleichen.

FOUT Effekt als Animation
  1. Über die CSS-Eigenschaft letter-spacing   lässt sich die Laufweite einer Schrift anpassen. Mit dieser muss man etwas herumspielen, bis die Laufweite der Fallback-Schrift mit der der eigentlichen Schrift übereinstimmt.
  2. Mit font-size-adjust existiert eine weitere Eigenschaft, über die sich die x-Höhe einer Schrift anpassen lässt. Leider unterstützt momentan nur Firefox diese Eigenschaft von Haus aus.

Mit FFFFALLBACK gibt es ein einfaches Tool zur Überprüfung von Fallback-Fonts, mit dessen Hilfe zwei Schriften übereinandergelegt verglichen werden.

FOIT

Beim FOIT (Flash of invisible text) wird der Text, anders als bei FOUT, während des Ladevorgangs versteckt und je nach Browser erst nach dem vollständigen Laden der Schrift oder dem Ablauf eines definierten Zeitraums angezeigt. Ist die gewünschte Schrift nach Ablauf des Zeitraums noch nicht verfügbar, wird hierbei die Fallback-Schriftart genutzt. Diese Vorgehensweise ist optisch schöner, kann aber ganz besonders bei langsamen Internetverbindungen eine schlechte UX mit sich bringen. Auch wenn die Seite bereits vollständig geladen und angezeigt werden kann, ist diese nicht nutzbar, da keinerlei Textinformationen angezeigt werden. Chrome, Firefox und Opera zeigen bereits nach drei Sekunden die definierten Fallback-Schriftarten an, in dieser Zeit wird das Rendering der Webseite blockiert. Safari (OSX und iOS) und Android Webkit haben dagegen eine weitaus größere Zeitspanne zum Laden der Web-Fonts vorgesehen, sodass hier erst nach 30 Sekunden oder (noch schlimmer) überhaupt keine Schrift angezeigt wird, wenn der Font nicht verfügbar ist.

FOIT Effekt als Animation

Welcher Browser welche Technik einsetzt, kann in der folgenden Tabelle nachgesehen werden:

Font Rendering / Timeout
Internet Explorer: FOUT / n/a
Chrome: FOIT / 3 sec.
Firefox: FOIT / 3 sec.
Safari: FOIT / ∞
Opera: FOIT / 3 sec.

FOUT vs FOIT

Im Internet finden sich viele Meinungen, die entweder FOUT oder FOIT bevorzugen. Interessant ist zu sehen, dass die meisten Browser-Hersteller früher FOUT eingesetzt haben, aufgrund von eigener Empfindung oder Nutzerberichten aber auf FOIT gewechselt sind.

Aus der ästhetischen Sicht empfinden die meisten Nutzer FOIT als die bessere Wahl. Lädt eine Webseite aber mit deutlich langsamerer Geschwindigkeit (GPRS, EDGE), wandelt sich die Meinung oftmals. Insbesondere auf Mobilgeräten mit einer langsamen Datenverbindung muss der Nutzer eine längere Zeit auf die Darstellung des für ihn relevanten Inhalts warten. Auch wenn andere Ressourcen noch nachgeladen werden, sollte der Text als wichtigster Informationsträger direkt sichtbar sein.

Das Ziel sollte sein, FOUT einzusetzen und den Request und die Ladezeit einer Schrift zu optimieren. Wie das funktioniert, zeigen die folgenden Abschnitte.

Mehr Kontrolle über die Ladeprozedur

Glücklicherweise gibt es seit einiger Zeit JavaScript Libraries, welche eine bessere Kontrolle über die Ladeprozedur, Anzeige und Verfügbarkeit eines Web-Fonts ermöglichen. Die beiden prominentesten Beispiele hierfür sind der von Google und Typekit entwickelte Web Font Loader und der Font Face Observer von Bram Stein.

Web Font Loader

Der Web Font Loader ermöglicht ein asynchrones Laden einer Web-Font über JavaScript und unterstützt Google-Fonts, Typekit, Fonts.com und Fontdeck. Die Library bietet Events und CSS-Klassen, um auf den Ladestatus eines Fonts zu reagieren. Dadurch kann man bspw. direkt im CSS über die entsprechenden Selektoren einen Austausch der Schrift vornehmen.

Die Library hängt standardmäßig zusätzliche Klassen an das html-Element, welche wiederum im CSS einfach angesprochen werden können. Je nach Status werden bspw. die Klassen .wf-loading, .wf-inactive oder .wf-active angehängt.

.wf-loadingEs wird versucht, die Schrift zu laden
.wf-activeSchrift ist vollständig geladen
.wf-inactiveDie Schrift konnte nicht geladen werden

Beispiel für die Nutzung von Google Fonts:

<script type="text/javascript">
  WebFontConfig = {
    google: {
      families: [ 'Lato::latin' ]
    }
  };
  (function() {
    var wf = document.createElement('script');
    wf.src = ('https:' == document.location.protocol ? 'https' : 'http') +
             '://ajax.googleapis.com/ajax/libs/webfont/1/webfont.js';
    wf.type = 'text/javascript';
    wf.async = 'true';
    var s = document.getElementsByTagName('script')[0];
    s.parentNode.insertBefore(wf, s);
  })();
</script>

Eine entsprechende, einfache Anwendung im CSS zeigt dieses Beispiel:

body {
  font-family: Arial, sans-serif;
}

.wf-active body {
  font-family: 'Lato';
}

Das asynchrone Laden der Library ist performant und blockiert das Rendering einer Webseite nicht, führt aber in diesem Fall zu einem durchaus merkbaren FOUT, insbesondere wenn die Seite bereits gerendert wurde, bevor das JavaScript geladen ist. Selbst bei langsamen Internetverbindungen wird somit die Seite mit einer Standardschrift angezeigt und ist vom Nutzer direkt bedienbar. Will man den FOUT verhindern, kann man an dieser Stelle auch eine Ladeanimation in die Seite integrieren und die Inhalte erst nach erfolgtem Laden anzeigen. Ist die gewünschte Schrift nicht verfügbar oder konnte nicht geladen werden, wird die Klasse .wf-inactive angehängt und kann ebenfalls über CSS angesprochen werden.

Zusätzlich zu den allgemeinen Klassen wird auch für jede Schrift und Schriftstärke eine Klasse mit den Status loading, active oder inactive an das html-Element gehängt. Dadurch ist eine noch detailliertere Kontrolle über die geladenen und angezeigten Schriften möglich. Für die verwendete Schrift Lato sieht dies bspw. so aus:

.wf-lato-n4-loading
.wf-lato-n4-active
.wf-lato-n4-inactive

Der Wert n4 bezieht sich auf den Schriftschnitt und die Schriftdicke des zu verwendeten Fonts. Der Web Font Loader benutzt hier eine eigene Variantenbeschreibung (Font Variation Description), die sich aus den Werten von font-style und font-weight zusammensetzt. n4 steht hier also für font-style: normal und font-weight: 400, die weiteren Definitionen können auf der entsprechenden GitHub Seite zu Font Variation Description nachgesehen werden.

Für die weitere Steuerung des Verhaltens bietet der Web Font Loader auch Einstellungen für die Verwendung der automatischen Klassensetzung und der Ausführung der Callback-Events. Wird der Parameter classes auf false gesetzt, werden die erwähnten Klassen nicht automatisch an das html-Element gehängt. Mit events: false lässt sich die Ausführung der Callback-Events deaktivieren. Sehr interessant ist auch die Angabe eines Timeouts, mit dem sich einstellen lässt, wie lange der Web Font Loader versuchen soll, die Schrift zu laden. Als Standard sind hierfür 3 Sekunden angegeben. Nach Ablauf des Timeouts wird der Ladeversuch abgebrochen.

Will man selbst auf das Laden eines Fonts reagieren, kann man die generellen Callback-Funktionen loading, active und inactive nutzen oder mit den Funktionen fontloading, fontactive und fontinactive auf einzelne Fonts reagieren.

Neben der Verwendung der genannten Dienste ist es auch möglich, einen Custom-Font über eigenes CSS zu laden.

Alternativ kann man das Script synchron laden, dies hat allerdings wieder Auswirkungen auf die Performance, da die Seite erst angezeigt wird, wenn das Laden der JavaScript Library abgeschlossen wurde. Daher ist die Verwendung der asynchronen Methode vorzuziehen.

<script src="https://ajax.googleapis.com/ajax/libs/webfont/1.5.18/webfont.js"></script><script>
  WebFont.load({
    google: {
      families: ['Lato::latin']
    }
  });
</script>

Font Face Observer

Im Unterschied zum Web Font Loader bietet der Font Face Observer nur eine Überprüfung auf das Vorhandensein eines Fonts, indem dieser geladen wird. Mit gerade einmal 5,2 KB (1,9 KB gzipped) ist die Library aber im Gegensatz zum Web Font Loader mit 12,3 KB deutlich schmaler gehalten.

Um die Library zu nutzen, wird das Script in der Seite inkludiert und die @font-face Deklaration wie gehabt im CSS hinterlegt. Die Verfügbarkeit des Fonts wird dann über eigenes JavaScript abgefragt.

Das hier gezeigte Beispiel bildet die einfachste Grundfunktion des Web Font Loaders nach, indem Klassen an das html-Element gehängt werden, nachdem die Überprüfung des Fonts abgeschlossen ist.

<script>
var fontObserver = new FontFaceObserver("MyFont");

fontObserver.check().then(function() {
  // Font wurde geladen    
  document.documentElement.classList.add("fonts-loaded");
}, function() {
  // Font wurde nicht geladen
  document.documentElement.classList.add("fonts-unavailable");
});
</script>

Hier kann, wie beim Web Font Loader, im CSS auf die Veränderung reagiert werden. Mithilfe von Promises können auch mehrere Schriften gleichzeitig abgefragt und gemeinsam aufgelöst werden.

Auf die hinzugefügten Klassen kann auch hier wieder über CSS reagiert werden.

body {
  font-family: Arial, sans-serif;
}

.fonts-loaded body {
  font-family: 'My Font';
}

Native Lösung

Eine native Alternative zu den erwähnten JavaScript Libraries ist in Form des CSS Font Loading in aktuellen Versionen von Chrome, Firefox und Opera bereits verfügbar und stellt eine ähnliche Schnittstelle zum Laden von Fonts bereit.

Caniuse.com Feature CSS Font Loading

Aufgrund der aktuell fehlenden Unterstützung von Internet Explorer, Edge und Safari ist der produktive Einsatz noch nicht zu empfehlen.

Ebenso liegt ein Entwurf für eine neue CSS-Eigenschaft innerhalb der @font-face-Regel vor, welche die Steuerung der Darstellung von Schriften beim Laden einer Webseite ermöglicht. Die font-display Eigenschaft wird aber leider zu diesem Zeitpunkt noch von keinem Browser unterstützt.

Performance verbessern

Wir wissen nun, wie Web-Fonts eingebunden werden können. Um den Nutzern die Schriften aber auch möglichst schnell auszuliefern, gibt es einige Methoden, um einen Font möglichst schlank zu halten und dessen Ladezeit zu optimieren.

Weniger ist mehr

Generell gilt immer, je mehr Daten zur Darstellung geladen werden müssen, umso langsamer erscheint eine Webseite. Es lässt sich beobachten, dass nicht nur die Anzahl der Seiten mit eingebundenen Schriften, sondern auch die Menge der Schriften je Seite ansteigt.

Durschnittliche Anzahl geladener Fonts pro Webseite

Mit der Menge der Schriften nimmt entsprechend auch die Gesamtgröße der geladenen Fonts stetig zu.

Durschnittliche Dateigröße der Schriften pro Webseite

Web-Fonts sollten nicht übermäßig eingesetzt werden. Schon in der Design-Phase gilt es zu überlegen, welche Schriften und Schnitte wirklich benötigt werden. Häufig nutzt man dabei eine Grundschriftart mit zwei Schnitten (normal und fett oder kursiv) für Fließtexte und eine Sonderschrift für Überschriften. Verwendet man für jeglichen Text nur eine Schriftart mit zwei Schnitten, spart man an dieser Stelle bereits wertvollen Traffic. Noch besser sieht es aus, wenn man lediglich eine gesonderte Schrift für Headlines als Eye-Catcher verwendet.

Google bietet bei der Auswahl von Schriften eine nette Ansicht über die Belastung der Webseite.

Google Fonts Anzeige zum Page Load einer Schrift

WOFF

WOFF steht für Web Open Font Format, wird in allen modernen Browsern unterstützt, und ist seit dem 13.12.2012 ein Internetstandard des W3C. Mussten früher Schriften noch in 4 - 5 verschiedenen Formaten vorliegen, reicht heute dieses eine Format aus. Die Abdeckung der Unterstützung für WOFF liegt in Deutschland bei ca. 95 % und ist damit weitestgehend verbreitet (Quelle: caniuse.com). Durch die hohe Komprimierung der WOFF Schriften eignen sie sich besonders gut für Webseiten. Ob der alleinige Einsatz von WOFF für die eigene Webseite ausreicht, zeigt eine Analyse der Besucherdaten (z.B. in Google Analytics).

Caniuse.com Verbreitung WOFF

Der Nachfolger WOFF 2.0 ist bereits in der Entstehung und erlaubt eine noch höhere Komprimierung und damit bessere Performance. Aktuell wird WOFF 2.0 von Firefox, Chrome und Opera unterstützt und erreicht damit ca. 60 % der Internutzer in Deutschland (Quelle: caniuse.com). Man kann und sollte also auch heute schon den neuen Standard in seinen @font-face-Regeln verwenden.

@font-face {
    font-family: MyFont;
    src: url('myfont.woff2') format('woff2'),
         url('myfont.woff') format('woff');
}

Unterstützt der Browser das Format WOFF 2.0 noch nicht, weicht er automatisch auf die nächste angegebene URL aus und lädt den Font im WOFF Format.

Subsetting

Eine weitere Möglichkeit der Komprimierung einer Schrift liegt im Subsetting. Dabei werden nur die Zeichen in einer Schrift eingebunden, die auch tatsächlich benötigt werden.

Dies muss von Hand erfolgen und hat auch durchaus seine Nachteile. So werden alle nicht in der Schrift eingebundenen Zeichen in einer Fallback-Schriftart angezeigt.

Subsetting Fallback

Man sollte also im Vorfeld genau überlegen, welche Zeichen die genutzte Schrift mitbringen sollte. Bei internationalen Seiten, die eine erweiterte Zeichenpalette für bestimmte Sprachen benötigen (bspw. Kyrillisch oder Griechisch), bietet es sich an, gesonderte Schriftpakete für die jeweiligen Sprachen anzubieten. Dadurch kann der Datenverkehr für Sprachen ohne spezielle Zeichen deutlich reduziert werden.

Bei der Einbindung von Google Fonts können bereits per Auswahl nur bestimmte Zeichensätze eingesetzt werden, die Standardeinstellung latin ist dabei in den meisten Fällen ausreichend.

Google Fonts Subsetting

Google bietet auch bereits eine Beta Schnittstelle für Font Requests an, bei der nur die benötigten Zeichen angefragt werden.

Der Web-Font Generator von FontSquirrel geht noch einen Schritt weiter und bietet neben dem Subsetting auch detaillierte Anpassungen an der zu verwendenden Schrift. Hier kann bspw. German als Sprache ausgewählt werden und FontSquirrel zeigt übersichtlich alle im Subset vorhandenen Glyphen an.

FontSquirrel Subsetting

Durch diese Anpassung habe ich am Beispiel der Schrift Bebas Neue eine Reduzierung um 55,6 % für WOFF und um 52,7 % für WOFF 2.0 erzielen können. Soll bspw. nur der Text Hallo Welt in einer anderen Schriftart dargestellt werden, reduziert sich die Schriftgröße insgesamt um 86,3 % sowohl für WOFF als auch WOFF 2.0. Die genaue Ersparnis zeigt die folgende Tabelle.

WOFF20,5 kB9,1 kB (-55,6 %)2,8 kB (-86,3 %)
WOFF 2.014,6 kB6,9 kB (-52,7 %)2,0 kB (-86,3 %)

Font Caching

Caching sollte bei der Entwicklung einer Webseite immer berücksichtigt werden und gilt ebenso für Fonts. Die Einstellungen werden dazu einfach in der htaccess-Datei auf dem Server hinterlegt und beim Aufruf der Seite mitgeschickt. Dadurch wird dem Browser des Nutzers mitgeteilt, wie lange dieser die Inhalte einer Seite im Cache behalten sollte, bevor sich daran etwas ändert. Dies sind nur Empfehlungen an den Browser, was dieser daraus macht, ist eine andere Sache. Bei Verwendung der in der HTML5 Boilerplate enthaltenen htaccess-Datei sind bereits umfangreiche Caching-Angaben enthalten.

DNS-Prefetching

Nutzt man einen der verschiedenen Font-Dienste, lässt sich die Ladezeit für den Font-Abruf noch etwas beschleunigen. Damit der Browser im Vorfeld schon einmal weiß, von wo er Dateien laden soll, kann man über dns-prefetch den Browser anweisen, die benötigten Domain-Namen im Vorfeld aufzulösen. Im Fall von Google Web Fonts sind zwei Angaben zu machen, da das eingebundene Stylesheet und die Font-Dateien auf zwei unterschiedlichen Domains liegen.

<link rel="dns-prefetch" href="//fonts.googleapis.com">
<link rel="dns-prefetch" href="//fonts.gstatic.com">

Welche Domains hier eingesetzt werden müssen, muss oftmals von Hand ermittelt werden. Der Aufwand lohnt sich aber durchaus, da hier wertvolle Millisekunden bei der Erstanzeige einer Webseite eingespart werden können. Das DNS-Prefetching lässt sich aber nicht nur auf Fonts anwenden. Verwendet man bspw. einen CDN für die Inhalte der Seite, kann dieser ebenfalls in der Prefetch-Anweisung angegeben werden, um die Zugriffszeit auf die Inhalte zu verkürzen.

Besser nicht ...

Neben den bereits genannten Verfahren gibt es auch vermeintliche Verbesserungen, die sich auf den zweiten Blick leider oftmals als schlecht entpuppen. Ich gehe hier einmal auf zwei Beispiele genauer ein. Auch wenn diese als Negativbeispiele genannt werden, gibt es durchaus Anwendungsfälle, bei denen deren Einsatz eventuell sogar sinnvoll ist.

... alles auf einmal

Um Aufrufe zu sparen, kann man eigene Fonts base64-kodiert im CSS hinterlegen, aufgrund der Beschaffenheit von base64 führt das im Gegenzug aber zu einer Erhöhung der eigentlichen Font-Größe und der in der CSS-Datei hinterlegten Datenmenge und damit zu einer längeren Ladezeit, bevor der Browser anfangen kann, die Seite zu rendern.

Welche Auswirkung die base64-Kodierung auf die Dateigröße der WOFF und WOFF 2.0 Dateien hat, zeigen die nachfolgenden Tabellen.

WOFF9132 byte
WOFF (base64)12177 byte33,3 %
WOFF (base64 + gzip)9187 byte0,6 %

Fast identisch sieht das Ergebnis mit WOFF 2.0 aus.

WOFF 2.06992 byte
WOFF 2.0 (base64)9352 byte33,3 %
WOFF 2.0 (base64 + gzip)7115 byte1,8 %

Selbst die per gzip komprimierten Daten verbrauchen mehr Speicherplatz als deren Original. Benutzt man wiederum ein sehr kleines Subset eines Fonts (bspw. eine kleine Anzahl an Icons aus einem Icon-Font), kann dieses durchaus per Inlining eingefügt werden, dies sollte generell aber für normale Schriften vermieden werden.

... lokale Schriften

Die @font-face-Regel erlaubt es auch, lokal auf dem Nutzersystem installierte Schriften zu verwenden.

@font-face {
  font-family: 'Lato';
  src: local('Lato'),
       url('lato.woff');
}

Ist die definierte Schrift auf dem Nutzersystem bereits vorhanden, wird diese nicht vom Server geladen, sondern direkt benutzt. Was prinzipiell gut klingt, hat aber auch entscheidende Nachteile. Web-Fonts unterscheiden sich teilweise deutlich von deren Desktop-Versionen. So sind Web-Fonts meistens nur ein Subset und modifizierte Versionen ihrer Desktop-Pendants. Die Wahrscheinlichkeit, dass ein Web-Font genau der Gleiche ist, der auf dem Nutzersystem installiert ist, ist gering.

Als Entwickler hat man keinen Einfluss auf die korrekte Darstellung der Seite beim Nutzer. Trotzdem können lokale Schriften durchaus als Fallback verwendet werden, falls die gewünschte Schriftart nicht heruntergeladen werden konnte. Sie sollte aber nicht als primär verwendete Schrift für eine Webseite verwendet werden.

Fazit

Bei der Verwendung von Web-Fonts gibt es viele Stolpersteine, die es zu beachten gilt. Neben den genannten Methoden gibt es noch eine schier endlose Liste weiterer Punkte, die man für die Verwendung von Web-Fonts heranziehen kann. Die aufkommenden Themen Preload Hints und HTTP2 sind nur zwei davon.

Prinzipiell gilt: Die Verwendung von Custom Fonts ist und bleibt eine Designentscheidung und sollte immer unter dem Gesichtspunkt des Progressive Enhancement zu verstehen sein. Die Anzeige der im Text angegebenen Informationen ist der Gestaltung dessen immer vorzuziehen.

Nach oben