First Contentful Paint

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 paginasnelheid niet samenvatten als één moment in de tijd; er zijn eigenlijk verschillende 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 het moment waarop de eerste betekenisvolle content voor het eerst op het scherm wordt gerenderd.

Wat vertelt dat je 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 user experience. Op het FCP-moment weet je zeker 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 allereerste exacte moment waarop iets substantieels in je browser verschijnt.
2. Contentful: Met contentful bedoelen we een HTML-element met inhoud. Dus geen 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 is eigenlijk de meest ingewikkelde 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 vereist is voordat er iets aan het scherm kan worden toegevoegd.

Wat is een goede First Contentful Paint score?

Een goede FCP-score is alles tussen 0 en 1,8 seconden. Als je FCP-score tussen 1,8 en 3 seconden ligt, heeft deze verbetering nodig. Elke FCP-score boven de 3 seconden wordt als slecht beschouwd. Om te slagen voor de Core Web Vitals voor de Largest Contentful Paint moet ten minste 75% van je bezoekers een 'goede' FCP-score hebben.

Zoals altijd bij de Core Web Vitals is een snellere First Contentful Paint score beter dan een tragere. 

Hoe meet je je 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 lab-tests. De meest voorkomende lab-test 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 nieuwe gegevens en dat de gegevens veel gedetailleerder kunnen worden opgevraagd en geanalyseerd.

De FCP meten in Lighthouse

1. Open de pagina – in Chrome – waarvan je de FCP wilt meten. Doe dit in incognito-modus zodat plug-ins je niet storen en mogelijk de FCP van je pagina vertragen.
2. Klik met de rechtermuisknop op de pagina en selecteer Element inspecteren. Hiermee open je de Chrome-ontwikkelaarsconsole.
3. Boven in de console zie je het tabblad Lighthouse. Klik erop. Kies dan onder Categorieën voor Performance (laat de andere leeg) en kies Mobiel onder Apparaat.
4. Klik nu op Rapport genereren. Lighthouse maakt een snelheidsrapport van je pagina. Links bovenaan 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 gemakkelijk om mee te werken en geven wat gegevens over de LCP onder specifieke lab-omstandigheden.

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: ervoor zorgen dat een browser onmiddellijk kan beginnen met renderen. Alles wat vertraging in het renderen kan veroorzaken, zal leiden tot een slechte FCP-score.

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

1. Time to first byte (TTFB) - De tijd vanaf het begin van het laden van de pagina tot wanneer de browser 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 nodig is om de FCP-resource zelf te laden.
   
4. Element render delay - De tijd tussen wanneer de FCP-resource klaar is met laden totdat het LCP-element volledig is gerenderd
   

Snelheidstip: Je kunt stap 2 & 3 eenvoudig elimineren door ervoor te zorgen dat het LCP-element geen netwerkresource vereist. Overweeg in het geval van een tekstelement het gebruik van font-display:swap. Overweeg bij een kleine afbeelding 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 plaats kan juist vertragingen veroorzaken. Daarom is het het beste om een pagespeed-expert te raadplegen voordat je zelf begint.

1. Snelle server response (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 punt begint je browser te multitasken en neemt de impact van verdere optimalisaties af. De HTML-code is het enige verzoek dat 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 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 doe je als volgt:

1. Gebruik de sneltoets Ctrl-Shift-I om de ontwikkelaarsconsole van Google Chrome te openen.
   
2. Boven in de console zie je een tabblad Netwerk. Klik erop.
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, dat 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 tegelijk 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 netwerk-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. 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 bewaard mogen worden. 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.

4. 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 verstuurd. Compressie vermindert het aantal bytes dat van de server moet worden verzonden – minder bytes betekent minder wachttijd 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 maken.

Er zijn twee populaire compressietechnieken: Gzip en Brotli. Gzip is de meest gebruikte compressietechniek, maar Brotli is snel aan een inhaalslag bezig. Brotli is gemaakt door Google zelf 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.

5. Vroege web-fonts met resource hints

Resource hints starten 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 onmiddellijk begint met downloaden of verbinding maken met de resource. Het gevolg is dat de resource eerder beschikbaar is en de browser eerder kan 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 hebt. Dit is vaak een heel goed idee bij fonts, kritieke scripts en afbeeldingen op 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 server van derden, zoals een CDN of Google Analytics.

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

6. Prefetch de volgende pagina met prefetch

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

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

7. 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 hij doorgestuurd naar de niet-beveiligde versie van je website. Echter, als alles goed is ingesteld, wordt de bezoeker doorgestuurd naar de beveiligde website. Je ziet dit in het groene voorbeeld hieronder.

Maar soms vindt het doorsturen 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.

8. Minimaliseer CSS

Een extern CSS-bestand is altijd render-blocking. Dat betekent dat een browser normaal gesproken niet kan beginnen met het weergeven van content totdat alle stylesheets zijn gedownload en geanalyseerd. Daarom is het het beste om stylesheets zo klein mogelijk te houden. Zo hoef je minder lang te wachten tot de stylesheet is gedownload.

De CSS-grootte verkleinen met shortcode

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 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 als

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

9. Kritieke CSS

We kunnen CSS een stap verder nemen door gebruik te maken van kritieke CSS. 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. Zet 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 gendercyclus is voltooid. Voor je bezoeker is de pagina al klaar – niemand merkt dat de nieuwe stijlen nog op de achtergrond worden toegevoegd.

Kritieke 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!

10. JavaScript laden uitstellen

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 gebouwd. Zonder de render tree kan een browser niets op het scherm zetten – dit geldt ook voor de FCP.

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 de 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, waarbij de First Contentful Paint al op de pagina staat.

Defer JavaScript

<script defer src="async.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 tegelijkertijd 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.

11. 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. Daarnaast 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.

Externe resources blokkeren

Geen externe resources

12. Gebruik het juiste lettertype-formaat

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. 

Recentelijk hebben webfonts meer aandacht gekregen en zijn er meer nieuwe, snellere lettertype-formaten. Het snelste lettertype-formaat op dit moment is woff2, gevolgd door woff. Woff2 wordt door elke moderne browser ondersteund. 

Je kunt de voorkeursvolgorde van je webfont specificeren 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');
}

13. Font display:swap

Bij het gebruik van webfonts is het standaardgedrag van deze fonts om de tekst op de pagina pas te tonen als het font is geladen. Dit gaat meestal direct ten koste van de First Contentful Paint. 

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

Zonder font-display:swap

Met font-display:swap

Lees ons volledige artikel  Zorg dat tekst zichtbaar blijft tijdens het laden van webfonts

14. 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 mee op 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 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 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 stijl, lay-out en paint over te slaan tijdens het renderen. Dit gebeurt 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 eigenlijk lazy loading: bij het scrollen door herhaalde elementen zoals afbeeldingen (pinterest) of grote datatabellen, kan infinite scroll je pagina aanzienlijk versnellen.
• Vermijd JavaScript DOM-interactie
  Wees extra voorzichtig met JavaScript wanneer je een groot aantal DOM-nodes op je pagina hebt. Een commando kan dan een groot aantal DOM-nodes laden, wat het geheugengebruik verhoogt.
• Vermijd ingewikkelde CSS-declaraties
  Wees extra voorzichtig met ingewikkelde CSS-commando's bij een groot aantal DOM-nodes. Je moet bijvoorbeeld de last-child status controleren voor elk div-element op je pagina.
• Gebruik web workers om de main thread 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.