De ultieme Core Web Vitals-checklist (2026)

Table of Contents!

• De ultieme Core Web Vitals-checklist
• Core Web Vitals-optimalisatiechecklist
  • Afbeeldingen optimaliseren
  • Web fonts optimaliseren
  • Scripts optimaliseren
  • Styles optimaliseren
  • Resource hints optimaliseren
  • Iconen optimaliseren
  • Serverresponstijden optimaliseren
  • Interactiviteit optimaliseren
  • Core Web Vitals monitoren
  • Critical Rendering Path optimaliseren
  • Cookie consent optimaliseren
  • Single Page Applications optimaliseren
  • Een te grote DOM voorkomen
  • API-requests optimaliseren
  • Chat-widgets optimaliseren
  • Service worker-performance optimaliseren
  • Videocontent optimaliseren

Afbeeldingen optimaliseren

Een grote afbeelding in de zichtbare viewport wordt meestal het Largest Contentful Paint-element. Afbeeldingen aanpakken is daarom een van de beste dingen die je kunt doen voor LCP. Lees hoe je de LCP-afbeelding optimaliseert voor de complete strategie.

• Schaal afbeeldingen naar het maximale formaat waarop ze op het scherm getoond worden. Elke byte aan pixels die niemand ziet is verspild. Goed geschaalde afbeeldingen zijn vaak 50% kleiner of meer, zonder zichtbaar kwaliteitsverlies. Combineer dit met responsive images voor kleinere schermen.
• Pas lazy loading toe op afbeeldingen below the fold. De browser laat ze met rust tot de bezoeker in de buurt scrollt. Zo gaat de vroege bandbreedte naar wat direct in beeld staat, wat helpt voor First Contentful Paint (FCP) en de algemene laadtijd. Pas nooit lazy loading toe op de LCP-afbeelding: de browser wacht dan op de layout voordat het downloaden überhaupt begint.
• Geef de LCP-afbeelding fetchpriority="high" en preload hem alleen als de HTML hem verbergt. Een <img> in de HTML ontdekt de preload scanner sowieso; het attribuut schuift hem naar voren in de wachtrij. Preloaden met <link rel="preload" as="image" fetchpriority="high"> is bedoeld voor een LCP-afbeelding in CSS of geladen via JavaScript, die de browser in de HTML niet kan zien.
• Geef elke afbeelding een width en height mee. Moderne browsers gebruiken beide attributen om de aspect ratio te bepalen voordat de afbeelding geladen is. Zo reserveren ze de juiste hoeveelheid ruimte en verschuift er niets zodra het bestand binnenkomt. Dat scheelt alvast één bron van layout shifts.
• Gebruik WebP of AVIF in plaats van JPEG of PNG. Bij vergelijkbare kwaliteit is een WebP-bestand meestal 25 tot 34% kleiner dan een JPEG, en AVIF kan tot 50% besparen. Met een <picture>-element met fallbacks zit je in elke browser goed.
• Gebruik native lazy loading en schakel lazy loading via JavaScript uit. Het loading="lazy"-attribuut doet hetzelfde werk zonder dat er eerst een script geparsed en uitgevoerd moet worden.
• Geef afbeeldingen een srcset mee, met het sizes-attribuut voor exacte controle. De browser kiest dan de optimale afbeelding voor het apparaat, zodat een telefoon niet langer het bestand voor een groot desktopscherm downloadt.
• Voeg decoding="async" toe. De browser decodeert de afbeelding parallel en blijft ondertussen de rest van de pagina renderen.
• Strip metadata uit afbeeldingen. EXIF-data en dergelijke voegen alleen bytes toe, terwijl verwijderen niets afdoet aan de beeldkwaliteit. ImageOptim en Squoosh doen dit handmatig; Sharp regelt het voor je als onderdeel van je build.
• Gebruik geen CSS-background-image voor het LCP-element. De browser ontdekt een background image in CSS veel later dan een <img> in de HTML. Heb je geen andere keuze, preload hem dan met een <link rel="preload">-tag zodat hij vroeg ontdekt wordt. Lees meer over LCP resource load delay.

