Heb je de juiste tool gekozen, of vooral de traagste?

Je webshop kan technisch prima gebouwd zijn en toch traag aanvoelen. Niet door je eigen code, maar door alles wat er later aan is toegevoegd: cookie banners, heatmaps, chat widgets, tag managers en andere third parties.

Die tools leveren vaak waarde op. Maar ze hebben ook een prijs. En die prijs wordt steeds vaker betaald door je bezoekers.

Sinds Interaction to Next Paint, kortweg INP, onderdeel is van de Core Web Vitals, is dit onderwerp belangrijker geworden. INP meet hoe snel een pagina reageert op interacties zoals klikken, tikken en typen. En precies daar kunnen third parties flink in de weg zitten.

Third parties geven vaak geen laadtijd probleem, maar interactieproblemen

Veel teams kijken bij performance nog steeds vooral naar laadtijd. Hoe snel verschijnt de homepage? Hoe snel staat de productfoto in beeld? Hoe scoort een pagina in een testomgeving? Belangrijk, maar niet compleet.

Een bezoeker ervaart performance juist ook wanneer die iets probeert te doen. Een filter openklappen. Een maat kiezen. Een cookie banner accepteren. Een chatvenster sluiten. Een product in de winkelwagen zetten.

Als JavaScript op dat moment de browser bezet houdt, voelt de site traag. Soms reageert de pagina pas na honderden milliseconden. Soms klikt de gebruiker nog een keer, omdat het lijkt alsof er niets gebeurt. Dat is geen klein detail. Dit raakt direct aan de gebruikerservaring.

Waarom we naar (third party) LoAF data kijken

Om die impact zichtbaar te maken, kijken we in RUMvision onder andere naar LoAF-data. LoAF staat voor Long Animation Frames.

Simpel gezegd laat LoAF zien wanneer JavaScript de browser zo lang bezighoudt dat interacties kunnen gaan haperen. Daardoor kun je beter herleiden welke scripts, bijvoorbeeld van een CMP, heatmaptool of chatbot, mogelijk bijdragen aan een slechtere INP.

In plaats van alleen te zeggen “de site voelt traag”, kun je dus concreter worden: Welke third party veroorzaakt veel JavaScript execution time bij echte bezoekers? Dat maakt het onderwerp ineens een stuk praktischer. Niet alleen voor developers, maar ook voor e-commerce, marketing, CRO en product teams.

Niet elke tool in dezelfde categorie is even zwaar

Dit is misschien wel het belangrijkste punt. De discussie hoeft niet te zijn: wel of geen cookiebanner. Wel of geen heatmap. Wel of geen chat. De betere vraag is “Hebben we de juiste tool gekozen voor deze taak?”

Uit RUMvision data zien we grote verschillen binnen dezelfde categorieën. In de benchmark vergelijken we third-party performance over de laatste 7 dagen met de voorgaande week. Om de data zinvol te houden, nemen we alleen third parties mee met minimaal 1000 events. En dan worden de verschillen al snel zichtbaar.

Consent Management Platforms: noodzakelijk, maar niet altijd licht

Een CMP is voor veel webshops geen optie meer. Je hebt een consent oplossing nodig. Maar dat betekent niet dat elke oplossing dezelfde impact heeft.

In de RUMvision-benchmark zien we bij CMP’s flinke uitschieters. Zo komt Cookiebot terug met 804 ms JavaScript execution time. Pandectes zit op 572 ms. Ook tools als Cookiefirst, iubenda, Osano, Usercentrics en CookieInformation zitten in de middenmoot, met waarden tussen grofweg 280 en 426 ms.

Tegelijk zien we ook CMP’s die lager uitkomen. CookieYes zit bijvoorbeeld op 177 ms en Didomi op 145 ms.

Dat betekent niet automatisch dat de ene tool goed is en de andere slecht. Functionaliteit, configuratie, implementatie en timing spelen allemaal mee. Maar het laat wel zien dat de keuze voor een CMP geen neutrale technische beslissing is.

Een cookie banner is vaak een van de eerste scripts waar een nieuwe bezoeker mee te maken krijgt. Als die ervaring traag is, begint de sessie al met frictie.

Heatmapping: frictie meten, of frictie veroorzaken?

Heatmaps en sessie recordings worden vaak ingezet om frictie op te sporen. Waar haken bezoekers af? Waar klikken ze? Welke elementen worden genegeerd? Welke stappen zorgen voor twijfel? Dat zijn waardevolle inzichten. Maar er zit wel een interessante tegenstrijdigheid in.

Als de tool waarmee je frictie meet zelf zorgt voor extra JavaScript execution time, meet je mogelijk deels een ervaring die je zelf zwaarder hebt gemaakt.

Ook in deze categorie zien we grote verschillen. In de benchmark komt PostHog terug met 516 ms, Heatmap.com met 490 ms en Hotjar met 426 ms JavaScript execution time. Microsoft Clarity zit in de benchmark rond 209 tot 225 ms. Noibu en FigPii komen lager uit, met respectievelijk 193 ms en 145 ms. Voor CRO-teams is dit belangrijke informatie. Niet om meteen tools uit te zetten, maar wel om kritisch te kijken naar de balans.

