Optimaliseer de LCP Element Render Delay

Van gedownload naar getoond: leer hoe u de element render delay fase van de Largest Contentful Paint kunt verbeteren.

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-03-03
  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 informatiecentrum. Element Render Delay is de laatste fase in de LCP tijdlijn en vertegenwoordigt het gat tussen het moment waarop de LCP-resource klaar is met downloaden en het moment waarop deze zichtbaar op het scherm wordt getoond (painted).

Optimaliseer de LCP Element Render Delay

Van de vier LCP fasen is de Element Render Delay de meest onbegrepen fase. Teams optimaliseren de TTFB, elimineren Resource Load Delay en comprimeren assets om de Resource Load Duration te verkorten. Ze zien de netwerk-waterval eindigen en gaan ervan uit dat het werk klaar is. Dat is een misvatting.

De Element Render Delay is de tijd vanaf het moment dat de LCP-resource klaar is met downloaden tot het moment dat het element volledig is getoond op het scherm van de gebruiker. 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 belasting op uw LCP score, waarbij soms 200ms of meer wordt toegevoegd nadat alle netwerkverzoeken zijn voltooid.

Precieze Definitie: Het 'Last Mile' Probleem

Element Render Delay begint op het moment dat de laatste byte van de LCP-resource (bijv. een afbeelding of een webfont) bij de browser aankomt. Het eindigt wanneer het LCP-element zichtbaar op het scherm is getoond. Het is letterlijk de laatste stap.

Voor tekstgebaseerde LCP-elementen die een systeemfont gebruiken, is deze vertraging vaak nul, omdat er geen externe resource hoeft te worden opgehaald. Echter, 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-intensieve taken: het vertalen van gedownloade bits naar zichtbare pixels.

Het 'Waarom': Een Vastgelopen Assemblagelijn

Om render delay op te lossen, moet u begrijpen hoe een browser een pagina tekent. Dit is een proces met meerdere fasen, vaak het Critical Rendering Path genoemd. Zie het als een assemblagelijn in een fabriek:

  1. De Blauwdrukken Maken (DOM & CSSOM): De browser analyseert de HTML om het Document Object Model (DOM) op te bouwen en de CSS om het CSS Object Model (CSSOM) op te bouwen. Dit zijn de blauwdrukken voor de pagina-inhoud en de styling ervan.
  2. Blauwdrukken Combineren (Render Tree): De DOM en CSSOM worden gecombineerd tot een Render Tree, die alleen de nodes bevat 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 Kleuren (Paint): De browser vult de pixels voor elk element in, rekening houdend met tekst, kleuren, afbeeldingen, randen en schaduwen.
  5. Lagen Samenstellen (Composite): De pagina wordt op verschillende lagen getekend, die vervolgens in de juiste volgorde worden samengevoegd om het uiteindelijke schermbeeld te creëren.

De Element Render Delay is de tijd die wordt verbruikt door deze laatste fasen: Layout, Paint en Composite. Deze hele assemblagelijn wordt gerund door één enkele werker: de main thread. Als die werker bezig is met het uitvoeren van een lange JavaScript-taak of het analyseren van een enorm CSS-bestand, komt de assemblagelijn tot stilstand. De LCP-afbeelding is misschien wel aangekomen, maar ligt op het laadperron te wachten tot de main thread vrijkomt om deze te verwerken en te tekenen.

Hoe u Element Render Delay Kunt Lokaliseren

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 u DevTools opent, moet u bevestigen dat Element Render Delay een reëel probleem is voor uw werkelijke gebruikers. Een professionele Real User Monitoring (RUM) tool zoals mijn eigen tool, CoreDash, is essentieel. Het splitst de LCP van uw site op in de vier onderdelen. Als uw RUM-data een significante Element Render Delay laat zien op het 75e percentiel, heeft u een gevalideerd probleem met een hoge impact om op te lossen.

