First Contentful Paint (FCP): Wat het is, hoe je het meet en oplost

First Contentful Paint oplossen

De First Contentful Paint (FCP) is het moment waarop een browser het eerste betekenisvolle element op een pagina tekent dat de bezoeker kan zien. Met andere woorden, het is het moment waarop een browser voor het eerst iets op het scherm rendert. Daarom is de FCP een goede manier om de waargenomen laadsnelheid te meten.

Je kunt de FCP verbeteren door ervoor te zorgen dat een browser zonder vertraging kan beginnen met renderen. Hieronder leer je wat de FCP is, hoe je deze meet en ontdek je 15 bewezen technieken om hem sneller te maken.

Wat is de First Contentful Paint (FCP)?

De First Contentful Paint (FCP) is een manier om de laadsnelheid van een pagina te meten. Je kunt laadsnelheid niet samenvatten als een enkel moment in de tijd. Er zijn eigenlijk meerdere momenten tijdens het laadproces waarop een bezoeker de site als snel of traag ladend kan ervaren. De FCP meet het tijdsverschil tussen het opvragen van de pagina en het moment waarop de eerste betekenisvolle content voor het eerst op het scherm wordt gerenderd.

Wat vertelt je dat precies? Het vertelt je dat de FCP in de eerste plaats een "gebruikersgerichte metriek" is, omdat het iets zegt over de laadsnelheid die een bezoeker ervaart. Het zegt iets over de gebruikerservaring. Op het FCP-moment weet je zeker dat een bezoeker daadwerkelijk "iets" op het scherm ziet.

Laten we de woorden opsplitsen: 'First', 'Contentful' en 'Paint'.

1. First: Met First bedoelen we uiteraard het eerste exacte moment dat er iets substantieels in je browser verschijnt.
2. Contentful: Met Contentful bedoelen we een HTML-element met content. Dus geen lay-outelement zoals een leeg element of een achtergrondkleur, maar bijvoorbeeld tekst, een afbeelding (inclusief achtergrondafbeelding), SVG of canvas.
3. Paint: Paint betekent (min of meer) dat de browser klaar is om iets op het scherm te zetten. Dit lijkt eenvoudig, maar het is eigenlijk de meest complexe taak van de browser. Om iets op het scherm te zetten, moet een browser klaar zijn om alle eigenschappen van een element te berekenen. Hieronder vind je een voorbeeld van het renderproces dat nodig is voordat er iets aan het scherm kan worden toegevoegd.

FCP vs LCP: Wat is het verschil?

FCP en LCP (Largest Contentful Paint) meten beide de laadprestaties, maar ze leggen verschillende momenten in de tijdlijn van het laden van de pagina vast. Het begrijpen van het verschil helpt je om je optimalisatiewerk correct te prioriteren.

In de praktijk vuurt de FCP vaak ruim voor de LCP. Een pagina kan bijvoorbeeld binnen 400ms een kop renderen (FCP), maar nog eens 2 seconden wachten totdat de hero-afbeelding is geladen (LCP). Als je FCP traag is, zal je LCP vrijwel zeker ook traag zijn, omdat FCP het allereerste knelpunt in de renderpijplijn vastlegt. Lees meer in onze complete LCP-gids.

Wat is een goede First Contentful Paint score?

Een goede FCP-score is alles onder 1,8 seconden. Als je FCP-score tussen de 1,8 en 3 seconden ligt, heeft deze verbetering nodig. Een FCP-score boven de 3 seconden wordt als slecht beschouwd. Om te voldoen aan de aanbevolen drempelwaarde voor de First Contentful Paint, moet ten minste 75% van je bezoekers een "goede" FCP-score hebben.

Zoals altijd bij performancemetrieken is een snellere First Contentful Paint score beter dan een langzamere.

Hoe meet je je First Contentful Paint (FCP)?

De FCP wordt door Google gemeten door data van echte gebruikers te verzamelen. Deze data wordt opgeslagen in de CrUX-dataset. Deze data is openbaar beschikbaar via de CrUX API of Google BigQuery. De FCP kan ook worden gemeten met behulp van zogenaamde lab tests. De bekendste lab test is Lighthouse.

De First Contentful Paint ophalen uit de CrUX-dataset

