De ultieme Core Web Vitals checklist (2026)

Table of Contents!

• De ultieme Core Web Vitals checklist
• Core Web Vitals optimalisatie checklist
  • Afbeeldingen optimaliseren
  • Web fonts optimaliseren
  • Scripts optimaliseren
  • Stijlen optimaliseren
  • Resource hints optimaliseren
  • Iconen optimaliseren
  • Server response times optimaliseren
  • Interactiviteit optimaliseren
  • Core Web Vitals monitoring
  • Critical rendering path optimaliseren
  • Cookie consent optimaliseren
  • Single Page Applications optimaliseren
  • Vermijd een extreme DOM grootte
  • API requests optimaliseren
  • Chat widgets optimaliseren
  • Service worker performance optimaliseren
  • Video content optimaliseren

Afbeeldingen optimaliseren

Grote afbeeldingen in de zichtbare viewport worden meestal het Largest Contentful Paint element. Afbeeldingen optimaliseren heeft een enorme impact op de LCP. Gebruik deze Core Web Vitals checklist items om afbeeldingen sneller te maken. Lees voor de volledige strategie de gids over het optimaliseren van de LCP afbeelding.

• Schaal afbeeldingen naar de maximale weergavegrootte: Zo verspil je geen bytes aan het downloaden van afbeeldingen die groter zijn dan ze op het scherm verschijnen. Combineer dit met responsive afbeeldingen voor kleinere schermen. Het serveren van correct geschaalde afbeeldingen kan de bestandsgrootte met 50% of meer verkleinen zonder zichtbaar kwaliteitsverlies.
• Gebruik lazy loading voor afbeeldingen below-the-fold: Lazy loading stelt het laden van afbeeldingen buiten de viewport uit tot je ze in beeld scrolt. Dit verbetert de First Contentful Paint (FCP) en de algehele laadtijd van de pagina. Gebruik nooit lazy loading op de LCP afbeelding, want dit vertraagt de LCP aanzienlijk.
• Preload visueel belangrijke afbeeldingen zoals het LCP element: Preloading instrueert de browser om kritieke afbeeldingen te downloaden voor de rest van de content. Dit geeft prioriteit aan de LCP. Gebruik <link rel="preload" as="image"> samen met fetchpriority="high" voor het beste resultaat. Dit is cruciaal wanneer de CSS of JavaScript de LCP afbeelding laadt.
• Stel width en height in: Geef afmetingen vooraf op. Dit voorkomt layout shifts doordat de browser wacht op het laden van afbeeldingen. Dit verbetert de CLS. Moderne browsers gebruiken de width en height attributen om de aspect ratio te bereken voor de afbeelding is geladen. Zo reserveren ze exact genoeg ruimte.
• Gebruik moderne bestandsformaten zoals WebP of AVIF: Deze formaten zijn kleiner dan JPEG of PNG bij een vergelijkbare kwaliteit. Dit zorgt voor snellere laadtijden. WebP bestanden zijn meestal 25-34% kleiner dan JPEG. AVIF kan de bestandsgrootte tot 50% reduceren. Gebruik het <picture> element met format fallbacks voor maximale browserondersteuning.
• Gebruik native lazy loading en schakel JavaScript lazy loading uit: Lazy loading stelt het laden van afbeeldingen buiten de viewport uit. Native lazy loading via het loading="lazy" attribuut is sneller dan een JavaScript oplossing. Het vereist geen extra parsing of executie van scripts.
• Gebruik responsive afbeeldingen met srcset: Dit attribuut specificeert verschillende versies van een afbeelding voor diverse schermformaten. De browser levert de optimale afbeelding voor het apparaat van de gebruiker. Dit voorkomt onnodig grote downloads. Combineer srcset met het sizes attribuut voor exacte controle.
• Voeg decoding="async" toe: Het decoding="async" attribuut voorkomt dat de browser andere content blokkeert tijdens het decoderen van een afbeelding. De rendering engine kan andere elementen blijven painten terwijl de afbeelding parallel wordt gedecodeerd.
• Verwijder afbeeldingsmetadata: Metadata zoals EXIF data voegt onnodige bytes toe. Verwijder deze informatie om de bestandsgrootte te verkleinen zonder de kwaliteit te beïnvloeden. Tools zoals ImageOptim, Squoosh of Sharp kunnen dit automatiseren in je build proces.
• Vermijd CSS background images voor LCP elementen: De browser ontdekt achtergrondafbeeldingen in CSS veel later dan <img> elementen in de HTML. Moet je een achtergrondafbeelding gebruiken als het LCP element, preload deze dan met een <link rel="preload"> tag voor vroege ontdekking. Lees meer over LCP resource load delay.

