Optimiseer de rendervertraging van het LCP-element

Van gedownload naar weergegeven: leer hoe je de element render delay van de Largest Contentful Paint verbetert.

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-07-10
  1. Nl
  2. Core Web Vitals
  3. Largest contentful paint
  4. Element render delay

Deze gids is onderdeel van de Largest Contentful Paint (LCP)-sectie van ons Core Web Vitals-kenniscentrum. Element Render Delay is de laatste fase in de LCP-tijdlijn. Het is de tijd tussen het einde van de download van de LCP-resource en het moment waarop het element zichtbaar op het scherm is getekend.

Optimaliseer de LCP Element Render Delay

Van de vier LCP-fases is Element Render Delay de meest onbegrepene. Teams optimaliseren TTFB, elimineren Resource Load Delay en comprimeren assets om de Resource Load Duration te verkorten. Ze zien de netwerk-waterval eindigen en nemen aan dat het werk erop zit. Ze hebben het mis.

De Element Render Delay is de tijd tussen het afronden van de download van de LCP-resource en het moment waarop het element volledig op het scherm van de gebruiker is getekend. Dit is geen netwerkprobleem; het is een main thread-probleem. Een hoge render delay betekent dat de browser de afbeelding of het lettertype heeft, maar het te druk heeft met andere taken om deze daadwerkelijk te tekenen. Deze vertraging is een directe aanslag op je LCP-score en voegt soms 200ms of meer toe nadat alle netwerkverzoeken zijn afgerond.

Precieze definitie: het 'last mile'-probleem

Element Render Delay begint op het moment dat de laatste byte van de LCP-resource (bijvoorbeeld een afbeeldingsbestand of webfont) bij de browser binnenkomt. Het eindigt wanneer het LCP-element zichtbaar op het scherm is getekend. Het is letterlijk de allerlaatste stap.

Voor LCP-tekstelementen die een systeemlettertype gebruiken is deze vertraging vaak nul, omdat er geen externe resource nodig is. Maar voor de overgrote meerderheid van de sites waar het LCP-element een afbeelding is of een custom webfont gebruikt, is deze fase vaak de grootste bottleneck. De browser besteedt deze tijd aan CPU-bound taken: het vertalen van gedownloade bits naar zichtbare pixels.

Het 'waarom': een vastgelopen lopende band

Om de render delay op te lossen, moet je begrijpen hoe een browser een pagina tekent. Dit is een proces met meerdere stappen dat vaak de Critical Rendering Path wordt genoemd. Zie het als de lopende band in een fabriek:

  1. Bouwen van de blauwdrukken (DOM & CSSOM): De browser parst de HTML om het Document Object Model (DOM) te bouwen en de CSS om het CSS Object Model (CSSOM) te bouwen. Dit zijn de blauwdrukken voor de pagina-inhoud en de styling ervan.
  2. Blauwdrukken samenvoegen (Render Tree): De DOM en CSSOM worden samengevoegd tot een Render Tree. Deze bevat alleen de nodes die nodig zijn om de pagina te renderen. Elementen zoals <head> of elementen met display: none; worden weggelaten.
  3. Geometrie berekenen (Layout): De browser berekent de exacte grootte en positie van elk element in de render tree. Deze fase staat ook bekend als "reflow".
  4. Pixels inkleuren (Paint): De browser vult de pixels voor elk element in, rekening houdend met tekst, kleuren, afbeeldingen, randen en schaduwen.
  5. Lagen samenvoegen (Composite): De pagina wordt op verschillende lagen getekend, die vervolgens in de juiste volgorde worden samengevoegd tot het uiteindelijke beeld op het scherm.

De Element Render Delay is de tijd die deze laatste fasen in beslag nemen: Layout, Paint en Composite. Deze hele lopende band wordt bediend door één enkele arbeider: de main thread. Als die arbeider druk is met het uitvoeren van een JavaScript long task of het parsen van een enorm CSS-bestand, valt de lopende band stil. De LCP-afbeelding is misschien al binnen, maar ligt nog op het laaddock te wachten tot de main thread vrijkomt om deze te verwerken en te tekenen.

Hoe je Element Render Delay opspoort

Het diagnosticeren van dit probleem volgt een strikt proces van twee stappen. Sla de eerste stap niet over.

Stap 1: Valideer met field data (RUM)
Voordat je DevTools opent, moet je bevestigen dat Element Render Delay een daadwerkelijk probleem is voor je echte gebruikers. Een professionele Real User Monitoring (RUM)-tool zoals mijn eigen CoreDash is hierbij essentieel. Deze splitst de LCP van je site op in de vier subonderdelen. Als je RUM-data een significante Element Render Delay laat zien op het 75e percentiel, dan heb je een gevalideerd probleem met een hoge impact om op te lossen.

