First Contentful Paint (FCP): Wat het is, hoe te meten en te verbeteren

Wat is de First Contentful Paint (FCP)?

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

Wat vertelt dat je precies? Het vertelt je dat de FCP voornamelijk een "gebruikersgerichte statistiek" is omdat het iets zegt over de laadsnelheid die een bezoeker ervaart. Het zegt iets over de gebruikerservaring. Op het FCP-moment kun je er zeker van zijn dat een bezoeker daadwerkelijk "iets" op het scherm ziet.

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

1. First: Met First bedoelen we natuurlijk het eerste exacte moment dat er iets substantieels op je browser verschijnt.
2. Contentful: Met Contentful bedoelen we een HTML-element met inhoud. Dus niet een layout-element zoals een leeg element of achtergrondkleur, maar eerder wat 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 simpel, maar eigenlijk is dit de meest gecompliceerde 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 staat een voorbeeld van het renderproces dat nodig is voordat er iets op 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 FCP vaak ruim voor LCP. Een pagina kan bijvoorbeeld binnen 400ms een kop (FCP) renderen, maar nog eens 2 seconden wachten tot de hero-afbeelding geladen is (LCP). Als je FCP traag is, zal je LCP vrijwel zeker ook traag zijn, omdat FCP het allereerste knelpunt in de render-pijplijn vastlegt. Lees meer in onze complete LCP gids.

Wat is een goede First Contentful Paint score?

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

Zoals altijd met prestatiestatistieken, is een snellere First Contentful Paint score beter dan een langzamere.

Hoe meet je jouw First Contentful Paint (FCP)?

De FCP wordt door Google gemeten door gegevens van echte gebruikers te verzamelen. Die gegevens worden opgeslagen in de CrUX-dataset. Die gegevens zijn openbaar beschikbaar via de CrUX API of Google BigQuery. De FCP kan ook worden gemeten via zogenaamde labtests. De meest voorkomende labtest heet Lighthouse.

De First Contentful Paint uit de CrUX-dataset halen

De First Contentful Paint kan uit de CrUX-dataset worden gelezen 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 kun je de First Contentful Paint volgen via interacties van echte gebruikers. Het voordeel van RUM Tracking is dat je niet 28 dagen hoeft te wachten op verse data en dat de data in veel groter detail 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 storen en mogelijk de FCP van je pagina vertragen.
2. Klik met de rechtermuisknop op de pagina en selecteer Element inspecteren. Op deze manier open je de Chrome developer console.
3. Bovenin de console zie je het tabblad Lighthouse. Klik daarop. Kies dan onder Categorieën voor Performance (laat de anderen leeg) en kies Mobile onder Device.
4. Klik nu op Generate Report. Lighthouse maakt een snelheidsrapport van je pagina. In de linkerbovenhoek van 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 om mee te werken en geven wat gegevens over de FCP onder specifieke lab-omstandigheden.

Wat Real-World FCP data laat zien

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

Wereldwijd, volgens de HTTP Archive Web Almanac 2024, behaalt 68% van de desktop-pagina's een goede FCP, terwijl slechts 51% van de mobiele pagina's dat doet. FCP herstelde zich in 2024 na een lichte daling in 2023, wat suggereert dat webdevelopers steeds vaker render-blocking resources 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 serverrespons in plaats van aan render-blocking werk.

De First Contentful Paint verbeteren

Nu je weet wat de First Contentful Paint is, kunnen we aan de slag om deze sneller te maken. Het idee achter een snelle FCP is eigenlijk heel simpel: zorgen dat een browser direct kan beginnen met renderen. Alles wat ervoor kan zorgen dat het renderen wordt vertraagd, resulteert in een slechte FCP-score.

Net als bij de Largest Contentful Paint, kan de First Contentful Paint worden opgesplitst 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 wanneer de browser begint met het laden van de FCP-resource.
3. Resource load time: De tijd die het kost om de FCP-resource zelf te laden.
4. Element render delay: De tijd tussen wanneer de FCP-resource klaar is met laden totdat het FCP-element volledig is gerenderd.

