Optimaliseer de render delay van het LCP-element.

Van download tot weergave: leer hoe je de rendervertraging van het element binnen 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 afronden van de download van de LCP-bron en het moment dat deze zichtbaar op het scherm staat.

Optimaliseer de LCP Element Render Delay

Van de vier LCP-fases is Element Render Delay de meest onbegrepen fase. Teams optimaliseren de TTFB, elimineren de Resource Load Delay en comprimeren bestanden om de Resource Load Duration in te korten. 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 vanaf het moment dat de LCP-bron klaar is met downloaden tot het moment dat 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 te druk is met andere taken om het daadwerkelijk te tekenen. Deze vertraging is een directe straf voor je LCP-score en voegt soms 200 ms 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-bron (bijvoorbeeld een afbeeldingsbestand of een webfont) bij de browser aankomt. Het eindigt wanneer het LCP-element zichtbaar op het scherm is getekend. Het is vrij letterlijk de allerlaatste stap.

Voor op tekst gebaseerde LCP-elementen die een systeemlettertype gebruiken, is deze vertraging vaak nul. Er is immers geen externe bron nodig. Maar voor de overgrote meerderheid van de sites, waar het LCP-element een afbeelding is of een aangepast webfont gebruikt, is deze fase vaak de grootste bottleneck. De browser besteedt deze tijd aan CPU-gebonden 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. Het is een proces met meerdere fasen, vaak het Critical Rendering Path genoemd. Zie het als een lopende band in een fabriek:

  1. Blauwdrukken maken (DOM & CSSOM): De browser parset de HTML om het Document Object Model (DOM) op te bouwen en de CSS om het CSS Object Model (CSSOM) te bouwen. Dit zijn de blauwdrukken voor de pagina-inhoud en de styling.
  2. Blauwdrukken combineren (Render Tree): Het DOM en CSSOM worden gecombineerd 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. De pixels inkleuren (Paint): De browser vult de pixels voor elk element in. Hierbij wordt rekening gehouden met tekst, kleuren, afbeeldingen, randen en schaduwen.
  5. Lagen samenvoegen (Composite): De pagina wordt op verschillende lagen getekend. Deze worden in de juiste volgorde samengevoegd om de uiteindelijke schermafbeelding te maken.

De Element Render Delay is de tijd die deze laatste fasen in beslag nemen: Layout, Paint en Composite. Deze hele lopende band wordt beheerd door één enkele werknemer: de main thread. Als die werknemer druk is met het uitvoeren van een long task in JavaScript of het parsen van een gigantisch CSS-bestand, komt de lopende band tot stilstand. De LCP-afbeelding is misschien al binnen, maar wacht op het laadperron totdat de main thread vrij is om deze te verwerken en te tekenen.

Hoe je Element Render Delay opspoort

Dit probleem diagnosticeren volgt een strikt proces in 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 echt probleem is voor je daadwerkelijke gebruikers. Een professionele Real User Monitoring (RUM) tool, zoals mijn eigen CoreDash, is onmisbaar. Deze splitst de LCP van je site op in zijn vier onderdelen. Als je RUM-data een aanzienlijke Element Render Delay op het 75e percentiel laat zien, heb je een gevalideerd probleem met hoge impact om op te lossen.

Stap 2: Diagnoseer met DevTools
Zodra RUM de probleempagina's heeft geïdentificeerd, gebruik je het Chrome DevTools Performance-paneel om de oorzaak te vinden. Onze gids Diagnose LCP with the Chrome DevTools Performance panel behandelt de throttling-setup en de opname-workflow stap voor stap. Specifiek voor render delay:

  1. Neem het laden van een pagina op met de "Record and reload" knop.
  2. Open het "LCP breakdown" inzicht in de Insights-zijbalk en noteer de waarde voor Element render delay.
  3. Bestudeer nu de Main track in de tijdlijn. Zoek naar long tasks (gele blokken met rode hoeken) die plaatsvinden tussen het einde van het netwerkverzoek van de LCP-bron en de LCP-timingmarkering. Deze taken zijn de directe oorzaak van je vertraging. Beweeg je muis eroverheen 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 pixels totdat alle CSS-bestanden in de <head> zijn gedownload en geparset. Een grote, complexe stylesheet kan de main thread honderden milliseconden bezighouden. Dit vertraagt de start van de layout- en paint-fasen. Dit verergert wanneer sites meerdere stylesheets laden, die elk een apart netwerkverzoek en parse-cyclus vereisen. Voor gedetailleerde strategieën om je CSS-payload te verkleinen, bekijk je onze gids over removing unused CSS.

