Webshop sneller maken: zo pak je productpagina, filters en afrekenen aan

Een webshop maak je sneller door te beginnen bij de pagina's waar je omzet ontstaat: de productpagina, de categoriepagina, de winkelwagen en de afrekenpagina. Per paginatype zoek je het grootste element in beeld, de interacties die traag aanvoelen en de onderdelen die verspringen. Daarmee raak je de drie meetwaarden die Google Core Web Vitals noemt, waarvan de volledige uitleg staat in ons artikel over Core Web Vitals. Hier lees je wat in een webshop typisch traag of onstabiel is en hoe je dat meet. Cijfers over hoeveel sneller jouw shop wordt, geven we niet: die hangen af van je situatie en van metingen.

Welke drempels gelden en waar vind je de uitleg?

Per 11 oktober 2026 noemt Google (web.dev) een LCP van 2,5 seconden of minder, een INP van 200 milliseconden of minder en een CLS van 0,1 of lager goed, gemeten op het 75e percentiel van paginaladingen, uitgesplitst naar mobiel en desktop. Waarom die drempels zo zijn gekozen en wat het percentiel betekent, lees je in de uitleg van LCP, INP en CLS. Google zegt dat de metrics in de loop van de tijd kunnen veranderen, dus controleer de actuele web.dev-pagina als je dit later leest.

Wat meet LCP en wat is er in een webshop traag?

LCP (Largest Contentful Paint) meet volgens web.dev de rendertijd van de grootste afbeelding, het grootste tekstblok of de grootste video in het zichtbare gebied, gerekend vanaf het moment dat de gebruiker naar de pagina navigeert. Op een productpagina kan dat de hoofdafbeelding van het product zijn. Op een categoriepagina kan het een banner of de eerste productafbeelding zijn. Een praktische aanpak is daar te beginnen met zoeken: de eerste grote afbeelding in beeld moet snel verschijnen, en niet pas nadat alles eromheen geladen is.

Wat vertraagt LCP typisch in een webshop? We noemen geen getallen, want die verzinnen we niet. De bronnen geven wel richting. Google adviseert afbeeldingen die waarschijnlijk bij het laden al in beeld zijn niet te lazy-loaden, zeker geen LCP-afbeelding. Controleer daarom of je thema of plug-in ook de eerste productafbeelding uitgesteld laadt. Web.dev noemt daarnaast dat WebP en AVIF doorgaans betere compressie geven dan oudere formaten. Met srcset kun je volgens web.dev meerdere versies van dezelfde afbeelding in verschillende formaten aanbieden, zodat de browser de passende kiest. Het helpt dus om bij een trage LCP eerst naar het formaat en de afmetingen van je productfoto’s te kijken.

Wat meet INP en wat vertraagt een klik?

Bij INP kun je een interactie zien als een klik, tik of toetsaanslag op de pagina. In een webshop zijn dat de knop Toevoegen aan winkelwagen, het openen van een filter of het kiezen van een variant. Per 11 oktober 2026 wordt de INP volgens web.dev beoordeeld op het 75e percentiel van in het veld gemeten paginaladingen, uitgesplitst naar mobiel en desktop. Een INP van 200 milliseconden of minder noemt web.dev goede responsiviteit, boven 500 milliseconden slechte. Een hoge INP kun je zien als wachten voordat er iets gebeurt na een handeling, ook als de pagina zelf snel opkwam.

Wat zorgt er typisch voor dat een klik traag aanvoelt? De bronnen die wij hebben, noemen geen specifieke webshopoorzaken en daarom beperken we ons tot de aanpak. Zoek de interacties die het meest voorkomen op je shop: toevoegen aan winkelwagen, filteren, variant kiezen, afrekenen. Test elk daarvan op een gewone telefoon, niet alleen op een snelle laptop. Kijk daarna naar welke scripts bij die handelingen draaien, waaronder die van derde partijen zoals chat of tracking. Onnodige scripts weghalen kan een eerste stap zijn, en je hoeft er geen nieuwe shop voor te bouwen.

Waarom verspringt de pagina en hoe voorkom je dat?

