Het pleidooi voor het beperken van analytics- en trackingskripts

Waarom sites analytics- en trackingskripts gebruiken

Analytics- en trackingskripts dienen een reëel doel. Google Analytics vertelt je waar je bezoekers vandaan komen. Facebook Pixel houdt advertentieconversies bij. Hotjar laat je zien waar mensen klikken. Zonder deze data ben je aan het gissen.

Het probleem is niet dat deze tools bestaan. Het probleem is dat de meeste sites veel meer tracking laden dan ze nodig hebben. Populaire tools zoals Google Analytics, Facebook Pixel en Cloudflare analytics voegen allemaal JavaScript, cookies en HTTP-verzoeken toe. En ze zijn zelden de enige tracking op de pagina.

Feit: In ongeveer 90% van alle audits vind ik ongebruikte trackingskripts. Meestal worden deze skripts laat geïnjecteerd via een tag manager of een ander skript van een derde partij.

Hoe zwaar zijn deze skripts?

Niet alle trackingskripts zijn gelijk. Dit is wat de meest voorkomende je daadwerkelijk kosten:

• Google Analytics 4 (gtag.js): 134 KB gecomprimeerd, 371 KB ongecomprimeerd. Asynchroon geladen, dus het blokkeert het renderen niet, maar de JavaScript moet nog steeds worden geparst en uitgevoerd op de hoofdtrååd.
• Google Tag Manager: ~33 KB gecomprimeerd voor de library zelf, plus de tags die je erin plaatst. De [url=https:\/\/web.dev\/articles\/tag-best-practices]mediane container is ongeveer 50 KB[\/url]. Een lege GTM-container voegt ongeveer 100 ms vertraging toe. Acht trackingtags binnen GTM voegen ongeveer [url=https:\/\/www.analyticsmania.com\/post\/google-tag-manager-impact-on-page-speed-and-how-to-improve\/]3 seconden toe op Fast 3G en 10 seconden op Slow 3G[\/url].
• Facebook\/Meta Pixel: 340 KB ongecomprimeerd (95 KB gecomprimeerd). Dat is [url=https:\/\/pixely.co.uk\/high-performance-cost-of-facebook-tracking-pixels\/]7 keer groter dan Google Analytics[\/url]. Het doet 4 HTTP-verzoeken voordat het klaar is en voegt 1,3 tot 1,5 seconden toe aan elke pagina-load.
• Consent Management Platforms: OneTrust kan 124 tot 347 KB toevoegen, afhankelijk van de configuratie. In één geval [url=https:\/\/www.rumvision.com\/use-cases\/be-wary-a-cookie-banner-may-cause-your-lcp-to-vary\/]werd een cookiebanner het LCP-element[\/url], waardoor LCP steeg van 1,43 s naar 3,61 s.

  Stapel GA4 + GTM + Facebook Pixel + een cookiebanner en je kijkt naar ongeveer 400 tot 600 KB aan tracking-JavaScript voordat je eigen code überhaupt draait. Dat is vaak meer dan de gehele pagina-inhoud zelf.

  Hoe trackingskripts de Core Web Vitals beïnvloeden

  Largest Contentful Paint

  Elk skript concurreert om netwerkbandbreedte en CPU-tijd tijdens het laden van de pagina. Zelfs asynchrone skripts nemen bandbreedte in beslag die gebruikt had kunnen worden voor de [url=\/core-web-vitals\/largest-contentful-paint]LCP[\/url]-afbeelding of kritieke CSS. Wanneer je 8 trackingskripts laadt naast je hero-afbeelding, dwing je de browser om zijn beperkte mobiele bandbreedte over al deze skripts te verdelen.

  Dit is vooral erg op mobiele netwerken. De [url=https:\/\/almanac.httparchive.org\/en\/2025\/performance]2025 Web Almanac[\/url] rapporteert een mediane mobiele Total Blocking Time van 1.916 ms (58% meer dan in 2024). Veel van die blokkering is afkomstig van JavaScript van derden. Je kunt je [url=\/pagespeed\/14-methods-to-defer-javascript]skripts uitstellen (defer)[\/url], maar ze concurreren nog steeds om resources zodra ze beginnen te laden.

  Interaction to Next Paint

  [url=\/core-web-vitals\/interaction-to-next-paint]Interaction to Next Paint (INP)[\/url] is waar trackingskripts de meeste schade aanrichten. De [url=https:\/\/almanac.httparchive.org\/en\/2024\/performance]2024 Web Almanac[\/url] ontdekte dat presentation delay de belangrijkste bijdrage levert aan een slechte INP, en de skripts die dit veroorzaken zijn tools voor gedragstracking, consent-providers en advertentiepixels.

  Veel trackingskripts blijven werken lang nadat de pagina is geladen. Google Analytics kan worden geconfigureerd om elke klik bij te houden. Heatmap-tools zoals Hotjar luisteren naar elke muisbeweging. Elk van deze event-listeners voegt verwerkingstijd toe aan gebruikersinteracties. Wanneer een bezoeker op een knop klikt en jouw code 50 ms nodig heeft om dit af te handelen, maar drie trackingskripts vuren ook event-listeners af die nog eens 150 ms toevoegen, voelt de interactie traag aan.

  De cijfers vertellen het verhaal: 77% van alle mobiele pagina's slaagt voor INP, maar slechts 53% van de top 1.000 meest bezochte websites doet dat. Die top-sites hebben complexere JavaScript en meer skripts van derden. Als je je [url=\/pagespeed\/yield-to-main-thread]pagina's responsief wilt houden[\/url], zijn trackingskripts de eerste plek om te kijken.

  Time to First Byte en cookie-overhead

  Elk trackingskript kan zijn eigen cookies plaatsen. Individuele cookies zijn klein (mediaan 40 bytes volgens de [url=https:\/\/almanac.httparchive.org\/en\/2025\/cookies]2025 Web Almanac Cookies hoofdstuk[\/url]), maar hun collectieve impact telt op omdat cookiegegevens bij elk HTTP-verzoek worden meegestuurd. Als je site 4 KB aan cookies plaatst en 39 resources laadt, is dat 156 KB aan extra uploadgegevens over die verzoeken.

  Wanneer de totale cookiegegevens de 1.500 bytes overschrijden, passen verzoekheaders niet meer in een enkel TCP-pakket. Dat dwingt tot extra round-trips, waardoor je [url=\/core-web-vitals\/time-to-first-byte]Time to First Byte[\/url] bij volgende navigaties en het laden van statische resources direct toeneemt.

  Cumulative Layout Shift

  Consentbanners zijn hier de grootste boosdoener. Wanneer een cookiebanner laat rendert en de pagina-inhoud naar beneden drukt, veroorzaakt dit een [url=\/core-web-vitals\/cumulative-layout-shift]layout shift[\/url]. Sommige consent-platforms injecteren grote DOM-trees (200+ nodes) die de pagina herberekenen. In één gedocumenteerd geval was een consentbanner het LCP-element voor 50% van de paginaweergaven omdat het bovenop de eigenlijke inhoud werd gerenderd.

  Strategieën voor slimmere tracking

  Audit wat je daadwerkelijk gebruikt

  Open je tag manager en loop elke afzonderlijke tag na. Vraag je bij elke tag af: wie leest deze data? Wanneer is dit voor het laatst gecontroleerd? Als niemand het antwoord weet, verwijder het dan. Ik vind regelmatig tags voor A\/B-testtools van campagnes die maanden geleden zijn geëindigd, pixels voor advertentieplatforms die het bedrijf niet meer gebruikt, en dubbele analytics-implementaties (zowel GA4 via GTM als een hardcoded gtag.js).

  Stel niet-essentiële skripts uit

  Niet alles hoeft direct bij het laden van de pagina te worden geladen. Niemand is ooit teleurgesteld geweest dat een heatmap-skript pas 3 seconden na het laden begon met opnemen. Vuur analytics- en trackingtags af bij het Window Loaded event of, nog beter, [url=\/pagespeed\/defer-scripts-until-needed]stel ze uit totdat de gebruiker interactie heeft[\/url] met de pagina. Uit tests van AnalyticsMania bleek dat het uitstellen van het vuren van tags met 1,5 seconde na het laden van de pagina 6 seconden bespaarde op Slow 3G.

  \/\/ Laad analytics pas na de eerste gebruikersinteractie
  const events = ['click', 'scroll', 'mousemove', 'touchstart'];
  const loadAnalytics = () => {
      events.forEach(e => document.removeEventListener(e, loadAnalytics));
      \/\/ Laad hier je analytics-skript
      const script = document.createElement('script');
      script.src = 'https:\/\/www.googletagmanager.com\/gtag\/js?id=G-XXXXXXX';
      document.head.appendChild(script);
  };
  events.forEach(e => document.addEventListener(e, loadAnalytics, {once: true}));
  
  Gebruik de Beacon API voor aangepaste events
  
  Als je aangepaste analytics-events verstuurt (formulierinzendingen, knopklikken, scrolldiepte), gebruik dan navigator.sendBeacon() in plaats van XMLHttpRequest. De Beacon API verstuurt data asynchroon zonder de hoofdtrååd te blokkeren en garandeert voltooiing, zelfs tijdens paginanavigatie. Dit is vooral belangrijk om [url=\/pagespeed\/datalayer-inp-yield-pattern]INP laag te houden bij interacties[\/url] die analytics-aanroepen triggeren.
  
  \/\/ Verstuur analytics-data zonder de interactie te blokkeren
  document.querySelector('.buy-button').addEventListener('click', (e) => {
      \/\/ Gebruik sendBeacon - niet-blokkerend, overleeft paginanavigatie
      navigator.sendBeacon('\/analytics', JSON.stringify({
          event: 'purchase_click',
          timestamp: Date.now()
      }));
  });
  
  Overweeg server-side alternatieven
  
  De meest effectieve manier om tracking-JavaScript te elimineren, is door het helemaal niet te laden. [url=\/pagespeed\/configure-cloudflare-for-passing-the-core-web-vitals]Cloudflare[\/url] Zaraz verplaatst de uitvoering van analytics naar de edge, waardoor client-side tag manager skripts worden vervangen door een lichtgewicht beacon. GTM Server-Side Containers laten je server data doorsturen naar analytics-providers zonder dat er JavaScript van de leverancier bij de browser komt. Deze benaderingen vergen meer inspanning om op te zetten, maar hun impact op de prestaties is nagenoeg nul.
  
  Voor eenvoudigere behoeften bieden lichtgewicht alternatieven zoals Plausible (minder dan 1 KB) of Umami (ongeveer 2 KB) bezoekersstatistieken voor een fractie van de 134 KB kosten van GA4.
  
  Hoe het eruit ziet als het goed is
  
  Bij sites die worden gemonitord door [url=https:\/\/coredash.app]CoreDash[\/url] slaagt ongeveer 88% voor INP op pagina's die minder dan 5 skripts van derden laden, vergeleken met 64% voor pagina's die er 15 of meer laden. Het verschil in LCP is net zo duidelijk: minder concurrerende verzoeken betekent dat de browser prioriteit kan geven aan wat er echt toe doet voor de bezoeker.
  
  Je hoeft niet alle tracking te verwijderen. Je moet bewust omgaan met wat je laadt, wanneer je het laadt en of iemand de data daadwerkelijk gebruikt. Begin met het auditen van je tag manager. Verwijder wat je niet nodig hebt. Stel uit wat je wel nodig hebt. Gebruik [url=https:\/\/coredash.app]Real User Monitoring[\/url] om de verbetering in fietddata te verifiëren, want labtests laten je niet het volledige beeld zien van hoe trackingskripts omgaan met echte netwerkomstandigheden en echt gebruikersgedrag.
  
  [include]cwv\/authorbio.html[\/include]
  
      
  
      
  [include]sidebar.html[\/include]
  
    
  
  
  [include]blogfooter.html[\/include]