Snelheidstip: Je kunt stappen 2 en 3 eenvoudig elimineren door ervoor te zorgen dat het FCP-element geen netwerkresource nodig heeft. In het geval van een tekstelement, overweeg het gebruik van font-display:swap. In het geval van een klein afbeeldingselement, overweeg om de afbeelding inline te plaatsen.

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

Hieronder staan 14 oplossingen die ik vaak gebruik om de FCP te verbeteren. Maar wees voorzichtig, het gebruik van een oplossing op de verkeerde plek kan juist vertragingen veroorzaken. Daarom is het het beste om een pagespeed-expert te raadplegen voordat je zelf begint.

1. Snelle serverrespons (TTFB)

De TTFB (de tijd tussen het verzoek 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 begint de impact van verdere optimalisaties af te nemen. De HTML-code is het enige verzoek dat direct invloed heeft op alle snelheidsstatistieken.

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 dit 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 gaat als volgt:

1. Gebruik de sneltoets Ctrl-Shift-I om de developers console van Google Chrome te openen.
2. Bovenin de console zie je een Netwerk tabblad. Klik daarop.
3. Herlaad de pagina via Ctrl-R.
4. Je ziet nu alle netwerkverzoeken die Chrome naar je server heeft gestuurd.
5. Klik op het bovenste netwerkverzoek, dit is het verzoek voor je pagina zelf.
6. Nu krijg je meer informatie over dit netwerkverzoek. Klik op het tabblad timing bovenaan deze informatie om te zien wat de TTFB voor je pagina is.

2. HTTP/3

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

Zonder te veel in detail te treden, zorgt HTTP/3 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 gebruik maakt van het snellere HTTP/3-protocol. Gebruik de sneltoets Ctrl-Shift-I om de netwerk-inspecteur 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 relatief nieuwe HTTP-statuscode 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 een database bevragen of server-side logica draaien). In plaats van de browser inactief te laten wachten, stuurt de server een 103-respons 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 fonts, stylesheets en andere render-kritieke resources voordat de HTML zelfs maar 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
...

Niet alle hostingproviders ondersteunen 103 Early Hints al. Cloudflare heeft ingebouwde ondersteuning voor Early Hints, en Apache en Nginx kunnen worden geconfigureerd om ze te verzenden. Lees meer in onze complete 103 Early Hints gids.

4. Browser Caching

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

Wanneer een bezoeker je site eerder heeft bezocht, kun je aangeven of en hoe lang de netwerkresources (bijvoorbeeld een stylesheet) door de browser van de bezoeker kunnen worden opgeslagen. Elke keer dat de bezoeker een van deze bestanden weer nodig heeft, komen ze in een mum van tijd uit de cache van de browser. Hierdoor kan de browser veel sneller beginnen met renderen en de FCP versnellen.

5. Compressie

De netwerksnelheid is in bijna alle gevallen een zwakke schakel. Voor een goede First Contentful Paint is het zo belangrijk dat de bestanden zo snel mogelijk over het netwerk worden verzonden. Compressie vermindert het aantal bytes dat vanaf de server moet worden verzonden; minder bytes betekent minder tijd wachten op een netwerkresource. Compressie is naar mijn mening een techniek die niet de aandacht krijgt die het verdient. Helaas "zetten te veel webmasters compressie aan" en kijken er vervolgens niet meer naar om. En dat is zonde, want het is gewoon een makkelijke manier om dingen net iets sneller te laten gaan.

Er zijn twee populaire compressietechnieken: Gzip en Brotli. Gzip is de meest gebruikte compressietechniek, maar Brotli is snel aan een inhaalslag bezig. Brotli is door Google zelf gemaakt en heeft 15 tot 20% betere resultaten als het gaat om HTML-, JavaScript- of CSS-bestanden. Brotli is daarom 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 om te comprimeren, maar wordt zelden gebruikt.

6. Vroege webfonts met resource hints