CLS (Cumulative Layout Shift) gaat over verspringende pagina-inhoud. Web.dev noemt als typische oorzaken afbeeldingen of video’s zonder afmetingen, fonts die groter of kleiner renderen dan het terugvallettertype, en dynamisch geladen advertenties of widgets die zichzelf van grootte veranderen. Voor een webshop kun je denken aan productafbeeldingen zonder vaste ruimte, een cookiebanner die de pagina omlaag duwt of een widget voor reviews die later laadt. Een klant die op een knop wil tikken terwijl de pagina verspringt, kan op het verkeerde ding tikken.

De aanpak staat ook bij web.dev: neem altijd width- en height-attributen op voor afbeeldingen en video-elementen, of reserveer de nodige ruimte met CSS aspect-ratio. MDN voegt toe dat width en height de browser in staat stellen de beeldverhouding te berekenen voordat de afbeelding geladen is. Voor fonts schrijft web.dev dat font-display invloed kan hebben op LCP, FCP en layoutstabiliteit. Kies dus bewust hoe je tekst toont zolang het webfont nog laadt. Wij laden in onze eigen projecten alleen de lettertypen en gewichten die nodig zijn.

Hoe meet je een webshop per paginatype?

Google schrijft dat Core Web Vitals primair veldmetingen zijn, dus metingen bij echte bezoekers, en een labtest is een momentopname waarmee je zoekt waar het misgaat. Het verschil tussen beide staat in het artikel over Core Web Vitals. Een praktische werkwijze: meet eerst in het veld waar je staat, per paginatype (home, categorie, product, winkelwagen, afrekenen) en apart voor mobiel. Gebruik daarna labtests om te achterhalen wat een pagina vertraagt en om een aanpassing te controleren voordat je hem live zet. Meet daarna opnieuw in het veld, want effecten van een wijziging zie je pas met echte bezoeken terug. Leg de uitgangswaarden vast. Zonder voor- en nameting weet je niet of het werk iets heeft opgeleverd, en dan is het een gok.

Een voorbeeld van zo'n meetplan voor een webshop. Neem de productpagina en kijk bij LCP naar de hoofdafbeelding van het product. Neem de categoriepagina en kijk bij INP naar het openen van een filter en het kiezen van een variant. Neem de winkelwagen en de afrekenpagina en kijk bij INP naar elke knop die je klant moet aanklikken, en bij CLS naar elementen die later binnenkomen, zoals een cookiebanner of een widget voor reviews. Noteer per pagina en per meetwaarde de uitgangswaarde, pas één ding aan en meet opnieuw.

Helpt snelheid voor je positie in Google?

Helpt dit voor je positie in Google? Per 11 oktober 2026 zegt Google dat het site-eigenaren sterk aanraadt goede Core Web Vitals te halen voor succes in Zoeken en voor een goede gebruikerservaring in het algemeen. Tegelijk schrijft Google dat je niet op een of twee aspecten van pagina-ervaring moet focussen, maar op de algehele ervaring, inclusief veilig serveren via HTTPS en goede weergave op mobiel. Snelheid is dus een onderdeel, geen toverknop. Voor het geheel aan vindbaarheid lees je ons artikel over webshop-SEO voor beginners.

Waar begin je? Neem de pagina’s met het meeste verkeer of de meeste omzet, bijvoorbeeld de productpagina en de afrekenpagina, en meet daar. Verbeter per keer één ding en meet opnieuw. De hosting kan meespelen, omdat de browser pas kan beginnen met laden als de server antwoordt; managed hosting start bij ons vanaf €25 per maand. Productmarkup die correct is en snel laadt, vind je in ons artikel over productdata en structured data.

Bij Digitaalnu bouwen we webshops in React en Next.js, vanaf €2.500. Snelheid nemen we mee vanaf het ontwerp: afbeeldingen met vaste afmetingen, alleen de lettertypen die nodig zijn en geen scripts die we niet nodig hebben. We beloven geen vaste scores, omdat die van je producten, je verkeer en je koppelingen afhangen. Wat we wel doen, is meten voor en na de oplevering en de uitkomst met je delen. Na de livegang blijft onderhoud nodig, zodat nieuwe plug-ins en koppelingen je snelheid niet ongemerkt verslechteren.

Laatst bijgewerkt op 11 oktober 2026