Web fonts optimaliseren

Web fonts kunnen de First Contentful Paint vertragen, layout shifts veroorzaken en vechten met andere bestanden om de weinige bandbreedte vroeg in de paginalaadtijd. Waar je de bestanden host, lees je in de handleiding over Google Fonts zelf hosten.

• Zet font-display: swap in je @font-face-regels voor een snellere first paint. De browser toont direct een fallback font en laadt het web font op de achtergrond. Zodra het klaar is, wisselt hij het in. Lees meer over zorgen dat tekst zichtbaar blijft tijdens het laden van web fonts.
• Combineer font-display: optional met een preload om layout shifts door fonts te voorkomen. Bij optional wacht de browser zo'n 100 ms op het web font; is het er dan nog niet, dan blijft de fallback staan voor die pageview en wisselt er niets meer. De preload maakt de kans veel groter dat het font binnen dat tijdvenster binnenkomt.
• Stem de afmetingen van het fallback font af op het web font met font-face descriptors. Stel size-adjust, ascent-override, descent-override en line-gap-override in op de fallback; de tekst verschuift dan amper zodra het web font inwisselt, wat CLS minimaal houdt.
• Subset fonts tot alleen de tekens die je content nodig heeft. Een volledig Latijns font van 100 KB+ zakt na goed subsetten vaak onder de 20 KB. Font Squirrel maakt online subsets; pyftsubset en glyphhanger doen dit op de command line.
• Beperk het aantal font weights en stijlen. Elk extra gewicht voegt 15 tot 50 KB toe om te downloaden. Beperk je tot maximaal 2 kritieke fonts (meestal gepreload) en 2 die pas laat laden, na de eerste render.

Scripts optimaliseren

Scripts kunnen problemen met Interaction to Next Paint veroorzaken, Cumulative Layout Shifts triggeren of de Largest Contentful Paint vertragen. Zelfs een klein, net script vroeg op de pagina vecht om resources en stelt de paint metrics (LCP en FCP) uit. Al je opties vind je in 14 methodes om JavaScript uit te stellen.

• Verwijder JavaScript die je niet nodig hebt. Het tabblad Coverage in Chrome DevTools toont de ongebruikte code. Elk stuk dode code dat je schrapt, scheelt downloadtijd en main thread-tijd.
• Prioriteer scripts op wat ze doen. Een script dat grote wijzigingen aanbrengt in de zichtbare viewport hoort render blocking te zijn. Belangrijke scripts laad je met defer of async, en de extra's wachten tot de browser idle is. De handleiding voor resource prioritization bevat de volledige strategie.
• Splits je code en laad onderdelen met lazy loading. Hak grote JavaScript-bundles op in kleinere chunks die pas laden als ze nodig zijn; zo blijft de eerste load lichter. Elke moderne bundler (webpack, Rollup, esbuild) splitst automatisch bij dynamische imports.
• Minify en recompileer je JavaScript-bestanden standaard met een tool als SWC, Terser of esbuild. Dat haalt doorgaans 30 tot 50% van de bestandsgrootte af.
• Beperk third-party scripts. Elk script voegt DNS lookups, connectie-overhead en main thread-tijd toe. Vraag je dus af of je het nodig hebt en of er een lichter alternatief is. Controleer ze geregeld in het Network-paneel van Chrome DevTools.
• Laad third-party scripts met async of defer. Je weet nooit wat een third-party gaat doen, dus laat ze rendering nooit blokkeren.
• Houd in de gaten wat third-party scripts je echte bezoekers kosten. De Long Animation Frames (LoAF) API of CoreDash laten hun impact zien op INP en LCP in field data. Stel een performance budget in voor third-party JavaScript en evalueer dat geregeld.

Styles optimaliseren

Styles blokkeren rendering standaard. Elke stylesheet in de head vertraagt daardoor de First Contentful Paint en vergroot de LCP element render delay. Houd stylesheets klein en gescheiden, en sla trucjes over die je CSS in tweeën splitsen. Zie hoe je ongebruikte CSS verwijdert voor tips om ongebruikte styles op te schonen.