Stap 2: Diagnose stellen met DevTools
Zodra RUM de probleempagina's heeft geïdentificeerd, gebruik je het Performance-paneel in Chrome DevTools om de oorzaak te achterhalen.

  1. Ga naar het tabblad Performance en vink het selectievakje "Web Vitals" aan.
  2. Klik op de knop "Record and reload page".
  3. Klik in het "Timings"-spoor op de LCP-marker. Het tabblad "Summary" eronder toont de exacte duur van elk van de vier LCP-fases. Noteer de waarde van de Element render delay.
  4. Bekijk nu het Main-spoor in de tijdlijn. Zoek naar long tasks (gele blokken met rode hoeken) die plaatsvinden tussen het einde van het netwerkverzoek van de LCP-resource en de LCP-marker. Deze taken zijn de directe oorzaak van je vertraging. Beweeg je muis erover om de verantwoordelijke scripts te identificeren.

Veelvoorkomende oorzaken en oplossingen met hoge impact

Een hoge Element Render Delay wordt bijna altijd veroorzaakt door een geblokkeerde main thread.

Oorzaak: Render-blocking CSS

Het probleem: Standaard is CSS render blocking. De browser tekent geen enkele pixel totdat alle CSS-bestanden die in de <head> gelinkt staan, zijn gedownload en geparst. Een groot, complex stylesheet kan de main thread honderden milliseconden bezet houden, wat de start van de layout- en paint-fases vertraagt. Dit wordt nog erger als sites meerdere stylesheets laden, die elk een apart netwerkverzoek en een eigen parse-cyclus vereisen. Zie onze gids over het verwijderen van ongebruikte CSS voor gedetailleerde strategieën om de CSS-payload te verminderen.

De oplossing: Zorg dat je CSS klein, schoon en cachebaar is.

  • Verwijder ongebruikte CSS: Dit is de optimalisatie met de allerhoogste impact. Op grote sites kan ongebruikte CSS 70% of meer van de totale grootte van het stylesheet beslaan. Tools zoals PurgeCSS kunnen je HTML en JavaScript scannen om ongebruikte selectors te identificeren. Het verwijderen van overbodige regels vermindert zowel de downloadtijd als de parsetijd op de main thread.
  • Streef naar kleine, cachebare stylesheets: De sweet spot voor een CSS-bestand ligt rond de 10-15 kB (gecomprimeerd). Kleiner dan dat en je riskeert te veel parallelle verzoeken, elk met zijn eigen verbindingsoverhead. Groter dan dat en de blokkeertijd loopt op, vooral op trage mobiele netwerken. Een enkel goed gestructureerd stylesheet in dat bereik downloadt snel, parst snel en wordt gecached door de browser voor volgende bezoeken.
  • Inline CSS alleen als laatste redmiddel: Het inlinen van kritieke CSS in een <style>-blok elimineert het netwerkverzoek voor het eerste laden van de pagina, maar dat heeft een prijs: geïnlinede CSS kan niet door de browser worden gecached. Elke terugkerende bezoeker downloadt het opnieuw bij elke pagina. Voor de meeste sites met terugkerende gebruikers is een klein extern stylesheet dat de browser cached de betere keuze. Inlinen is alleen zinvol voor landingspagina's met heel weinig terugkerende bezoekers.

De impact van CSS kwantificeren: Om te meten hoeveel je CSS bijdraagt aan de render delay, open je het tabblad Coverage in Chrome DevTools (Ctrl+Shift+P, typ vervolgens "Coverage"). Laad de pagina en bekijk het percentage ongebruikte bytes in je CSS-bestanden. Een hoog percentage ongebruikte CSS is een duidelijk signaal dat opschonen de Element Render Delay zal verminderen.

Oorzaak: JavaScript long tasks

Het probleem: Dit is de meest voorkomende oorzaak. Zware JavaScript-uitvoering, of het nu gaat om frameworks, analytics-scripts, A/B-testtools of slecht geoptimaliseerde code, kan de main thread monopoliseren. Een enkele langlopende taak kan het renderen honderden milliseconden blokkeren, wat direct bijdraagt aan de Element Render Delay. Google definieert een long task als elke taak die langer dan 50 ms duurt, en taken die langer dan 200 ms duren worden als kritiek lang beschouwd. Zie ons artikel over 14 manieren om JavaScript uit te stellen voor een complete verzameling strategieën om JavaScript uit te stellen.