Resource hints initiëren een download of netwerkverbinding voordat de browser dit uit zichzelf zou doen. Sommige netwerkresources, zoals webfonts of afbeeldingen, worden pas gedownload nadat de browser zeker weet dat hij ze moet weergeven.

Als je zeker weet dat je een resource nodig hebt om het zichtbare deel van de site te renderen, is het bijna altijd een goed idee om een "resource hint" op te nemen. Dit zorgt ervoor dat de browser direct begint met downloaden of verbinding maken met de resource. Hierdoor is de resource eerder beschikbaar en kan de browser eerder beginnen met renderen.

Maar wees voorzichtig met resource hints. Als je ze verkeerd gebruikt, kunnen ze je pagina juist vertragen.

Vroeg downloaden 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 paginasnelheid-arsenaal. Via de preload link download je een netwerkresource die je later nodig zult hebben. Dit is vaak een heel goed idee bij fonts, kritieke scripts en afbeeldingen op het zichtbare deel van de site.

Vooraf verbinding maken met preconnect

De preconnect link maakt alvast verbinding met een server. Dit is handig wanneer je bestanden host op een server van een derde partij, 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 preconnecten naar Google Fonts is je Google Fonts zelf hosten. Dit elimineert de verbinding met derden 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 lage prioriteit ophalen. Dit is een handige manier om resources op te halen waarvan je denkt dat je ze later nodig zult hebben, bijvoorbeeld wanneer je verwacht dat iemand op de volgende pagina-link klikt.

8. Vermijd redirects

Een veelgemaakte fout is het hebben van een redirect chain 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 omgeleid naar de niet-beveiligde versie van je website. Als alles echter goed is ingesteld, wordt de bezoeker omgeleid naar de beveiligde website. Je ziet dit in het groene voorbeeld hieronder.

Maar soms vindt de omleiding plaats via een of meer tussenstappen, zoals te zien in het rode voorbeeld. Het zijn deze tussenstappen die ervoor zorgen dat de website traag wordt, wat resulteert in 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 komt.

9. Minimaliseer CSS

Een extern CSS-bestand is altijd render-blocking. Dat betekent dat een browser normaal gesproken geen content kan tonen totdat alle stylesheets zijn gedownload en geanalyseerd. Daarom is het het beste om stylesheets zo klein mogelijk te houden. Op deze manier hoef je niet zo lang te wachten tot de stylesheet is gedownload. Lees voor een completere gids ons artikel over hoe ongebruikte CSS te fixen en verwijderen.

De CSS-grootte verkleinen met shortcode

Een van de manieren om de CSS-grootte te verkleinen is door gebruik te maken van shortcodes. Dit zijn one-liners waarmee je de belangrijkste eigenschappen van een CSS-selector in één regel kunt opschrijven.

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 meer 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 zoals

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

10. Kritieke CSS

We kunnen CSS een stap verder nemen door kritieke CSS te gebruiken. Kritieke CSS is een must-have voor een snelle website en een snelle First Contentful Paint.

Kritieke 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. Plaats deze kritieke CSS niet in een aparte stylesheet; voeg het in plaats daarvan 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 zal merken dat de nieuwe stijlen nog op de achtergrond worden toegevoegd.

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

Inline Kritieke CSS Voorbeeld

<head>
  <style>
    /* Critical CSS: only what is needed for above-the-fold content */
    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 loaded asynchronously -->
  <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. JavaScript uitgesteld laden

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

We kunnen dit omzeilen door JavaScript uit te stellen. Je kunt dit op drie manieren doen.

Async JavaScript

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

Door het async-attribuut toe te voegen aan een script-tag, wordt de opbouw van de pagina niet langer geblokkeerd terwijl het JavaScript wordt gedownload. Het async-attribuut geeft aan dat het downloaden en de opbouw van de render tree tegelijkertijd kunnen plaatsvinden.

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 op te bouwen, met de First Contentful Paint al op de pagina.

Defer JavaScript

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

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

12. Vertrouw niet op externe resources