• Minify je CSS. Gebruik cssnano of PostCSS, of de ingebouwde compressie van je CSS-preprocessor, om witruimte en commentaren te strippen. Het kost niets, dus doe het, maar het scheelt slechts een paar kilobyte en geen bezoeker merkt het verschil.
• Verwijder CSS die je pagina's niet gebruiken. Minder CSS betekent minder downloaden en parsen. PurgeCSS of het Coverage-tabblad in Chrome DevTools helpen je bij het vinden van ongebruikte CSS. Doe dit wel in je eigen build en laat de optie 'Remove Unused CSS' in plugins als WP Rocket, Perfmatters of LiteSpeed uitstaan: dat levert net zoveel gedoe op als critical CSS.
• Zet je CSS niet inline en sla critical CSS over. Inline CSS maakt de HTML groter, en op de HTML staat alles te wachten. De browser kan die HTML meestal ook niet cachen; elke pageview downloadt dus opnieuw dezelfde CSS, terwijl een losse stylesheet vanaf de tweede pagina uit de cache komt. Critical CSS scheelt weliswaar een round trip bij het eerste bezoek, maar de rest van de CSS arriveert pas na de first paint: een restyle, een repaint en vaak een layout shift.
• Houd elke render-blocking stylesheet gecomprimeerd onder ongeveer 15 KB. Dat past grofweg in de eerste round trip van een nieuwe connectie; zie het als een budget om naar te streven. Een Slow 4G-waterfall toont hoe het op twee manieren misgaat: een stylesheet van 60 KB duurt te lang, en een rij bestanden van 0,3 KB betaalt elk de opstarttijd van zijn eigen request. Voeg de kleintjes samen en knip of verklein de grote.
• Laad CSS niet standaard async in. De truc met media="print" werkt alleen voor CSS waarvan je zeker weet dat die nooit in het eerste scherm gebruikt wordt, en dat weet je zelden echt zeker. CSS voor het eerste scherm scheiden van de rest is gewoon critical CSS onder een andere naam."
• Verwijder elke @import uit je CSS. Elk exemplaar start een keten van stylesheets die de browser alleen na elkaar kan ophalen, en de preload scanner ziet de bestanden aan het eind van de keten niet. Link ze vanuit de HTML of combineer ze in je build.

Resource hints optimaliseren

Resource hints helpen de browser om kritieke resources als eerste te downloaden. Een gepreload bestand staat meestal veel eerder in de wachtrij — en is eerder beschikbaar — dan zonder hint. Goed ingezet verlagen hints de LCP resource load delay. Lees voor de geavanceerde variant meer over 103 Early Hints.

• Verwijder hints voor resources die niet nodig zijn voor het eerste scherm. Vroege bandbreedte is schaars; elke preload of connectie die je niet nodig hebt, snoept bandbreedte af van bestanden die er wel toe doen.
• Gebruik preconnect voor domeinen die je vroeg nodig hebt, zoals een content delivery network of een font-provider. De DNS lookup, TCP-connectie en TLS handshake zijn dan al klaar voordat het eerste request naar dat domein vertrekt. Gebruik <link rel="preconnect" href="https://example.com"> voor kritieke third-party origins.
• Overweeg DNS-prefetch waar een preconnect te zwaar is. Preconnect zet de complete verbinding op, terwijl <link rel="dns-prefetch"> alleen de domeinnaam vooraf opzoekt. Dat volstaat voor een domein dat je waarschijnlijk later nodig hebt, wanneer de kosten van een volledige verbinding het nog niet waard zijn.
• Preload de LCP-afbeelding als deze niet in de HTML staat. LCP meet hoe lang de hoofdcontent nodig heeft om te verschijnen, en het preloaden van het LCP-element schuift die resource naar voren in de wachtrij. Voor een <img> die al in de HTML staat, doet fetchpriority="high" hetzelfde zonder extra tag.
• Preload kritieke fonts met <link rel="preload" as="font" type="font/woff2" crossorigin>. De browser haalt ze vroeg op, zodat tekst sneller zichtbaar is en het wisselen van fonts minder layout shifts veroorzaakt.
• Verstuur je resource hints waar mogelijk als 103 Early Hints. Bij een 103 verstuurt de server de hints al voordat de volledige response klaarstaat. Sneller kan de browser een resource simpelweg niet ontdekken. Kan je server geen 103 versturen, gebruik dan Link-response-headers. Zijn headers ook geen optie, voeg dan als fallback <link>-elementen toe aan de <head> van de pagina.
• Preload fonts voordat je CSS ze ontdekt. Een font dat in CSS staat, wordt pas gevonden nadat die CSS is gedownload en geparsed. Een preload in de HTML-<head> neemt die wachttijd weg. Het font laadt parallel, waardoor zowel FCP als het risico op layout shifts daalt.