Web fonts optimaliseren

Web fonts vertragen de First Contentful Paint, veroorzaken layout shifts en concurreren om vroege bandbreedte. Gebruik deze checklist voor een soepele web font ervaring. Lees onze gids over Google Fonts lokaal hosten voor best practices.

• Gebruik font-display: swap voor een snellere first paint: Stel de font-display eigenschap in op swap in je @font-face declaraties. De browser toont direct een fallback font terwijl het web font op de achtergrond laadt. Zodra het font klaar is, wisselt de browser deze naadloos om. Lees meer over hoe je zorgt dat tekst zichtbaar blijft tijdens het laden van webfonts.
• Combineer font-display: optional met preloading om layout shifts door fonts te voorkomen: De combinatie van font-display: optional en preloading biedt een balans tussen snelheid en layout shifts. De optional waarde verbergt tekst heel kort (ongeveer 100ms) voordat een fallback font verschijnt. Preloading instrueert de browser om het web font vroeg op te halen. Dit minimaliseert de tijd met fallback fonts en voorkomt layout shifts.
• Gebruik font-face descriptors om het fallback font op de afmetingen van het web font te laten lijken: Dit zorgt voor minimale CLS wanneer het web font inlaadt. Gebruik size-adjust, ascent-override, descent-override en line-gap-override op het fallback font. Dit voorkomt dat content verspringt.
• Subset fonts tot alleen de nodige karakters: Verklein de font bestandsgrootte door fonts te subsetten. Beperk de karakters tot de tekens die je daadwerkelijk gebruikt. Tools zoals Font Squirrel, pyftsubset of glyphhanger genereren deze subsets. Een compleet Latijns font krimpt vaak van 100KB+ naar minder dan 20KB na correct subsetten.
• Beperk het aantal font weights en styles: Voorkom overbodige font variaties. Houd maximaal 2 kritieke fonts aan (meestal preloaded) en 2 laat ladende fonts. Elke extra font weight voegt 15 tot 50KB toe aan de payload.

Scripts optimaliseren

Scripts veroorzaken Interaction to Next Paint problemen, triggeren Cumulative Layout Shifts of vertragen de Largest Contentful Paint. Zelfs geoptimaliseerde en onschuldige vroege scripts concurreren om resources. Ze vertragen verfmetrieken zoals de LCP en FCP. Lees onze gids over 14 methoden om JavaScript uit te stellen.

• Verwijder onnodige JavaScript: Spoor ongebruikte JavaScript code op en verwijder deze. Dit minimaliseert de code die de browser moet downloaden en uitvoeren. Gebruik de Coverage tab in Chrome DevTools om ongebruikte code te vinden. Dode code verwijderen verkort de laadtijd en bespaart main thread verwerking.
• Geef scripts prioriteit op basis van functie en belang: Scripts die grote wijzigingen aanbrengen in de zichtbare viewport moeten render blocking zijn. Belangrijke scripts moeten deferred of async laden. Niet-essentiële scripts laad je tijdens browser idle. Bekijk onze gids over resource prioriteit voor de volledige strategie.
• Code splitting en lazy loading: Splits grote JavaScript bundels op in kleinere chunks en laad ze pas wanneer dat nodig is. Dit verlaagt de initiële laadtijd. Moderne bundlers zoals webpack, Rollup en esbuild ondersteunen automatische code splitting via dynamische imports.
• Minify en recompileer JavaScript bestanden: Minify en recompileer altijd je JavaScript met een tool als SWC, Terser of esbuild. Minificatie verkleint JavaScript bestanden meestal met 30 tot 50%.
• Beperk third-party scripts: Third-party scripts leveren flinke performance overhead op. Evalueer de noodzaak en zoek naar alternatieven. Elk third-party script voegt DNS lookups, connectie overhead en main thread executietijd toe. Controleer third-party scripts regelmatig in het Chrome DevTools Network panel.
• Laad third-party scripts asynchroon: Laat het renderen nooit blokkeren door een third party vanwege het onvoorspelbare karakter van deze scripts. Gebruik altijd het async of defer attribuut op third-party script tags.
• Monitor third-party script performance: Gebruik de Long Animation Frames (LoAF) API of CoreDash om de werkelijke impact van third-party scripts op INP en LCP te meten. Stel performance budgets in voor third-party JavaScript en beoordeel deze regelmatig.

