Los Ensure text remains visible during webfont load op
Webfonts moeten voor gebruik worden gedownload, waardoor tekst tijdens het laden tijdelijk verborgen is.

"Ensure text remains visible during webfont load" in het kort
Webfonts zijn lettertypen die standaard niet beschikbaar zijn in een webbrowser. Dit betekent dat webfonts gedownload moeten worden voordat ze gebruikt kunnen worden. Tijdens het downloaden van een webfont is de tekst op een webpagina tijdelijk verborgen totdat de webfont geladen is.
Hierdoor lijkt het alsof de pagina veel langzamer laadt, omdat de pagina niet "klaar" is met laden voor bezoekers. Dit kan leiden tot een verminderde gebruikerservaring. Wanneer je een Lighthouse-analyse op je pagina uitvoert, verschijnt er een waarschuwing over de laadprestaties van de pagina: "Ensure text remains visible during webfont load".
Los dit op door de font-display waarde te wijzigen of door een font loader te gebruiken. Ik leg in dit artikel uit hoe dit werkt.
Laatst beoordeeld door Arjen Karel in februari 2026

Zorg ervoor dat de tekst zichtbaar blijft tijdens het laden van webfonts
Voordat webfonts bestonden, zaten webdesigners vast aan een klein aantal voorgeïnstalleerde lettertypen. Webfonts geven je de vrijheid om elk lettertype op een website te gebruiken.
Dat klinkt natuurlijk mooi, maar webfonts hebben ook hun nadelen; ze vertragen de laadsnelheid van de pagina op verschillende manieren.
Webfonts zijn meestal grote bestanden die niet standaard op een computer zijn geïnstalleerd. Webfonts moeten dus gedownload worden voordat ze gebruikt kunnen worden. Tijdens het downloaden van een webfont wordt de tekst op een webpagina tijdelijk verborgen totdat de webfont volledig is geladen. Dit zorgt voor een slechte gebruikerservaring; niemand wil te lang naar een leeg scherm staren.
Zodra de webfont is geladen en weergegeven, vervangt de browser de "onzichtbare tekst" door de uiteindelijke tekst met de nieuwe webfont. Dit moment wordt de Flash of Invisible Text (FOIT) genoemd. Deze FOIT veroorzaakt de foutmelding "Ensure text remains visible during webfont load".