Iconen optimaliseren

Met iconen schiet je snel door: een complete icoon-set inladen voor de vijf iconen die de pagina gebruikt. Grote inline SVG-iconen blazen je HTML op en een icon font bevat vaak duizenden glyphs die je nooit gebruikt. Iconen goed aanpakken helpt voor LCP (minder HTML en CSS om te laden) en CLS (ruimte gereserveerd voor elk icoon).

• Plaats geen grote SVG-iconen inline in je HTML. Ze maken de HTML zwaarder en de pagina trager, en de browser kan ze los niet cachen. Een externe SVG-spritesheet biedt meestal de beste balans tussen performance en flexibiliteit, al houden losse bestanden of een icon font (wees voorzichtig) de HTML ook compact.
• Laad een grote icon set zoals Font Awesome nooit volledig in. De hele set kan meer dan 100 KB zijn, terwijl een subset van 20 iconen onder de 5 KB kan blijven. Subset hem dus naar een kleiner icon font of gebruik losse SVG's.
• Reserveer een width en height voor iconen, net als voor afbeeldingen. De browser houdt de ruimte dan vrij, zodat de iconen tijdens het laden geen layout shifts veroorzaken. Zet de width- en height-attributen direct op de SVG-elementen of geef ze expliciete afmetingen in CSS.
• Preload of inline geen iconen die het eerste scherm niet nodig heeft; laat de essentiële content eerst laden. Pas lazy loading toe op iconen below the fold.

Serverresponstijden optimaliseren

Serverresponstijd, gemeten als Time to First Byte (TTFB), gaat vooraf aan elke paint metric. Een trage server vertraagt dus alles wat daarna komt. Zie voor uitgebreide strategieën de handleidingen over TTFB-problemen opsporen en Cloudflare configureren voor performance.