Externe resources, zoals externe fonts, 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. Bovendien kun je de bestaande verbinding met de webserver niet gebruiken. Er moet een nieuwe verbinding met een nieuwe server worden opgezet, en dat kost tijd.

Een van de meest voorkomende externe resources op het web is Google Fonts. Je Google Fonts zelf hosten elimineert een volledige verbinding met derden en geeft je volledige controle over caching, compressie en font-display gedrag.

Externe resources blokkeren

Geen externe resources

13. Gebruik het juiste lettertypeformaat

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

Onlangs hebben webfonts meer aandacht gekregen en zijn er meer nieuwe, snellere fontformaten. Het snelste fontformaat op dit moment is woff2, gevolgd door woff. Woff2 wordt ondersteund door elke moderne browser.

Je kunt de voorkeursvolgorde van je webfont 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

Bij het gebruik van webfonts is het standaardgedrag van deze fonts om de tekst niet op de pagina te tonen totdat het font is geladen. Dit gaat meestal direct ten koste van de First Contentful Paint. Lees onze complete gids over hoe je ervoor 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 op de pagina te tonen, in een lettertype dat de browser kent, terwijl het 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 fallback-font direct, wisselt wanneer webfont laadt */
@font-face {
  font-family: 'MyFont';
  font-display: swap;
  src: url('/fonts/myfont.woff2') format('woff2');
}

/* optional: Toont fallback-font, gebruikt webfont alleen als het 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 rendert in het fallback-font. Het gebruik van font-display: optional vermijdt 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 met 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 ingewikkeld 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, nogmaals, allemaal direct ten koste van de FCP.

Los dit op door:

• Delen van je webpagina lui te laden (lazy load)
  Om de initiële weergave te versnellen, overweeg om delen van je website, zoals de footer, later via AJAX te laden.
• Gebruik te maken van content-visibility
  De CSS-eigenschap content-visibility vertelt een browser om stijl, lay-out en paint over te slaan tijdens het renderen. Het doet dit net voordat het element zichtbaar wordt.
• Grote pagina's op te splitsen in meerdere pagina's
  Het aantal DOM-nodes kan worden verminderd door grote pagina's op te splitsen in meerdere pagina's.
• Infinite scroll te implementeren
  Infinite scrolling is eigenlijk lazy loading: bij het scrollen door herhalende elementen zoals afbeeldingen (Pinterest) of grote gegevenstabellen, kan infinite scroll je pagina aanzienlijk versnellen.
• JavaScript DOM-interactie te vermijden
  Wees extra voorzichtig met JavaScript wanneer je een groot aantal DOM-nodes op je pagina hebt. Een commando als querySelectorAll kan dan een groot aantal DOM-nodes laden, wat het geheugengebruik verhoogt.
• Gecompliceerde CSS-declaraties te vermijden
  Wees extra voorzichtig met gecompliceerde CSS-commando's bij een groot aantal DOM-nodes. Bijvoorbeeld, het controleren van de last-child status voor elk div-element op je pagina kan duur zijn.
• Web workers te gebruiken om de hoofdthread van je browser te sparen
  Web workers zijn JavaScript die parallel met 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 het door aan de oorspronkelijke pagina. Het voordeel hiervan is dat je nog steeds complexe JavaScript kunt uitvoeren zonder dat de pagina bevriest.

Gerelateerde optimalisatiegidsen

Het verbeteren van FCP vereist werk op meerdere gebieden. Hier zijn onze meest relevante diepgaande artikelen:

• Google Fonts zelf hosten: Elimineer een verbinding met derden en krijg volledige controle over de levering van fonts.
• Zorg dat tekst zichtbaar blijft tijdens het laden van webfonts: Gebruik font-display om snelle tekstweergave te garanderen.
• 14 methoden om JavaScript uit te stellen: Elke techniek om te voorkomen dat JavaScript je FCP blokkeert.
• Ongebruikte CSS fixen en verwijderen: Verminder render-blocking CSS tot het minimum.
• 103 Early Hints: Laat de browser beginnen 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 bijdrager aan FCP. Begin hier als je serverrespons traag is.