Font display in Lighthouse: wat het markeert en hoe je het fixt

Schaadt de font-display-waarschuwing je score?

Lighthouse markeert elk webfont dat laadt met font-display: block, auto of fallback in het Font display-inzicht ("Consider setting font-display to swap or optional"), vóór Lighthouse 13 "Ensure text remains visible during webfont load" genoemd. Het weegt niet mee in je score, maar is een kop je LCP-element, dan maakt het verbergen ervan LCP op mobiel te laat. Zet swap op de fonts die bezoekers als eerste zien en match de fallback met metric overrides.

Wat controleert het Font display-inzicht?

In Lighthouse 13 en PageSpeed Insights luidt het inzicht: "Consider setting font-display to swap or optional to ensure text is consistently visible. swap can be further optimized to mitigate layout shifts with font metric overrides." Vóór Lighthouse 13 heette de audit "Ensure text remains visible during webfont load".

Lighthouse leest Chrome's eigen trace van de page load uit. Voor elk webfont dat de pagina begint te downloaden, registreert de trace de font-display-waarde die Chrome gebruikte. Het inzicht markeert drie waarden:

• block: de tekst blijft tot 3 seconden onzichtbaar terwijl het font downloadt.
• auto: helemaal geen waarde. Google Fonts stuurt dit mee zonder &display=, en oudere thema's, Font Awesome 4 en Material Icons hebben dit.
• fallback: de tekst is slechts 100 ms onzichtbaar. Lighthouse 13 markeert het toch.

Slechts twee waarden slagen: swap en optional. Dat veranderde met Lighthouse 13. De oude audit keurde block en fallback goed, dus een site die dit jaren geleden "fixte" met fallback krijgt de melding opnieuw. WordPress-block-thema's gebruiken standaard fallback, en Font Awesome 5 en 6 gebruiken block.

"Est savings" is de tijd die het font-request kostte in de trace, gemaximeerd op 3.000 ms. PageSpeed Insights neemt die trace op zonder throttling, dus daar zie je vaak een laag getal. Het rapport hieronder komt van een testpagina, een productpagina van een outdoorwinkel met een condensed headline-font, op een telefoon met DevTools-throttling (Slow 4G). Daar duurde het body-font meer dan 3 seconden, en de tabel toont het maximum. Hoe dan ook win je die tijd niet terug: met fallback verbergt een font tekst maximaal 100 ms, en bij auto stopt Chrome 2 seconden na het starten van de navigatie met wachten.

Naast de beschrijving toont Lighthouse twee labels. FCP is de metric waarop je volgens Lighthouse bespaart. Unscored betekent gewicht 0: het inzicht zelf verandert nooit iets aan je score. Een block-font duikt in je score op via Speed Index en LCP.

Een @font-face-regel die niemand gebruikt, triggert het nooit. En doordat Lighthouse de trace leest, toont het nu ook fonts die je niet zelf hebt toegevoegd, zoals een Typekit-kit of het Google Fonts-bestand van een plugin. De oude audit toonde "unable to check" voor fonts van andere domeinen.

Wat gebeurt er in de browser terwijl een webfont laadt?

De browser kan een font pas opvragen als hij weet dat een zichtbaar element het nodig heeft. Hij heeft de HTML nodig, dan de CSS, en dan een stijlberekening die zegt: "deze kop gebruikt Barlow Condensed". Pas dan start het font-request. Op een gethrottlede telefoon was dat op 0,74 s, nadat de HTML en de CSS binnen waren. Een font wordt altijd pas laat ontdekt. Een preload haalt die start alleen naar voren: fonts krijgen van zichzelf al de hoogste prioriteit.

Vanaf dat moment bepaalt de font-display-waarde wat de bezoeker ziet. Dit zijn de timings in de broncode van de browser:

Safari en Firefox verbergen tekst bij block en auto eveneens tot 3 s. Is 75% van het font al binnen, dan wacht Firefox 1,5 s langer. Beide verbergen tekst 100 ms bij fallback en optional, en Firefox doet hetzelfde bij swap.

