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

First Contentful Paint verbeteren

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

U kunt de FCP verbeteren door ervoor te zorgen dat een browser zonder enige vertraging kan beginnen met renderen. Hieronder leert u wat FCP is, hoe u het kunt meten en ontdekt u 15 beproefde technieken om het 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. U kunt de paginasnelheid niet samenvatten als één enkel tijdstip; er zijn in feite verschillende 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 inhoud voor het eerst op het scherm wordt gerenderd.

Wat vertelt dat u precies? Het vertelt u dat de FCP primair een "gebruiker-centrische metriek" is, omdat het iets zegt over de laadsnelheid die een bezoeker ervaart. Het zegt iets over de user experience. Op het FCP-moment kunt u 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 allereerste moment dat er iets substantieels in uw browser verschijnt.
2. Contentful: Met contentful bedoelen we een HTML-element met inhoud. Dus geen lay-out-element zoals een leeg element of een 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 plaatsen. Dit lijkt eenvoudig, maar het is in feite de meest ingewikkelde taak van de browser. Om iets op het scherm te kunnen plaatsen, moet een browser klaar zijn om alle kenmerken van een element te berekenen. Hieronder ziet u een voorbeeld van het renderproces dat vereist is voordat er iets op het scherm kan worden geplaatst.

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 u om uw optimalisatiewerk correct te prioriteren.

In de praktijk vuurt FCP vaak ruim voor LCP. Een pagina kan bijvoorbeeld een koptekst renderen (FCP) binnen 400 ms, maar nog eens 2 seconden wachten tot de hero-afbeelding is geladen (LCP). Als uw FCP traag is, zal uw LCP vrijwel zeker ook traag zijn, omdat FCP de allereerste bottleneck in de randerings-pipeline vastlegt. Lees meer in onze volledige LCP-gids.

Wat is een goede First Contentful Paint-score?

Om te slagen voor de Core Web Vitals-beoordeling voor de First Contentful Paint, moet ten minste 75% van uw bezoekers een 'goede' FCP-score hebben. Een FCP-score onder de 1,8 seconden wordt beschouwd als een goede FCP-score, een FCP-score tussen de 1,8 en 3,0 seconden moet worden verbeterd en een FCP-score boven de 3,0 seconden wordt beschouwd als slecht.

Hoe de First Contentful Paint te meten

U kunt de First Contentful Paint op verschillende manieren meten. De meest voorkomende tools zijn Lighthouse, PageSpeed Insights en Chrome DevTools. Al deze tools maken gebruik van labgegevens, wat betekent dat ze een paginabezoek simuleren onder gecontroleerde omstandigheden. Om de werkelijke prestaties van uw gebruikers te begrijpen, moet u tools gebruiken die veldgegevens verzamelen.

FCP meten met Chrome DevTools

U kunt de FCP direct in uw browser meten met de Chrome DevTools. Open de ontwikkelaarstools (Ctrl+Shift+I), ga naar het tabblad Performance en herlaad de pagina. U ziet de FCP-markering in de sectie Timings.

FCP meten met PageSpeed Insights

PageSpeed Insights biedt zowel labgegevens (Lighthouse) als veldgegevens (CrUX) voor een specifieke URL. Hiermee kunt u zien hoe echte gebruikers uw site ervaren en dit vergelijken met een gecontroleerde test.

FCP meten met RUM-data

Real User Monitoring (RUM) tools, zoals CoreDash, verzamelen prestatiegegevens van elke echte bezoeker van uw site. Dit geeft u een veel nauwkeuriger beeld van uw FCP-prestaties op verschillende apparaten, netwerken en locaties. CoreDash breekt de FCP af in zijn subonderdelen, waardoor u kunt identificeren of de vertraging wordt veroorzaakt door de server, het laden van bronnen of het renderen zelf.

De First Contentful Paint verbeteren