Stijlen optimaliseren

Stijlen zijn standaard render blocking. Stijlen optimaliseren resulteert in betere paint metrics. Volg deze checklist om de CSS performance van je pagina te verbeteren. Render blocking CSS beïnvloedt direct de First Contentful Paint en de LCP element render delay. Voor tips over opschonen, lees hoe je ongebruikte CSS verwijdert.

• Minify CSS bestanden: Verwijder onnodige karakters zoals witruimte, comments en opmaak uit CSS. Geminificeerde bestanden zijn kleiner, wat leidt tot snellere laadtijden. Tools zoals cssnano, PostCSS of de ingebouwde compressie van je CSS preprocessor automatiseren dit.
• Verwijder ongebruikte CSS: Identificeer en verwijder CSS code die niet actief is op je pagina's. Dit vermindert de data die de browser moet downloaden en parsen. Tools zoals PurgeCSS of de Chrome DevTools Coverage tab helpen bij het vinden van ongebruikte CSS.
• Inline critical CSS: Plaats stijlen die essentieel zijn voor de initiële render direct in de HTML. Dit verbetert je paint metrics. Serveer critical CSS alleen aan nieuwe bezoekers en gebruik gecachte externe stylesheets voor terugkerende bezoekers. Deze techniek verlaagt de FCP omdat je de round trip voor een externe stylesheet elimineert.
• Verdeel CSS bestandsgroottes gelijkmatig: Alle CSS in één bestand stoppen lijkt efficiënt, maar extreem grote bestanden vertragen de download. Splits je CSS op in kleinere bestanden met een gelijke verdeling (10 tot 15KB per stuk). De browser kan stijlen dan incrementeel verwerken.
• Laad offscreen stijlen asynchroon: Gebruik het media="print" onload="this.media='all'" patroon voor stijlen buiten de initiële viewport. De browser downloadt deze stijlen parallel aan andere resources zonder de initiële render te blokkeren.

Resource hints optimaliseren

Resource hints geven prioriteit aan kritieke downloads. Preloaded resources staan direct in de wachtrij en zijn veel sneller beschikbaar voor de browser. Effectieve resource hints verlagen de LCP resource load delay aanzienlijk. Lees voor geavanceerde implementaties over 103 Early Hints.

