In navolging van web performance, als ook requests optimalisatie vorige maand, hebben we er voor gekozen om de custom Google Font asynchroon in te laden. Geen issue's zover, mits je surft over goed internet.
Het voordeel van asynchroon inladen is slechts dat je je bezoekers niet oplegt om eerst die font-file te downloaden voordat je browser begint met uittekenen van de website. Door dus die download af te dwingen, voorkom je automatisch ook flikkeringen, want op het moment dat de webpagina getoond wordt, is de font reeds gedownload.
Verspringing of flikkering van de webpagina
Verspringingen kunnen gebeuren door onvolledige Critical Path CSS, waarna de browser aan de hand van een asynchroon ingeladen stylesheet, de rest-onderdelen (naar Google's idee, onder de vouw) uit zal tekenen. Ook de inzet van asynchrone bronnen (waaronder fonts) kunnen dus de oorzaak van verspringingen of flikkeringen zijn.
Overigens vinden flikkeringen of verspringingen altijd plaats, ongeacht of je bronnen asynchroon inlaadt. Dit valt te testen via Chrome's Throttling-optie, maar merk je echter doorgaans wellicht niet, doordat:
- je op een snelle internetverbinding zit;
- je je bezoeker dwingt om eerst die font te downloaden, voordat de rest door de browser uitgetekend wordt.
Wachten met lezen
Soms wordt er, bijvoorbeeld doordat de wijze waarop bronnen geserveerd worden in bijvoorbeeld Wordpress, niet bewust een keuze gemaakt. Soms wordt er echter bewust voor gekozen voor de strategie om fonts voorrang te geven, om af te dwingen dat de bezoeker de tekst enkel en alleen in die font voorgeschoteld krijgt. De web font loading strategy betreft dus een kwestie van voorkeur van de website bouwer of opdrachtgever, hoe fonts afgehandeld c.q. voorgeschoteld worden.
Tegelijkertijd blijft de bezoeker echter een lege pagina zien, todat blokkerende bronnen (render blocking resources, zoals Google ze noemt) door de browser ingeladen zijn (overigens is het doel van Critical Path CSS om dit juist te tackelen). Is die font echter daadwerkelijk dusdanig belangrijk, dat je je bezoekers er van moet weerhouden om alvast te kunnen beginnen met lezen?
Asynchroon inladen
Ik adviseer tegenwoordig asynchroon inladen van fonts. Gevolg van asynchroon inladen, is normaliter onzichtbare tekst, ook bekend als FOIT. Browsers tonen namelijk bij gebruik van custom fonts gedurende een bepaalde tijdsspanne (3 seconden) geen tekst, zolang die custom font nog niet ingeladen is.
Er zijn technieken om FOIT te tackelen, met als gevolg een FOUT. Teksten zijn dan gestyled middels de backup font-family, waarna ze verspringen naar de custom font-family, zodra deze gedownload is. Hieronder enkele praktische technieken:
Web font loader
Asynchroon inladen zonder een effect van flikkerende tekst (FOIT), kan via een JS webfontloader. Dit voorkomt echter dat de browser de custom font-afhandeling op zich neemt (met dus de onzichtbare tekst als gevolg). Standaard wordt een algemeen ondersteunde font toegepast, waarbij de webfontloader periodiek controleert of de custom font reeds gedownload is. Dit gebeurt middels een onzichtbare tekstueel element, aangemaakt door de web font loader. Bij de conclusie door de webfontloader dat de font geladen is, wordt vervolgens een CSS-class toegpast op de body van het HTML-document, waarmee op zijn beurt de custom font zichtbaar wordt.
Meer inhoudelijk leesvoer omtrent web font loading:
In mijn optiek is extra code toevoegen om een eerder ontnomen feature te tackelen, echter geen performance winst. Echter, ook hier geldt dat voorkeur leidend zal zijn.
Versimpelde oplossing
Zelf gebruik ik een versimpelde techniek als alternatief om de font asynchroon in te laden en tegelijkertijd onzichtbare tekst te voorkomen. Hierbij vindt geen periodieke controle door JavaScript plaats. Via JavaScript wordt wel een CSS-class toegepast op de body van het HTML-document. Via session-setting wordt in opvolgende page-hits de benodigde CSS-class direct server side in het HTML document ingebakken, omdat vanaf dat moment het caching-mechanisme van de browser zijn werk zal doen (de third party font file zal in de meeste gevallen namelijk inmiddels in de cache staan).
FOFT: Flash of Faux Text
Een andere boeiende methode, is om de standaard / reguliere font wel direct bij downloaden mee te nemen en 'op te dringen' aan de bezoeker, maar de vetgedrukte (bold) en schuingedrukte (italic) varianten van de custom font, later in te laden. Deze techniek wordt afgekort tot FOFT.
Dit voorkomt benodigde repaints door de browser: de browser van de gebruiker, hoeft niet het gehele scherm te hertekenen. Hier merkt een bezoeker visueel weinig van, en zal dan ook vooral gekozen worden om performance te verhogen; de browser van de device (smartphone, desktop) gebruikt door de bezoeker, heeft het minder zwaar om de webpagina in te vullen.
Pure CSS oplossing
Een CSS-only voorstel is gedaan, en kan wat mij betreft niet snel genoeg uitgerold worden door browsers. Via font-display: swap, kun je de browser bevelen om gewoonweg de in CSS gedeclareerde back-up font-family toe te passen. Zodra de browser de font heeft kunnen downloaden, zal de custom font direct toegepast worden. Middels de swap-value, zal de browser de tekst niet gedurende 3 seconden onzichtbaar maken (is de bedoeling).
Deze CSS property geniet nog weinig ondersteuning (Chrome bijvoorbeeld pas vanaf versie 60) en is momenteel nog niet te combineren wanneer je gebruik maakt via third party / Google Fonts, waarbij de directe fonts.googleapis.com-verwijzing wordt gebruikt.
Bonus font leesmetariaal