Tijd om de FCP 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 ervoor kan zorgen dat het renderen wordt vertraagd, zal resulteren in 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 moment dat de browser de pagina begint te laden tot het moment dat deze de eerste byte van de HTML ontvangt.
2. Resource load delay: De tijd tussen TTFB en het moment dat 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 vanaf het moment dat de FCP-resource klaar is met laden tot het moment dat het FCP-element volledig is gerenderd.

Snelheidstip: U kunt stap 2 en 3 eenvoudig elimineren door ervoor te zorgen dat het FCP-element geen netwerkbron vereist. In het geval van een tekstelement kunt u overwegen om font-display:swap te gebruiken. In het geval van een klein afbeeldingselement kunt u overwegen de afbeelding inline te plaatsen.

Dit laat ons alleen nog de Time to First Byte and 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 paginasnelheid-expert te raadplegen voordat u zelf aan de slag gaat.

1. Snelle serverrespons (TTFB)

De TTFB (de tijd tussen de aanvraag en de eerste byte die de server verzendt) is altijd de eerste stap in het renderproces. Vanaf dat punt begint uw browser met multitasken en begint de impact van verdere optimalisaties af te nemen. De HTML-code is de enige aanvraag die direct invloed heeft op alle snelheidsmetrieken.

De snelheid waarmee de HTML-code van 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 doet u dit door server-side caching in te schakelen.

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

U kunt de Time to First Byte eenvoudig zelf meten. Dit gaat als volgt:

1. Gebruik de sneltoets Ctrl-Shift-I om de ontwikkelaarsconsole van Google Chrome te openen.
2. Bovenaan de console ziet u een tabblad Network. Klik daarop.
3. Herlaad de pagina via Ctrl-R.
4. U ziet nu alle netwerkaanvragen die Chrome naar uw server heeft verzonden.
5. Klik op de bovenste netwerkaanvraag, dit is de aanvraag voor uw pagina zelf.
6. U krijgt nu meer informatie over deze netwerkaanvraag. Klik op het tabblad timing bovenaan deze informatie om te zien wat de TTFB is voor uw pagina.

2. HTTP/3

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

Zonder al te diep in details te treden, maakt HTTP/3 een aanzienlijke snelheidswinst mogelijk, vooral op een trager netwerk zoals een mobiel netwerk. Uw netwerkbeheerder kan u vertellen of uw webserver al geschikt is voor het snellere HTTP/3-protocol.

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

3. 103 Early Hints

103 Early Hints is een relatief nieuwe HTTP-statuscode waarmee een server voorlopige responskoppen kan verzenden voordat de definitieve respons klaar is. Dit is vooral handig wanneer uw server tijd nodig heeft om de HTML te genereren (bijvoorbeeld door een database te raadplegen of server-side logica uit te voeren). In plaats van de browser inactief te laten wachten, verzendt de server een 103-respons met preload- en preconnect-hints, zodat de browser onmiddellijk kan beginnen met het ophalen van kritieke bronnen.

Dit verbetert de FCP direct omdat de browser kan beginnen met het downloaden van lettertypen, stylesheets en andere bronnen die cruciaal zijn voor het renderen, nog voordat de HTML 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 verzenden. Lees meer in onze volledige 103 Early Hints-gids.

4. Browser Caching

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

Wanneer een bezoeker eerder op uw site is geweest, kunt u aangeven of en hoe lang de netwerkbronnen (bijvoorbeeld een stylesheet) door de browser van de bezoeker mogen worden opgeslagen. 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 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 via het netwerk worden verzonden. Compressie vermindert het aantal bytes dat vanaf de server moet worden verzonden; minder bytes betekent minder tijd wachten op een netwerkbron. 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 jammer, want het is gewoon een gemakkelijke manier om de zaken net even sneller te laten gaan.

Er zijn twee populaire compressietechnieken: Gzip en Brotli. Gzip is de meest gebruikte compressietechniek, maar Brotli is bezig met een snelle inhaalslag. Brotli is ontwikkeld door Google zelf en levert 15 tot 20% betere resultaten bij 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 comprimeert u het bestand vlak voordat u het via uw webserver verzendt; bij statische compressie wordt het gecomprimeerde bestand op de server opgeslagen. Dit is vaak een veel slimmere manier om te comprimeren, maar het wordt zelden gebruikt.