• Verwijder niet-kritieke resource hints: Verwijder preload hints voor resources die niet essentieel zijn tijdens de eerste laadfase. Dit voorkomt onnodige downloads die concurreren om vroege, beperkte bandbreedte. Elke overbodige preload steelt bandbreedte van kritieke resources.
• Preconnect naar kritieke domeinen: Bouw vroegtijdig connecties op met belangrijke domeinen (zoals CDNs of font providers). Dit versnelt de download van kritieke resources doordat DNS, TCP en TLS handshakes vooraf klaar zijn. Gebruik <link rel="preconnect" href="https://example.com"> voor kritieke third-party origins.
• Overweeg DNS prefetch als alternatief voor preconnect: Net als preconnect hint DNS prefetch de browser over mogelijke connecties. Preconnect zet de volledige connectie op, terwijl DNS prefetch enkel de domeinnaam vooraf oplost. Gebruik <link rel="dns-prefetch"> wanneer de overhead van een volledige preconnect niet nodig is.
• Preload het LCP element: De LCP meet hoelang het duurt voor de hoofdcontent laadt. Het preloaden van het LCP element dwingt de browser om deze kritieke resource met prioriteit te downloaden. Gebruikers zien de content sneller. Dit is cruciaal voor afbeeldingen in de CSS of geladen via JavaScript.
• Preload kritieke fonts: Het preloaden van kritieke fonts garandeert dat de browser ze vroeg ophaalt. Dit voorkomt tekstvertragingen en verbetert de Cumulative Layout Shift door font swapping. Gebruik <link rel="preload" as="font" type="font/woff2" crossorigin> voor je belangrijkste lettertypes.
• Kies voor 103 Early Hints voor resource hints: De 103 Early Hints HTTP statuscode laat de server hints sturen voordat de volledige response klaar is. Ondersteunt je server geen 103, gebruik dan Link response headers. Zijn headers niet mogelijk, voeg dan <link> elementen toe aan de <head> als fallback. Eerdere hints betekenen snellere resource ontdekking.
• Preload fonts voordat CSS bestanden ze ontdekken: Fonts in CSS worden pas ontdekt na de download en parse van dat CSS bestand. Preload fonts direct in de HTML <head> om deze afhankelijkheid weg te nemen. Fonts laden parallel. Dit verlaagt de FCP en het risico op layout shifts.

Iconen optimaliseren

Iconen voegen onnodig gewicht toe als ze niet zijn geoptimaliseerd. Grote inline SVG iconen blazen je HTML op. Icon fonts bevatten vaak duizenden ongebruikte glyphs. Iconen optimaliseren verbetert de LCP (kleinere HTML/CSS payload) en de CLS (correcte ruimtereservering).

• Vermijd inline SVG iconen in de HTML: Grote SVG iconen direct in de HTML vergroten de payload en vertragen de laadtijd. Gebruik losse bestanden of (met mate) icon fonts. Dit houdt de HTML klein en maakt caching mogelijk. Een externe SVG sprite sheet biedt de beste balans tussen performance en flexibiliteit.
• Vermijd grote icon fonts: Gebruik nooit complete icon sets zoals Font Awesome. Maak subsets of gebruik individuele SVGs. Dit verlaagt de paginagrootte en versnelt het laden. Een complete Font Awesome weegt ruim 100KB, een subset met 20 iconen blijft onder de 5KB.
• Reserveer width en height voor iconen: Net als bij afbeeldingen, reserveert de browser ruimte als je afmetingen opgeeft. Dit voorkomt layout shifts. Gebruik de width en height attributen op SVG elementen of definieer ze in CSS.
• Geef niet-kritieke icon sets een lage prioriteit: Laad iconen met een lagere prioriteit als ze niet cruciaal zijn voor de eerste render. Essentiële content laadt dan eerst. Dit minimaliseert de impact op de Core Web Vitals. Gebruik lazy loading of laad icon stylesheets asynchroon na de initiële paint.

Server response times optimaliseren

Server response times, gemeten als Time to First Byte (TTFB), hebben direct invloed op alle paint metrics. Een trage server vertraagt het hele proces. Lees onze gidsen over het diagnosticeren van TTFB problemen en het configureren van Cloudflare voor performance.

