Voorheen trof je fonts als Arial, Verdana en hopelijk nooit Times New Roman aan op websites. Inmiddels komen lettertypes in verschillende soorten en maten, en daarmee ook in verschillende (bestand)groottes. Waar wil je je bezoekers mee opzadelen, en kan dit optimaler?
Fonts, voorheen
In ieder geval tot en met 2009 heb ik veel met Cufon en sIFR gewerkt, om huisstijl fonts toe te passen op websites. Dit ging ten koste van de laadtijd en performance van webpagina's, waardoor ik op zijn minst adviseerde dit enkel voor kopteksten te gebruiken.
Tegenwoordig zijn er nieuwere technieken. Iedere website bouwer of afnemer weet inmiddels waar ik het over heb: Google Fonts (of Font Squirrel, Typekit, et cetera).
Kies voor kleinere font-files c.q. lettertypes
Beperk het aantal fonts
Uiteraard zou je vanuit estethisch oogpunt niet meerdere lettertypes moeten gebruiken. Echter, je kunt er voor kiezen om voor kopteksten een ander lettertype toe te passen. Vervolgens kan er sprake zijn van one-liners, met bijvoorbeeld een handgeschreven lettertype. Desalniettemin, probeer verschillende fonts tot een minimum te beperken.
Slechts specifieke font-karakters inladen
Wil je toch ook een derde font inladen voor die one-liner? Ga dan na of het volstaat met slechts enkele karakters. Je kunt bij het inladen vanuit bijvoorbeeld een Google Font ook aangeven welke karakters je wilt gebruiken, waardoor je geen onbenut Font-materiaal inlaadt:
http://fonts.googleapis.com/css?family=Gloria+Hallelujah&text=1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
Dit bespaart logischerwijs weer kilobytes dat door de bezoeker gedownload moet worden. Keerzijde is dat het resultaat dat door Google voorgeschoteld gaat worden, aan de kant van Google eerst gegenereerd moet worden op basis van de specifieke aanroep. Het is dus mogelijk dat dit alsnog ten koste gaat van de laadtijd (ongetest).
Maak je echter gebruik van een populair lettertype c.q. font? Dan kun je (met zorg) de gok nemen dat gebruikers de font gecached zullen hebben. Zie "CDN benutten".
Meerdere font-files samenvoegen
Wanneer je toch gebruik maakt van meerdere fonts, kun je er voor kiezen deze bronnen samen te voegen. Let echter op, in de strijd de requests te beperken, kan het voor komen dat deze bronbestanden niet (consequent) gecached worden. Overschrijding van bestandsgrootte kan het cachen van files voorkomen. De website smashingmagazine is hier tegen aan gelopen, en heeft gebruik gemaakt van HTML5's localStorage om caching via die weg te simuleren.
Beperk font requests
Hoe beperk je requests als je de verschillende fonts reeds tot een minimum hebt beperkt? Simpel. Bovenstaande url, laadt op zijn beurt pas de daadwerkelijke fonts in. Kopieer en plak de url in je browser en je ziet een verwijzing naar een adres als https://fonts.gstatic.com. Dit betekent niet enkel een een http-request die zijn eigen nieuwe http-request vereist, maar de daadwerkelijke font-file wordt ook nog eens elders gehost. Dit resulteert dus in twee eigen DNS lookups.
Je kunt het stukje CSS dat je daar aantreft, prima in je eigen stylesheet plaatsen (en vervolgens uiteraard deze stylesheets mergen en minimaliseren). Dit is ook gedaan op deze website, waardoor dit artikel slechts 9 requests vereist. Je kunt je voorstellen dat dit performance en laadtijd bevordert. Alle optimalisaties bij elkaar, dusdanig dat we sneller zijn dan Google's AMP.
Meerdere fonts in een enkele aanroep
Wil je toch gebruik maken van de link-attribuut en meerdere Google Fonts? Combineer dit dan als volgt:http://fonts.googleapis.com/css?family=Open+Sans|Roboto
De winst is uiteraard erg beperkt, want het bestand dat door Google Fonts voorgeschoteld wordt, zal alsnog meerdere nieuwe aanroepen bevatten. Je beperkt dus hooguit http-requests naar toch al erg kleine CSS files.
Font zelf hosten of CDN benutten
Gebruik je een andere font dan een Google Font? Host het zelf om een DNS lookup te besparen.
CDN voor font caching
Indien je geen gebruik maakt van een zeer specifiek huisstijl lettertype, en de font (of een gelijkenis) aanwezig is binnen Google Fonts, zou je het voordeel van caching moeten benutten. Doordat andere sites wellicht dezelfde font gebruikt, is het mogelijk dat deze font reeds door de browser van de bezoeker als cache is opgeslagen op de computer.
Asynchroon inladen van lettertypes
Dit punt staat ter discussie en is afhankelijk van je wensen. Sommigen pleiten er voor om een font primair in te laden, vooral om het wit blijven van tekst of een verspringing van lettertype te voorkomen. Ik kijk hier anders tegen aan, doordat je een bezoeker dan primair opzadelt met een te downloaden bestand. Bovendien heb je met de methode genoemd onder "beperk font requests", tevens de styling in de hand. Via de CSS property font-display (geniet op dit moment nog beperkte browser ondersteuning) in combinatie met de swap-value kun je er voor kiezen om de font pas te tonen als deze is ingeladen, en tot die tijd de backup lettertype toe blijven passen.
Naar mijn idee kun je er prima voor kiezen om een font secundair in te laden, zodat de bezoeker alvast kan beginnen met lezen. Voor dit doeleind, het lezen, is een specifieke font namelijk niet benodigd. Om dit te kunnen realiseren, zijn webfont loading scripts te vinden. Dit druist echter tegen alle performance tips in, en kan ik vanuit dat oogpunt dus niet aanbevelen.
Wil je ondanks eerdere punten, toch gebruik maken van een link-attribuut? Gebruik dan een techniek voor het asynchroon inladen van fonts (of CSS in het algemeen). Deze techniek gebruiken wij voor unieke gebruikers, zolang bronnen nog niet gecached zijn.
Verdere bonus fonts-leesvoer