De First Contentful Paint kan worden uitgelezen uit de CrUX-dataset via pagespeed.web.dev, de CrUX API of via Google BigQuery.

De First Contentful Paint meten via Real User Monitoring (RUM)

RUM Tracking staat voor Real User Monitoring. Met Real User Monitoring (RUM) kun je de First Contentful Paint volgen via echte interacties van de gebruiker. Het voordeel van RUM Tracking is dat je geen 28 dagen hoeft te wachten op actuele data en dat de data veel gedetailleerder kan worden opgevraagd en geanalyseerd.

De FCP meten in Lighthouse

1. Open de pagina (in Chrome) waarvan je de FCP wilt meten. Zorg ervoor dat je dit incognito doet, zodat plugins niet interfereren en de FCP van je pagina mogelijk vertragen.
2. Klik met de rechtermuisknop op de pagina en selecteer Inspecteren. Hiermee open je de Chrome developer console.
3. Bovenaan de console zie je het tabblad Lighthouse. Klik hierop. Kies vervolgens onder Categorieën voor Performance (laat de rest leeg) en kies Mobile onder Apparaat.
4. Klik nu op Generate Report. Lighthouse maakt een snelheidsrapportage van je pagina aan. Links bovenaan in het rapport zie je wat de FCP van je pagina is.

Dit is een screenshot van het Lighthouse-rapport voor deze pagina. De FCP van deze pagina op een mobiel apparaat is 0,8 seconden! Niet slecht, toch?

FCP meten met een online tool

Je kunt de FCP ook meten met een aantal online tools. De bekendste zijn GTMetrix, Pingdom en pagespeed.web.dev. Deze tools zijn makkelijk in het gebruik en geven data over de FCP onder specifieke labomstandigheden.

Wat data uit de echte wereld over FCP laat zien

Data van CoreDash laat zien dat FCP de TTFB nauw volgt: de p75 FCP is 392ms in totaal, met desktop op 372ms en mobiel op 692ms (1,9x trager). De FCP naar TTFB delta is slechts 248ms op desktop en 376ms op mobiel, wat aangeeft dat render blocking tijd een relatief klein deel uitmaakt van de FCP op een goed geoptimaliseerde site.

Wereldwijd, volgens de 2025 Web Almanac, behaalt 70% van de desktoppagina's een goede FCP, terwijl slechts 55% van de mobiele pagina's dit haalt. Beide zijn verbeterd ten opzichte van 2024, waarbij mobiel 4 procentpunten is gestegen. Dit suggereert dat webontwikkelaars render blocking resources steeds meer aanpakken.

De sterke correlatie tussen FCP en TTFB betekent dat het verbeteren van je Time to First Byte vaak de meest effectieve manier is om je First Contentful Paint te verbeteren. Op deze site ligt de FCP slechts ongeveer 250ms boven de TTFB, wat betekent dat de meeste FCP-tijd wordt besteed aan het wachten op de server en niet aan render blocking werk.

De First Contentful Paint verbeteren

Tijd om de FCP sneller te maken. Het idee achter een snelle FCP is eigenlijk heel eenvoudig: ervoor zorgen dat een browser direct kan beginnen met renderen. Alles wat ervoor kan zorgen dat het renderen vertraging oploopt, zal resulteren in een slechte FCP-score.

Net als bij de Largest Contentful Paint kan de First Contentful Paint worden opgedeeld in 2 of 4 categorieën:

1. Time to First Byte (TTFB): De tijd vanaf het moment dat de browser begint met het laden van de pagina totdat deze de eerste byte van de HTML ontvangt.
2. Resource load delay: De tijd tussen TTFB en het moment waarop de browser begint met het laden van de FCP-resource.
3. Resource load time: De tijd die nodig is om de FCP-resource zelf te laden.
4. Element render delay: De tijd tussen het moment waarop de FCP-resource is geladen en het moment waarop het FCP-element volledig is gerenderd.

Snelheidstip: Je kunt stap 2 en 3 makkelijk elimineren door ervoor te zorgen dat het FCP-element geen netwerkresource nodig heeft. Bij een tekstelement kun je font-display:swap gebruiken. Bij een kleine afbeelding kun je de afbeelding inline plaatsen.