• Gebruik een snelle en betrouwbare hosting provider: Een snelle hosting provider met een sterke infrastructuur verbetert server response times enorm. Benchmark hosting providers met echte TTFB metingen, niet met marketingclaims.
• Optimaliseer server-side code en database queries: Log de uitvoeringstijd van code en database queries regelmatig. Zo vind je bottlenecks en verhoog je de snelheid. Gebruik query profiling en application performance monitoring (APM) tools om trage endpoints op te sporen.
• Implementeer caching strategieën: Gebruik browser caching en server-side caching voor veelgebruikte data. Dit voorkomt dat je data herhaaldelijk ophaalt en verbetert laadtijden. Full-page caching verlaagt de TTFB van seconden naar minder dan 100ms. Lees meer over cache duration optimization.
• Client-side of edge rendering voor personalisatie: Gebruik client-side of edge rendering voor kleine personalisaties zoals een winkelmandteller, inlogstatus of menu-aanpassingen. Zo behoud je de full page cache. Dit voorkomt cache invalidatie door kleine dynamische elementen.
• Optimaliseer serverconfiguraties: Controleer en tune je webserver instellingen voor optimale performance. Kijk naar keep-alive connecties, worker processen, geheugentoewijzing en timeouts. Verkeerd geconfigureerde servers verspillen resources en verhogen response times.
• Gebruik een Content Delivery Network (CDN): Een CDN verdeelt statische content over meerdere edge servers. Dit verkleint de fysieke afstand naar de gebruiker. Dit versnelt de laadtijd voor een wereldwijd publiek. CDNs zijn meestal ook beter geconfigureerd dan je eigen server. Bekijk onze gids over Cloudflare configureren voor een praktische setup.
• Verminder server-side processing: Beperk het werk dat je server per request uitvoert. Bereken zware operaties vooraf, gebruik efficiënte algoritmes en verplaats niet-essentiële taken naar background jobs. Analyseer de request lifecycle om onnodige stappen te elimineren.
• Gebruik HTTP/3: HTTP/3 is de nieuwste versie van het Hypertext Transfer Protocol. HTTP/3 is sneller en efficiënter dan HTTP/2 en vele malen sneller dan HTTP/1.1. Upgraden naar HTTP/3 verlaagt de laadtijd en kan alle drie de Core Web Vitals (LCP, INP, CLS) verbeteren. Lees meer over connection duration optimization.
• Stel Server-Timing headers in: Deze headers tonen hoelang de server over specifieke onderdelen doet. Met deze data spoor je direct bottlenecks op, vooral nuttig voor het verbeteren van de Largest Contentful Paint (LCP). Server-Timing headers zijn zichtbaar in het Chrome DevTools Network panel. RUM tools zoals CoreDash vangen deze data ook op.
• Log trage database queries en optimaliseer ze wekelijks: Activeer slow query logging in je database (MySQL, PostgreSQL, MongoDB) en analyseer de logs. Het optimaliseren van indexen, herschrijven van queries en toevoegen van caching voor veelgebruikte queries verlaagt de TTFB dramatisch.
• Gebruik GZIP of Brotli compressie: GZIP, en de nieuwere Brotli, bieden on the fly compressie van tekstbestanden (HTML, CSS, JavaScript). Dit verkleint bestanden met ongeveer 70%. Brotli comprimeert typisch 15 tot 20% beter dan GZIP. Kleinere bestanden leiden tot snellere laadtijden.

Interactiviteit optimaliseren

Interaction to Next Paint (INP) meet hoe snel je site reageert op interacties. Slechte interactiviteit ontstaat vaak door lange JavaScript taken die de main thread blokkeren. Bekijk de drie INP fases in detail via onze gidsen over input delay, processing time en presentation delay.

• Implementeer een idle-until-urgent patroon voor zware scripts: Geef prioriteit aan kritieke taken en stel niet-essentiële JavaScript uit tot de main thread idle is. Dit voorkomt dat lange scripts rendering en interactie blokkeren. Gebruik requestIdleCallback voor niet-urgente taken. Lees meer over processing time optimaliseren.
• Breek long tasks op met yielding naar de main thread: Complexe JavaScript taken blokkeren de main thread en vertragen de reactietijd. Breek deze taken op in kleinere chunks en geef controle terug (yielding) aan de main thread. Dit houdt de UI soepel en laat de browser interacties verwerken. Gebruik scheduler.yield() (indien ondersteund) of setTimeout(0) voor long tasks. Lees onze gids over INP verbeteren door JavaScript scrolling te verwijderen.
• Geef direct feedback op input: Gebruikers verwachten een onmiddellijke reactie na een interactie. Geef directe visuele feedback, zelfs als zware taken op de achtergrond draaien. Gebruik CSS transities en de :active pseudo-class. Dit wekt de indruk van snelheid en voorkomt dat de bezoeker denkt dat de pagina is vastgelopen.
• Gebruik passive event listeners voor scroll en touch: Voeg { passive: true } toe aan scroll en touch event listeners. Dit vertelt de browser dat de handler preventDefault() niet aanroept. De browser kan direct scrollen zonder te wachten op JavaScript. Dit werkt extreem goed op mobiele apparaten en verbetert de INP voor scroll-gerelateerde interacties aanzienlijk.

