A/B testen en Core Web Vitals: zo houd je beide gezond

Client-side A/B testen kost bijna altijd LCP, CLS of INP. Het testscript laadt extra JavaScript, verbergt de pagina tot de variant klaar is en wijzigt de DOM na de eerste render. Server-side of edge testing voorkomt dat grotendeels. Het kost wel meer bouwwerk. Kies op basis van hoeveel verkeer en hoeveel developer-capaciteit je hebt.

Waarom breekt A/B testen je Core Web Vitals?

Een client-side testtool wijzigt je pagina nadat de browser hem heeft opgebouwd. Dat raakt alle drie de Core Web Vitals.

Volgens Google zijn dit de drempels voor "goed", gemeten op het 75e percentiel van paginabezoeken (web.dev):

• LCP: binnen 2,5 seconden
• INP: 200 milliseconden of minder
• CLS: 0,1 of lager

Concreet gebeurt dit met een client-side tool:

1. De browser downloadt het testscript. Dat staat vaak in de en blokkeert rendering.
2. Het script bepaalt welke variant de bezoeker krijgt.
3. Het script past de DOM aan: andere kop, andere knop, verplaatst blok.
4. De bezoeker ziet intussen de originele pagina, een lege pagina, of een pagina die verspringt.

Elke stap kost milliseconden. Bij een shop met een LCP van 2,3 seconden is 300 ms extra genoeg om in het rood te belanden.

Wat is flicker en waarom is de anti-flicker snippet geen oplossing?

Flicker is het moment waarop de bezoeker kort de originele pagina ziet voordat de variant verschijnt. Een anti-flicker snippet verbergt de pagina tot de test geladen is. Dat lost het visuele probleem op en verergert je LCP.

De snippet zet de body op opacity: 0 en haalt dat weg zodra het testscript klaar is of een timeout afloopt. Typische timeouts liggen rond 3 seconden en meer. Alles wat je pagina in die tijd zou tonen, blijft onzichtbaar.

Het gevolg:

• LCP stijgt, want het grootste element is pas zichtbaar na het vrijgeven van de pagina.
• Een trage derde partij bepaalt je laadtijd. Valt de testtool uit of is hij traag, dan wacht je shop mee.
• Je meet het niet altijd goed in lab-tests. Een snelle testverbinding verbergt het probleem dat een bezoeker op 4G wel ziet.

Google Optimize, waarvoor de snippet oorspronkelijk bekend werd, bestaat niet meer. De tool is per 30 september 2023 gestopt. De snippet staat bij veel shops nog steeds in de code. Controleer of je hem nog laadt. Zo ja, dan kost hij performance zonder iets op te leveren.

Welke A/B-testaanpakken zijn er en wat kosten ze in CWV?

Er zijn vier aanpakken. Hoe dichter bij de server, hoe minder impact op je Core Web Vitals en hoe meer bouwwerk.

De eerlijke versie: er is geen gratis optie. Client-side is snel te starten en duur in performance. Server-side is schoon en duur in uren.

Wanneer kies je voor server-side testing?

Kies server-side zodra de test iets anders raakt dan tekst of kleur. Dat geldt voor checkoutstappen, prijsweergave, sortering, zoekresultaten en productpagina-layout.

Bij server-side testing bepaalt je backend de variant en stuurt direct de juiste HTML. De browser ziet geen wissel. Er is geen flicker en geen anti-flicker snippet. Je LCP-element staat in de eerste response.

Let op deze punten:

• Caching. Bij full-page cache (Varnish, Fastly) moet de variant in de cache-key, of je serveert per ongeluk variant A aan iedereen. Dit is de meest gemaakte fout.
• Bucketing. Wijs een bezoeker één keer toe en bewaar dat in een cookie. Anders ziet dezelfde persoon wisselende varianten.
• Meting. Stuur de variant mee in je analytics-events, zodat je conversie per variant kunt vergelijken.