Dit laat ons alleen de Time to First Byte en de Element render delay over om te optimaliseren.

Hieronder vind je 14 oplossingen die ik vaak gebruik om de FCP te verbeteren. Maar pas op, het gebruik van een oplossing op de verkeerde plek kan juist voor vertraging zorgen. Daarom is het verstandig om een pagespeed expert te raadplegen voordat je zelf aan de slag gaat.

1. Snelle server response (TTFB)

De TTFB (de tijd tussen de request en de eerste byte die de server verstuurt) is altijd de eerste stap in het renderproces. Vanaf dat moment begint je browser te multitasken en neemt de impact van verdere optimalisaties af. De HTML-code is de enige request die direct invloed heeft op alle snelheidsmetrieken.

De snelheid waarmee de HTML-code vanaf de server wordt verzonden, wordt vaak gemeten als de Time to First Byte (TTFB). Het is belangrijk om deze zo snel mogelijk te maken. Vaak doe je dit door server side caching in te schakelen.

Als het gaat om Time to First Byte, is lager altijd beter.

Je kunt de Time to First Byte eenvoudig zelf meten. Dat doe je als volgt:

1. Gebruik de sneltoets Ctrl-Shift-I om de developer console van Google Chrome te openen.
2. Bovenaan de console zie je een Network tabblad. Klik daarop.
3. Herlaad de pagina met Ctrl-R.
4. Je ziet nu alle network requests die Chrome naar je server heeft gestuurd.
5. Klik op het bovenste network request. Dat is de request voor de pagina zelf.
6. Je krijgt nu meer informatie over dit network request. Klik bovenaan deze informatie op het tabblad Timing om te zien wat de TTFB voor jouw pagina is.

2. HTTP/3

HTTP/3 is de derde versie van het HTTP-protocol. HTTP/3 lost veel van de problemen op die zich voordeden in de oudere HTTP/1.1 en HTTP/2 protocollen. Zo kun je sinds HTTP/2 meerdere bestanden tegelijkertijd via dezelfde verbinding versturen. HTTP/3 zorgt voor een snellere initiële verbinding en minder last van kleine netwerkonderbrekingen.

Zonder te veel in detail te treden: HTTP/3 zorgt voor een aanzienlijke snelheidswinst, vooral op een trager netwerk zoals een mobiel netwerk. Je netwerkbeheerder kan je vertellen of je webserver al geschikt is voor het snellere HTTP/3 protocol.

Je kunt zelf controleren of je website al gebruikmaakt van het snellere HTTP/3 protocol. Gebruik de sneltoets Ctrl-Shift-I om de Network inspector van Google Chrome te openen. Klik met de rechtermuisknop op de tabelkop en selecteer Protocol. Herlaad nu de pagina om te zien welk protocol je site gebruikt.

3. 103 Early Hints

103 Early Hints is een vrij nieuwe HTTP status code waarmee een server voorlopige response headers kan sturen voordat de definitieve response klaar is. Dit is vooral handig wanneer je server tijd nodig heeft om de HTML te genereren (bijvoorbeeld bij het bevragen van een database of het uitvoeren van server side logica). In plaats van de browser doelloos te laten wachten, stuurt de server een 103 response met preload en preconnect hints zodat de browser direct kan beginnen met het ophalen van kritieke resources.

Dit verbetert de FCP direct, omdat de browser kan beginnen met het downloaden van lettertypen, stylesheets en andere render-kritieke resources voordat de HTML überhaupt arriveert. De impact is het grootst op pagina's met een hoge TTFB.

HTTP/1.1 103 Early Hints
Link: </static/font/outfit.woff2>; rel=preload; as=font; type=font/woff2; crossorigin
Link: </static/css/critical.css>; rel=preload; as=style

HTTP/1.1 200 OK
Content-Type: text/html
...

Nog niet alle hostingproviders ondersteunen 103 Early Hints. Cloudflare heeft ingebouwde ondersteuning voor Early Hints en Apache en Nginx kunnen worden geconfigureerd om ze te sturen. Lees meer in onze complete 103 Early Hints gids.

4. Browser Caching