• Kies een snelle, betrouwbare hostingprovider met een solide infrastructuur. Vergelijk providers op basis van TTFB die je zelf in de praktijk meet. De cijfers in hun marketing zijn synthetisch.
• Log hoe lang je code en je database-queries duren, en doe dat vaak. Query-profiling en APM-tools (application performance monitoring) wijzen je direct op trage endpoints.
• Cache in de browser en op de server, zodat data die vaak wordt opgevraagd niet telkens opnieuw opgehaald hoeft te worden. Full-page caching kan TTFB verlagen van seconden naar minder dan 100 ms. De handleiding over het optimaliseren van de cacheduur bevat alle details.
• Render kleine gepersonaliseerde onderdelen op de client of aan de edge. Een winkelmandteller, loginstatus of kleine menuaanpassing mag niet de cache van de hele pagina breken. Behoud de full-page cache en vul dat soort details in via de client of met edge rendering.
• Tune je webserver: keep-alive-instellingen, het aantal worker processes, geheugentoewijzing en timeout-waarden. Een verkeerd geconfigureerde server verspilt resources en reageert trager.
• Gebruik een Content Delivery Network (CDN). Dat serveert je statische content vanaf edge nodes (servers) dicht bij de bezoeker. Dat verkort de afstand die de data aflegt en versnelt het laden voor een wereldwijd publiek. Een CDN is meestal ook beter geconfigureerd dan je eigen server. Bekijk de handleiding over Cloudflare configureren voor een praktische walkthrough.
• Doe minder werk per request. Bereken zware taken vooraf, gebruik efficiënte algoritmes en verplaats alles wat niet essentieel is naar een background job. Loop daarna de request-lifecycle van je applicatie nog eens na en schrap elke stap die overbodig is.
• Gebruik HTTP/3. QUIC zet de verbinding op in één round trip, waar TCP plus TLS er twee of meer nodig heeft. Bovendien houdt een verloren packet de andere requests op die verbinding niet meer tegen. Dat merk je vooral op mobiele netwerken. De winst zit in de verbinding, dus dat zie je terug in TTFB en daardoor in LCP. Een eerste bezoek verloopt vaak nog via HTTP/2, omdat de browser pas over HTTP/3 leert via de Alt-Svc-header of een HTTPS-DNS-record. Meer hierover vind je in het optimaliseren van de verbindingsduur.
• Voeg Server-Timing-headers toe. Die vertellen hoe lang elk onderdeel van het serverwerk voor een pagina duurt. Zo zie je het knelpunt direct en kun je werken aan het deel dat de Largest Contentful Paint (LCP) tegenhoudt. Je ziet ze in het Network-paneel van Chrome DevTools, en RUM-tools zoals CoreDash kunnen ze verzamelen.
• Log trage database-queries en los ze regelmatig op. Zet slow query logging aan (elke serieuze database heeft het) en bekijk het log wekelijks. Betere indexen, herschreven queries en een cachelaag voor frequente queries kunnen de TTFB flink verlagen.
• Comprimeer tekstbestanden (HTML, CSS, JavaScript) met GZIP of, nog beter, Brotli. De server comprimeert ze on the fly voor verzending, wat ze zo'n 70% kleiner maakt. Brotli comprimeert doorgaans 15 tot 20% beter dan GZIP.

Interactiviteit optimaliseren

Interaction to Next Paint (INP) meet hoe snel je site reageert op interacties van gebruikers. Een slechte INP ontstaat meestal door long tasks in JavaScript die de main thread blokkeren. Elk van de drie INP-fases heeft een eigen handleiding: input delay, processing time en presentation delay.

• Gebruik een idle-until-urgent-patroon voor zware scripts. Kritiek werk draait eerst en niet-essentiële JavaScript wacht tot de main thread idle is. Zo lopen rendering en gebruikersinvoer nooit vast achter een langlopend script. Plan het niet-urgente werk in met requestIdleCallback; heb je het resultaat toch eerder nodig, voer het dan direct uit. Lees meer over processing time optimaliseren.
• Knip long tasks op door te yielden naar de main thread. Een long task blokkeert de main thread en de pagina reageert niet meer. Hak hem in kleinere stukken en geef tussendoor de controle terug aan de browser; die kan in die gaten een klik of toetsaanslag verwerken. Gebruik scheduler.yield() waar dat ondersteund wordt, of setTimeout(0). Zie de handleiding over INP verbeteren door te stoppen met JavaScript-scrolling.
• Render de feedback vóór het zware werk. INP loopt tot de volgende paint. Pas dus eerst de button state aan of toon een spinner, yield daarna (met scheduler.yield() of setTimeout) en doe pas daarna het zware werk. Een :active-stijl of CSS-transitie verschijnt pas als de main thread vrij is om te painten; een handler die de thread bezet houdt, bevriest de feedback samen met de rest van de pagina.
• Maak scroll- en touch-listeners passief met { passive: true }. Dat vertelt de browser dat de handler nooit preventDefault() aanroept, zodat het scrollen direct kan starten zonder op JavaScript te wachten. Dat merk je vooral op mobiel. Scrollen op zich is geen interactie die INP meet, dus dit gaat meer over soepel scrollen dan over de INP-score.

Core Web Vitals monitoren

Blijf je Core Web Vitals monitoren; zo vang je een regressie vroeg op en controleer je of een fix deed wat je verwachtte. Field data op p75 is wat telt; lab tests zoeken uit waarom. Begin met de p75 van elke metric op mobiel, de paginagroepen die Search Console markeert en de trend over de afgelopen weken: een plotselinge daling wijst meestal op een deploy, terwijl een langzame verslechtering vaker komt doordat third-party scripts zich één voor één opstapelen.

