Als bezoeker van websites erger ik me al vanaf het begin aan de Cookie Consent (of Privacy Consent) meldingen. Vooral degenen die na een paar seconden verschijnen of die me doorverwijzen naar een andere pagina om de instellingen globaal te beheren (nou ja, ze beheren mijn verwachtingen zeker niet!). Het leidt me af van de inhoud en zoals de meeste bezoekers accepteer ik die cookies toch wel. Dus hoe sneller ze verschijnen, hoe beter. Google heeft onlangs aangekondigd dat de Core Web Vitals deel gaan uitmaken van het algoritme voor zoekmachineranking en is al begonnen met het labelen van snelle sites in Chrome! Daarom wil ik weten hoe de verschillende implementaties van cookietoestemming deze statistieken beïnvloeden.
Als je niet weet wat er aan de hand is met de Core Web Vitals, lees er dan over na het lezen van mijn artikel: Link voor meer informatie. Voor nu is het belangrijkste dat je weet dat de Largest Content Paint (LCP) een visuele laadmethode is en wordt bijgewerkt tijdens het laden van de pagina. Dit betekent dat wanneer er iets verandert, deze metriek kan/zal worden bijgewerkt totdat de pagina als geladen wordt beschouwd. Mijn veronderstelling was dat de LCP beïnvloed zou worden door het langzaam laden van toestemmingsmodals. Spoiler: dit is het geval, maar op onverwachte manieren! Voor dit voorbeeld heb ik 4 bekende merken in Nederland uitgekozen met allemaal een andere implementatie. In de afbeelding hieronder zie je het eindresultaat wanneer de pagina wordt geladen.
Twee van de vier websites zouden moeten optimaliseren op het moment dat ze de cookietoestemming tonen, maar slechts één wordt daadwerkelijk bestraft in de LCP metric. Kun je raden welke dat is? Ik niet! Tenminste niet als ik de screenshots van de volledig geladen pagina’s vergelijk. Een andere aanwijzing zou zijn dat twee van hen een extern geladen toestemmingsbeheerder gebruiken, maar dat slechts bij één van hen de metriek wordt beïnvloed. Enig idee op welke ik me verder moet richten?
Allereerst wil ik een compliment geven aan Wehkamp en Bol.com, omdat beiden de toestemmingsmanager op de best mogelijke manier hebben geïmplementeerd vanuit het oogpunt van prestaties en frustratie. Voor hen is het het belangrijkste stuk content en daarom wordt het als eerste geladen.
Extern geladen Cookie Toestemmingsbeheerders
In deze vergelijking is Zalando de enige die een extern geladen toestemmingsmanager van een derde partij gebruikt. Veel sites gebruiken zo’n toestemmingsmanager, maar in dit geval wilde ik de verschillende soorten implementaties laten zien.
Feit is dat deze toestemmingsbeheerders worden geladen nadat de externe scripts zijn geladen, wat meestal wordt geïmplementeerd via een Tag Management Systeem. Hetzelfde geldt voor elke pure javascriptimplementatie, wat vaak het geval is bij Single Page Applications.
Frustratie
Als de toestemmingsmanager plotseling de pagina overneemt, zorgt dit voor frustratie door misklikken of afhaken. Afhankelijk van hoe streng je bent, zul je de frustratie waarschijnlijk niet monitoren met je analytische schermopnametools. De juiste manier zou zijn om het vanaf het begin te laten zien, zoals Bol.com en Wehkamp, en zelfs te overwegen of het überhaupt een paginagrote overname moet zijn.
Je zou verwachten dat Zalando en VZG allebei een boete zouden krijgen voor dit gedrag. Maar alleen VGZ betaalt de boete.
Als ik naar de Chrome Devtools kijk met behulp van een klein fragment van https://web.dev/lcp/, kan ik zien wat er wordt gerapporteerd als mogelijke LCP. De laatste waarde wordt de uiteindelijke waarde. Hier kan ik zien dat een tijdje de H2 titel wordt overwogen, maar wanneer de toestemming wordt getoond, wordt dit de LCP.
De metrics kloppen niet altijd!
Waarom is dit niet het geval bij Zalando? Bij het laden van de Zalando homepage wordt het volgende gemeld door dezelfde snippet.
Below list is a user friendly representation of the above list from the Chrome Onderstaande lijst is een gebruiksvriendelijke weergave van de bovenstaande lijst uit de Chrome Developer Tools:
De hoofdinhoud wordt weergegeven na 229 ms
De koptitel wordt na 254 ms gerenderd
De afbeelding van de held wordt geladen van een ander domein, gedownload en gerenderd na 400ms
En het categoriemenu wordt na 525 ms gerenderd
De laat getoonde toestemming voor de volledige pagina wordt niet beschouwd als de LCP.
Hoe is dat mogelijk? Het menu beslaat slechts 1/4e van de pagina, geen tekst en kleine afbeeldingen. Het toestemmingsmodaal is duidelijk het grootste element dat wordt weergegeven. Op de een of andere manier denkt Chrome dat er een paginavullend menu is en rapporteert het daarom als de grootste content full paint.
Het gemelde menu is niet echt het zichtbare menu, maar een aantal links die niet worden getoond omdat het menu wordt verkleind naar 1 x 1 pixels. Mijn beste gok is dat dit wordt gedaan voor toegankelijkheid of SEO-doeleinden.
Op de rechterafbeelding heb ik de resize door CSS verwijderd om de werkelijke inhoud te laten zien. Als je naar de W3C specs kijkt, zie je dat er moeite is gedaan om ervoor te zorgen dat de intrinsieke afbeeldingsgrootte wordt gebruikt, maar ik kan niet hetzelfde vinden voor tekstknooppunten, wat waarschijnlijk de reden is waarom de CSS-resize niet wordt gebruikt om de werkelijke grootte te herberekenen. Misschien moet ik er een bugrapport voor maken.
Mijn beste gok zou zijn dat het Google-team hier een oplossing voor zal toepassen, aangezien dit duidelijk verkeerd wordt gerapporteerd. Omdat ik er vrij zeker van ben dat dit zal worden opgelost, raad ik je af om hetzelfde te doen alleen om een betere positie op LCP te krijgen. De statistieken zijn er tenslotte om betere ervaringen te bieden en frustraties weg te nemen. Is het niet voor de mensheid, dan wel voor mij. Ik ben nu al dankbaar.
Conclusie en te nemen maatregelen
- In de meeste gevallen zijn de statistieken correct en wijzen ze in de juiste optimalisatierichting.
- Soms kloppen de statistieken niet, dus wees voorzichtig als je vergelijkt met je concurrenten en controleer altijd dubbel of de vergelijking eerlijk is. Je weet nooit wanneer specificaties veranderen zolang het concepten zijn zoals deze.
- JavaScript geïnjecteerde en extern geladen toestemmingsmanagers schaden bijna altijd de waargenomen prestaties en worden meestal correct weergegeven in de statistieken. Als het krijgen van toestemming belangrijk is voor je bedrijf, zorg er dan voor dat het zo vroeg mogelijk wordt weergegeven.
- Implementeer een soort metingen om bij te houden wanneer de toestemming wordt getoond. Dit kan worden gedaan met gebruikerstimingmarkeringen die naar je analytics kunnen worden gestuurd.
- Alle 4 de merken hebben de toestemming zo geïmplementeerd dat 3e partijen niet worden geladen zonder toestemming. Hierdoor wordt er minder javascript uitgevoerd en zijn de pagina’s lichter. Dit heeft in de meeste gevallen een positief effect op de First Input Delay.
Bonus
Als je de mogelijkheid hebt om gebruik te maken van een CND edge worker (Cloudflare of Akamai bijvoorbeeld), dan zou je de toestemmings-HTML kunnen opnemen in de respons van de basispagina om deze te laten cachen op je CDN en de edge worker de HTML laten verwijderen als de toestemming al is gegeven (bijvoorbeeld als er een consent=true cookie is ingesteld). Dit heeft wel het voordeel dat je pagina’s ‘lang’ in de cache blijven. Zo’n contentvervangopdracht is slechts milliseconden werk voor de edge worker. Wehkamp en Bol.com gebruiken iets soortgelijks met hun CMS.
Dit artikel is eerder gepubliceerd op LinkedIn.
