Responsief Web Font Laden: Een Apparaatbewuste Strategie

Responsieve font display & responsieve preloading strategie

Als Core Web Vitals specialist zie ik elke dag verschillende creatieve oplossingen. De meeste slaan nergens op, maar heel soms kom ik een strategie tegen die zo simpel en elegant is dat het wel degelijk zin heeft voor bepaalde sites.

Volgens de 2025 Web Almanac gebruikt 88% van de websites web fonts, waarbij een mediaan van 4 fontbestanden per pagina wordt geladen. Toch preload slechts 12% van de sites fonts, en een schamele 0,5% gebruikt font-display: optional. De meeste sites behandelen font loading als een one-size-fits-all probleem. Dit artikel legt een slimmere aanpak uit: fonts verschillend laden voor desktop en mobiel.

De strategie combineert responsieve preloading met font-display: optional op desktop (wat de Flash Of Unstyled Text elimineert) en font-display: swap op mobiel (wat prioriteit geeft aan snelle tekst rendering boven visuele consistentie).

Laatst beoordeeld door Arjen Karel in maart 2026

tip: deze strategie werkt goed voor sites met een groter critical rendering path, wat betekent dat sites meerdere fonts, stylesheets en scripts laden voor het LCP element. Als jouw site een enkel lichtgewicht font laadt, is de extra complexiteit het niet waard.

Het probleem met vroeg fonts laden

Bij het optimaliseren van de Core Web Vitals is er één simpele regel die altijd geldt:
"Alles wat je doet voor de Largest Contentful Paint zal die Largest Contentful Paint vertragen".

Dit principe is ook van toepassing op web fonts. Het prioriteren van web font loading tijdens het laden van de pagina kan de user experience verbeteren, maar als jouw site moeite heeft om de Core Web Vitals drempels te halen, vooral voor specifieke apparaattypes, moet je mogelijk UX afwegen tegen het verbeteren van LCP.

Het 2025 Web Almanac Performance hoofdstuk laat zien dat tekst het LCP element is op bijna 24% van de mobiele pagina's. Wanneer tekst het LCP element is, beïnvloedt de font laadstrategie direct je LCP score. Op de overige 76% van de pagina's waar een afbeelding het LCP element is, concurreren fonts nog steeds om vroege netwerkbandbreedte en kunnen ze het laden van de afbeelding naar achteren schuiven.

Laten we het onderstaande voorbeeld bekijken van een Nederlandse krantensite. Op een mobiel apparaat worden 3 fonts in de wachtrij geplaatst voor het LCP element. Dit zorgt ervoor dat de 3 fonts concurreren om vroege netwerkresources en de timing van de afbeelding naar achteren schuiven.

Het begrijpen van font-display: optional vs swap

Voordat we in de responsieve strategie duiken, moet je de twee font-display waarden begrijpen waar deze op leunt. Voor een breder overzicht van font-display, zie hoe je ervoor zorgt dat tekst zichtbaar blijft tijdens het laden van webfonts.

font-display: swap toont direct het fallback font en wisselt naar het custom font zodra het geladen is. Dit is geweldig voor LCP omdat tekst vanaf het begin zichtbaar is. Het nadeel: wanneer het custom font arriveert en de fallback vervangt, kunnen de verschillende font metrics een zichtbare layout shift veroorzaken, wat je CLS score schaadt. Ongeveer 50% van de sites gebruikt swap, waardoor het verreweg de populairste waarde is.

font-display: optional geeft de browser ongeveer 100ms om het font te laden. Als het font op tijd arriveert (meestal uit de cache of via een snelle preload), wordt het gebruikt. Zo niet, dan wordt het fallback font gebruikt voor de gehele pagina laadtijd en vindt er nooit een swap plaats. Dit betekent nul layout shifts, maar het custom font wordt mogelijk niet getoond bij het eerste bezoek. Slechts 0,5% van de sites gebruikt optional, ondanks dat het de meest CLS-veilige optie is.

Sinds Chrome 83 blokkeert het combineren van font-display: optional met <link rel="preload"> de first paint voor maximaal ~100ms (met een absoluut maximum van 1500ms), wachtend tot het font arriveert. Als het font gepreload is, arriveert het bijna altijd binnen dat tijdvenster. Het resultaat: gestylede tekst bij de first paint, nul FOUT, nul layout shifts. Dit is waarom de desktopkant van de responsieve strategie zo goed werkt.