De netwerkverbinding is vaak een zwakke schakel als het gaat om laadsnelheid. Zou het niet veel makkelijker zijn om het netwerk helemaal over te slaan?

Als een bezoeker al eerder op je site is geweest, kun je aangeven of en hoelang de netwerkresources (bijvoorbeeld een stylesheet) door de browser van de bezoeker bewaard mogen worden. Elke keer dat de bezoeker een van deze bestanden weer nodig heeft, verschijnen ze in een mum van tijd uit de cache van de browser. Hierdoor kan de browser veel sneller beginnen met renderen en wordt de FCP versneld.

5. Compressie

De netwerksnelheid is in vrijwel alle gevallen een zwakke schakel. Voor een goede First Contentful Paint is het essentieel dat de bestanden zo snel mogelijk via het netwerk worden verzonden. Compressie vermindert het aantal bytes dat vanaf de server verzonden moet worden. Minder bytes betekent minder wachttijd voor een netwerkresource. Compressie is naar mijn mening een techniek die niet de aandacht krijgt die het verdient. Helaas zetten te veel webmasters compressie gewoon "aan" en kijken er daarna niet meer naar om. Dat is zonde, want het is een eenvoudige manier om alles net wat sneller te maken.

Er zijn twee populaire compressietechnieken: Gzip en Brotli. Gzip is de meest gebruikte compressietechniek, maar Brotli maakt een snelle inhaalslag. Brotli is door Google zelf ontwikkeld en behaalt 15 tot 20% betere resultaten bij HTML, JavaScript of CSS bestanden. Brotli is daardoor ideaal voor het web.

Er is ook een verschil tussen dynamische compressie en statische compressie. Bij dynamische compressie comprimeer je het bestand vlak voordat je het via je webserver verstuurt. Bij statische compressie wordt het gecomprimeerde bestand op de server opgeslagen. Dit is vaak een veel slimmere manier van comprimeren, maar wordt zelden gebruikt.

6. Vroege web-fonts met resource hints

Resource hints starten een download of netwerkverbinding voordat de browser dit uit zichzelf zou doen. Sommige netwerkresources, zoals web fonts of afbeeldingen, worden pas gedownload als de browser zeker weet dat deze moeten worden weergegeven.

Als je zeker weet dat je een resource nodig hebt om het zichtbare deel van de site te renderen, is het vrijwel altijd een goed idee om een "resource hint" toe te voegen. Dit zorgt ervoor dat de browser direct begint met het downloaden of verbinden met de resource. Hierdoor is de resource sneller beschikbaar en kan de browser sneller beginnen met renderen.

Maar pas op met resource hints. Als je ze verkeerd gebruikt, kunnen ze je pagina juist vertragen.

Vroege download met "preloading"

<link rel="preload" href="/static/font/opensans600.woff2" as="font" type="font/woff2" crossorigin>

De preload link is een van de krachtigste tools in het pagespeed arsenaal. Via de preload link download je een netwerkresource die je later nodig hebt. Dit is vaak een heel goed idee voor lettertypen, kritieke scripts en afbeeldingen in het zichtbare deel van de site.

Vooraf verbinden met preconnect

De preconnect link maakt alvast verbinding met een server. Dit is handig wanneer je bestanden host op een externe server, zoals een CDN of Google Analytics.

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

Nog beter dan vooraf verbinden met Google Fonts is het zelf hosten van je Google Fonts. Dit elimineert de externe verbinding volledig en geeft je volledige controle over caching en levering.

7. De volgende pagina vooraf ophalen met prefetch

<link rel="prefetch" href="/page2.html">

Met prefetch kun je resources met een lage prioriteit ophalen. Dit is een nuttige manier om resources op te halen waarvan je denkt dat je ze later nodig zult hebben, bijvoorbeeld wanneer je verwacht dat iemand op de link naar de volgende pagina klikt.

8. Vermijd redirects

Een veelgemaakte fout is een redirectketen die te lang is. Laat me het uitleggen: je site draait waarschijnlijk via een beveiligde verbinding. Wanneer een bezoeker je site intypt zonder https toe te voegen, wordt de bezoeker naar de niet-beveiligde versie van je website gestuurd. Als alles echter goed is ingesteld, wordt de bezoeker doorgestuurd naar de beveiligde website. Dit zie je in het groene voorbeeld hieronder.