Core Web Vitals monitoring

Het continu monitoren van de Core Web Vitals is essentieel. Zo vang je regressies vroeg op en valideer je de impact van optimalisaties. Gebruik een combinatie van lab data, field data en Real User Monitoring (RUM) voor een compleet beeld.

• Controleer Lighthouse regelmatig: Lighthouse is een gratis audit tool van Google voor performance. Lighthouse meet de Core Web Vitals niet direct in de context van echte gebruikers, maar is perfect voor periodiek testen in gestandaardiseerde omgevingen. Draai Lighthouse in CI/CD pipelines om regressies voor een deploy te vangen.
• Controleer wekelijks de CrUX historie: Het Chrome User Experience Report (CrUX) is een publieke dataset van Google met echte performancedata. Google gebruikt CrUX om te bepalen of je de Core Web Vitals haalt. Bekijk de historische data om regressies te spotten. Je vindt CrUX data in PageSpeed Insights, het CrUX Dashboard of de CrUX API.
• Stel RUM in: Met Real User Monitoring (RUM) volg je de ervaring van echte bezoekers. RUM tools meten de exacte laadtijden per bezoeker op diverse locaties en apparaten. Dit vult de lab data van Lighthouse en CrUX perfect aan. We raden CoreDash aan als RUM tool voor gedetailleerde Core Web Vitals attributie.
• Stel performance budgets in: Performance budgets bepalen harde limieten voor metrics (bijvoorbeeld LCP onder de 2,5 seconden, INP onder de 200ms, CLS onder 0.1). Gebruik ze als benchmarks om je doelen te bewaken. Test hier regelmatig tegenaan om kritieke knelpunten te signaleren en taken te prioriteren.
• Gebruik segmentatie: Segmenteer je data om waardevolle bezoekerstypes en specifieke paginatypes te analyseren. Grote bakken met traffic maskeren vaak problemen in subgroepen. Segmenteer op apparaat, connectiesnelheid, geografie en paginatemplates om verborgen fouten te vinden.

Critical rendering path optimaliseren

Het critical rendering path is de reeks stappen die de browser zet om HTML, CSS en JavaScript om te zetten in pixels. Het optimaliseren hiervan verbetert de First Contentful Paint en de LCP element render delay. Zie ook hoe je een gigantische DOM vermijdt.

• Minimaliseer het aantal kritieke resources: Elke render-blocking resource (CSS en synchrone JavaScript) moet worden gedownload en verwerkt voor de browser kan painten. Verlaag dit aantal door niet-essentiële scripts en stylesheets uit te stellen of asynchroon te laden.
• Optimaliseer de inlaadvolgorde: Laad kritieke CSS en fonts eerst, daarna above-the-fold afbeeldingen, en als laatste deferred scripts. Gebruik het fetchpriority attribuut en resource prioritization hints om prioriteit aan de browser te communiceren.
• Verklein de diepte van de DOM tree: Diep geneste DOM trees verhogen de style berekeningstijd en layout kosten. Streef naar maximaal 32 niveaus en minder dan 1.500 DOM elementen. Een vlakkere DOM structuur versnelt de paint performance en de INP presentation delay.
• Kies classes en IDs in plaats van element tags: Gebruik .important in plaats van p.important. De browser hoeft dan niet alle elementen van dat type te doorzoeken voor styling matches. Dit resulteert in snellere style recalculation.
• Vermijd diep geneste selectors: Hoe dieper je CSS selectors nest, hoe meer de browser moet berekenen. Herschrijf je HTML of gebruik specifiekere classes op het element. Limiteer selector diepte tot maximaal 3 niveaus.
• Minimaliseer descendant selectors: Selectors zoals .container > .content dwingen de browser om elk element binnen de container te evalueren. Plaats direct een class op het content element voor snellere matches.
• Groepeer selectors met dezelfde stijlen: Deel je dezelfde stijl met meerdere elementen? Voeg ze samen in één class of gebruik BEM (Block Element Modifier). Dit verbetert het onderhoud en verkleint de CSS.

