Webfonts en performance: elke milliseconde telt voor AI
Het webfont-probleem dat niemand serieus neemt
Ik heb een bekentenis. Ik heb ooit een complete avond besteed aan het optimaliseren van webfonts voor een klantsite. Vier uur. Voor lettertypen. Mijn vrouw vond het minder indrukwekkend dan ik. Maar het scheelde 800 milliseconden aan laadtijd.
800 milliseconden.
Dat klinkt als niks, maar het is het verschil tussen een LCP van 1,8 seconden (groen, mooi, feestje) en 2,6 seconden (oranje, problematisch, AI-crawler kijkt op zijn horloge).
En ik zie het bij bijna elke website die we bij Kobalt onder handen nemen: een prachtig ontwerp met drie custom webfonts, elk in vijf gewichten, allemaal via Google Fonts. Het ziet er fantastisch uit. En het vreet je performance op als een hongerige kiekendief.
Largest Contentful Paint (LCP) is de tijd totdat het grootste zichtbare element op de pagina geladen is. Vaak een hero-afbeelding of een grote koptekst. Google beschouwt een LCP onder 2,5 seconden als goed. AI-crawlers kijken naar vergelijkbare drempelwaarden. Boven de 3 seconden? Dan ga je content verliezen.
font-display: swap — de snelste winst die je vandaag kunt boeken
Als ik één ding zou mogen veranderen aan elke website die ik tegenkom, is het dit: `font-display: swap` toevoegen aan alle font-declaraties.
Wat het doet: de browser toont eerst een fallback-font en vervangt het zodra het webfont geladen is. De tekst is direct zichtbaar. Geen wachten. Geen onzichtbare tekst.
Zonder swap wacht de browser op het font voordat hij tekst toont. Dit heet FOIT (Flash of Invisible Text). En het blokkeert je LCP direct. Je pagina staat daar, wit, wachtend, terwijl een AI-crawler al heeft besloten dat er niks te halen valt.
Hoe je het instelt:
- Via Google Fonts URL: voeg `&display=swap` toe aan het einde van je URL. Klaar.
- Via zelf-gehoste fonts: voeg `font-display: swap;` toe aan je @font-face declaraties in je CSS.
- Via een font-plugin (WordPress, etc.): zoek in de instellingen naar "font display" of "swap." De meeste moderne plugins ondersteunen dit.
Subsetting: laad alleen wat je nodig hebt
Hier wordt het leuk. Een volledig webfont-bestand bevat honderden tekens die je nooit gebruikt. Cyrillisch. Arabisch. Wiskundige symbolen. Als je een Nederlandse website hebt, heb je alleen het Latijnse alfabet nodig.
Subsetting snijdt alle onnodige tekens weg. Het resultaat: een fontbestand van 150 KB wordt 30 KB. Vijf keer sneller. Voor niks.
- Via Google Fonts: gebruik `&subset=latin` in je URL om alleen het Latijnse subset te laden.
- Via zelf-gehoste fonts: gebruik Glyphhanger of pyftsubset om te subsetten. FontSquirrel's WebFont Generator werkt ook voor een snelle online subset.
- Converteer naar WOFF2: het meest efficiënte fontformaat, ondersteund door alle moderne browsers. Gebruik alleen WOFF2 en vergeet de rest.
Gebruik nooit meer dan twee webfonts op een site. Eén voor koppen, één voor broodtekst. Meer is zelden noodzakelijk en altijd duurder in laadtijd. Als het ontwerp drie of meer fonts voorschrijft, is dat een gesprek met de designer waard. Ik heb dat gesprek al heel vaak gevoerd. Het went.
System font stacks: mijn eerlijke, ongefilterde mening
Hier is mijn stellige standpunt, en ik weet dat designers me er niet populair om vinden: voor de meeste zakelijke websites is een system font stack de beste keuze.
Niet de mooiste. De beste.
Een system font stack gebruikt de fonts die al op het apparaat staan. Geen download, geen laadtijd, geen FOIT. Nul milliseconden overhead.
- font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif;
- Op een Mac ziet de bezoeker San Francisco. Op Windows Segoe UI. Op Android Roboto.
- Allemaal professionele, goed leesbare fonts. Zonder een milliseconde extra laadtijd.
Is het net zo onderscheidend als een custom font? Nee. Is het voor een B2B-dienstenleverancier die serieus aan AI-zichtbaarheid werkt de juiste afweging? Vaak wel.
Maar wacht. Is dat eigenlijk wel altijd zo? Nee. Als je merk draait om visuele identiteit (design bureaus, luxury brands), dan is een custom font de investering waard. Je moet alleen wel de performance-kosten kennen en ze bewust accepteren. Niet per ongeluk.
Bij Kobalt helpen we klanten met precies die afweging. Soms is het antwoord: "ja, laad dat custom font, maar dan wel goed." Soms is het: "gebruik een system stack en investeer die 800 milliseconden in iets dat meer oplevert."
Een website die in 1,2 seconden laadt met een system font wint het altijd van een website die in 3,5 seconden laadt met een prachtig custom font. Bij mensen én bij AI-crawlers. Dat is geen mening. Dat is een stopwatch.
Veelgestelde vragen
Heeft het preloaden van fonts zin?
Ja, voor je primaire font (bodytekst of je grootste heading) is preloaden zinvol. Voeg een `` tag toe in je `
`. Dit vertelt de browser dat hij het font met hoge prioriteit moet ophalen, nog vóór de CSS wordt geparseerd. Maar overdrijf niet: preload maximaal één of twee bestanden. Anders verlies je de winst door bandbreedteconcurrentie.Is Google Fonts goed of slecht voor performance?
Genuanceerd antwoord: Google Fonts zijn niet inherent traag. Maar de standaard implementatie via een `` tag voegt een extra DNS-lookup en verbindingsstap toe. Zelf hosten is bijna altijd sneller. Gebruik de google-webfonts-helper tool (gwfh.mranftl.com) om je fonts eenvoudig zelf te hosten. Het kost je een kwartier en levert je honderden milliseconden op.
Merken AI-crawlers het verschil tussen snel en langzaam geladen fonts?
Niet direct op fontniveau, maar wel via de impact op LCP. Als je font de LCP blokkeert, duurt het langer voordat de pagina als "volledig" geladen beschouwd wordt. AI-crawlers hebben een time-budget per pagina. Boven de 3 seconden LCP loopt dat budget op en kan de crawler besluiten je pagina als onvolledig te crawlen. En dat merk je niet. Tot je je citaties ziet teruglopen.
Hoe scoort jouw website op AI-gereedheid?
Krijg binnen 30 seconden je AEO-score en ontdek wat je kunt verbeteren.