Maar soms vindt de omleiding plaats via één of meerdere tussenstappen, zoals te zien is in het rode voorbeeld. Het zijn deze tussenstappen die ervoor zorgen dat de website traag wordt, wat leidt tot een slechte First Contentful Paint score. Elke tussenstap kost extra tijd, wat snel kan oplopen. Zorg er dus altijd voor dat je binnen één redirect op de juiste pagina uitkomt.

9. Minimaliseer CSS

Een extern CSS-bestand is altijd render blocking. Dat betekent dat een browser normaal gesproken pas kan beginnen met het tonen van content als alle stylesheets gedownload en geanalyseerd zijn. Daarom is het het beste om stylesheets zo klein mogelijk te houden. Zo hoef je minder lang te wachten tot het stylesheet is gedownload. Lees voor een uitgebreidere gids ons artikel over hoe je ongebruikte CSS fixt en verwijdert.

De CSS-grootte verkleinen met shortcodes

Een van de manieren om de CSS-grootte te verkleinen is door shortcodes te gebruiken. Dit zijn oneliners waarmee je de belangrijkste eigenschappen van een CSS-selector op één regel kunt schrijven.

body{
    font-style: normal;
    font-weight: 400;
    font-stretch: normal;
    font-size: 0.94rem;
    line-height: 1.6;
    font-family: "Segoe UI", "Segoe UI", system-ui, -apple-system, sans-serif;
}

Je kunt het ook schrijven als:

body{font: 400 .94rem/1.6 Segoe UI,Segoe UI,system-ui,-apple-system, sans-serif;}

De grootte van CSS verder verkleinen

Het is mogelijk om de CSS-grootte nog verder te verkleinen door selectors samen te voegen met een komma, enters en spaties te verwijderen en kortere kleurcodes te schrijven.

h1{
  color : #000000;
}
h2{
  color : #000000;
}
h3{
  color : #000000;
}
h4{
  color : #000000;
}
h5{
  color : #000000;
}

Kan worden ingekort tot

