Website performance optimalisatie is het werk om pagina's sneller te laten laden en reageren, zonder verspringende inhoud. Google meet het resultaat met drie Core Web Vitals, met een vaste grens per Core Web Vital. Die grenzen zijn LCP binnen 2,5 seconden, INP van 200 milliseconden of minder en CLS van 0,1 of minder. Volgens de HTTP Archive Web Almanac 2025 haalde maar 48% van de mobiele websites alle drie, dus de meeste sites kunnen sneller. In 2026 lossen zeven stappen de meeste trage websites op. Afbeeldingen zijn stap 1, omdat bij 76% van de mobiele pagina's een afbeelding het LCP-element is. Daarna volgt JavaScript als stap 2. De overige stappen gaan over rendering, caching, fonts, blokkerende bestanden en monitoring. Een site die met Next.js is gebouwd, krijgt het verkleinen van afbeeldingen en het zelf hosten van fonts standaard mee. Meet tot slot met velddata van echte bezoekers via PageSpeed Insights, en niet alleen met een labtest (Lighthouse).
Waarom doet website performance ertoe in 2026?
Website performance is tegelijk een rankingfactor en een onderdeel van de gebruikerservaring. Volgens Google Search Central gebruiken de rankingsystemen van Google de Core Web Vitals. Google zegt er wel bij dat Search de meest relevante content blijft tonen, ook als de paginabeleving zwak is. Snelheid is dus een tiebreaker in de zoekresultaten, geen kortere weg langs goede content. Voor bezoekers is het effect directer: een trage productpagina verliest op mobiel de aandacht voordat de eerste afbeelding verschijnt. De HTTP Archive Web Almanac laat zien hoe vaak dat nog gebeurt: slechts 48% van de mobiele websites haalde alle drie de Core Web Vitals in 2025. Op mobiel had 62% van de pagina's een goede LCP-score, tegenover 74% op desktop. De mobiele score verdient daarom de meeste aandacht, ook omdat Google mobile-first indexeert: de mobiele versie van een pagina telt voor de ranking. Mobiel en desktop krijgen elk een eigen rapport via Google Search Console.
Wat zijn de drempelwaarden van de Core Web Vitals?
Google beoordeelt elke meetwaarde op het 75e percentiel van echte paginaweergaven.
Stap 1: Hoe optimaliseer je afbeeldingen voor een snellere LCP?
Afbeeldingen optimaliseren is de eerste stap, omdat het grootste element op de meeste pagina's een afbeelding is. Volgens de HTTP Archive Web Almanac 2025 heeft 76% van de mobiele pagina's een afbeelding als LCP-element. Hetzelfde rapport ziet dat ongeveer 16% tot 17% van de pagina's juist die LCP-afbeelding lazy-loadt, net als in 2024. Lazy loading vertraagt dan precies de belangrijkste pixels, terwijl Google een LCP binnen 2,5 seconden als goed beoordeelt. Begin met moderne formaten: volgens de documentatie van Next.js zijn AVIF-bestanden ongeveer 20% kleiner dan WebP, maar duurt het encoderen ongeveer 50% langer. Geef altijd breedte en hoogte op, zodat de CLS laag blijft. Gebruik srcset, zodat telefoons nooit desktopafbeeldingen downloaden. Laad de hero-afbeelding direct met een hoge fetch priority en lazy-load alleen afbeeldingen onder de vouw. Een site die met Next.js is gebouwd, krijgt schalen, moderne formaten en lazy loading van de Image-component. Controleer tot slot via PageSpeed Insights welk element de LCP bepaalt.
Stap 2: Hoe verminder je JavaScript om INP te verbeteren?
Minder JavaScript is de belangrijkste hefboom voor INP, de meetwaarde voor reactiesnelheid. INP verving First Input Delay als Core Web Vital op 12 maart 2024. Volgens Google geldt een INP boven 500 milliseconden als slecht. De HTTP Archive Web Almanac 2025 laat het verschil tussen apparaten zien: 97% van de desktopsites had een goede INP, tegenover 77% op mobiel. Elk script concurreert om de main thread, dus zware bundels maken klikken en tikken traag. Splits ten eerste de code per route, zodat een bezoeker alleen de JavaScript voor de huidige pagina downloadt. Verwijder ten tweede ongebruikte libraries; een bundle analyzer toont de zwaarste dependencies. Stel ten derde niet-essentiële scripts uit tot na de eerste interactie, zoals chatwidgets en tags via Google Tag Manager. Knip daarnaast lange taken op in kleinere stukken, zodat de browser tussendoor op invoer kan reageren. Een site met Next.js en React Server Components rendert veel op de server, waardoor de code van Server Components buiten de browserbundel blijft.
Stap 3: Welke renderstrategie is het snelst: SSG, SSR of ISR?
Static site generation (SSG) is meestal de snelste renderstrategie, omdat de HTML al bestaat voordat een bezoeker binnenkomt. Een statische pagina komt via Cloudflare of een ander CDN bij de bezoeker, zonder enige databasequery. Server-side rendering (SSR) bouwt de HTML per request, wat past bij pagina's met persoonlijke of steeds veranderende gegevens. Incremental static regeneration (ISR) zit ertussenin: pagina's blijven statisch, maar vernieuwen na een interval of na een contentwijziging. Eén project met Next.js kan alle drie de strategieën per route combineren. Een marketingpagina is dan statisch, een blog vernieuwt na publicatie en een klantdashboard rendert per request. Een single page application die alles in de browser rendert, is voor publieke pagina's vaak de traagste optie, omdat content pas na de JavaScript verschijnt. Dat raakt de First Contentful Paint: volgens de HTTP Archive Web Almanac was die goed op 55% van de mobiele pagina's in 2025. Op desktop was dat 70%. Vooraf gerenderde HTML helpt bovendien Google en andere crawlers om de content te lezen.
Stap 4: Hoe richt je caching en een CDN in?
Caching is het bewaren van een kant-en-klaar antwoord, zodat server en netwerk de volgende keer minder werk doen. Stap 4 bouwt voort op stap 3. Een statische pagina is namelijk makkelijk te cachen. Geef ten eerste statische bestanden zoals CSS, JavaScript en afbeeldingen een lange browsercache. Bestanden met een contenthash in de naam mogen een jaar in de cache blijven, omdat elke nieuwe versie een nieuwe naam krijgt. Zet ten tweede een CDN voor de website, zodat bezoekers bestanden downloaden vanaf een server in Amsterdam of Frankfurt. Cache ten derde zwaar werk op de server, zoals databasequery's, API-antwoorden en gerenderde pagina's. Een trage serverrespons vertraagt elke andere meetwaarde, ook de LCP. Volgens Google is een Time to First Byte van 0,8 seconde of minder goed. Dat haalde in 2025 maar 44% van de mobiele pagina's, tegenover 55% op desktop, aldus de HTTP Archive Web Almanac. Bij WordPress-sites met veel plugins is de serverrespons vaak het verborgen probleem. Controleer tot slot de cacheheaders via Chrome DevTools.
Stap 5: Hoe laad je webfonts zonder verspringende tekst?
Fontoptimalisatie is stap 5, de stap die voorkomt dat tekst verspringt zodra het definitieve lettertype binnenkomt. Volgens de web.dev-documentatie van Google ontstaan layout shifts vaak door fonts die groter of kleiner renderen dan het fallbackfont. Beperk ten eerste het aantal fontbestanden: twee families met elk twee of drie gewichten is meestal genoeg. Gebruik ten tweede het WOFF2-formaat, met een subset van alleen de tekens die de website nodig heeft. Volgens de HTTP Archive Web Almanac was ongeveer 65% van alle fontverzoeken WOFF2 in 2025. Preload ten derde de een of twee fonts die bovenaan de pagina staan. Zet daarnaast font-display op swap of optional, zodat bezoekers de tekst meteen lezen. Swap stond op 50,1% van de mobiele pagina's. Wie fonts via Google Fonts laadt, kan ze ook zelf hosten. Een site met Next.js doet dat met next/font, dat externe netwerkverzoeken weghaalt. Het resultaat is stabiele tekst en één verbinding met een externe partij (third party) minder.
Stap 6: Hoe verwijder je render-blocking resources?
Een render-blocking resource is een CSS- of JavaScript-bestand dat de browser moet downloaden voordat de eerste weergave verschijnt. Zulke bestanden vertragen de First Contentful Paint. Elk blokkerend bestand kost een extra netwerkronde, en op een mobiele verbinding is elke ronde merkbaar. Volgens de HTTP Archive Web Almanac slaagde maar 15% van de mobiele pagina's voor deze Lighthouse-controle, en 13% op desktop in 2025. Zet ten eerste de kleine hoeveelheid kritieke CSS voor de bovenkant van de pagina inline en laad de rest zonder te blokkeren. Geef ten tweede scripts die niet vóór de eerste weergave hoeven te draaien een defer- of async-attribuut. Gebruik ten derde preconnect voor de paar externe domeinen die de pagina echt nodig heeft, zoals een betaalprovider. Vervang daarnaast zware embeds door een lichte facade. Een YouTube-embed van Google kan eerst een statische thumbnail tonen en de speler pas na een klik laden. Een korte controle via Lighthouse in Chrome DevTools toont de blokkerende bestanden en de tijdwinst per bestand.
Stap 7: Hoe monitor je website performance continu?
Continu monitoren is stap 7, de laatste stap, omdat een snelle website weer trager wordt naarmate functies, plugins en trackingscripts zich opstapelen. Google biedt daarvoor drie gratis tools: 1) PageSpeed Insights, 2) Google Search Console en 3) de open-source web-vitals-library. PageSpeed Insights combineert labdata uit Lighthouse met velddata van echte Chrome-gebruikers over de afgelopen 28 dagen, inclusief de First Contentful Paint. Search Console groepeert trage pagina's per URL-groep en per type probleem. De web-vitals-library meet echte gebruikersdata in de browser, klaar om te rapporteren via Google Analytics of een andere tool. Google beoordeelt het 75e percentiel: minstens 75% van de paginaweergaven moet dus goed scoren. Verbeteren gaat stap voor stap: volgens de HTTP Archive Web Almanac steeg het aandeel mobiele sites dat alle drie haalt van 44% in 2024 naar 48% in 2025. Een korte performancecheck vóór elke release voorkomt de meeste terugvallen. Een performancebudget, bijvoorbeeld een maximale hoeveelheid JavaScript per pagina, maakt die check objectief.
Veelgestelde vragen
Heb je een Lighthouse-score van 100 nodig?
Nee, een Lighthouse-score van 100 is niet nodig. Core Web Vitals worden gemeten met velddata van echte gebruikers en niet met een labscore. Lighthouse is een labtest op één gesimuleerd apparaat met één gesimuleerde verbinding. De score is ook anders samengesteld: Total Blocking Time weegt voor 30% mee en First Contentful Paint voor 10%. Vergelijk bijvoorbeeld een pagina met labscore 85 en goede veldwaarden met een pagina met een labscore van 100. Heeft die tweede pagina een slechte INP bij echte gebruikers, dan staat de eerste pagina er beter voor. Bekijk daarom eerst de velddata via PageSpeed Insights of het Core Web Vitals-rapport in Google Search Console. Richt je op goede veldwaarden voor LCP, INP en CLS, gemeten op het 75e percentiel van de paginaladingen. Volgens Google Search Central weegt relevantie in 2026 nog steeds zwaarder dan paginabeleving, dus de kwaliteit van je content blijft de eerste prioriteit. Een labscore blijft handig als snelle test vóór elke release.
Is Next.js sneller dan WordPress?
Next.js is niet automatisch sneller dan WordPress, maar het framework maakt een snel resultaat makkelijker haalbaar. De snelheid van WordPress hangt af van hosting, thema en plugins. Volgens W3Techs draait WordPress op 39,7% van alle websites en op 58,4% van de sites met een bekend CMS, gemeten in oktober 2026. Een lichtgewicht WordPress-thema op goede hosting met paginacaching kan alle drie de Core Web Vitals van Google halen. Een zware pagebuilder met veel plugins heeft daarentegen vaak moeite met INP of LCP. Een React-framework zoals Next.js begint met vooraf gerenderde HTML voor een snelle First Contentful Paint, automatische code splitting en ingebouwde optimalisatie van afbeeldingen en fonts. De website van VirtuoLab draait zelf op Next.js met React Server Components. De keerzijde is contentbeheer: een Next.js-site vraagt meestal een headless CMS, terwijl WordPress standaard een editor heeft. Next.js kan content ook via WordPress ophalen, als headless CMS. Meet in elke eerlijke vergelijking de velddata van echte pagina's, niet van een demopagina.
Kun je een bestaande website beter optimaliseren of opnieuw bouwen?
Een bestaande website optimaliseren is de juiste keuze als de basis goed is en de problemen specifiek zijn, zoals grote afbeeldingen, ontbrekende caching of te veel scripts. Zulke problemen komen veel voor: volgens de HTTP Archive Web Almanac mist op 62% van de mobiele pagina's bij minstens één afbeelding de breedte of hoogte. Opnieuw bouwen is de betere investering als een oud thema, een zware pagebuilder of verouderde hosting elke verbetering blokkeert. Een trage Time to First Byte is daarvan een signaal; maar 44% van de mobiele pagina's had er een goede in 2025. Bekijk eerst de velddata via PageSpeed Insights van Google voor de vijf pagina's met de meeste bezoekers. Raken de verbeteringen bijna elk template, dan is opnieuw bouwen meestal de voorspelbaardere route. Een site van acht pagina's op een modern thema heeft misschien alleen beter beeld en caching nodig. VirtuoLab geeft in 2026 voor een bedrijfswebsite een indicatie van €2000 tot €8000. De exacte prijs volgt na een gratis kennismaking met VirtuoLab.