Cookie consent optimaliseren

Cookie banners zijn vereist, maar verpesten de Core Web Vitals als je niet oppast. Een slecht geladen banner vertraagt de LCP, veroorzaakt CLS en verhoogt de INP. Lees meer over het optimaliseren van third-party widgets.

• Overweeg server-side cookie consent: Bij server-side gerenderde pagina's is het veel sneller om de banner direct in de HTML in te sluiten dan in te laden via een JavaScript module. Dit scheelt een zware network request en script overhead.
• Laad cookie consent scripts asynchroon op gecachte pagina's: Laad je cookie script asynchroon op gecachte pagina's. Voeg fetchpriority="high" toe aan het script. Dit garandeert dat de banner zichtbaar is voor de gebruiker wil klikken.
• Houd consent tekst kort: Lange cookie teksten domineren vaak de LCP. De browser markeert het grootste zichtbare tekstblok als kandidaat. Schrijf korte copy of splits de tekst in meerdere alinea's met een klein oppervlak.
• Host cookie scripts lokaal: Cache en host je cookie scripts en CSS zelf. Dit elimineert DNS lookups en connectiekosten naar de consent tool en geeft je controle over de laadstrategie.

Single Page Applications optimaliseren

Single Page Applications (SPAs) gebouwd met React, Vue, Angular en vergelijkbare frameworks kennen unieke Core Web Vitals uitdagingen. Client-side rendering vertraagt zowel de FCP als de LCP. Hydratatie blokkeert vaak de INP.

• Gebruik altijd server-side rendering of prerendering: SPAs die volledig op client-side rendering leunen, dwingen de browser om JavaScript te downloaden, te parsen en te runnen voordat er beeld is. Gebruik SSR (Next.js, Nuxt, SvelteKit) of statische prerendering. Stuur direct HTML mee die de browser kan painten.
• Kies statische prerenders boven dynamische generatie: Statische prerenders (tijdens build gegenereerd) zijn veel sneller. Een CDN levert ze direct af zonder serverberekeningen. Gebruik statische generatie voor pagina's die geen unieke data per bezoeker tonen.
• Laad third-party scripts pas na hydratatie: Hydratatie vreet al main thread tijd om de pagina interactief te maken. Laad je op dat moment ook nog externe scripts in, dan explodeert de input delay. Stel niet-essentiële scripts uit tot de hydratatie compleet is.

Vermijd een extreme DOM grootte

Een extreme DOM (meer dan 1.500 elementen of een diepte van 32 niveaus) verhoogt het geheugengebruik. Het vertraagt stijlberekeningen en forceert zware reflows. Dit sloopt direct de INP presentation delay en de verfmetrieken. Lees hoe je een grote DOM voorkomt.

• Verwijder onnodige DOM elementen: Schrap lege wrapper elementen in je HTML. Vervang diep geneste <div> structuren door semantische HTML. Virtualiseer lange lijsten met bibliotheken zoals react-window of virtual-scroller om de actieve DOM klein te houden.
• Gebruik efficiënte JavaScript en CSS selectors: Complexe CSS selectors en JavaScript queries (zoals een brede querySelectorAll) worden exponentieel trager in een grote DOM. Gebruik specifieke class selectors. Beperk DOM queries waar mogelijk tot subtrees.
• Gebruik content-visibility: auto voor off-screen content: De content-visibility: auto eigenschap vertelt de browser om onzichtbare elementen niet te renderen. Dit vermindert het renderwerk aanzienlijk op lange pagina's.

API requests optimaliseren