De oplossing: Maak je CSS klein, schoon en cachebaar.

  • Verwijder ongebruikte CSS: Dit is de optimalisatie met de hoogste impact. Op grote sites kan ongebruikte CSS 70% of meer van de totale stylesheetgrootte uitmaken. Tools zoals PurgeCSS kunnen je HTML en JavaScript scannen om ongebruikte selectors te identificeren. Het verwijderen van dode regels vermindert zowel de downloadtijd als de parse-tijd op de main thread.
  • Streef naar kleine, cachebare stylesheets: De ideale grootte voor een CSS-bestand is ongeveer 10-15 kB (gecomprimeerd). Kleiner dan dat, en je loopt het risico op te veel parallelle verzoeken, elk met eigen verbindings-overhead. Groter dan dat, en de blokkeertijd neemt toe, vooral op trage mobiele netwerken. Een enkele, goed gestructureerde stylesheet in die grootte downloadt snel, parset snel en wordt door de browser in de cache opgeslagen voor volgende bezoeken.
  • Inline CSS alleen als laatste redmiddel: Het inlinen van kritieke CSS in een <style> blok elimineert het netwerkverzoek bij de eerste keer laden van de pagina, maar dit heeft een prijs: ge-inlinete CSS kan niet in de browser-cache worden opgeslagen. Elke terugkerende bezoeker downloadt het opnieuw bij elke pagina. Voor de meeste sites met terugkerende gebruikers is een kleine externe stylesheet, die de browser in de cache opslaat, de betere keuze. Inlinen is alleen logisch voor landingspagina's met heel weinig terugkerende bezoekers.

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

Oorzaak: Long tasks in JavaScript

Het probleem: Dit is de meest voorkomende oorzaak. Zware uitvoering van JavaScript eist de main thread volledig op, of dit nu komt door frameworks, analytics-scripts, A/B-testtools of slecht geoptimaliseerde code. Eén enkele langlopende taak kan de rendering honderden milliseconden blokkeren. Dit voegt direct tijd toe aan de Element Render Delay. Google definieert een long task als elke taak die langer dan 50 ms duurt. Taken die langer dan 200 ms duren, worden als kritiek lang beschouwd. Voor een compleet overzicht van strategieën om JavaScript uit te stellen, zie ons artikel 14 methods to defer JavaScript.

De oplossing: Breek het werk op.

  • Yield aan de main thread: Long tasks moeten worden opgesplitst in kleinere stukken. Dit doe je door de controle periodiek terug te geven aan de browser via yielding met setTimeout(..., 0) of de nieuwere scheduler.yield() API. Dit stelt de browser in staat om tussendoor rendering-updates uit te voeren.
  • Optimaliseer en stel third-parties uit: Controleer elk third-party script. Als ze niet essentieel zijn voor de eerste render, laad ze dan met het defer-attribuut of injecteer ze pas nadat de pagina is geladen. Scripts voor A/B-testen zijn extra problematisch omdat ze vaak ontworpen zijn om rendering te blokkeren.
  • Gebruik requestAnimationFrame voor visuele updates: Als JavaScript tijdens het laden van de pagina DOM-manipulaties moet uitvoeren, wikkel het werk dan in requestAnimationFrame. Dit plant het werk net voor de volgende paint in. Dit zorgt ervoor dat de browser de kans krijgt om frames te renderen tussen JavaScript-operaties 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, zichtbaar in de "Main" track. Om te achterhalen welke scripts verantwoordelijk zijn:

  1. Neem het laden van een pagina op in het Performance-paneel.
  2. Zoek de LCP-markering in de Timings-track.
  3. Bestudeer de Main track voor long tasks die plaatsvinden tussen het voltooien van het netwerkverzoek voor de LCP-bron en de LCP-markering.
  4. Klik op deze taken om de call stack te bekijken in het Summary-paneel. De call stack onthult het bronbestand en de functie die verantwoordelijk is voor de long task.