6. Vroege webfonts met resource hints

Resource hints initiëren een download of netwerkverbinding voordat de browser dat uit zichzelf zou doen. Sommige netwerkbronnen, zoals webfonts of afbeeldingen, worden pas gedownload nadat de browser er zeker van is dat deze moeten worden weergegeven.

Als u zeker weet dat u een bron nodig heeft 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 het downloaden van of verbinding maken met de bron. Hierdoor is de bron eerder beschikbaar en kan de browser eerder beginnen met renderen.

Maar wees voorzichtig met resource hints. Als u ze verkeerd gebruikt, kunnen ze uw 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 arsenaal voor paginasnelheid. Via de preload-link downloadt u een netwerkbron die u later nodig heeft. Dit is vaak een heel goed idee bij lettertypen, 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 u 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 het zelf hosten van uw Google Fonts. Dit elimineert de verbinding met derden volledig en geeft u volledige controle over caching en levering.

7. De volgende pagina vooraf ophalen met prefetch

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

Met prefetch kunt u bronnen met een lage prioriteit ophalen. Dit is een handige manier om bronnen op te halen waarvan u denkt dat u ze later nodig zult hebben, bijvoorbeeld wanneer u verwacht dat iemand op de link naar de volgende pagina zal klikken.

8. Vermijd redirects

Een veelgemaakte fout is het hebben van een redirect-keten die te lang is. Laat me dit uitleggen: Uw site draait waarschijnlijk via een beveiligde verbinding. Wanneer een bezoeker uw site intypt zonder https toe te voegen, wordt de bezoeker doorgestuurd naar de niet-beveiligde versie van uw website. Als alles echter goed is ingesteld, wordt de bezoeker doorgestuurd naar de beveiligde website. U kunt dit zien in het groene voorbeeld hieronder.

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

9. CSS minimaliseren

Een extern CSS-bestand is altijd render-blocking. Dat betekent dat een browser normaal gesproken niet kan beginnen met het weergeven van inhoud totdat alle stylesheets zijn gedownload en geanalyseerd. Daarom is het het beste om stylesheets zo klein mogelijk te houden. Op die manier hoeft u minder lang te wachten tot de stylesheet is gedownload. Voor een completere gids, lees ons artikel over hoe u ongebruikte CSS kunt vinden en verwijderen.

De CSS-omvang verkleinen met shortcodes

Een van de manieren om de CSS-omvang te verkleinen is door shortcodes te gebruiken. Dit zijn one-liners waarmee u de belangrijkste eigenschappen van een CSS-selector op éé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;
}

U kunt het ook schrijven als:

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

De omvang van CSS verder verkleinen

Het is mogelijk om de CSS-omvang 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;
}

Zou verkort kunnen worden als:

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

10. Kritieke CSS (Critical CSS)

We kunnen CSS nog een stap verder brengen 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 u nodig heeft om het zichtbare deel van de pagina te tonen. Plaats deze kritieke CSS niet in een aparte stylesheet; voeg deze in plaats daarvan direct toe in de <head> van de pagina. Op die manier hoeft u geen nieuw bestand te downloaden en kan de browser op lichtsnelheid beginnen met renderen. Dit zorgt voor een snellere FCP. De CSS die u niet direct nodig heeft voor het zichtbare deel van de pagina wordt geladen nadat de eerste randeringscyclus is voltooid. Voor uw 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 uw webpagina in de tool en wij doen de rest voor u!

Voorbeeld van inline kritieke CSS