Stap 2: Diagnosticeer met DevTools
Zodra RUM de probleem-pagina's heeft geïdentificeerd, gebruikt u het Chrome DevTools Performance paneel om de oorzaak te ontleden.

  1. Ga naar het tabblad Performance en schakel het selectievakje "Web Vitals" in.
  2. Klik op de knop "Record and reload page".
  3. Klik in de "Timings" track op de LCP-marker. Het tabblad "Summary" eronder toont de exacte duur voor elk van de vier LCP fasen. Noteer de waarde voor Element render delay.
  4. Bekijk nu de Main track in de tijdlijn. Zoek naar lange taken (gele blokken met rode hoeken) die plaatsvinden tussen het einde van het netwerkverzoek van de LCP-resource en de LCP-tijdmarker. Deze taken zijn de directe oorzaak van uw vertraging. Beweeg de 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 zal geen pixels tekenen totdat alle CSS-bestanden die in de <head> zijn gekoppeld, zijn gedownload en geanalyseerd. Een groot, complex stylesheet kan de main thread honderden milliseconden bezet houden, waardoor de start van de layout- en paint-fasen wordt vertraagd. Dit wordt verergerd wanneer sites meerdere stylesheets laden, die elk een apart netwerkverzoek en analysecyclus vereisen. Voor gedetailleerde strategieën over het verminderen van de CSS payload, zie onze gids over het verwijderen van ongebruikte CSS.

De Oplossing: Maak uw CSS klein, schoon en cachebaar.

  • Verwijder Ongebruikte CSS: Dit is de optimalisatie met de allerhoogste impact. Op grote sites kan ongebruikte CSS 70% of meer van de totale stylesheet-grootte beslaan. Tools zoals PurgeCSS kunnen uw HTML en JavaScript scannen om ongebruikte selectors te identificeren. Het verwijderen van dode regels vermindert zowel de downloadtijd als de analysetijd op de main thread.
  • Streef naar kleine, cachebare stylesheets: De 'sweet spot' voor een CSS-bestand is ongeveer 10-15kB (gecomprimeerd). Kleiner dan dat en u riskeert opsplitsing in te veel parallelle verzoeken, elk met zijn eigen verbindingsoverhead. Groter dan dat en de blokkeringstijd groeit, vooral op trage mobiele netwerken. Een enkel goed gestructureerd stylesheet in dat bereik downloadt snel, analyseert snel en wordt door de browser gecacht voor herhaalbezoeken.
  • Inline CSS alleen als laatste redmiddel: Het inlinen van kritieke CSS in een <style> blok elimineert het netwerkverzoek voor de eerste paginalading, maar het heeft een prijs: ingesloten CSS kan niet door de browser worden gecacht. Elke terugkerende bezoeker downloadt het opnieuw bij elke pagina. Voor de meeste sites met terugkerende gebruikers is een klein extern stylesheet dat de browser cacht de betere keuze. Inlining is alleen zinvol voor landingspagina's met zeer weinig terugkerende bezoekers.

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

Oorzaak: Lange JavaScript-taken

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 meer dan 50ms duurt, en taken die de 200ms overschrijden worden als kritiek lang beschouwd. Voor een volledige verzameling van JavaScript-uitstelstrategieën, zie ons artikel over 14 methoden om JavaScript uit te stellen.

De Oplossing: Splits het werk op.

  • Geef over aan de Main Thread (Yield): Lange taken moeten in kleinere stukken worden gebroken. Dit kan worden gedaan door de controle periodiek terug te geven aan de browser met behulp van setTimeout(..., 0) of de nieuwere scheduler.yield() API. Dit stelt de browser in staat om tussentijds rendering-updates uit te voeren.
  • Optimaliseer en Stel Third-Parties Uit: Controleer elk third-party script. Als ze niet essentieel zijn voor de initiële paginalading, 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 doelbewust 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 in om net voor de volgende paint te draaien, zodat de browser de kans krijgt om frames te renderen tussen JavaScript-bewerkingen door.

Lange Taken Identificeren in DevTools

In het Chrome DevTools Performance paneel verschijnen lange taken als gele blokken met een rode driehoek in de rechterbovenhoek in de "Main" track. Om te identificeren welke scripts verantwoordelijk zijn:

  1. Registreer een paginalading in het Performance paneel.
  2. Zoek de LCP-marker in de Timings track.
  3. Controleer de Main track op lange taken die plaatsvinden tussen de voltooiing van het netwerkverzoek van de LCP-resource en de LCP-marker.
  4. Klik op deze taken om de call stack te zien in het Summary paneel. De call stack onthult het bronbestand en de functie die verantwoordelijk is voor de lange taak.

