Core Web Vitals voor E-commerce: Waarom Bezoekers met Hoge Intentie de Slechtste Prestaties Krijgen

Het onzichtbare prestatieprobleem in e-commerce

Veel van mijn klanten hechten veel waarde aan het behalen van de Core Web Vitals. Behalen betekent dat 75% van al het verkeer een goede ervaring zou moeten hebben. Een bewonderenswaardig doel. Maar bij het optimaliseren voor die 75%, wordt een kleine maar cruciale groep van ongeveer 5% over het hoofd gezien: de bezoekers die zullen converteren naar klanten.

De ironie? Deze bezoekers met hoge intentie krijgen vaak de slechtste prestaties op je site. Niet omdat je vergeten bent te optimaliseren. Omdat je caching-systeem hen actief uitsluit.

Laatst beoordeeld door Arjen Karel in maart 2026

Waarom je CrUX-data het probleem verbergt

Core Web Vitals-optimalisatie, voornamelijk vanwege de Google-rankingbonus, richt zich vaak op het optimaliseren voor de bezoeker die net onder het gemiddelde zit. In e-commerce is het erg logisch om verder te kijken en extra focus te leggen op bezoekers met een hoge intentie. Dat zijn de bezoekers die converteren naar klanten.

Volgens onderzoek door Deloitte en Google leidt een verbetering van 0,1 seconde in paginasnelheid tot een toename van 9,1% in toevoegen-aan-winkelwagen acties voor retailsites. Dat is ook het exacte moment waarop caching voor hen stopt met werken.

We kunnen deze gebruikers typisch identificeren aan het aantal items in hun winkelwagen.

Er is nog een blinde vlek. CrUX (het Chrome User Experience Report) volgt alleen Chrome-gebruikers die synchronisatie hebben ingeschakeld. Veel e-commerce shoppers gebruiken Safari op mobiel of browsers die niet synchroniseren. Je CrUX-dashboard toont misschien groene scores terwijl je daadwerkelijke kopers iets heel anders ervaren. Dit is waarom een voldoende CrUX-score niet het hele verhaal vertelt.

De caching-klif: wat er gebeurt wanneer een gebruiker toevoegt aan de winkelwagen

Hier is het probleem: het toevoegen van items aan een winkelwagen vernietigt je caching. En caching is wat je site snel maakt.

Caching plug-ins schakelen volledige pagina-caching uit voor gebruikers met dynamische content. Iets simpels als "items in een winkelwagen" dwingt de server om de hele pagina bij elk verzoek opnieuw op te bouwen. Dit verhoogt je Time to First Byte aanzienlijk, wat direct de Largest Contentful Paint en First Contentful Paint vertraagt.

De cijfers zijn dramatisch. Op een typische WooCommerce-site gaat de TTFB van ongeveer 100ms (gecached) naar 1.600ms of meer (ongecached). Dat is een 16-voudige toename in serverresponstijd op het moment dat iemand een product toevoegt aan zijn winkelwagen. Ik heb gevallen gezien waarbij ingelogde WooCommerce-gebruikers 5 tot 9 seconden wachten op een pagina die voor anonieme bezoekers in minder dan een seconde laadt.

Hoe elk platform ermee omgaat

WooCommerce stelt verschillende cookies in wanneer een gebruiker toevoegt aan de winkelwagen: woocommerce_cart_hash, woocommerce_items_in_cart en wp_woocommerce_session. Op het moment dat een caching plug-in (WP Rocket, LiteSpeed Cache, WP Super Cache) deze cookies detecteert, wordt de cache voor elke pagina omzeild. Niet alleen de winkelwagenpagina. Je homepage, je productpagina's, je categoriepagina's: allemaal ongecached. Daarbovenop vuurt WooCommerce een AJAX-verzoek af naar /?wc-ajax=get_refreshed_fragments bij elke paginalading om de mini-winkelwagen-widget up-to-date te houden. Dit verzoek alleen al kan 2 tot 3 seconden duren op shared hosting.

Dit is een reden waarom WooCommerce het laagste Core Web Vitals slagingspercentage heeft van alle grote e-commerce platforms. Volgens de 2025 Web Almanac slaagt slechts 33% van de WooCommerce-sites voor alle drie de Core Web Vitals op desktop, vergeleken met 76% voor Shopify.

Shopify gaat hier beter mee om dankzij de beheerde CDN-infrastructuur, maar zelfs Shopify kan geen pagina's cachen die customer of cart objecten bevatten. Het verschil is dat Shopify's basis-TTFB (rond 0,51 seconden) al snel genoeg is, waardoor de ongecachte straf kleiner is.

Magento 2 vond een slimme oplossing: de volledige pagina wordt altijd gecached, zelfs voor winkelwagen-gebruikers. Dynamische content (mini-winkelwagen, begroeting van de gebruiker, voorraadstatus) wordt aan de clientzijde opgehaald via AJAX naar /customer/section/load/ en opgeslagen in de localStorage van de browser. De pagina zelf blijft in de volledige pagina-cache. Dit is het "slow by design" probleem opgelost op architectuurniveau.

Je beste klanten krijgen je slechtste pagina's

De cijfers maken dit pijnlijk. Farfetch mat een daling van 1,3% in conversieratio voor elke toename van 100ms in LCP. Blue Triangle vond een daling van 40 tot 50% in conversieratio wanneer LCP van 2 seconden naar 4 tot 5 seconden gaat.