De oplossing: Hak het werk in stukken.

  • Yield naar de main thread: Long tasks moeten in kleinere stukken worden opgeknipt. Dit doe je door de browser periodiek de controle terug te geven (yielding) met behulp van setTimeout(..., 0) of the nieuwere scheduler.yield()-API. Hierdoor kan de browser rendering-updates uitvoeren tussen de taken door.
  • Optimaliseer en defer third-party scripts: Analyseer elk extern script. Als ze niet essentieel zijn voor de eerste render, laad ze dan met het defer-attribuut of injecteer ze nadat de pagina is geladen. Scripts voor A/B-testen zijn bijzonder problematisch omdat ze het renderen vaak bewust blokkeren.
  • Gebruik requestAnimationFrame voor visuele updates: Als JavaScript DOM-manipulatie moet uitvoeren tijdens het laden van de pagina, verpak het werk dan in requestAnimationFrame. Dit plant het werk vlak voor de volgende paint, zodat de browser de kans krijgt om frames te renderen tussen JavaScript-acties door.

Long tasks identificeren in DevTools

In het Chrome DevTools Performance-paneel verschijnen long tasks als gele blokken met een rode driehoek in de rechterbovenhoek van het "Main"-spoor. Om te zien welke scripts verantwoordelijk zijn:

  1. Neem het laden van een pagina op in het Performance-paneel.
  2. Zoek de LCP-marker in het Timings-spoor.
  3. Onderzoek het Main-spoor op long tasks die plaatsvinden tussen de afronding van het netwerkverzoek van de LCP-resource en de LCP-marker.
  4. Klik op deze taken om de call stack in het Summary-paneel te bekijken. De call stack toont het bronbestand en de functie die verantwoordelijk zijn voor de long task.

Veelvoorkomende third-party boosdoeners

Op basis van praktijkervaring zijn dit de meest voorkomende third-party scripts die Element Render Delay veroorzaken:

  • A/B-testtools (Optimizely, VWO, AB Tasty): Deze blokkeren het renderen vaak opzettelijk om te voorkomen dat inhoud knippert (flicker) tussen varianten. Door de testbeslissing naar de server-side te verplaatsen (server-side testing), los je dit probleem volledig op.
  • Tag managers met synchrone tags: Een tag manager die is geconfigureerd met synchrone (niet-async) tags kan render-blocking scripts injecteren. Controleer je container om er zeker van te zijn dat alle tags zijn ingesteld om te vuren na DOM ready of window load.
  • Consent management platforms: Cookiebanners die het renderen blokkeren totdat een keuze is gemaakt, kunnen de LCP vertragen. Gebruik een asynchrone implementatie die de Critical Rendering Path niet blokkeert.
  • Chat-widgets: Livechat-scripts voeren vaak zware initialisatiecode uit tijdens het laden van de pagina. Stel het laden uit (defer) tot nadat de pagina interactief is, of laad ze pas na gebruikersinteractie (bijvoorbeeld een klik).

Oorzaak: Client-Side Rendering (CSR)

Het probleem: Bij pure client-side rendering bestaat het LCP-element vaak nog niet in de initiële HTML. JavaScript moet eerst draaien om de DOM op te bouwen en het LCP-element in te voegen, waarna de browser het pas kan renderen. Dit hele proces is één grote render delay.

De oplossing: Render op de server. Er is geen andere optie. Gebruik Server-Side Rendering (SSR) of Static Site Generation (SSG) om ervoor te zorgen dat het LCP-element aanwezig is in het initiële HTML-document dat vanaf de server wordt verzonden. Dit elimineert de hele JavaScript-gestuurde renderingfase als bron van vertraging.

Oorzaak: Inhoud verborgen door andere code

Het probleem: Soms staat het LCP-element al in de DOM, maar is het verborgen door CSS (bijvoorbeeld opacity: 0) of door een script, zoals een "reveal on scroll"-animatie of een A/B-testtool die nog aan het bepalen is welke variant moet worden getoond. Het element is gedownload en klaar, maar kan nog niet worden getekend omdat het nog niet zichtbaar is.

De oplossing: Zorg voor directe zichtbaarheid. Gebruik voor het LCP-element geen verschijningsanimaties of logica die het verbergt tijdens het laden van de pagina. Het element moet in de DOM staan en vanaf de allereerste paint zo gestyled zijn dat het direct zichtbaar is. Configureer A/B-testtools om asynchroon te draaien of zorg dat ze minimale impact hebben op de zichtbaarheid van het LCP-element.