Veelvoorkomende boosdoeners onder third-parties

Gebaseerd op praktijkervaring uit consultancy, zijn de meest voorkomende third-party scripts die Element Render Delay veroorzaken:

  • A/B-testtools (Optimizely, VWO, AB Tasty): Deze blokkeren rendering vaak bewust om content-flicker tussen varianten te voorkomen. De beslissing voor het experiment naar de server verplaatsen (server-side testing) lost dit probleem volledig op.
  • Tag managers met synchrone tags: Een tag manager die is geconfigureerd met synchrone (non-async) tags kan render blocking scripts injecteren. Controleer je container om er zeker van te zijn dat alle tags vuren na DOM ready of window load.
  • Consent management platforms: Cookie-banners die rendering blokkeren totdat er een beslissing is genomen, kunnen de LCP vertragen. Gebruik een async implementatie die het critical rendering path niet blokkeert.
  • Chat widgets: Live chat-scripts voeren vaak zware initialisatiecode uit bij het laden van de pagina. Stel het laden uit totdat de pagina interactief is, of laad ze pas bij interactie van de gebruiker (bijvoorbeeld een klik).

Oorzaak: Client-side rendering (CSR)

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

De oplossing: Render op de server. Er is geen andere manier. 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 door de server wordt verzonden. Dit elimineert de volledige door JavaScript aangedreven renderingfase als bron van vertraging.

Oorzaak: Inhoud verborgen door andere code

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

De oplossing: Zorg voor onmiddellijke zichtbaarheid. Gebruik voor het LCP-element geen inkomende animaties of logica die het verbergt tijdens het eerste laden. Het element moet zichtbaar zijn in de DOM en zo gestyled zijn dat het vanaf de allereerste paint zichtbaar is. Configureer A/B-testtools zodat ze asynchroon draaien, of zorg dat ze minimale impact hebben op de zichtbaarheid van het LCP-element.

Oorzaak: Buitensporige DOM-grootte

Het probleem: Een grote DOM (meer dan 1.500 nodes) verhoogt de kosten van elke rendering-operatie. Elke layout-berekening, style-herberekening en paint-operatie moet meer nodes verwerken. Dit kost meer tijd op de main thread. Zelfs als je CSS en JavaScript goed geoptimaliseerd zijn, voegt een opgeblazen DOM render delay toe door pure omvang. Voor gedetailleerde strategieën om je DOM-grootte te reduceren, zie onze gids over avoiding excessive DOM size.

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

  • Vereenvoudig de HTML-structuur: Verwijder onnodige wrapper-elementen. Maak diep geneste structuren platter. Gebruik CSS Grid of Flexbox in plaats van extra <div>-elementen voor de lay-out.
  • Virtualiseer lange lijsten: Voor pagina's met honderden lijstitems (productrasters, datatabellen) gebruik je virtualisatie-libraries die alleen de items renderen die momenteel zichtbaar zijn in de viewport.
  • Lazy-render below-the-fold content: Gebruik content-visibility: auto (hieronder behandeld) om het renderen van offscreen-secties volledig over te slaan.

Geavanceerde tactieken: Volledige controle over rendering

Complexe applicaties hebben meer controle over de main thread nodig.

Prestaties ontgrendelen met content-visibility

De CSS-eigenschap content-visibility is gebouwd voor grote pagina's. Door content-visibility: auto; in te stellen op secties van je pagina die zich below the fold bevinden, vertel je de browser dat deze de layout-, paint- en composite-taken voor die inhoud kan overslaan totdat deze de viewport nadert. Dit vermindert de initiële rendering-werklast. Hierdoor is de main thread eerder vrij om het LCP-element te tekenen.

De sleutel is om content-visibility: auto te combineren met contain-intrinsic-size. Dit geeft een placeholder-formaat voor de verborgen inhoud. Zonder dit wordt het gedrag van de scrollbar onvoorspelbaar omdat de browser niet weet hoe hoog de verborgen secties zijn.

/* Toepassen op below-the-fold secties */
.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;
}

Prestatie-impact: Volgens een Chrome Developers blog post verminderde het toepassen van content-visibility: auto op below-fold secties van een blogpagina de renderingtijd tot wel 7x. De browser slaat het layout-, paint- en composite-werk voor deze secties volledig over. Zo komt de main thread vrij om zich te focussen op de above-the-fold inhoud, waaronder het LCP-element. Browserondersteuning dekt alle moderne browsers: Chromium, Firefox en Safari 18+.