In Chrome is block trager dan auto: auto heeft de limiet van 2 seconden en block niet. En optional heeft in Chrome geen respijtperiode van 100 ms. Zonder preload haalt het font de eerste render vrijwel nooit, zelfs niet vanaf een snelle server. Met een preload kan het wel, als het font binnen zo'n 100 ms arriveert van het moment dat de pagina kon renderen. Uit de cache op de volgende pagina lukt het wel.

De productpagina bij de first paint, 0,9 s op een gethrottlede telefoon. Het donkere vlak is de foto, die in beide nog laadt. Testpagina op corewebvitals.io, Chrome 155, telefoon 412 px breed, Slow 4G en 4x CPU-slowdown.

Met block toont de first paint de header, de breadcrumbs en de sterbeoordeling, en een leeg vlak waar de productnaam hoort. Het headline-font is klein (15 kB) en arriveert op 1,7 s. Het body-font is 344 kB en downloadt nog wanneer Chrome op 3,7 s stopt met wachten, dus tot die tijd staat er niets onder de foto. Met swap zijn de productnaam en de beschrijving vanaf de first paint leesbaar.

Dezelfde pagina op 3 s: het headline-font en de foto zijn binnen, het body-font nog niet.

Heeft font-display invloed op LCP, CLS en FCP?

LCP

Onzichtbare tekst kan niet het LCP-element zijn. Bij block of auto wordt een tekst-LCP pas gerapporteerd zodra de tekst zichtbaar wordt: wanneer het font binnenkomt, of wanneer de block-periode afloopt. Op een pagina waar het LCP-element een kop of een alinea is, kan block tot 3 seconden aan LCP toevoegen. Chrome voegt bij auto minder toe, en op Slow 4G toonde het die tekst zelfs direct in Arial. Bij swap is de LCP de paint in het fallback-font, en de overgang naar het webfont voegt geen nieuw LCP-item toe, zelfs niet als de tekst in het webfont groter is.

Op de productpagina hierboven is de foto in elke versie het LCP-element, dus font-display veranderde daar niets aan LCP. Dat is het eerste wat je op je eigen pagina's moet checken: is het LCP-element tekst of een afbeelding? Het LCP breakdown-inzicht in hetzelfde Lighthouse-rapport noemt dit.

CLS

Elke swap die verandert hoeveel ruimte de tekst inneemt, verschuift alles wat eronder staat. Dat gebeurt bij block en auto evengoed: onzichtbare tekst neemt de ruimte in van het fallback-font, en de swap naar het webfont geeft dezelfde sprong. De block-, auto- en swap-versies scoorden allemaal een CLS van 0,031, op het moment dat het headline-font binnenkwam.

Met gewone swap gaat de kop van drie regels naar twee zodra Barlow Condensed op 1,7 s binnenkomt. Alles daaronder schuift 39 px omhoog: CLS 0,031. De stippellijn geeft aan waar de foto eerst stond.

Dezelfde pagina met een fallback-face die Arial Bold schaalt naar de breedte van Barlow (size-adjust: 68.32%). De kop beslaat vanaf de first paint twee regels en niets verschuift: CLS 0.

Swap slaagt dus voor het Font display-inzicht, maar behoudt de layout shift. 0,031 ligt onder de 0,1, maar op een echte productpagina kan een tweede font dat later binnenkomt, een prijs in een ander font of een sticky bar flink optellen. Metric overrides op de fallback stoppen die shift.

Lighthouse wijst je niet op het font. Bij de swap-versie geeft Layout shift culprits de schuld aan de foto, als een "Unsized image element". Terwijl die gewoon een width en een height heeft. Wat hem verschoof was het headline-font, dat exact op dat moment binnenkwam. Leg het tijdstip van een shift naast je font-requests voordat je gaat zoeken naar afmetingen die er al lang staan.

FCP

Lighthouse rapporteert de besparing als FCP. Op de meeste pagina's bepaalt iets anders de FCP: op de productpagina staan de header en de verzendbalk in een systeemfont en die tonen op 0,8 s, zowel met block als met swap. In mijn eigen test met uitsluitend webfont-tekst op de pagina rapporteerde Chrome 155 nog steeds FCP op 112 ms terwijl de tekst onzichtbaar was. Chrome beschouwt de tekst als gepaint; het slaat alleen het tekenen van de glyphs over. De tijd die Lighthouse toont als FCP-besparing ga je in je FCP dan ook niet terugzien. Wat je met block wél verliest, is de LCP van een tekstelement, Speed Index en wat de bezoeker ziet.

