Font loading strategie voor e-commerce — FOUT vs FOIT

Font loading strategie voor e-commerce — FOUT vs FOIT

30% van de shoppers verlaat een pagina als tekst meer dan 3 seconden onzichtbaar blijft. Fonts zijn daar vaak de stille boosdoener. De browser wacht op een lettertype, tekst blijft leeg of verspringt plots — en dat kost je conversie. Een goede font loading strategie lost dit op zonder dat je bezoeker er iets van merkt.

Dit artikel gaat over de keuzes die er echt toe doen: FOUT vs FOIT, font-display waarden, preloading, self-hosting en subsetting. Met de impact op LCP en CLS als leidraad.

FOUT en FOIT: wat is het verschil?

Browsers hebben twee basisstrategieën bij het laden van een font.

Chrome, Firefox en Edge geven fonts standaard 3 seconden de tijd. Als het font daarna nog niet geladen is, valt de browser terug op het systeem font — dat is de FOUT-fallback die alsnog optreedt. Safari hanteert tot recent zelfs een oneindig wachttijd, wat FOIT in theorie permanent maakt.

Voor e-commerce is FOIT bijna altijd de slechtere keuze. Onleesbare productinformatie, onzichtbare prijzen en CTA-knoppen zijn direct omzetschade.

font-display: de schakelaar die het verschil maakt

De font-display descriptor in CSS bepaalt hoe de browser omgaat met fontvertraging. Er zijn vijf waarden, maar in de praktijk zijn er drie relevant.

Voor productpagina's en category-overzichten — waar tekst direct actionable moet zijn — is swap de standaard aanbeveling. Wij zien bij klanten dat het overschakelen van block naar swap de Largest Contentful Paint met 0,4 tot 1,2 seconden verkort, afhankelijk van de fontgrootte en het CDN.

Wanneer is optional slimmer?

Voor repeat traffic (doorgaans 40-60% bij een gezonde e-commerce site) is optional de meest stabiele keuze. Het nadeel: nieuwe bezoekers zien het webfont nooit bij het eerste bezoek. Of dat een probleem is hangt af van je merk en hoe sterk het font bijdraagt aan herkenning.

Preloading: fonts proactief laden

De oplossing: het font zo vroeg mogelijk laden zodat de swap plaatsvindt vóór de eerste render. Dit doe je met .

<link
  rel="preload"
  href="/fonts/inter-var.woff2"
  as="font"
  type="font/woff2"
  crossorigin="anonymous"
/>

Zet dit in de , zo vroeg mogelijk. Het crossorigin attribuut is verplicht — ook bij self-hosted fonts. Zonder dit attribuut laadt de browser het font twee keer.

In de praktijk: preload de fonts die boven de vouw (above the fold) gebruikt worden. Preload je te veel fonts, dan verzwaar je de kritieke laadketen en verlies je juist snelheid. Beperk je tot maximaal 2 à 3 fontbestanden.

Voor Magento 2 / Hyva-setups voeg je dit toe aan je theme default_head_blocks.xml. Voor Shopify doe je dit in theme.liquid. Op Laravel zet je het in je Blade layout-template.

Self-hosting vs Google Fonts

Google Fonts is gratis en makkelijk. Maar voor performance heeft het een serieuze keerzijde.

Het laden van fonts via fonts.googleapis.com vereist twee extra DNS-lookups en TCP-handshakes: één naar fonts.googleapis.com voor de CSS, één naar fonts.gstatic.com voor het eigenlijke fontbestand. Op een nieuwe verbinding kost dat doorgaans 200-600ms extra. Dat is meetbaar in je LCP.

Daarnaast: Google Fonts biedt geen controle over caching. De browser kan fonts van gstatic.com in theorie cachen, maar cross-site cache partitioning (geïntroduceerd in Chrome 86) zorgt ervoor dat je site de cache van een andere site niet meer deelt. Het voordeel van "iedereen heeft Roboto al in cache" bestaat niet meer.

Self-hosting is de betere keuze voor serieuze e-commerce. Je host het font op je eigen domein, elimineert externe verbindingen, en hebt volledige controle over cache-headers.

1. Download fonts via google-webfonts-helper.herokuapp.com of rechtstreeks van de font-leverancier.
2. Genereer alleen de formaten die je nodig hebt. In 2025 is woff2 voldoende — alle moderne browsers ondersteunen het. Laat woff, ttf en eot weg tenzij je IE11-ondersteuning vereist (dat is bijna nooit het geval).
3. Plaats fonts in een statische map met lang cache-leven (1 jaar of meer).
4. Definieer @font-face in je CSS met de juiste font-display waarde.

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter-var.woff2') format('woff2');
  font-weight: 100 900;
  font-style: normal;
  font-display: swap;
}

Variable fonts (zoals inter-var.woff2) dekken alle gewichten in één bestand. Dat scheelt meerdere HTTP-requests. Voor een typische e-commerce site met twee font-weights (regular + bold) ga je van twee bestanden naar één.