Werk uitbesteden met Web Workers

Met Web Workers kun je JavaScript in een achtergrond-thread draaien, volledig los van de main thread. Elke zware berekening die in een Worker draait, kan de rendering niet blokkeren. Deze site, corewebvitals.io, gebruikt een Web Worker voor de analytics-verwerking, en het prestatievoordeel is reëel: de main thread blijft vrij om zonder onderbreking te 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 sitebouwers bieden hier geen ingebouwde ondersteuning voor, wat de implementatie zonder maatwerk lastig maakt. Als je de technische vaardigheden 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 in de praktijk meer impact hebben.

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

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

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

// analytics-worker.js: Draait in een background 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 });
  }
};

Impact in de praktijk

  • Casus 1: De render blocking CSS-bottleneck: DebugBear analyseerde een site waar een groot CSS-bestand voor een aanzienlijke render delay zorgde. De LCP-afbeelding was gedownload, maar de browser zat vast in het parsen van CSS. Door simpelweg kritieke CSS in te linen, kon de browser vrijwel direct na het parsen van de HTML de pagina-inhoud, inclusief het LCP-element, tekenen. Dit elimineerde effectief de render delay veroorzaakt door de stylesheet.
  • Casus 2: De A/B-test penalty: Een grote e-commercesite ontdekte dat hun LCP werd tegengehouden door een synchroon A/B-testscript. Hoewel de LCP-afbeelding snel was gedownload, blokkeerde het script de main thread terwijl het bepaalde welke productafbeelding getoond moest worden. Het verplaatsen van de A/B-test zodat deze na de initiële page load liep voor niet-kritieke elementen, verbeterde hun LCP direct met meer dan 400 ms. Dit werd allemaal teruggewonnen uit de Element Render Delay.

Checklist: Zo elimineer je Element Render Delay

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

  1. Valideer met RUM: Gebruik data van echte gebruikers 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 hoogste impact. Gebruik tools zoals PurgeCSS of het Coverage-tabblad in DevTools.
  3. Houd stylesheets klein en cachebaar: Streef naar ongeveer 10-15 kB (gecomprimeerd) per CSS-bestand. Klein genoeg om snel te downloaden, groot genoeg om buitensporige parallelle verzoeken te vermijden. Laat de browser ze cachen voor terugkerende bezoekers.
  4. Breek long tasks in JavaScript op: Geen enkel script mag langer dan 50 ms draaien. Yield aan de main thread om rendering-updates toe te staan.
  5. Controleer en stel third-party scripts uit: Vraag jezelf af: verdient elk third-party script zijn plek op de pagina? Stel alles uit 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 volledig gevormde HTML vanaf de server.
  7. Zorg voor onmiddellijke LCP-zichtbaarheid: Verwijder alle 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 offscreen inhoud over te slaan. Dit maakt de main thread vrij om content above the fold te tekenen.
  9. Verklein de DOM-grootte: Maak diep geneste HTML platter, verwijder onnodige wrappers en virtualiseer lange lijsten om de kosten van layout- en paint-operaties te verlagen.

Volgende stappen: Ga door met LCP optimaliseren

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

  • LCP-problemen vinden en oplossen: De complete diagnostische methodologie voor het vinden en oplossen van alle LCP-problemen met behulp van field data en lab-tools.
  • De LCP-afbeelding optimaliseren: Selectie van bestandsformaten, responsieve afbeeldingen, preloading en veelgemaakte fouten bij het optimaliseren van afbeeldingen.
  • Resource Load Delay: Zorg ervoor dat de browser de LCP-bron zo vroeg mogelijk ontdekt. Dit is vaak de allergrootste LCP-bottleneck.
  • Resource Load Duration: Verkort de laadtijd door compressie, moderne formaten, CDN-configuratie en netwerkoptimalisatie.

Live data. Geen 28-daags gemiddelde.

CoreDash splitst elke metric uit per route, toestel, browser en verbinding.

Bekijk CoreDash
Optimaliseer de render delay van het LCP-element. Core Web Vitals Optimaliseer de render delay van het LCP-element.