Hoeveel sites krijgen de melding, en wanneer kun je hem negeren?

State of CWV meet de @font-face-regels op de homepages van 170.706 sites die webfonts declareren. Laadt het font, dan triggert de helft van die regels het inzicht: 39,7% heeft geen waarde (auto), 9,6% gebruikt block en 0,9% fallback. Slechts 471 sites gebruiken ergens de waarde optional.

Sites met een goede LCP op telefoons, gegroepeerd op het aantal font-bestanden dat de homepage laadt en op de font-display-waarden in de @font-face-regels. State of CWV, oktober 2026: 170.706 sites die webfonts declareren, CrUX p75 op telefoons, een goede LCP is 2,5 s of minder.

Bij één of twee font-bestanden maakt het vrijwel geen verschil: 88% van de sites met uitsluitend swap of optional heeft een goede LCP op telefoons, tegenover 87% van de sites met alleen block, auto of fallback. Bij zes tot tien font-bestanden is het verschil 6 procentpunt, bij elf of meer is dat 9. De sites die beide soorten combineren doen het het slechtst. Die declareren veel meer fonts – mediaan 44 @font-face-regels tegenover 18 – wat duidt op een thema-font plus een plugin-font plus een icon font. CLS verschilt nauwelijks tussen de groepen.

Dat is een correlatie. Sites die goed voor hun fonts zorgen, letten meestal ook op al het andere. Tel daar het browsergedrag hierboven bij op en mijn vuistregel is: schrap eerst font-bestanden, stel daarna font-display in.

Je kunt de melding laten voor wat hij is als:

• het font alleen tekst below the fold rendert, zoals de footer of de reviews;
• je LCP-element een afbeelding is en het font geen shift veroorzaakt.

Hoe zie je font-problemen in je field data?

Lighthouse geeft je één load op één gesimuleerde telefoon. Je bezoekers hebben alle mogelijke verbindingen, en een terugkerende bezoeker heeft het font in de cache. In CoreDash laten twee breakdowns zien of fonts je iets kosten.

• LCP by element. Is het LCP-element op mobiel een kop of een alinea, dan vertraagt een font op block of auto dit bij elk bezoek dat op het font moet wachten. Is het een afbeelding, dan raakt het font je LCP niet.
• CLS by element. Een font-swap verschuift wat eronder staat: de foto, de volgende sectie, de koopknop. CoreDash noemt het element dat verschoof. Het zegt er niet bij dat een font de oorzaak was: staat het verschoven element direct onder een kop of alinea en heeft het een width en height, dan is een font-swap de waarschijnlijke oorzaak.

CrUX geeft je dezelfde metrics op p75 voor je origin of een URL over de afgelopen 28 dagen, zonder die attributie.

LCP by element

CLS by element

CoreDash op een voorbeeldwinkel, acme-pagespeed.com, mobiel, p75. De producttitel is bij meer sessies het LCP-element dan enig ander element, met een LCP van 3,28 s. Is de productfoto het LCP-element, dan is LCP 2,21 s. In de CLS-tabel staat die foto, vlak onder de titel, op de bovenste rij: 0,07 over 1.214 sessies. Nog steeds als good beoordeeld, maar geen enkel ander element verschuift bij zoveel sessies.

Hoe vind je het gemarkeerde font in DevTools?

Open de pagina in Chrome, ga naar het Performance-paneel, zet het netwerk op Slow 4G en de CPU op 4x slowdown, en neem een reload op. De Insights-zijbalk toont Font display met elk gemarkeerd font. Klik erop en DevTools omlijnt de font-requests in de Network-track.

Kijk vervolgens waar elk font-request eindigt, waar de LCP-marker staat en of de Layout shifts-track direct na afloop van een font een shift vertoont.

Wil je elke @font-face vinden die naar een gemarkeerd bestand verwijst, open dan Sources, zoek in alle bestanden (Ctrl+Shift+F, Cmd+Option+F op een Mac) naar de bestandsnaam en stel de waarde in bij elke regel die je tegenkomt.

Hoe los je het Font display-inzicht op?

De font-URL in de Lighthouse-tabel verraadt waar het font vandaan komt, en dat bepaalt waar – of dat – je font-display kunt instellen.