Laad je een webfont op je pagina en neem je geen voorzorgsmaatregelen om deze Flash of Invisible Text te voorkomen? Tijdens je PageSpeed analyse in Lighthouse zal de volgende melding verschijnen: "Ensure text remains visible during webfont load". Dit vertelt je hoeveel tijd je zou kunnen besparen door de tekst zichtbaar te maken voordat de webfont geladen is. Voor 1 enkel lettertype is dit al snel 100ms.
Waarom is onzichtbare tekst slecht voor de pagespeed?
Onzichtbare tekst zal de uiteindelijk gemeten laadtijd van een pagina niet echt vertragen. Dus waarom vindt Lighthouse het dan zo'n probleem?
Google vindt het belangrijk dat een webpagina de best mogelijke gebruikerservaring biedt. De gebruikerservaring kan worden verbeterd door content op de pagina zo snel mogelijk te tonen. Onzichtbare tekst heeft direct invloed op je First Contentful Paint (FCP) omdat de browser tekst die verborgen is niet kan renderen. Als tekst je Largest Contentful Paint (LCP) element is, vertraagt FOIT ook die metric. Vergelijk de twee filmstripversies van onze homepage hieronder:
Flash of Invisible Text
Geen flash of invisible text met display:swap
Zoals je kunt zien, waren de twee pagina's op exact hetzelfde moment klaar met laden. Toch ziet de nieuwste versie van de website er voor bezoekers een stuk beter uit. Bezoekers kunnen direct beginnen met lezen.
Daarom is het slim om toch tekst te tonen, niet in het uiteindelijke lettertype, maar in een "fallback" lettertype. Op deze manier denkt de bezoeker dat je pagina echt razendsnel laadt.
Een korte herinnering: FOIT en FOUT
Voordat we verder gaan, is het nuttig om de volgende concepten te onderscheiden: FOIT en FOUT. FOIT staat voor Flash of Invisible Text en treedt op wanneer webfonts niet zichtbaar zijn tijdens het laden. Je kunt dit tegengaan door een fallback lettertype toe te voegen. Wanneer het fallback lettertype wordt vervangen door de webfont, wordt dit FOUT, Flash of Unstyled Text, genoemd.
Maak webfonts zichtbaar tijdens het laden
Er zijn twee manieren om webfonts zichtbaar te maken tijdens het laden: ten eerste via de CSS font-display waarde; ten tweede door gebruik te maken van een fallback lettertype via een class. Beide methoden hebben voor- en nadelen, die ik hieronder zal bespreken.
Methode 1: Font-display:swap
Font-display is een CSS-descriptor die beschikbaar is voor alle moderne browsers. De font-display descriptor bepaalt hoe een lettertype wordt weergegeven op basis van of en wanneer het is gedownload. Font-display wordt gebruikt in een @font-face regel.
Er zijn vier font-display waarden die je moet kennen:
- swap: Toont onmiddellijk het fallback lettertype en wisselt vervolgens naar de webfont wanneer deze geladen is. Het swap-venster is oneindig, dus de webfont vervangt altijd de fallback uiteindelijk. Het beste voor merklettertypen en koppen.
- optional: Toont onmiddellijk het fallback lettertype. De browser beslist of er gewisseld wordt op basis van de verbindingssnelheid. Niet wisselen betekent nul layout shift. Het beste voor bodytekst waarbij prestaties prioriteit hebben.
- fallback: Toont onmiddellijk het fallback lettertype en geeft de webfont een kort venster (~3 seconden) om te laden. Als het dit venster mist, blijft de fallback. Een middenweg tussen swap en optional.
- block: Verbergt tekst tot 3 seconden terwijl het lettertype laadt. Dit is de oorzaak van FOIT. Gebruik dit niet tenzij je een specifieke reden hebt (zoals icon fonts).
Volgens de 2025 Web Almanac gebruikt slechts 50% van de sites font-display: swap, terwijl 25% nog steeds block gebruikt. Dat betekent dat een kwart van het web nog steeds onzichtbare tekst toont tijdens het laden van fonts.
Gebruik de swap waarde om FOIT te voorkomen en de tekst zo snel mogelijk op het scherm te laten verschijnen. Zodra we de font-display: swap waarde in de @font-face regel instellen, worden de standaard lettertypen van het systeem gebruikt terwijl de pagina laadt totdat de webfonts zijn geladen. Dit helpt de bezoeker om de tekst op de pagina onmiddellijk te lezen.
Google Fonts
Bij gebruik van Google Fonts kun je de font-display: swap methode toepassen met een simpele "&display=swap" in de stylesheet of embed-code.
<!-- via een externe stylesheet --> <link href="https://fonts.googleapis.com/css?family=Open+Sans&display=swap" rel="stylesheet">
<!-- via de import methode (langzamer, niet aanbevolen) -->
<style>
@import url('https://fonts.googleapis.com/css?family=Open+Sans&display=swap');
</style>
De @import methode blokkeert de rendering en dwingt de browser om stylesheets opeenvolgend te downloaden. De <link> methode is sneller omdat de browser de font stylesheet eerder in het parse-proces kan ontdekken.
Maar we zijn geen fan van beide aanpakken. Het is bijna altijd veel sneller om webfonts zelf te hosten. Het geeft je meer controle over het "preloading" proces van de fonts. Je kunt de reeds bestaande HTTP/2 verbinding gebruiken en je hoeft geen extra stylesheet te downloaden.
Lokale lettertypen
@font-face {
font-family: "Open Sans";
font-weight: 400;
font-style: normal;
src: url("OpenSans400.woff2") format("woff2");
font-display: swap
}
WOFF2 is alles wat je nodig hebt. Het wordt ondersteund in elke moderne browser en biedt de beste compressie. Volgens de 2025 Web Almanac host 72% van de sites nu zelf hun fonts, en is WOFF2 goed voor 65% van alle web font verzoeken. Er is geen enkele reden meer om WOFF of TTF als fallback formaten op te nemen.
Voorkom layout shift bij het wisselen van fonts
Er is een nadeel aan font-display: swap. Wanneer de browser wisselt van de fallback font naar de webfont, verandert de tekst vaak van grootte. Verschillende lettertypen hebben verschillende tekenbreedtes, ascent hoogtes en regelafstanden. Deze verandering in grootte veroorzaakt Cumulative Layout Shift (CLS), wat een Core Web Vital is.
De oplossing is de size-adjust CSS-descriptor. Het schaalt de fallback font zodat de afmetingen overeenkomen met die van je webfont, waardoor de wissel weinig tot geen zichtbare verschuiving veroorzaakt. Browserondersteuning is meer dan 93%, inclusief Safari 17+.
/* Definieer een gematchte fallback font */
@font-face {
font-family: "Open Sans Fallback";
src: local("Arial");
size-adjust: 105%;
ascent-override: 110%;
descent-override: 25%;
line-gap-override: 0%;
}
/* Gebruik beide in je font stack */
body {
font-family: "Open Sans", "Open Sans Fallback", sans-serif;
}
De ascent-override, descent-override en line-gap-override descriptors geven nog preciezere controle over de verticale statistieken. Deze werken in Chrome, Firefox en Edge maar nog niet in Safari, dus behandel ze als progressive enhancement. De size-adjust eigenschap alleen al maakt een merkbaar verschil.
Op sites die worden gemonitord door CoreDash, hebben pagina's die font-display: swap combineren met font metric overrides [CD:placeholder]% minder font-gerelateerde CLS dan pagina's die alleen swap gebruiken.
Methode 2: Fonts met een class
De tweede manier om fonts zichtbaar te maken tijdens het laden is om met classes te werken. Deze classes worden meestal (maar niet altijd) toegevoegd aan het <body> of <html> element.
Het voordeel van deze methode is dat je meer controle hebt over het fallback lettertype en de timing van de Flash of Unstyled Text.
Deze methode werkt als volgt: Geef in je stylesheet aan dat een pagina in eerste instantie moet worden gerenderd met een lettertype (de fallback font). Je laadt vervolgens de webfont via de JavaScript FontFace API of via preloading. Nadat deze font is geladen, voeg je een class toe aan je pagina. De class zorgt ervoor dat de webfont wordt geactiveerd.
Waarom zou je dat doen, vraag je je misschien af? Je doet dit om meer controle te krijgen over de fallback font. Je kunt de fallback font weergeven met een grotere regelafstand of een andere grootte zodat deze beter overeenkomt met de webfont. Dit voorkomt layout shifts.
Bij het gebruik van meerdere webfonts kun je de FontFace API methode gebruiken om alle fonts tegelijkertijd om te wisselen. Dit bespaart veel browser repaints. Persoonlijk ben ik geen fan van deze methode; dit zorgt ervoor dat FOUT plaatsvindt nadat de laatste font is geladen. Dus dat is altijd later dan nodig.
Font met een class via de FontFace API:
<style>
// fallback font with a .9rem font-size
html{
font-family: sans-serif;
font-size:.9rem;
}
// webfont with a 1rem font-size
html.fl{
font-family: 'webfont';
font-size:1rem;
}
</style>
<script>
var font = new FontFace("webfont", "url(/font.woff2)", {
style: 'normal', unicodeRange: 'U+000-5FF', weight: '400'
});
// don't wait for the render tree, initiate an immediate fetch!
font.load().then(function() {
document.fonts.add(font);
document.documentElement.classList.add("fl")
});
</script>
Via een preload link
De tweede methode is via een preload link. Preload het lettertype zoals hieronder beschreven. Zodra dit klaar is, wissel je de class van het <html> element om.
<link
rel="preload"
href="/webfont.woff2"
as="font"
type="font/woff2" crossorigin
onload="document.documentElement.classList.add('fl')">
<style>
// fallback font with a .9rem font-size
html{
font-family: sans-serif;
font-size:.9rem;
}
// webfont with a 1rem font-size
html.fl{
font-family: 'webfont';
font-size:1rem;
}
// @font-face, only activated once the .fl class is added to the html tag
@font-face{
font-family:'Open Sans';
font-style:normal;
font-weight:400;
font-display:swap;
src: url(/webfont.woff2) format("woff2");
unicode-range:U+000-00FF;
}
</style>
Extra tips en trucs
- Preload altijd zichtbare lettertypen. Lettertypen worden standaard pas gedownload als ze daadwerkelijk op een pagina worden gebruikt. Als je een webfont nodig hebt, preload deze dan zodat hij eerder beschikbaar is.
- Wil je FOIT en FOUT volledig vermijden? Gebruik font-display: optional in combinatie met preloading.
- Zelf webfonts hosten is altijd sneller dan webfonts via Google Fonts of een ander extern CDN.
Wil je verifiëren dat je font loading strategie daadwerkelijk de echte gebruikerservaring verbetert? Gebruik Real User Monitoring om je FCP en CLS te tracken voor en nadat je wijzigingen hebt aangebracht.
Ask AI why your INP spiked.
CoreDash is the only RUM tool with MCP support. Connect it to your AI agent and query your Core Web Vitals data in natural language. No more clicking through dashboards.
See How It Works