Responsieve font strategie schiet te hulp!

In gevallen zoals deze waar er veel vroege netwerkconcurrentie is, is het logisch om onderscheid te maken tussen apparaattypes. Typisch snellere desktopapparaten op bekabelde (en snellere netwerkverbindingen) kunnen meer vroege netwerkresources tegelijk aan en het is volkomen logisch om enkele kritieke fontbestanden te preloaden.

Mobiele apparaten daarentegen worden mogelijk gebruikt tijdens het forenzen naar werk onder minder dan optimale netwerkomstandigheden. Mobiele apparaten hebben vaak ook tragere CPU's en minder beschikbaar geheugen vergeleken met desktops. Deze beperkingen betekenen dat het verschillend behandelen van font loading op basis van apparaattype logisch kan zijn.

• Desktop: Het preloaden van fonts verbetert de rendering prestaties op apparaten met betere bandbreedte en rekenkracht. Gebruik font-display: optional om font-swapping problemen te elimineren. Gecombineerd met een preload zal Chrome kort de rendering blokkeren (tot ~100ms) om op het font te wachten, wat je gestylede tekst geeft bij de first paint met nul CLS.
• Mobiel: Preload het font niet vanwege netwerkconcurrentie. Gebruik font-display: swap voor snellere tekst rendering. Deze aanpak toont onmiddellijk fallback fonts terwijl het custom font op de achtergrond blijft laden, wat een betere ervaring biedt op minder krachtige apparaten.

Implementatie met <link rel="preload"> en media queries

In plaats van het font universeel te laden, kun je het media attribuut in de HTML's <link> tag samen met CSS gebruiken om verschillende font strategieën toe te passen op basis van apparaattypes.

Volledige implementatie

<head>
  <!-- viewport meta MUST come before media-conditional preloads -->
  <meta name="viewport" content="width=device-width, initial-scale=1">

  <!-- Preload font for desktop only -->
  <link rel="preload" href="/fonts/custom-font.woff2"
        as="font" type="font/woff2" crossorigin
        media="(min-width: 768px)">

  <style>
    /* Mobile: swap ensures fast text rendering */
    @font-face {
        font-family: 'CustomFont';
        src: url('/fonts/custom-font.woff2') format('woff2');
        font-display: swap;
    }

    /* Desktop: optional + preload = styled text on first paint */
    @media (min-width: 768px) {
        @font-face {
            font-family: 'CustomFont';
            src: url('/fonts/custom-font.woff2') format('woff2');
            font-display: optional;
        }
    }

    body {
        font-family: 'CustomFont', sans-serif;
    }
  </style>
</head>

Een paar belangrijke details over deze implementatie:

1. Viewport meta tag volgorde: De <meta name="viewport"> tag moet vóór de preload link staan. De preload scanner van de browser evalueert het media attribuut voordat andere meta tags worden geparsed. Als de viewport niet is ingesteld, wordt de media query geëvalueerd tegen de verkeerde dimensies op mobiele apparaten.
2. Volledige @font-face declaraties: Elk @font-face blok moet zowel font-family als src bevatten. In tegenstelling tot reguliere CSS eigenschappen, cascadet @font-face descriptors niet. Je kunt niet alleen font-display overschrijven in een tweede blok zonder de volledige font face opnieuw te declareren. De browser zal een onvolledige @font-face regel negeren.
3. Het crossorigin attribuut: Fonts die zonder crossorigin worden gepreload, worden twee keer opgehaald. Voeg het altijd toe aan font preloads, zelfs voor same-origin fonts.
4. Overeenkomende breekpunten: Het media attribuut op de preload (768px) moet overeenkomen met de CSS media query (768px). Als ze niet overeenkomen, preload je op het ene breekpunt en pas je de verkeerde font-display toe op een ander.

Layout shifts verminderen op mobiel met fallback font matching

De mobiele strategie gebruikt font-display: swap, wat betekent dat er een korte Flash Of Unstyled Text zal zijn wanneer het custom font de fallback vervangt. Je kunt deze visuele sprong minimaliseren met behulp van CSS font metric overrides:

@font-face {
    font-family: 'CustomFont Fallback';
    src: local('Arial');
    ascent-override: 105%;
    descent-override: 25%;
    size-adjust: 97%;
}