Oorzaak: Overmatige DOM-omvang

Het probleem: Een grote DOM (meer dan 1.500 nodes) verhoogt de kosten van elke rendering-operatie. Elke layout-berekening, style-recalculatie en paint-operatie moet meer nodes verwerken, wat meer tijd kost op de main thread. Zelfs als je CSS en JavaScript goed geoptimaliseerd zijn, zorgt een opgeblazen DOM voor extra render delay door de pure omvang ervan. Zie onze gids over het vermijden van een te grote DOM-omvang voor gedetailleerde strategieën om de DOM-grootte te verminderen.

De oplossing: Verminder het aantal DOM-nodes dat deelneemt aan de initiële render.

  • Vereenvoudig de HTML-structuur: Verwijder overbodige wrapper-elementen. Maak diep geneste structuren platter. Gebruik CSS Grid of Flexbox in plaats van extra <div>-elementen voor de layout.
  • Virtualiseer lange lijsten: Gebruik voor pagina's met honderden lijstitems (zoals productoverzichten of datatabellen) virtualisatie-bibliotheken die alleen de items renderen die momenteel zichtbaar zijn in de viewport.
  • Lazy-render content onder de vouw: Gebruik content-visibility: auto (hieronder besproken) om het renderen van secties buiten het scherm volledig over te slaan.

Geavanceerde tactieken: volledige controle over rendering

Complexe applicaties hebben meer controle over de main thread nodig.

Prestaties verbeteren met content-visibility

De CSS-eigenschap content-visibility is gemaakt voor grote pagina's. Door content-visibility: auto; in te stellen op secties onder de vouw, vertel je de browser dat deze de layout, paint en composite voor die inhoud kan overslaan tot het moment dat het de viewport bijna binnenkomt. Dit vermindert de initiële rendering-werklast, waardoor de main thread eerder vrijkomt om het LCP-element te tekenen.

De sleutel is om content-visibility: auto te combineren met contain-intrinsic-size, wat een tijdelijke grootte (placeholder size) geeft aan de verborgen inhoud. Zonder dit wordt het gedrag van de scrollbalk grillig, omdat de browser niet weet hoe hoog de verborgen secties zijn.

/* Toepassen op secties onder de vouw */
.below-fold-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px; /* Geschatte hoogte van de sectie */
}

/* Voorbeeld: een lange artikelpagina */
.article-comments {
  content-visibility: auto;
  contain-intrinsic-size: auto 800px;
}

.related-products {
  content-visibility: auto;
  contain-intrinsic-size: auto 600px;
}

.site-footer {
  content-visibility: auto;
  contain-intrinsic-size: auto 300px;
}

Impact op de prestaties: Volgens een blogpost van Chrome Developers verminderde het toepassen van content-visibility: auto op secties onder de vouw van een blogpagina de renderingtijd met tot wel 7x. De browser slaat de layout, paint en composite voor deze secties volledig op, waardoor de main thread zich kan richten op de inhoud boven de vouw, inclusief het LCP-element. De browserondersteuning beslaat alle moderne browsers: Chromium, Firefox en Safari 18+.

Werk uitbesteden met Web Workers

Web Workers maken het mogelijk om JavaScript in een achtergrond-thread te draaien, volledig los van de main thread. Zware berekeningen die in een Worker draaien, kunnen het renderen niet blokkeren. Deze site, corewebvitals.io, gebruikt een Web Worker voor de verwerking van analytics, en het prestatievoordeel is reëel: de main thread blijft vrij om zonder onderbreking te kunnen tekenen.

Dat gezegd hebbende, zijn Web Workers geen veelvoorkomend patroon op de meeste websites. Ze vereisen een apart JavaScript-bestand, communicatie via postMessage en hebben geen toegang tot de DOM. De meeste CMS-platformen en sitebuilders bieden er geen ingebouwde ondersteuning voor, wat de implementatie lastig maakt zonder maatwerk. Als je de technische capaciteiten hebt om ze te gebruiken, zijn ze een van de meest effectieve manieren om de main thread vrij te houden. Maar voor de meeste teams zullen de andere optimalisaties op deze pagina een grotere praktische impact hebben.

// main.js: Maak een worker aan en stuur data voor verwerking
const worker = new Worker('/js/analytics-worker.js');

// Verplaats zware analytics-verwerking naar de worker-thread
worker.postMessage({
  type: 'process-events',
  events: collectedEvents
});

// Ontvang resultaten zonder de main thread te blokkeren
worker.onmessage = (event) => {
  console.log('Analytics processed:', event.data.summary);
};