API requests die de render blokkeren of content vertragen, ruïneren de LCP en TTFB. Client-side data fetching is de grootste oorzaak van een trage LCP in Single Page Applications.

• Minimaliseer API requests: Elke request voegt milliseconden toe aan de paginalaadtijd. Combineer API calls om de eerste view te renderen. Technieken zoals data batching en GraphQL reduceren round trips aanzienlijk.
• Gebruik efficiënte APIs: Het API ontwerp zelf is bepalend voor je performance. Gebruik APIs die puur gebouwd zijn op snelheid en efficiëntie. Implementeer API-caching voor data die vaak wordt opgevraagd.
• Preload kritieke API requests: Net als afbeeldingen preload je kritieke APIs. Dit versnelt de performance enorm. Gebruik <link rel="preload" as="fetch"> om de data vroeg op te halen. De data is direct klaar als de browser gaat renderen. Bekijk onze resource prioritization guide.

Chat widgets optimaliseren

Chat widgets veroorzaken vaak layout shifts en saboteren de LCP als je ze te vroeg laadt. Lees voor een perfecte implementatie hoe je een chat widget laadt zonder impact op de Core Web Vitals.

• Laad chat widgets na de main content: Niemand in de geschiedenis van het internet wil chatten voordat de pagina überhaupt in beeld staat. Stel de chat widget uit tot de eerste render compleet is. Gebruik hiervoor een scroll-trigger of requestIdleCallback.
• Voorkom chat widget layout shifts: Verberg chat widgets tijdelijk met opacity: 0 tot ze volledig gerenderd zijn. De widget berekent zijn layout op de achtergrond zonder dat elementen in beeld verspringen. Gebruik een CSS transitie om de widget subtiel in te faden.
• Kies een snelle chat provider: Vergelijk je opties. Sommige widgets zijn vele malen lichter en veiliger voor de Core Web Vitals. Kijk naar de JavaScript bundel, het aantal network requests en de impact op de INP voor je kiest.

Service worker performance optimaliseren

Service workers versnellen vervolgbezoeken spectaculair door caching. Ze reduceren de TTFB door assets en zelfs complete pagina's lokaal te bewaren. Maar let op: een slechte service worker vertraagt navigatie. Lees meer over cache duration optimization.

• Cache kritieke assets in de service worker: Hanteer een cache-first strategie voor CSS, JavaScript, fonts en afbeeldingen. Terugkerende bezoekers laden de site direct vanuit de lokale cache. Precache je belangrijkste bestanden tijdens het install event.
• Optimaliseer service worker code: Houd je service worker licht en snel. Vermijd complexe routing en beperk event.waitUntil(). Grote precache manifesten vertragen de installatie. Gebruik een stale-while-revalidate patroon voor data die wijzigt, maar niet direct realtime vers hoeft te zijn.

Video content optimaliseren

Video's domineren de viewport en worden daarmee vaak het LCP element. Grote, zware video's stelen bandbreedte van andere kritieke resources.

• Comprimeer en optimaliseer video's: Gebruik moderne codecs zoals H.264, VP9 of AV1. Verlaag de resolutie tot het exacte weergaveformaat. Een video van 400px breed vereist geen 1920px bestand. Gebruik two-pass encoding voor de beste balans tussen kwaliteit en grootte.
• Gebruik lazy loading voor video's: Plaats loading="lazy" op <iframe> elementen under the fold. Je kunt ook de Intersection Observer API gebruiken. Vervang zware autoplay achtergrondvideo's door een poster afbeelding. Laad de video pas in zodra de bezoeker dichtbij is.
• Host video's op een snel CDN: Videobestanden zijn zwaar en hebben een CDN nodig. Gebruik een toegewijde video host (zoals Cloudflare Stream, Mux of Bunny.net) die adaptive bitrate streaming en razendsnelle distributie verzorgt.
• Gebruik een poster image: Zet altijd een poster attribuut op <video> elementen. Deze afbeelding paint direct terwijl de video buffert. Hij dient perfect als LCP element. Optimaliseer dit bestand exact zoals elke andere LCP afbeelding.