Een bezoeker bladert door je snelle, gecachte site. Ze vinden een product dat ze leuk vinden. Ze klikken op "toevoegen aan winkelwagen". Op dat exacte moment stopt de caching en springt hun TTFB van 100ms naar 1.600ms. Vanaf hier is elke pagina die ze bezoeken (producten vergelijken, verzending controleren, naar de kassa gaan) ongecached. De mensen die het meest waarschijnlijk zullen kopen, bladeren nu door de langzaamste versie van je site.

Op sites gemonitord door CoreDash zien we dat winkelwagen-gebruikers een 3 tot 5 keer slechtere TTFB ervaren dan anonieme bezoekers op zelf-gehoste e-commerce platforms. Op beheerde platforms zoals Shopify is het gat kleiner (1,5 tot 2x) maar nog steeds meetbaar.

Hoe je dit detecteert in je RUM-data

Je kunt dit probleem niet zien in Lighthouse of PageSpeed Insights. Die tools testen als anonieme bezoekers zonder cookies. Je labscores zullen er geweldig uitzien terwijl je daadwerkelijke kopers het moeilijk hebben.

Om dit probleem te vinden, heb je Real User Monitoring nodig. Segmenteer je RUM-data op of de gebruiker een winkelwagen-cookie heeft ingesteld. Vergelijk de TTFB, FCP en LCP tussen deze twee segmenten. Als je een gat van 2x of groter ziet, is het omzeilen van de cache je probleem.

In de meeste analytics-platforms kun je ook segmenteren op paginatype. Vergelijk je productoverzichtspagina's (meestal gecached) met je winkelwagen- en afrekenpagina's (nooit gecached). Een TTFB-verschil van meer dan 500ms tussen deze paginatypes is een rode vlag dat je server waiting duration aandacht nodig heeft.

Hoe je prestaties verbetert voor bezoekers met hoge intentie

Fix de backend voordat je op caching vertrouwt. Vertrouw niet uitsluitend op caching plug-ins. Analyseer je backend-code, optimaliseer databasequery's en finetune je server om een snelle TTFB te garanderen, zelfs zonder caching. Een site die traag is zonder cache zal catastrofaal traag zijn voor winkelwagen-gebruikers. Het cache duration onderdeel van TTFB zou niet al het zware werk moeten doen.

Gebruik gedeeltelijke caching (fragment caching). Cache de dure onderdelen van je pagina apart. Productbeschrijvingen, navigatiemenu's en footer-content veranderen zelden en kunnen gecached worden in Memcached of Redis, zelfs wanneer de volledige pagina-cache is uitgeschakeld. Wanneer een winkelwagen-gebruiker een pagina opvraagt, stelt je CMS deze samen uit gecachte fragmenten in plaats van alles vanaf nul te genereren. Dit kan ongecachte TTFB met 60 tot 80% verminderen.

Render dynamische componenten aan de clientzijde. Dit is de Magento 2-aanpak en het werkt. Serveer het grootste deel van de pagina als gecachte HTML (server-side rendered). Gebruik vervolgens JavaScript en een kleine API-call om de dynamische delen (aantal in winkelwagen, gebruikersbegroeting, gepersonaliseerde aanbevelingen) op te halen nadat de pagina is geladen. De browser krijgt onmiddellijk de snelle, gecachte HTML. De dynamische bits vullen een moment later aan. Je LCP en FCP blijven snel omdat ze worden aangedreven door de gecachte shell, niet door de dynamische content.

Shopify's headless framework (Hydrogen) doet exact dit: productdata wordt agressief gecached met lange TTL's, terwijl winkelwagen- en klantdata CacheNone() gebruikt en aan de clientzijde wordt opgehaald na het laden. Dit patroon voorkomt ook INP-problemen omdat de dynamische fetch asynchroon gebeurt in plaats van gebruikersinteractie te blokkeren.

Implementeer effectief beheer van cache-sleutels. Gebruik simpele sleutels voor statische elementen (de URL is vaak genoeg als cache-sleutel) en complexe sleutels voor dynamische content die de gebruikers-ID, product-ID's en timestamps bevat. Dit laat je cachen op gebruikersniveau in plaats van te kiezen tussen "volledig gecached" en "helemaal niet gecached".

Schakel winkelwagen-fragmenten uit op niet-winkelwagenpagina's. Als je WooCommerce draait, schakel dan de wc-ajax=get_refreshed_fragments call uit op pagina's die geen mini-winkelwagen tonen. Verschillende prestatie-plug-ins (Perfmatters, FlyingPress) bieden hiervoor een schakelaar. Het elimineert een AJAX-call van 2 tot 3 seconden bij elke paginalading voor winkelwagen-gebruikers.

Overweeg edge-side composition. Als je Cloudflare gebruikt, kunnen Workers pagina's samenstellen op de edge: serveer de gecachte paginabody vanuit het CDN en injecteer dynamische fragmenten (winkelwagen, gebruikersinfo) via afzonderlijke sub-requests. Cloudflare heeft een Edge Side Includes-implementatie voor Workers gepubliceerd die exact dit doet, waardoor je TTFB snel blijft terwijl je toch gepersonaliseerde content serveert.