• Draai Lighthouse regelmatig. Het is Google's gratis open-source audit-tool om performance-problemen op een pagina te vinden. Lighthouse meet de Core Web Vitals niet zoals echte bezoekers ze ervaren, maar het is ideaal om je site telkens onder dezelfde gestandaardiseerde omstandigheden te testen en vergelijken. Een standaard Lighthouse-run meet INP helemaal niet, want niemand klikt op iets tijdens de test; Total Blocking Time komt er het dichtst bij. Zet Lighthouse in je CI/CD-pipeline en je vangt regressies af vóór ze live gaan.
• Controleer de CrUX-historie regelmatig. CrUX (het Chrome User Experience Report) is Google's openbare dataset met prestaties uit de praktijk, en dat is de data die Google gebruikt om te bepalen of je slaagt voor de Core Web Vitals. Elk cijfer in CrUX is de p75 van de afgelopen 28 dagen. Een regressie sluipt er dus in de loop van weken in, en een fix heeft zo'n vier weken nodig om volledig zichtbaar te worden. PageSpeed Insights toont alleen de huidige 28 dagen; de historie vind je in CrUX Vis en de CrUX History API.
• Stel RUM-tracking in. Real User Monitoring meet hoe lang je pagina's er bij je bezoekers echt over doen, op hun locaties en op hun apparaten. Lighthouse is een lab test en CrUX geeft je de p75 van de afgelopen 28 dagen, zonder te vertellen welk element of script de oorzaak is. RUM vult dat aan. Ik raad CoreDash aan, dat ik heb gebouwd voor gedetailleerde Core Web Vitals-attributiedata.
• Stel performance budgets in: concrete doelen per metric op p75 op mobiel, bijvoorbeeld LCP onder 2,5 seconden, INP onder 200 ms en CLS onder 0,1. Meet hier regelmatig aan af en je ziet direct welke onderdelen het eerst aandacht vragen.
• Segmenteer je data. Meet je meest waardevolle bezoekerstypen en je paginatypes afzonderlijk; de rest van je verkeer kan een probleem verbergen dat alleen hen treft. Splits eerst op apparaat en paginatemplate; verbindingssnelheid en land komen daarna.

Critical Rendering Path optimaliseren

Het critical rendering path is elke stap die de browser zet om HTML en CSS (en JavaScript) om te zetten in pixels op het scherm. Een korter pad betekent een snellere First Contentful Paint en minder LCP element render delay. Zie ook hoe je een te grote DOM voorkomt.

• Minimaliseer het aantal kritieke resources. Elke render-blocking resource — CSS of synchrone JavaScript — moet gedownload en verwerkt zijn voordat de browser kan painten. Stel scripts uit die niet essentieel zijn en houd je stylesheets schaars en klein.
• Zorg voor de juiste laadvolgorde: eerst stylesheets, dan de LCP-afbeelding en de fonts voor het eerste scherm, daarna de overige afbeeldingen above the fold en tot slot de deferred scripts. Het fetchpriority-attribuut en hints voor resource prioritization vertellen de browser wat het belangrijkst is.
• Houd de DOM-tree ondiep. Diepe nesting betekent meer stijlberekeningen en meer layoutwerk. Mik waar mogelijk op maximaal 32 niveaus en minder dan 1.500 elementen in totaal; een plattere DOM paint sneller en helpt voor de INP presentation delay.
• Geef de voorkeur aan classes en ID's boven tags en attributen in je selectors. Schrijf .important in plaats van p.important, zodat de browser minder hoeft te controleren bij style matching en styles sneller herrekent.
• Nest selectors niet te diep. Elk extra niveau betekent meer werk voor de browser. Herstructureer de HTML om nesting te verminderen, of zet een specifiekere class dichter op het element, en blijf bij maximaal 3 niveaus.
• Gebruik minder descendant-selectors. Bij een selector als .container .content loopt de browser door alle voorouders van elk .content-element om de container te vinden. Een class direct op het content-element matcht sneller.
• Groepeer selectors die dezelfde styles delen in één class, of gebruik BEM-naamgeving (Block Element Modifier). Dat onderhoudt makkelijker en de CSS blijft compacter.

