Webfonts laden mit Font Face Observer

Die Geschichte der Webfonts ist eine Geschichte voller Missverständnisse. Oder sagen wir so: es war schon ein ziemliches Hin und Her. Erst wollten wir sie ganz dringend und änderten mehrmals die Syntax zur Einbindung; dann fiel uns auf, wie viele fürchterbare Schriften plötzlich über Google Fonts sehr leicht für den Webeinsatz verfügbar waren; dann bemerkten auch die letzten, dass schwergewichtige Webfonts auf schmalen Mobilbandbreiten nicht unbedingt ideal performen – und inzwischen plädieren die ersten dafür, doch wieder nur Systemfonts bzw. die extra dafür entworfenen und optimierten System UI Fonts der Betriebssysteme zu verwenden. Puh.

Nur Systemfonts, das mag in Web-Apps gehen, die sich an der Optik des Betriebssystem orientieren sollen. Und natürlich kann man auch mit Roboto, Fira Sans & Co. schöne Typografie machen. Aber nur mit diesen Schriften? Das scheint mir zumindest weder praktisch sinnvoll noch notwendig, wenn man sich ein bisschen Mühe gibt, die Webfonts sorgfältig auszuwählen und optimiert einzubinden. Ich zumindest würde nicht komplett auf tyografische Nettigkeiten verzichten wollen …

Ligaturen und stylistische Alternativen im Webfont Calendas_plus
Webfonts wie die hier im Blog verwendete Calendas Plus sind potenzielle Performance-Bremsen

Was ist eigentlich das Problem?

Vereinfacht gesagt: Lädt man – ob nun von Google Fonts oder „lokal“, also selbst gehostet – eine Schrift via @font-face, so hat man üblicherweise etwas, was das Rendering der Seite blockiert, weil eben erstmal die Schrift geladen wird, was insbesondere auf schmalbrüstigen Verbindungen unschön ist und zu einem sogenannten FOIT führen kann. Sprich: Man sieht gar nix, bis die Schrift geladen ist. Unter iOS z.B. kann es bis zu 30 Sekunden dauern, bis der Browser „aufgibt“ und stattdessen die Seite in einem Standard- bzw. Fallback-Font darstellt.

Man könnte argumentieren, dass eben dies das Standardverhalten sein sollte – so lange der Webfont nicht geladen werden kann, zeige Text in einem Systemfont an, damit der ungeduldige Leser nicht warten muss. Allerdings ergibt das eben einen FOUT, der lange Zeit als dringend zu umgehen galt. (Mehr Infos zu FOUT und FOIT gibt's bei CSS Tricks.)

Gestatten: Font Face Observer

Font Face Observer implementiert genau das mit Javascript. Die Webfonts werden wie gehabt (das finde ich persönlich den Clou daran) im CSS geladen – wahlweise lokal gehostet oder von einem Webfont-Anbieter. Man bindet das (minifiziert und komprimiert zumindest) kaum ins Gewicht fallende JS von Font Face Observer und folgenden Aufruf ein:

var font = new FontFaceObserver('calendas_plus');

font.load().then(function () {
    document.documentElement.className += " fonts-loaded";
});

Das ist nur eine einfache Anwendung des Font Face Observers, es geht durchaus komplexer. Für mich reicht dieses Beispiel hier im Blog (Tadaaa!) völlig aus. Font Face Observer nutzt eine noch relativ junge JS-Technik namens Promises (für ältere Browser bringt Font Face Observer bei Bedarf ein Polyfill mit), um quasi zu „beobachten“, ob der Font bereits geladen ist. Wenn er geladen ist, wird (in diesem Beispiel) eine Klasse fonts-loaded auf das Element <html> gesetzt, über die man dann den geladenen Font „aktivieren“ kann.

body {
    font-family: serif;
}

.fonts-loaded body {
    font-family: 'calendas_plus', serif;
}

Ehe der Webfont geladen ist, bekommt body also die Standard-Serifenschrift im Browser – das kann man aber natürlich auch anders handhaben (also z.B. explizit Georgia oder Times setzen). Und ja, das ergibt auch hier im Blog z.T. sogar über DSL-Verbindungen einen wahrnehmbaren FOUT, wenn man die Seite ohne Cache neu lädt. Aber sollte es erheblich länger dauern oder aus technischen Gründen gar komplett scheitern, den Webfont zu laden, muss man nicht bis zu 30 Sekunden auf eine größtenteils weiße Seite starren. Damit verbessert Font Face Observer effektiv die „wahrgenommene Performance“ der Seite.