Veelvoorkomende Third-Party Boosdoeners

Gebaseerd op praktijkervaring in consultancy, zijn 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 het flikkeren van content tussen varianten te voorkomen. Het verplaatsen van de experimentbeslissing naar de server-side (server-side testing) elimineert dit probleem volledig.
  • Tag managers met synchrone tags: Een tag manager die is geconfigureerd met synchrone (niet-asynchrone) tags kan render-blocking scripts injecteren. Controleer uw container om er zeker van te zijn dat alle tags zijn ingesteld om te vuren na DOM ready of window load.
  • Consent management platforms (CMP): Cookie-toestemmingsbanners die het renderen blokkeren totdat er een beslissing is genomen, kunnen de LCP vertragen. Gebruik een asynchrone 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 tot nadat de pagina interactief is, of laad ze bij gebruikersinteractie (bijv. 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, het LCP-element in te voegen, en dan kan de browser het eindelijk renderen. Dit hele proces is één grote render delay.

De Oplossing: Render op de server. Er is geen andere weg. 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 in de DOM, maar wordt het verborgen door CSS (bijv. opacity: 0) of door een script, zoals een "reveal on scroll" animatie of een A/B-testtool die nog aan het beslissen is welke variant moet worden getoond. Het element is gedownload en klaar, maar het kan niet worden getoond omdat het nog niet zichtbaar is.

De Oplossing: Zorg voor onmiddellijke zichtbaarheid. Gebruik voor het LCP-element geen verschijnings-animaties of enige logica die het verbergt bij de eerste lading. Het element moet zichtbaar zijn in de DOM en gestyled zijn om vanaf de allereerste paint zichtbaar te zijn. Configureer A/B-testtools om asynchroon te draaien of zorg ervoor dat ze een minimale impact hebben op de zichtbaarheid van het LCP-element.

Oorzaak: Overmatige DOM-grootte

Het Probleem: Een grote DOM (meer dan 1.500 nodes) verhoogt de kosten van elke rendering-operatie. Elke layout-berekening, herberekening van stijlen en paint-operatie moet meer nodes verwerken, wat meer tijd kost op de main thread. Zelfs als uw CSS en JavaScript goed geoptimaliseerd zijn, voegt een opgeblazen DOM render delay toe door puur volume. Voor gedetailleerde strategieën om de DOM-grootte te verminderen, zie onze gids over het vermijden van een overmatige DOM-grootte.

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 layout.
  • Virtualiseer lange lijsten: Gebruik voor pagina's met honderden lijstitems (productoverzichten, datatabellen) virtualisatie-bibliotheken die alleen de items renderen die momenteel zichtbaar zijn in de viewport.
  • Lazy-render content 'below-the-fold': Gebruik content-visibility: auto (hieronder behandeld) om het renderen van secties die buiten het scherm vallen volledig over te slaan.

Geavanceerde Tactieken: Volledige Controle over Rendering

Complexe applicaties hebben meer controle over de main thread nodig.

Prestaties Ontsluiten met content-visibility

De CSS eigenschap content-visibility is gebouwd voor grote pagina's. Door content-visibility: auto; in te stellen op secties van uw pagina die zich 'below the fold' bevinden, vertelt u de browser dat deze het layout-, paint- en composite-werk voor die inhoud kan overslaan totdat het op het punt staat de viewport te betreden. Dit vermindert de initiële rendering-werklast, waardoor de main thread vrijkomt om het LCP-element sneller te tonen.

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

/* Toepassen op secties onder de vouw (below-the-fold) */
.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 blogpost, verminderde het toepassen van content-visibility: auto op secties onder de vouw van een blogpagina de renderingtijd met maximaal 7x. De browser slaat layout-, paint- en composite-werk voor deze secties volledig over, waardoor de main thread zich kan concentreren op content boven de vouw, inclusief het LCP-element. Browserondersteuning omvat alle moderne browsers: Chromium, Firefox en Safari 18+.

Werk Verplaatsen met Web Workers

Met Web Workers kunt u JavaScript in een achtergrond-thread draaien, volledig los van de main thread. Elke zware berekening die in een Worker draait, kan het renderen niet blokkeren. Deze site, corewebvitals.io, gebruikt een Web Worker voor zijn analytics-verwerking, en het prestatievoordeel is reëel: de main thread blijft vrij om zonder onderbreking te tekenen.

Dat gezegd hebbende, Web Workers zijn geen algemeen 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 er geen ingebouwde ondersteuning voor, wat implementatie lastig maakt zonder maatwerk. Als u de technische capaciteit heeft 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 verwerkt:', event.data.summary);
};

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