Cookie consent optimaliseren

De AVG en vergelijkbare regels verplichten een cookie consent-banner, maar een slordig geladen banner kan LCP vertragen, CLS veroorzaken en INP opdrijven. Lees voor meer details over het optimaliseren van third-party widgets voor Core Web Vitals.

• Render de consent-banner op de server als de pagina daar toch al gerenderd wordt. Hij zit dan meteen in het eerste HTML-antwoord, wat vaak sneller is dan een aparte JavaScript-oplossing: geen extra netwerk-request en geen script om uit te voeren.
• Laad het consent-script async op gecachte pagina's en overweeg fetchpriority="high", zodat hij toch verschijnt voordat iemand interactie heeft.
• Toon de banner als een overlay met een fixed positie. Een banner die bovenaan de pagina wordt ingevoegd, drukt alles eronder naar beneden — een layout shift bij elk eerste bezoek. Met een fixed positie onderaan het scherm ligt hij bovenop de content en beweegt er niets.
• Host scripts en stylesheets voor cookiemeldingen waar mogelijk zelf en cache ze. Zo sla je de DNS lookups en connecties naar het consent management platform over en houd je het laadgedrag zelf in de hand."

Single Page Applications optimaliseren

Single Page Applications (SPA's) gebouwd met React of Vue hebben hun eigen Core Web Vitals-problemen: client-side rendering vertraagt zowel FCP als LCP, en hydration kan INP blokkeren.

• Gebruik altijd server-side rendering of prerendering. Een SPA die alleen op de client rendert, dwingt de browser om eerst al die JavaScript te downloaden en uit te voeren voordat er iets zichtbaar is. Met SSR (Next.js, Nuxt, SvelteKit) of statische prerendering stuur je direct HTML die de browser meteen kan painten.
• Kies liever voor statische prerenders dan dynamische. Een statische prerender wordt tijdens de build gegenereerd en direct vanaf een CDN geserveerd zonder server-side verwerking. Dat maakt hem veel sneller dan eentje die per request wordt gegenereerd. Gebruik statische generatie voor elke pagina die geen gegevens per request vereist.
• Laad third-party scripts pas na de hydration. Hydration kost al veel tijd op de main thread om de pagina interactief te maken, en third-party scripts die op hetzelfde moment draaien maken de input delay erger. Stel elk script dat niet essentieel is uit tot de hydration klaar is.

Een te grote DOM voorkomen

Een grote DOM (meer dan 1.500 elementen of dieper dan 32 niveaus) gebruikt meer geheugen, vertraagt stijlberekeningen en veroorzaakt dure layout reflows. Dat zie je terug in de INP presentation delay en in de paint metrics. Zie hoe je een te grote DOM oplost.

• Verwijder DOM-elementen die je niet nodig hebt. Zoek naar wrapper-elementen die niets doen voor styling of structuur en vervang diep geneste <div>-structuren door semantische HTML. Lange lijsten kun je virtualiseren met een library als react-window of virtual-scroller, wat de actieve DOM klein houdt.
• Houd selectors en DOM-queries efficiënt. Complexe CSS-selectors en brede JavaScript-queries (zoals een querySelectorAll met een breed patroon) worden steeds trager naarmate de DOM groeit. Gebruik specifieke class-selectors en beperk elke query waar mogelijk tot een subtree.
• Gebruik content-visibility: auto voor content buiten beeld. De browser slaat het renderen van die elementen over tot ze in beeld scrollen. Op pagina's met lange secties kan dat het initiële renderwerk drastisch verminderen.

API-requests optimaliseren

API-requests die rendering blokkeren of content tegenhouden, schaden LCP en TTFB. In single page applications is data ophalen op de client een van de gebruikelijke oorzaken van een trage LCP.

• Doe minder API-requests. Elk request telt op bij de laadtijd; kijk dus wat het eerste scherm echt nodig heeft en schrap de rest. Batching (meerdere requests combineren tot één) en GraphQL besparen round trips.
• Zorg dat de API's zelf snel zijn. Hoe een API is ontworpen en gebouwd, beïnvloedt direct de pagina die erop wacht. Voeg aan de API-kant caching toe voor data die vaak wordt opgevraagd.
• Preload kritieke API-requests met <link rel="preload" as="fetch" crossorigin>. Net als bij een afbeelding-preload start het request vroeg, zodat de data er al is wanneer de eerste render die nodig heeft. Laat je crossorigin weg, dan matcht de preload niet met de fetch()-aanroep en downloadt de browser de data dubbel. De handleiding voor resource prioritization bevat meer technieken.

Chat-widgets optimaliseren

Chat-widgets zijn een veelvoorkomende oorzaak van layout shifts en kunnen zelfs de LCP dwarsbomen als ze vroeg laden. Lees voor een stapsgewijze aanpak hoe je een chat-widget implementeert met perfecte Core Web Vitals.

• Laad de chat-widget pas nadat de hoofdcontent geladen is. Niemand in de geschiedenis van het internet heeft ooit hoeven chatten voordat de hoofdcontent van de pagina geladen was. Start hem pas zodra de eerste render klaar is, via requestIdleCallback of wanneer de bezoeker scrollt.
• Verberg de chat-widget tot hij klaar is. Veroorzaakt hij een layout shift, houd hem dan op opacity: 0 tot hij volledig gerenderd is. Zo kan hij op de achtergrond zijn layout bepalen zonder zichtbare content te verschuiven. Fade hem daarna in met een CSS-transitie.
• Zoek naar een lichte chat-widget. Sommige leveranciers veroorzaken aanzienlijk minder Core Web Vitals-problemen dan andere. Vergelijk voor je kiest de JavaScript-bundlegrootte, het aantal netwerk-requests en de impact op INP per aanbieder.

Service worker-performance optimaliseren

Een service worker kan herhaalbezoeken een stuk sneller maken door assets en zelfs complete pagina's te cachen, wat TTFB verlaagt voor terugkerende bezoekers. Bouw je hem verkeerd, dan vertraagt hij navigatie juist. Lees meer over het optimaliseren van de cacheduur.

• Cache kritieke assets in de service worker. Een cache-first-strategie voor statische assets (CSS, JavaScript, fonts, afbeeldingen) laat terugkerende bezoekers je site vrijwel direct inladen vanuit de lokale cache. Precache de belangrijkste resources in het install-event.
• Houd de code van de service worker lean. Complexe routing-logica, veelvuldig gebruik van event.waitUntil() en een groot precache-manifest vertragen de installatie allemaal. Gebruik stale-while-revalidate voor resources die vaak veranderen maar niet direct op de seconde actueel hoeven te zijn.

Videocontent optimaliseren

Een video wordt het LCP-element als het de grootste zichtbare content in de viewport is. Een zwaar videobestand snoept bovendien bandbreedte af van andere kritieke resources.

• Comprimeer je video's met een moderne codec (H.264, VP9 of AV1) op een verstandige kwaliteitsinstelling. Encodeer op het formaat waarin de video getoond wordt: eentje die 400px breed verschijnt, hoeft geen 1920px te zijn. Two-pass encoding levert de beste kwaliteit op voor de bestandsgrootte.
• Pas lazy loading toe op video's below the fold. Zet loading="lazy" op een <iframe> of houd de video tegen met de Intersection Observer API. Vervang automatisch afspelende achtergrondvideo's door een poster image en laad de video pas zodra de bezoeker in de buurt scrollt.
• Host video's op een snel CDN. Videobestanden zijn groot en hebben enorm veel baat bij CDN-distributie. Een gespecialiseerd video-CDN of hostingdienst (Cloudflare Stream, Mux, Bunny.net) voegt daar nog adaptive bitrate streaming, geografische spreiding en geoptimaliseerde levering aan toe.
• Zet altijd een poster-attribuut op <video>-elementen. De browser kan de poster direct painten terwijl de video laadt. De poster kan zelf het LCP-element zijn; optimaliseer die dus net als elke andere LCP-afbeelding.