body {
    font-family: 'CustomFont', 'CustomFont Fallback', sans-serif;
}

De ascent-override, descent-override en size-adjust descriptors laten je de dimensies van het fallback font matchen met het custom font. Wanneer de swap plaatsvindt, beweegt de tekst nauwelijks. Deze descriptors worden in alle moderne browsers ondersteund. Bibliotheken zoals Capsize kunnen automatisch de juiste override waarden berekenen voor jouw specifieke fonts.

Voordelen van deze aanpak

• Desktop UX: Desktop rendert met het web font bij de first paint, wat zowel FOUT als FOIT voorkomt. Nul layout shifts door font loading.
• Mobiele prestaties: font-display: swap zorgt ervoor dat gebruikers onmiddellijk tekst zien, zelfs als het custom font nog niet geladen is. Geen preload betekent dat fonts niet concurreren met de LCP afbeelding om bandbreedte.
• Declaratieve eenvoud: Pure HTML en CSS. Geen JavaScript, geen font laadbibliotheken, geen framework afhankelijkheden. Dit betekent ook dat het werkt met elke resource prioritization strategie die je al hebt geïmplementeerd.

Real-world impact

Deze strategie is gebaseerd op een real-world voorbeeld dat ik tegenkwam tijdens het auditen van een e-commerce site. De site laadde 3 custom fonts: een kopfont, een bodyfont en een iconfont. Op desktop laadde alles snel genoeg zodat de fonts zelden problemen veroorzaakten. Maar op mobiel via 4G concurreerden de drie font preloads met de hero afbeelding en stuwden ze de LCP ver boven de 2,5 seconde drempel.

Na het implementeren van de responsieve strategie (alleen preloaden op desktop, font preloads verwijderen op mobiel):

• Desktop: Verbeterde CLS en UX met gestylede fonts die verschijnen bij de first paint. De combinatie preload + font-display: optional elimineerde alle font-gerelateerde layout shifts.
• Mobiel: Snellere First Contentful Paint en Largest Contentful Paint omdat de fonts niet langer concurreerden om vroege bandbreedte. De hero afbeelding laadde zonder concurrentie.

Onderzoek van DebugBear bevestigt de impact: font preloading kan LCP met grofweg 30% verbeteren (van 1.82s naar 1.24s) wanneer dit correct wordt toegepast. Maar bij overmatig gebruik (één site had 38 gepreloade fonts), maakt preloading de zaken erger. De responsieve aanpak geeft je het voordeel van preloading op desktop zonder de kosten op mobiel.

Op sites gemonitord door CoreDash behaalt ongeveer 82% van de mobiele paginaweergaven een voldoende voor LCP wanneer fonts strategisch gepreload worden, vergeleken met 70% voor pagina's die alle fonts op dezelfde manier laden ongeacht het apparaattype. Op desktop, waar de preload + optional combinatie het beste werkt, is het verschil nog groter.

Wanneer gebruik je deze strategie (en wanneer niet)

Gebruik deze strategie wanneer:

• Jouw site 2 of meer custom font bestanden laadt
• Mobiel en desktop verschillende Core Web Vitals prestatieprofielen hebben (gebruikelijk op sites waar mobiel moeite heeft met LCP terwijl desktop een voldoende haalt)
• Fonts concurreren met andere kritieke resources (hero afbeeldingen, critical CSS) op mobiel
• Je je fonts zelf host (deze strategie werkt met elke font hosting, maar self-hosting geeft je volledige controle over het preload pad)

Sla deze strategie over wanneer:

• Je slechts één lichtgewicht WOFF2 font laadt (onder de 20 KB). De overhead van responsief laden is het niet waard.
• Jouw site al op zowel mobiel als desktop een voldoende haalt voor alle Core Web Vitals. Voeg geen complexiteit toe aan een probleem dat je niet hebt.
• Je leunt op systeemfonts. Als je al font-family: system-ui, sans-serif gebruikt, is er niets te optimaliseren.

Monitor na het implementeren van deze of enige andere font laadstrategie de impact met Real User Monitoring om te bevestigen dat de wijziging daadwerkelijk je velddata heeft verbeterd. Labtesten kunnen de variabiliteit in echte netwerkomstandigheden missen die deze strategie in de eerste plaats waardevol maken.