Subsetting: minder bytes, sneller laden

Een volledig Google Font als Inter bevat alle karakters voor tientallen talen en honderden glyphs. Jouw Nederlandse webshop gebruikt 99% van die glyphs nooit.

Subsetting snijdt alle ongebruikte karakters weg. Resultaat: een fontbestand van 80-200KB wordt teruggebracht naar 15-40KB. Dat is een reductie van 75-80% in bestandsgrootte — direct meetbaar in laadtijd.

Tools voor subsetting:

• pyftsubset (onderdeel van fonttools) — command line, maximale controle
• glyphhanger — automatisch detecteert welke karakters je site gebruikt
• subfont — integreert met je build pipeline

Voor een Nederlandse e-commerce site is de Latin subset (Latin + Latin Extended) in vrijwel alle gevallen voldoende. Voeg alleen Grieks, Cyrillisch of andere scripts toe als je die actief gebruikt.

# Subset met pyftsubset voor Latin + basis interpunctie
pyftsubset Inter.ttf \
  --unicodes="U+0000-00FF,U+0131,U+0152-0153,U+02BB-02BC,U+02C6,U+02DA,U+02DC,U+2000-206F,U+2074,U+20AC,U+2122,U+2191,U+2193,U+2212,U+2215,U+FEFF,U+FFFD" \
  --layout-features="*" \
  --flavor=woff2 \
  --output-file=inter-latin.woff2

Impact op LCP en CLS: concrete cijfers

Fonts raken twee Core Web Vitals direct.

Een techniek die steeds vaker wordt ingezet is size-adjust op het fallback font. Dit past de afmetingen van het fallback font aan zodat het bijna identiek is aan het webfont. De swap veroorzaakt daarmee nauwelijks of geen layout shift.

@font-face {
  font-family: 'Inter-Fallback';
  src: local('Arial');
  size-adjust: 107%;
  ascent-override: 90%;
  descent-override: 22%;
  line-gap-override: 0%;
}

Genereer de exacte waarden met de Fallback Font Generator van Brian Louis Ramirez of via de fontaine tool. De waarden zijn fontspecifiek — gebruik geen generieke getallen.

Voor Magento en Hyva setups is dit bijzonder waardevol omdat Hyva standaard een variabel font gebruikt en de thema's gevoelig zijn voor CLS door de rijke productgrids.

Praktische beslisboom

De juiste keuze hangt af van je situatie:

• Nieuwe bezoeker, brand-critisch font, snelle verbinding verwacht? → swap + preload + self-hosted + subset
• Hoge repeat-traffic, stabiele lay-out prioriteit? → optional + self-hosted + subset
• Font alleen decoratief (logo, heading)? → optional of block acceptabel, maar preload het wel
• Google Fonts via CDN en snelheid is geen prioriteit? → gebruik dan in ieder geval &display=swap in de URL-parameter en voeg toe

Voor Shopify is de manoeuvreerruimte beperkt — themes beheren fonts deels via het platform. Shopify laadt fonts via hun eigen CDN, maar je kunt in het theme de font-display waarde overschrijven in de CSS-assets.

Op Laravel maatwerk heb je volledige controle. Font-assets kun je meeleveren in de build pipeline (Laravel Mix of Vite), direct in de public/fonts directory plaatsen en cachen met de juiste Cache-Control headers via nginx of Apache.

Veelgestelde vragen

FOUT toont tekst direct in een fallback font en vervangt dat zodra het webfont geladen is. FOIT houdt tekst onzichtbaar totdat het webfont beschikbaar is. Voor e-commerce is FOUT bijna altijd beter: bezoekers kunnen de pagina lezen, ook al klopt het lettertype even niet.

Dat hangt af van je traffic-mix. Voor sites met veel nieuwe bezoekers is swap gecombineerd met preloading en een gecalibreerde fallback font de beste combinatie voor zowel LCP als CLS. Voor sites met overwegend terugkerende bezoekers kan optional betere CLS-scores opleveren. Test altijd in Chrome DevTools met gecachete en niet-gecachete staat.

Niet per se, maar voor serieuze e-commerce performance is self-hosting de betere keuze. Het elimineert externe afhankelijkheden, geeft controle over caching en caching-lifetime, en is meetbaar sneller — zeker op mobiel en trage verbindingen. De setup kost een middagje werk.

Fonts zijn zelden de enige factor, maar ze dragen direct bij aan LCP en CLS. Google's eigen onderzoek koppelt elke 100ms verbetering in laadtijd aan 0,5-1% conversiestijging. In de praktijk zien wij bij klanten die fonts optimaliseren als onderdeel van een bredere performance-aanpak verbeteringen van 10-20% in Core Web Vitals scores. Wil je weten wat dit voor jouw shop betekent? Neem contact op en we kijken samen naar de knelpunten.