Op een Magento-shop met Hyvä is dit goed te bouwen, omdat de frontend licht is en de variant in een template-blok of ViewModel wordt gekozen. Hoe sneller je basis, hoe meer ruimte je hebt voor tests. Meer over die basis staat op onze pagina over Magento performance.

Zijn feature flags hetzelfde als A/B testen?

Nee, maar ze delen de techniek. Een feature flag zet een functie aan of uit per gebruiker. Een A/B test is een flag met een meetplan eromheen.

Het voordeel van flags:

• Je rolt nieuwe functies gefaseerd uit, bijvoorbeeld naar 5% van het verkeer.
• Je schakelt een falende wijziging in seconden uit, zonder deploy.
• Dezelfde infrastructuur dient voor releases en experimenten.

In de praktijk zien wij dat teams die flags al gebruiken, A/B testen er bijna gratis bij krijgen. Teams die alleen een visuele editor hebben, missen die grip op performance.

Wil je in een Laravel-applicatie of een headless storefront testen, dan is een flag-laag meestal de schoonste route. Zie ook ons werk rond headless commerce met Laravel.

Welke A/B-testtools zijn er na Google Optimize?

Google Optimize en Optimize 360 zijn sinds 30 september 2023 niet meer beschikbaar. Google noemt zelf AB Tasty, Optimizely en VWO als partners met een integratie voor Google Analytics.

Dat geeft drie groepen:

• Visuele client-side platforms: AB Tasty, Optimizely, VWO. Ze zijn geschikt voor marketingteams. Je laadt een extern script. Controleer per tool hoe zwaar dat script is en of server-side of edge-opties zijn inbegrepen.
• Experimentatie met feature flags: onder meer GrowthBook, Statsig en PostHog. Deze zijn gericht op developers en werken vaak met SDK's in je backend.
• Eigen oplossing: een cookie, een flag in je code en events in je analytics. Voor één of twee tests per kwartaal is dit vaak genoeg.

Prijzen en featuresets veranderen regelmatig. Vraag dus altijd een actuele demo of bekijk de prijspagina van de leverancier voordat je kiest. Beoordeel ook de grootte van het script dat de tool in je pagina laadt. De impact daarvan lijkt op die van elke andere third-party script.

Hoe meet je of een test je Core Web Vitals schaadt?

Meet met veldata (CrUX) voor de uitspraak en met labdata (Lighthouse, WebPageTest) voor de diagnose. Alleen labdata is te optimistisch, alleen CrUX is te traag.

De CrUX-data is volgens Google gebaseerd op echte Chrome-gebruikers. Via de CrUX API zijn waarden beschikbaar over de voorgaande 28 dagen. Een verslechtering door een test zie je daar dus pas na dagen of weken volledig.

Daarom werkt dit in de praktijk beter:

1. Meet vooraf de baseline met lab en veld.
2. Stuur de variant mee in je RUM-data en vergelijk LCP, CLS en INP per variant.
3. Test eerst op een klein percentage verkeer.
4. Draai de test terug als de variant de 75e-percentielwaarde over een drempel duwt.

Let bij INP op de eventhandlers die een testscript registreert. Die lopen mee op elke klik. Meer over meten en verbeteren staat in ons artikel over INP voor e-commerce.

Hoeveel verkeer en hoe lang moet je testen?

Een test heeft genoeg bezoekers en conversies per variant nodig, en moet minimaal volledige weken lopen. Twee tot vier weken is een gangbare bandbreedte. Stop niet zodra de grafiek groen kleurt.

De kernregels:

• Bepaal vooraf je sample size. Die hangt af van je huidige conversieratio, het effect dat je wilt kunnen aantonen en je gewenste zekerheid. Gebruik een sample size calculator van je testtool.
• Hoe kleiner het effect, hoe meer verkeer. Een verbetering van 2% relatief vraagt veel meer bezoekers dan een van 20%.
• Loop hele weken. Gedrag op maandag verschilt van zaterdag. Stop op een volledige week.
• Niet tussentijds kijken om te stoppen. Wie telkens kijkt en stopt bij "significant", krijgt valse winnaars (peeking).
• Eén primaire metric. Kies er één, meestal conversie of omzet per bezoeker.