Je eigen @font-face

Een font op je eigen domein zonder /wp-content/, /cdn/fonts/ of /_next/ in de URL is afkomstig uit je eigen CSS. Voeg font-display: swap toe aan elke @font-face-regel voor dat font, inclusief de kopieën in een tweede stylesheet. Uitzondering hierop is een icon font, zie hieronder.

@font-face {
  font-family: "Barlow Condensed";
  src: url(/fonts/barlow-condensed-700.woff2) format("woff2");
  font-weight: 700;
  font-display: swap;
}

Google Fonts

De tabel toont fonts.gstatic.com, maar de instelling hoort thuis in de fonts.googleapis.com/css2-link die het font laadt. Voeg daar &display=swap aan toe:

<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Barlow+Condensed:wght@700&display=swap">

Nog sneller is om het font zelf te hosten: geen extra verbinding, en je hebt zelf de controle over de preload.

Adobe Fonts

Fonts op use.typekit.net halen hun font-display uit het webproject op fonts.adobe.com: kies Edit Project en stel het in via de zijbalk. De standaard van Adobe is auto, en een parameter in de URL doet niets.

WordPress

Thema-fonts hebben /wp-content/themes/ in hun URL. In een block-thema stel je fontDisplay per font face in via theme.json:

"fontFace": [{
  "fontFamily": "Barlow Condensed",
  "fontWeight": "700",
  "fontStyle": "normal",
  "fontDisplay": "swap",
  "src": ["file:./assets/fonts/barlow-condensed-700.woff2"]
}]

In een klassiek thema voeg je &display=swap toe aan de Google Fonts-URL in wp_enqueue_style, of zet je font-display in de eigen @font-face-regels van het thema. Fonts onder /wp-content/plugins/ horen bij een plugin of pagebuilder: zoek daar eerst naar een font-instelling. Voor Google Fonts die een pagebuilder laadt: bij Elementor staat de instelling onder Elementor, Editor, Settings op het tabblad Advanced: Google Fonts Load. OMGF host Google Fonts lokaal en kan swap afdwingen. De WordPress-guide behandelt de rest van het font- en CSS-werk.

Shopify

Shopify-themafonts hebben /cdn/fonts/ in hun URL, op het domein van je shop. Ze worden ingeladen via het font_face-filter in theme.liquid, en zonder font_display schrijft dat geen font-display weg:

{{ settings.type_header_font | font_face: font_display: 'swap' }}

Dawn stelt dit standaard al in.

Next.js

next/font gebruikt standaard display: 'swap', preloadt het font en maakt een fallback aan met metric overrides (adjustFontFallback). De bijbehorende fonts hebben /_next/static/media/ in hun URL. Heeft een gemarkeerd font dat pad, dan kreeg het in de next/font-call een andere waarde mee (display: 'block'): pas het daar aan. Een gemarkeerd font zonder dat pad is op een andere manier geladen: een <link> naar Google Fonts in de layout, of een CSS-bestand uit een component library.

Fonts die je niet kunt of moet aanpassen

• Een icon font (fa-solid-900.woff2, bootstrap-icons.woff2, eicons.woff2): met swap toont het letters of lege blokjes op de plek van de iconen. Vervang icon fonts door SVG waar dat kan, en laat ze anders op block staan.
• Een plugin of app zonder font-instelling (een WordPress-plugin, een font toegevoegd door een Shopify-app): vraag de developer om swap in te stellen.
• Een third-party script dat een font aan je pagina toevoegt (het domein van de leverancier): heb je niet in de hand. Laad het script pas nadat de pagina gerenderd is, of negeer de regel.

Laad minder font-bestanden

Schrap de gewichten en styles die je niet gebruikt, en gebruik één variable font in plaats van zes statische bestanden. Elk font-bestand dat je verwijdert, scheelt een request, een swap en een regel in dit inzicht.

swap of optional: welke kies je?

Gebruik swap voor de fonts die de merkidentiteit bepalen, zoals de kop en het logo, met een afgestemde fallback. Gebruik optional voor body-tekst als het systeemfont ook prima volstaat, en preload dat font zodat het op de eerste pagina een kans maakt:

<link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin>
<style>
@font-face {
  font-family: "Inter";
  src: url(/fonts/inter-var.woff2) format("woff2");
  font-weight: 100 900;
  font-display: optional;
}
</style>

Het attribuut crossorigin is verplicht, zelfs voor een font op je eigen domein: zonder dat attribuut downloadt de browser het font twee keer. Een font-preload kan in Chrome de eerste render tot 100 ms tegenhouden; preload daarom één of twee fonts, nooit allemaal. Op Slow 4G kwamen de gepreloade fonts alsnog pas na de first paint binnen, waardoor de pagina de fallback behield.

Stop de layout shift met metric overrides

Geef het fallback-font dezelfde afmetingen als het webfont. Dat doe je met een tweede @font-face die naar een lokaal font verwijst en dit schaalt:

@font-face {
  font-family: "Barlow Fallback Arial";
  src: local("Arial Bold"), local("Arial-BoldMT");
  font-weight: 700;
  size-adjust: 68.32%;
  ascent-override: 146.37%;
  descent-override: 29.27%;
  line-gap-override: 0%;
}
h1 {
  font-family: "Barlow Condensed", "Barlow Fallback Arial", Arial, sans-serif;
}

size-adjust is de breedte van je tekst in het webfont gedeeld door de breedte in de fallback. ascent-override en descent-override zijn de eigen ascent en descent van het webfont, gedeeld door diezelfde size-adjust. Tools als Fontaine en Capsize berekenen ze direct vanuit de font-bestanden.

Hetzelfde geldt voor het body-font, en daar meet je op je eigen tekst, op mobiele breedte en op de font-size die je gebruikt. Inter verandert van breedte afhankelijk van de lettergrootte: van zo'n 98% van Arial bij koppen tot circa 105% op 18 px. Een size-adjust van 97,6% liet de productbeschrijving in de fallback over vijf regels lopen tegenover zes in Inter, waardoor de koopknop alsnog verschoof. Bij 101% breken beide identiek af. Om dit te controleren blokkeer je het font-bestand in DevTools (Network, rechtermuisklik, Block request URL), reload je op mobiele breedte en vergelijk je de regeleindes met een normale load. Pas size-adjust aan tot ze matchen.

local() vindt alleen fonts die op het apparaat zijn geïnstalleerd: Arial staat op Windows, macOS en iPhones, Android-telefoons hebben Roboto. Voeg voor Android-bezoekers een tweede fallback-face toe voor Roboto met eigen waarden:

h1 {
  font-family: "Barlow Condensed", "Barlow Fallback Arial", "Barlow Fallback Roboto", sans-serif;
}

local() slaat een face over waarvan het font niet geïnstalleerd is, dus elk apparaat pakt het eerste beschikbare font. Safari ondersteunt wel size-adjust, maar nog geen ascent- en descent-overrides. De breedte klopt daar dus, maar met line-height: normal kan de regelhoogte iets afwijken. WordPress en Shopify hebben voor dit alles geen instelling. Hier is een developer voor nodig.

Hoe controleer je of de fix gewerkt heeft?

Draai Lighthouse opnieuw op mobiel: Font display verhuist naar de geslaagde inzichten. Op de productpagina ging de score van 97 naar 98, puur door de meewegende metrics: Speed Index van 1,9 s naar 1,3 s doordat de tekst eerder zichtbaar is, en CLS van 0,031 naar 0 dankzij de overrides. Kijk daarna naar CLS in je eigen rapport: verschuift de pagina nog steeds als een font binnenkomt, dan heeft de fallback metric overrides nodig.

Lighthouse 13.5.0, mobiel, DevTools-throttling.

Kies je voor optional, dan toont het Lighthouse-screenshot meestal het fallback-font. Lighthouse laadt de pagina koud, en dat is precies hoe optional hoort te werken.

CoreDash toont het effect per apparaat vanaf het eerstvolgende bezoek. CrUX en Search Console tonen de afgelopen 28 dagen, dus twee weken na de fix bestaat de helft van wat ze laten zien nog uit de oude site.

Wil je weten of een font jouw mobiele LCP of CLS in het rood houdt? In een Core Web Vitals power hour duiken we samen in je field data en een trace van je pagina, en weet je na afloop precies welke font-regel je in je thema moet aanpassen.