<head>
  <style>
    \/* Kritieke CSS: alleen wat nodig is voor de inhoud boven de vouw *\/
    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>
  <!-- Niet-kritieke 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. Laden van JavaScript uitstellen (Defer)

Een van de meest voorkomende redenen voor een trage First Contentful Paint is JavaScript. Afhankelijk van hoe u JavaScript gebruikt, kan het het renderen van de pagina blokkeren. Normaal gesproken wordt JavaScript gedownload en uitgevoerd voordat de render tree is opgebouwd. Zonder de render tree kan een browser niets op het scherm plaatsen, 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. U kunt dit op drie manieren doen.

Asynchroon JavaScript (Async)

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

Door het async-attribuut aan een script-tag toe te voegen, 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, is 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.

Uitgesteld JavaScript (Defer)

<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 gelijktijdig met het opbouwen 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 bronnen

Externe bronnen, zoals externe lettertypen, externe afbeeldingen, externe stylesheets of externe scripts, zijn een potentiële bottleneck als het gaat om de First Contentful Paint. Omdat u geen controle heeft over de server waar de bestanden worden gehost, weet u niet hoe snel ze zullen worden verzonden. Bovendien kunt u 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 bronnen op het web is Google Fonts. Zelf hosten van uw Google Fonts elimineert een volledige verbinding met derden en geeft u volledige controle over caching, compressie en font-display gedrag.

Blokkeren van externe bronnen

Geen externe bronnen

13. Gebruik het juiste lettertypeformaat

Lettertypen 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 u externe webfonts gebruikt, moet u deze lettertypen eerst van een server downloaden, wat natuurlijk tijd kost.

Sinds kort krijgen webfonts meer aandacht en zijn er meer nieuwe, snellere lettertypeformaten. Het snelste lettertypeformaat van dit moment is woff2, gevolgd door woff. Woff2 wordt door elke moderne browser ondersteund.

U kunt de voorkeursvolgorde van uw webfont specificeren in de CSS font-face declaratie. Dit doet u 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 lettertypen om de tekst op de pagina niet te tonen totdat het lettertype is geladen. Dit gaat meestal direct ten koste van de First Contentful Paint. Lees onze volledige gids over hoe u ervoor kunt zorgen dat tekst zichtbaar blijft tijdens het laden van webfonts.

U kunt dit oplossen door de declaratie font-display:swap te gebruiken. Hiermee kunt u ervoor kiezen om de tekst toch op de pagina te tonen, in een lettertype dat de browser 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 zodra 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 de webfont alleen als deze al gecacht is *\/
@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 onmiddellijk rendert in het fallback-lettertype. Het gebruik van font-display: optional voorkomt de 'flash of unstyled text' (FOUT) volledig bij het eerste bezoek, maar de webfont zal alleen worden weergegeven als deze al in de browsercache aanwezig is. Voor de meeste sites is swap de betere keuze voor FCP.

15. Minimaliseer de DOM-omvang

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

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

Los dit op door:

• Onderdelen van uw webpagina via lazy loading te laden
  Om de initiële weergave te versnellen, kunt u overwegen om onderdelen van uw website, zoals de footer, op een later tijdstip 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. Dit gebeurt vlak 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 in feite lazy loading: bij het scrollen door herhaalde elementen zoals afbeeldingen (Pinterest) of grote tabellen met gegevens, kan infinite scroll uw pagina aanzienlijk versnellen.
• JavaScript DOM-interactie te vermijden
  Wees extra voorzichtig met JavaScript wanneer u een groot aantal DOM-nodes op uw pagina heeft. 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 ingewikkelde CSS-commando's met een groot aantal DOM-nodes. Bijvoorbeeld, het controleren van de last-child status voor elk div-element op uw pagina kan kostbaar zijn.
• Web workers te gebruiken om de main thread van uw browser te ontlasten
  Web workers zijn JavaScript-bestanden die parallel aan uw webpagina kunnen draaien. U kunt deze web workers commando's geven die op de achtergrond worden uitgevoerd. Wanneer de web worker het commando heeft uitgevoerd, geeft deze het door aan de oorspronkelijke pagina. Het voordeel hiervan is dat u 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 gidsen:

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