Een rekenvoorbeeld: stel dat je shop 20.000 sessies per maand heeft en 2% converteert. Dat zijn 400 orders. Verdeel je dat over twee varianten, dan heeft elke variant ongeveer 200 orders per maand. Dat is te weinig om een klein effect betrouwbaar aan te tonen. Bij dit volume werk je beter met grote, risicovolle wijzigingen of met kwalitatief onderzoek.

Dat is ook de eerlijke kant van testen: kleine shops kunnen vaak beter eerst de basis fixen. Hoe je dat datagedreven aanpakt, staat in ons artikel over conversie-optimalisatie voor webshops.

Hoe test je veilig zonder performance te verliezen?

Zet performance-grenzen in je testproces. Een test die conversie wint maar je LCP over 2,5 seconden duwt, kan netto verliezen.

Een praktische checklist:

• Laad het testscript async en zo laat mogelijk, tenzij de test boven de vouw staat.
• Gebruik geen anti-flicker snippet voor tests onder de vouw.
• Test layoutwijzigingen met vaste afmetingen (width, height, aspect-ratio) tegen CLS.
• Houd het aantal gelijktijdige tests laag. Elke test voegt code en DOM-wijzigingen toe.
• Ruim afgelopen tests op. Dode varianten en oude snippets blijven vaak jaren staan.
• Verplaats complexe tests naar server-side of edge.

Samengevat

• Client-side testtools kosten LCP, CLS en soms INP. De anti-flicker snippet maakt LCP slechter.
• Google Optimize is op 30 september 2023 gestopt. Controleer of de oude snippet nog in je code staat.
• Server-side en edge testing houden je CWV schoon, maar vragen developer-tijd en aandacht voor caching.
• Feature flags geven je gefaseerde uitrol en een kill switch. Experimenten zijn een natuurlijke uitbreiding.
• Meet met veld (CrUX, RUM) en lab. CrUX loopt over 28 dagen, dus vertraagd.
• Bepaal sample size vooraf, test hele weken en stop niet bij de eerste groene grafiek.
• Bij weinig verkeer is testen minder zinvol dan de basis verbeteren.

Veelgestelde vragen

Is Google Optimize nog beschikbaar?

Nee. Google Optimize en Optimize 360 zijn sinds 30 september 2023 niet meer beschikbaar. Actieve experimenten zijn op die datum gestopt. Google verwijst naar partners als AB Tasty, Optimizely en VWO.

Beïnvloedt A/B testen mijn SEO?

Indirect wel, via Core Web Vitals en laadtijd. Een client-side testscript dat LCP of CLS verslechtert, kan je field data over de drempels duwen. Server-side testing met consistente content per bezoeker vermijdt dat grotendeels.

Wat is beter: client-side of server-side A/B testen?

Voor performance is server-side beter, omdat de juiste HTML direct binnenkomt. Client-side is sneller op te zetten en laat marketing zelf testen. Kies server-side voor checkout, prijs en productpagina's. Kies client-side voor kleine tests onder de vouw.

Hoe lang moet een A/B test lopen?

Minimaal een of twee volledige weken, en vaak twee tot vier weken, afhankelijk van je verkeer en het effect dat je wilt aantonen. Bepaal de sample size vooraf en stop niet eerder omdat de uitkomst er goed uitziet.

Hoe zie ik of een test mijn LCP of CLS verslechtert?

Vergelijk met RUM-data per variant, en gebruik Lighthouse of WebPageTest voor diagnose. CrUX laat het effect pas na dagen zien, want het is een rolling window van 28 dagen.

Kan ik A/B testen in Magento of Shopify zonder performance te verliezen?

Ja, met server-side of flag-gebaseerde tests of een licht, async client-side script. Op Magento met Hyvä is server-side goed te bouwen. Op Shopify ben je vaker aangewezen op apps of scripts. Beoordeel daarvan altijd de impact op je laadtijd.

Wil je A/B testen opzetten zonder je Core Web Vitals te verliezen? Neem contact op.