Impact in de Praktijk

  • Geval 1: De Render-Blocking CSS Bottleneck: DebugBear analyseerde een site waar een groot CSS-bestand een merkbare render delay veroorzaakte. De LCP-afbeelding was gedownload, maar de browser zat vast bij het analyseren van CSS. Door simpelweg kritieke CSS te inlinen, kon de browser de pagina-inhoud, inclusief het LCP-element, vrijwel onmiddellijk nadat de HTML was geanalyseerd tekenen, waardoor de render delay veroorzaakt door het stylesheet effectief werd geëlimineerd.
  • Geval 2: De A/B-test Boete: 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 paginalading te laten draaien voor niet-kritieke elementen, verbeterde hun LCP onmiddellijk met meer dan 400ms, wat volledig werd teruggewonnen op de Element Render Delay.

Checklist: Hoe Element Render Delay te Elimineren

Een hoge Element Render Delay duidt op een overbelaste main thread. De oplossingen zijn gericht op het vrijmaken van die thread zodat de browser kan tekenen.

  1. Valideer met RUM: Gebruik real user data om te bevestigen dat Element Render Delay uw primaire LCP bottleneck is voordat u 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 de Coverage-tab in DevTools.
  3. Houd stylesheets klein en cachebaar: Streef naar ongeveer 10-15kB (gecomprimeerd) per CSS-bestand. Klein genoeg om snel te downloaden, groot genoeg om overmatige parallelle verzoeken te vermijden. Laat de browser ze cachen voor terugkerende bezoekers.
  4. Splits Lange JavaScript-taken op: Geen enkel script mag langer dan 50ms draaien. Geef de controle terug aan de main thread (yield) om rendering-updates toe te staan.
  5. Controleer en Stel Third-Party Scripts Uit: Vraag uzelf af: verdient elk third-party script zijn plaats op de pagina? Stel alles uit wat niet essentieel is voor de initiële paint.
  6. Gebruik SSR of SSG: Vertrouw niet op client-side JavaScript om uw LCP-element te renderen. Verstuur volledig gevormde HTML vanaf de server.
  7. Zorg voor Onmiddellijke LCP-zichtbaarheid: Verwijder alle animaties, scripts of stijlen die het LCP-element verbergen bij het laden van de pagina.
  8. Gebruik content-visibility: auto: Vertel de browser voor lange pagina's om het renderen van content buiten het scherm over te slaan, zodat de main thread vrijkomt voor het tekenen van content boven de vouw.
  9. Verminder 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 Het Optimaliseren van LCP

Element Render Delay is de laatste fase. Om ze alle vier te dekken, gaat u door met:

  • Identificeer en Los LCP-problemen Op: De volledige diagnostische methodologie voor het vinden en oplossen van alle LCP-problemen met behulp van field data en lab tools.
  • Optimaliseer de LCP Afbeelding: Selectie van afbeeldingsformaten, responsive afbeeldingen, preloading en veelvoorkomende fouten bij afbeeldingsoptimalisatie.
  • Resource Load Delay: Zorg ervoor dat de browser de LCP-resource zo vroeg mogelijk ontdekt. Dit is vaak de grootste individuele LCP-bottleneck.
  • Resource Load Duration: Verkort de downloadtijd door compressie, moderne formaten, CDN-configuratie en netwerkoptimalisatie.

Your Lighthouse score is not the full picture.

Lab tests run on fast hardware with a stable connection. I analyze what your actual visitors experience on real devices and real networks.

Analyze Field Data
Optimaliseer de LCP Element Render DelayCore Web Vitals Optimaliseer de LCP Element Render Delay