h1,h2,h3,h4,h5{color:#000}

10. Critical CSS

We kunnen CSS nog een stap verder brengen door Critical CSS te gebruiken. Critical CSS is een must-have voor een snelle website en een snelle First Contentful Paint.

Critical CSS is een verzameling van alle selectors (zoals body, p, h1, etc.) die je nodig hebt om het zichtbare deel van de pagina te tonen. Zet deze Critical CSS niet in een apart stylesheet, maar voeg deze direct toe in de <head> van de pagina. Op deze manier hoef je geen nieuw bestand te downloaden en kan de browser razendsnel beginnen met renderen. Dit zorgt voor een snellere FCP. De CSS die je niet direct nodig hebt voor het zichtbare deel van de pagina wordt geladen nadat de eerste rendercyclus is voltooid. Voor je bezoeker is de pagina al klaar. Niemand merkt dat de nieuwe stijlen op de achtergrond nog worden toegevoegd.

Critical CSS kan eenvoudig worden gegenereerd met onze eigen Critical CSS tool. Plak gewoon de URL van je webpagina in de tool en wij doen de rest voor je!

Inline Critical CSS voorbeeld

<head>
  <style>
    /* Critical CSS: alleen wat nodig is voor het zichtbare gedeelte */
    body{font:400 1rem/1.6 system-ui,sans-serif;margin:0}
    h1{font-size:2rem;margin:.5em 0}
    .hero{padding:2rem;background:#f5f5f5}
  </style>
  <!-- Non-critical CSS asynchroon geladen -->
  <link rel="preload" href="/css/full.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
  <noscript><link rel="stylesheet" href="/css/full.css"></noscript>
</head>

11. Uitgesteld JavaScript laden

Een van de meest voorkomende redenen voor een trage First Contentful Paint is JavaScript. Afhankelijk van hoe je JavaScript gebruikt, kan het de rendering van de pagina blokkeren. Normaal gesproken wordt JavaScript gedownload en uitgevoerd voordat de render tree is gebouwd. Zonder de render tree kan een browser niets op het scherm zetten en dat geldt dus ook voor de FCP. Voor een compleet overzicht van technieken om uit te stellen, lees 14 methodes om JavaScript uit te stellen.

We kunnen dit omzeilen door JavaScript uit te stellen. Dit kun je op drie manieren doen.

Async JavaScript

<script async src="async.js"></script>

Door het async-attribuut aan een script-tag toe te voegen, wordt de opbouw van de pagina niet meer geblokkeerd tijdens het downloaden van het JavaScript. Het async-attribuut geeft aan dat het downloaden en het opbouwen van de render tree tegelijkertijd kunnen gebeuren.

Zodra het script wordt uitgevoerd, wordt de pagina geblokkeerd. In de meeste gevallen heeft de browser dankzij het async-attribuut genoeg tijd gehad om een belangrijk deel van de pagina te bouwen, waardoor de First Contentful Paint al op de pagina staat.

Defer JavaScript

<script defer src="deferred.js"></script>

Het defer-attribuut werkt min of meer hetzelfde als het async-attribuut. Door het defer-attribuut aan een script-tag toe te voegen, mag het script ook worden gedownload tegelijkertijd met het opbouwen van de pagina. Nadat alle scripts zijn gedownload, worden ze uitgevoerd in de volgorde waarin ze in de HTML-code staan. Dit kan de weergave van de pagina nog steeds blokkeren, maar in veel gevallen staat de First Contentful Paint al op het scherm.

12. Vertrouw niet op externe resources

Externe resources, zoals externe lettertypen, externe afbeeldingen, externe stylesheets of externe scripts, zijn een potentieel knelpunt als het gaat om de First Contentful Paint. Omdat je geen controle hebt over de server waar de bestanden worden gehost, weet je niet hoe snel ze worden verzonden. Daarnaast kun je geen gebruikmaken van de bestaande verbinding met de webserver. Er moet een nieuwe verbinding naar een nieuwe server worden opgezet, en dat kost tijd.

Een van de meest voorkomende externe resources op het web is Google Fonts. Door zelf je Google Fonts te hosten elimineer je een complete externe verbinding en krijg je volledige controle over caching, compressie en font-display gedrag.

Blokkerende externe resources

Geen externe resources

13. Gebruik het juiste lettertypeformaat

Lettertypen verdienen extra aandacht als het gaat om de First Contentful Paint. Op zo'n 99% van de pagina's die we bekijken is het FCP-element een tekstregel. Wanneer je externe web fonts gebruikt, moet je deze lettertypen eerst van een server downloaden, wat natuurlijk tijd kost.

De laatste tijd krijgen web fonts steeds meer aandacht en er zijn nieuwe, snellere lettertypeformaten bijgekomen. Het snelste lettertypeformaat op dit moment is woff2, gevolgd door woff. Woff2 wordt door elke moderne browser ondersteund.

Je kunt de voorkeursvolgorde van je web font opgeven in de CSS font-face declaratie. Dat doe je als volgt:

 @font-face {
   font-family: 'myFont';
   font-weight: 400;
   font-style: normal;
   font-display: swap;
   unicode-range: U+000-5FF
   src: local('myFont'),
        url('/fonts/myFont.woff2') format('woff2'),
        url('/fonts/myFont.woff') format('woff');
}

14. Font-display: swap

Wanneer je web fonts gebruikt, is het standaardgedrag van deze lettertypen om de tekst pas op de pagina te tonen als het lettertype geladen is. Dit gaat meestal direct ten koste van de First Contentful Paint. Lees onze complete gids over hoe je zorgt dat tekst zichtbaar blijft tijdens het laden van webfonts.

Je kunt dit oplossen door de font-display:swap declaratie te gebruiken. Hiermee kun je ervoor kiezen om de tekst toch alvast op de pagina te tonen, in een lettertype dat de browser al kent, terwijl de webfont op de achtergrond wordt geladen.

Zonder font-display:swap

Met font-display:swap

font-display: swap vs optional

Er zijn twee veelvoorkomende font-display strategieën voor FCP-optimalisatie:

/* swap: Toont direct het fallback lettertype, wisselt wanneer de webfont is geladen */
@font-face {
  font-family: 'MyFont';
  font-display: swap;
  src: url('/fonts/myfont.woff2') format('woff2');
}

/* optional: Toont het fallback lettertype, gebruikt webfont alleen als deze al in de cache zit */
@font-face {
  font-family: 'MyFont';
  font-display: optional;
  src: url('/fonts/myfont.woff2') format('woff2');
}

Het gebruik van font-display: swap garandeert de snelst mogelijke FCP, omdat tekst direct in het fallback lettertype wordt gerenderd. Het gebruik van font-display: optional voorkomt de flash of unstyled text (FOUT) volledig bij het eerste bezoek, maar het webfont wordt alleen weergegeven als het al in de browsercache zit. Voor de meeste sites is swap de betere keuze voor FCP.

15. Minimaliseer de DOM-grootte

Een webpagina bestaat uit HTML. Het eerste wat een browser doet, is de HTML omzetten naar DOM nodes. Dat is een boomstructuur van HTML-elementen die later wordt gebruikt om de render tree te bouwen. Vanuit de render tree begint een browser te renderen; uiteindelijk verschijnt de webpagina op het scherm.

Hoeveel DOM nodes (HTML-elementen) je hebt en hoe diep deze DOM nodes in de boomstructuur zitten, bepaalt hoe complex het is voor een browser om je pagina te bouwen. CSS en JavaScript kosten ook meer tijd om te analyseren wanneer je te veel DOM nodes hebt. Dit gaat allemaal weer direct ten koste van de FCP.

Los dit op door:

• Lazy load delen van je webpagina
  Om de initiële weergave te versnellen, kun je overwegen om delen van je website, zoals de footer, op een later moment via AJAX te laden.
• Maak gebruik van content-visibility
  De CSS-eigenschap content-visibility vertelt een browser om style, layout en paint over te slaan tijdens het renderen. Dat doet hij vlak voordat het element zichtbaar wordt.
• Splits grote pagina's op in meerdere pagina's
  Het aantal DOM nodes kan worden verminderd door grote pagina's op te splitsen in meerdere pagina's.
• Implementeer infinite scroll
  Infinite scroll is in feite lazy loading: wanneer je scrolt door herhalende elementen zoals afbeeldingen (Pinterest) of grote datatabellen, kan infinite scroll je pagina aanzienlijk versnellen.
• Vermijd JavaScript DOM interactie
  Wees extra voorzichtig met JavaScript als je een groot aantal DOM nodes op je pagina hebt. Een commando als querySelectorAll kan dan een groot aantal DOM nodes inladen, wat het geheugengebruik verhoogt.
• Vermijd complexe CSS-declaraties
  Wees extra voorzichtig met complexe CSS-commando's bij een groot aantal DOM nodes. Het controleren van de last-child status voor elk div-element op je pagina kan bijvoorbeeld kostbaar zijn.
• Gebruik web workers om de main thread van je browser te sparen
  Web workers zijn JavaScript die parallel aan je webpagina kunnen draaien. Je kunt deze web workers commando's geven die op de achtergrond worden uitgevoerd. Wanneer de web worker het commando heeft uitgevoerd, geeft hij dit door aan de originele pagina. Het voordeel hiervan is dat je nog steeds complexe JavaScript kunt uitvoeren zonder dat de pagina vastloopt.

Gerelateerde optimalisatiegidsen

Het verbeteren van FCP vereist werk op meerdere vlakken. Hier zijn onze meest relevante gidsen:

• Zelf Google Fonts hosten: Elimineer een externe verbinding en krijg volledige controle over de levering van lettertypen.
• Zorg dat tekst zichtbaar blijft tijdens het laden van webfonts: Gebruik font-display om snelle tekstrendering te garanderen.
• 14 methodes om JavaScript uit te stellen: Elke techniek om te voorkomen dat JavaScript je FCP blokkeert.
• Ongebruikte CSS fixen en verwijderen: Beperk render blocking CSS tot een minimum.
• 103 Early Hints: Laat de browser alvast starten met het ophalen van resources voordat de HTML arriveert.
• Largest Contentful Paint (LCP) gids: FCP en LCP delen veel optimalisatiestrategieën. Als je FCP traag is, zal je LCP dat ook zijn.
• Time to First Byte (TTFB) gids: TTFB is de grootste factor in FCP. Begin hier als de server response traag is.