// analytics-worker.js: Draait in een achtergrond-thread
self.onmessage = (event) => {
  if (event.data.type === 'process-events') {
    // Zware berekeningen gebeuren hier, los van de main thread
    const summary = processEvents(event.data.events);
    self.postMessage({ summary });
  }
};

Praktijkimpact

  • Casus 1: De render-blocking CSS-bottleneck: DebugBear analyseerde een site waar een groot CSS-bestand zorgde for een duidelijke render delay. De LCP-afbeelding was al gedownload, maar de browser zat vast bij het parsen van de CSS. Door simpelweg de kritieke CSS te inlinen, kon de browser de pagina-inhoud – inclusief het LCP-element – vrijwel direct na het parsen van de HTML tekenen. Dit loste de render delay veroorzaakt door het stylesheet effectief op.
  • Casus 2: De A/B-testboete: Een grote e-commerce-site ontdekte dat hun LCP werd opgehouden door een synchroon A/B-testscript. Hoewel de LCP-afbeelding snel was gedownload, blokkeerde het script de main thread terwijl het bepaalde welke productafbeelding moest worden getoond. Door de A/B-test na de initiële page load uit te voeren voor niet-kritieke elementen, verbeterde hun LCP onmiddellijk met meer dan 400ms. Al deze winst werd volledig teruggewonnen op de Element Render Delay.

Checklist: hoe je Element Render Delay elimineert

Een hoge Element Render Delay wijst op een overbelaste main thread. De oplossingen draaien om het wegnemen van die drukte, zodat de browser kan tekenen.

  1. Valideer met RUM: Gebruik echte gebruikersdata om te bevestigen dat Element Render Delay je primaire LCP-bottleneck is voordat je begint met optimaliseren.
  2. Verwijder ongebruikte CSS: Controleer en verwijder CSS-regels die nooit worden toegepast. Dit is de CSS-optimalisatie met de allerhoogste impact. Gebruik tools zoals PurgeCSS of het tabblad Coverage in DevTools.
  3. Houd stylesheets klein en cachebaar: Streef naar ongeveer 10-15 kB (gecomprimeerd) per CSS-bestand. Snel genoeg om snel te downloaden, groot genoeg om een overvloed aan parallelle verzoeken te voorkomen. Laat de browser ze cachen voor terugkerende bezoekers.
  4. Hak JavaScript long tasks in stukken: Geen enkel script mag langer dan 50 ms draaien. Yield naar de main thread om rendering-updates toe te staan.
  5. Controleer en defer third-party-scripts: Vraag jezelf af: verdient elk extern script zijn plek op de pagina? Defer alles wat niet essentieel is voor de eerste paint.
  6. Gebruik SSR of SSG: Vertrouw niet op client-side JavaScript om je LCP-element te renderen. Stuur kant-en-klare HTML vanaf de server.
  7. Zorg voor directe LCP-zichtbaarheid: Verwijder animaties, scripts of stijlen die het LCP-element verbergen tijdens het laden van de pagina.
  8. Gebruik content-visibility: auto: Vertel de browser bij lange pagina's om het renderen van inhoud buiten het scherm over te slaan. Zo blijft de main thread vrij voor het tekenen van de inhoud boven de vouw.
  9. Verminder de DOM-grootte: Maak diep geneste HTML platter, verwijder overbodige wrappers en virtualiseer lange lijsten om de kosten van layout- en paint-operaties te verlagen.

Volgende stappen: LCP blijven optimaliseren

Element Render Delay is de laatste fase. Om ze alle vier aan te pakken, ga je verder met:

  • LCP-problemen identificeren & oplossen: de volledige diagnostische methodologie voor het vinden en oplossen van alle LCP-problemen met behulp van field data en lab data.
  • De LCP-afbeelding optimaliseren: selectie van afbeeldingsformaten, responsieve afbeeldingen, preloading en veelgemaakte fouten bij afbeeldingoptimalisatie.
  • Resource Load Delay: zorg dat de browser de LCP-resource zo vroeg mogelijk ontdekt. Dit is vaak de grootste individuele LCP-bottleneck.
  • Resource Load Duration: verkort de downloadtijd via compressie, moderne formaten, CDN-configuratie en netwerkoptimalisatie.

Zoek uit wat echt traag is.

Ik leg je critical rendering path bloot met echte data. Je krijgt een fix-lijst op prioriteit, geen Lighthouse-rapport.

Boek een audit
Optimiseer de rendervertraging van het LCP-elementCore Web Vitals Optimiseer de rendervertraging van het LCP-element