Levert de tool genoeg inzichten op om deze performance-impact te rechtvaardigen? En zo ja, moet de tool dan echt op elke pagina direct actief zijn?

Chatbots: handig voor support, maar vaak sitebreed aanwezig

Chat Widgets hebben een duidelijke businesscase. Zeker in e-commerce kunnen ze vragen wegnemen, twijfels oplossen en support druk verlagen. Maar ook hier geldt: niet elke chatoplossing heeft dezelfde impact.

In de RUMvision benchmark zien we onder andere Trengo op 290 ms, CM.com op 282 ms, Intercom op 274 ms en tawk.to op 258 ms. Gorgias zit lager met 193 ms.

Het interessante aan chat widgets is dat ze vaak site breed worden ingeladen. Dus ook op pagina’s waar bijna niemand de chat gebruikt. Denk aan categoriepagina’s, contentpagina’s of pagina’s waar de bezoeker nog helemaal niet in de koopfase zit. Dan is het verstandig om kritisch te kijken naar timing en relevantie.

Moet de chat widget direct laden? Kan hij later worden ingeladen? Alleen na interactie? Alleen op bepaalde pagina’s? Alleen wanneer iemand langer blijft hangen?

Performance-optimalisatie betekent niet altijd schrappen. Vaak begint het met slimmer laden.

Waarom krijgt dit nog zo weinig aandacht?

Third parties beoordelen klinkt simpel. Je maakt een overzicht van externe scripts, kijkt naar de impact en besluit wat blijft, wat later mag laden en wat weg kan. Toch gebeurt het in de praktijk vaak niet.

Daar zijn twee begrijpelijke redenen voor:

1. Developers hebben al genoeg op hun bordje
Development Teams werken niet in een vacuüm. Er zijn roadmaps, bugs, releases, tracking verzoeken, marketingcampagnes, privacy wensen, platform migratie en incidenten.

Third-party governance voelt dan al snel als extra werk. Niet als iets dat direct omzet oplevert.

Totdat je het koppelt aan echte gebruikersdata. Dan wordt het minder abstract. Je ziet welke scripts bijdragen aan trage interacties, op welke pagina’s dat gebeurt en welke bezoekers daar last van hebben. Daarmee wordt het geen algemene performance-discussie meer, maar een concrete prioriteitenlijst.

2. Het legt ongemakkelijke keuzes bloot

Third-party performance is niet alleen technisch. Het raakt ook aan keuzes die eerder door marketing, CRO, legal, support of management zijn gemaakt.

Niemand zegt graag: “Deze tool die we vorig kwartaal hebben gekozen, maakt de site aantoonbaar zwaarder.” Maar precies daarom is de data waardevol. Het gaat niet om schuld. Het gaat om bijsturen.

Als een tool veel waarde levert, kun je onderzoeken hoe je hem slimmer implementeert. Als een tool weinig gebruikt wordt en veel JavaScript execution time veroorzaakt, is verwijderen misschien gewoon de beste optimalisatie.

Onder aan de streep wil iedereen hetzelfde: het beste resultaat voor je klant en voor de business.

Kijk verder dan een losse performance-score

Een synthetische test laat lang niet altijd zien wat er gebeurt bij echte bezoekers. Zeker niet wanneer third parties pas na consent, interactie, targeting of specifieke campagnes actief worden.

Daarom is real-user data belangrijk. Je meet niet alleen een testscenario, maar echte sessies op echte apparaten. Inclusief mobiele bezoekers, tragere toestellen, drukke pagina’s, marketingtags en scripts die alleen onder bepaalde omstandigheden actief zijn.

Voor third parties is dat essentieel. Want de vraag is niet alleen welke tools er gebruikt worden. Maar vooral, wat doen deze tools bij echte bezoekers?

Een goede third-party review kijkt daarom niet alleen naar aanwezigheid, maar ook naar impact.

● Wat doet deze tool met JavaScript execution time?
● Op welke pagina’s laadt hij?
● Is hij nodig voor elke bezoeker?
● Kan hij later of conditioneel worden geladen?
● Is er een lichter alternatief?
● Levert de tool genoeg waarde op voor de performance-impact?

De juiste tool is niet alleen functioneel, maar ook snel genoeg

Een third party kan perfect passen op papier en alsnog de verkeerde keuze zijn voor je webshop. Niet omdat de functionaliteit slecht is, maar omdat de impact op echte gebruikers te groot is. Zeker bij CMP’s, heat mapping tools en chatbots loont het om tools naast elkaar te zetten. Niet op basis van gevoel, maar op basis van data.

Want performance is geen technisch randje meer. Het raakt conversie, advertentie rendement, gebruikerservaring en klanttevredenheid.

De vraag is dus niet of je third parties nodig hebt. Die heb je vaak gewoon nodig. De betere vraag is: Heb je de juiste tool gekozen voor de job, of vooral de traagste?

 

Over de auteur: Jordy Scholing is Co-owner / Customer success bij RUMvision