In september 2024 introduceerde Google het gebruik van Service Workers in Google Tag Manager (GTM) om de prestaties en meetbetrouwbaarheid te verbeteren:
| “Google Tag Manager kan een service worker gebruiken om de prestaties en meetbetrouwbaarheid te verbeteren. Om ervoor te zorgen dat de service worker correct wordt geladen, raadpleeg je de richtlijnen voor Content Security Policy.” |
In maart 2025 kondigde Google vervolgens een uitbreiding van deze functionaliteit aan:
| “De Google tag gebruikt nu service workers, indien beschikbaar, om data naar server-side Tag Manager te verzenden, wat de prestaties en meetbetrouwbaarheid verbetert.” |
In dit artikel leggen we uit hoe GTM en gtag met Service Workers omgaan, wat een Service Worker is, hoe de communicatie daartussen verloopt en waarom je analytics-verzoeken mogelijk niet zichtbaar zijn in het DevTools Network-tabblad.
Service Workers zijn achtergrondscripts die los van de hoofdthread van een website draaien. Ze maken functies mogelijk zoals caching, offline ondersteuning en netwerkverzoeken op de achtergrond, zonder de gebruikersinterface te blokkeren.
In de context van GTM en gtag worden Service Workers gebruikt om het verzenden van meetdata vanaf de webpagina, zoals GA4- of Ads-hits, over te nemen. Dit maakt tracking sneller en betrouwbaarder, zelfs tijdens het verlaten van een pagina of bij trage netwerken. Let op dat in deze context events niet worden opgeslagen om later te verzenden.
Afhankelijk van je setup kunnen er twee soorten Service Workers worden geregistreerd:
1. Service Worker van je server-side GTM (sGTM) first-party domein
Wordt gebruikt voor GA4-verzoeken die naar server-side containers worden verstuurd.
2. Service Worker van het googletagmanager.com-domein
Wordt voornamelijk gebruikt door Ads-producten, zoals Google Ads en Floodlight, voor form-data- en user-data-verzoeken.
Beide varianten volgen een vergelijkbaar communicatiemodel waarbij meerdere browsercomponenten betrokken zijn.
Wanneer gtag of GTM wordt uitgevoerd, maakt het een onzichtbare infram aan (src=”about:blank”), die op zijn beurt een andere iframe laadt, sw_iframe.html. Deze tweede iframe is verantwoordelijk voor het installeren van het Service Worker-script (sw.js).
Deze elementen communiceren met elkaar via de postMessage() API van de browser om informatie te verzenden en via een message listener om deze te ontvangen. Dit vormt de volgende stroom:
gtag/GTM ↔ iframe (about:blank) ↔ iframe (sw_iframe.html) ↔ sw.js (Service Worker)Deze koppeling maakt het mogelijk dat gtag of GTM op de hoofdpagina eventdata doorgeeft aan de Service Worker, die vervolgens bepaalt hoe en wanneer deze data wordt verzonden.
Als je de webpagina inspecteert via het DevTools Elements-tabblad, kun je deze iframes terugzien.

Praktijkvoorbeeld van de berichten die worden uitgewisseld tussen de iframe en de Service Worker:
googletagmanager.com-domeinDeze Service Worker wordt gebruikt voor GA4-verzoeken die naar een server-side GTM-container worden verzonden.
Het GA4 gtag (G-{Measurement ID} enz.) is verantwoordelijk voor het doorsturen van events naar de Service Worker.
Het controleert op basis van meerdere voorwaarden of een event via de Service Worker moet worden verzonden:
⦿ Het event wordt niet rechtstreeks verzonden naar analytics.google.com/g/collect of www.google-analytics.com/g/collect (bijvoorbeeld wanneer de parameter server_container_url is geconfigureerd).
⦿ De pagina wordt niet afgesloten (beforeunload-event). Tijdens het afsluiten slaan verzoeken zoals het user_engagement-event de Service Worker over.
⦿ De browser bevindt zich niet in een beperkte omgeving (zoals WebView, de Google App op iOS of in-app browsers van Facebook en Messenger).
"; wv" OF "FBAN" OF "FBAV" OF (("GSA" OF "GoogleApp") EN ("iPhone" OF "iPad"))⦿ De Service Worker is actief en klaar voor gebruik (state 2).
.delegate(), die je hier kunt zien.Als aan alle voorwaarden wordt voldaan, wordt het event via de Service Worker verzonden. Zo niet, dan wordt het event rechtstreeks vanaf de hoofdpagina verzonden met fetch, XHR, sendBeacon, of Image (in deze volgorde).
Daarnaast wordt, als aan de eerste twee voorwaarden is voldaan, de parameter richsstsse toegevoegd aan de event-URL (lees hier meer over). Deze parameter stelt de browser in staat om de response te verwerken, zoals het verzenden van verzoeken die door sGTM worden aangestuurd voor synchronisatie van third-party cookies.
Deze Service Worker lijkt events te verwerken voor Google Ads- en Floodlight-producten.
Sommige verzoeken lopen via deze Service Worker, zoals:
https://www.google.com/ccm/form-data/{Conversion ID}/... en https://www.google.com/pagead/form-data/{Conversion ID}/...)https://www.google.com/ccm/form-data/{Conversion ID}/...).Het Ads-product gtag-script dat op de pagina wordt geladen (AW-{Conversion ID}, DC-{Floodlight Config ID}, enz.) is verantwoordelijk voor het doorsturen van events naar de Service Worker.
De voorwaarden voor het gebruik van deze Service Worker zijn vergelijkbaar:
⦿ De tag is geconfigureerd om user data te verzenden en de interne parameter send_user_data_hit heeft een van de volgende waarden:
user_data_web: gebruikt door het Auto-captured User-data Eventuser_data_lead: gebruikt door het Google Ads User-Provided Event⦿ De pagina wordt niet afgesloten (beforeunload event).
⦿ De Service Worker is actief en klaar voor gebruik (state 2).
.delegate(), die je hier kunt zien.Als aan een van deze voorwaarden niet wordt voldaan, wordt de hit zoals gebruikelijk vanaf de hoofdpagina verzonden.
Zowel gtag als GTM bevatten een methode met de naam .delegate, die de laatste controle uitvoert voordat wordt bepaald of het event via de Service Worker of via de hoofdpagina wordt verzonden.
De logica is vrij eenvoudig:
k.delegate = function (a, b, c) {
this.getState() !== 2
? (this.H.C( // Path 1: Not Ready - Sends event from main page.
this.C,
{
state: this.getState(),
hg: this.initTime,
ng: Math.round(Ab()) - this.initTime
},
void 0,
a.commandType
),
c({ // Call the failure callback
failureType: this.C
}))
: this.N.wo(a, b, c); // Path 2: Ready - Sends events from Service Worker.
};
Wanneer de state gelijk is aan 2, wordt het verzoek via de Service Worker verzonden. In alle andere gevallen wordt het verzoek via de hoofdpagina verstuurd.
De Service Worker en de hoofdpagina wisselen periodiek heartbeat-berichten met elkaar uit, momenteel elke 5 seconden, om deze state up-to-date te houden. De state-variabele geeft aan in hoeverre de Service Worker gereed is:
| State | Betekenis |
|---|---|
0 | initiële status bij het laden van de pagina |
1 | poging om communicatie tot stand te brengen tussen de hoofdpagina en de Service Worker |
2 | Service Worker is gereed en de handshake met de hoofdpagina is succesvol |
3 | opnieuw proberen na een fout |
4 | fatale fout / mislukt / communicatiekanaal is gesloten |
Je kunt het gebruik van Service Workers op meerdere manieren controleren.
Filter op verzoeken naar sw.js of sw_iframe.html.
Let op:
Service Worker geladen vanaf het sGTM first-party domein


Service Worker geladen vanaf het googletagmanager.com-domein.

Open DevTools → ga naar het Application-tabblad → Service Workers → klik op See all registrations en zoek naar je domein.

Als je Ads-producten van Google gebruikt, zie je de Service Worker die wordt geserveerd vanaf googletagmanager.com.

Verzoeken die door een Service Worker worden afgehandeld, tonen een tandwielicoon naast de URL. Dit zijn hits die vanuit een achtergrondproces worden verzonden in plaats van vanaf de hoofdpagina.

Als je GA4- of Ads-events niet verschijnen in het Network-tabblad van de hoofdpagina, worden ze waarschijnlijk via de Service Worker verzonden. Ze verschijnen echter nog steeds in het GTM Preview Mode-venster, waar je ze kunt inspecteren.
Je kunt maximaal twee Service Workers zien: één voor je sGTM-domein en één voor het domein van Google. Elk verwerkt verschillende typen events, zoals hierboven beschreven.
De geleidelijke integratie van Service Workers in GTM en gtag door Google markeert een verschuiving naar een robuustere manier van het verzenden en verwerken van events. Door het verzenden van events uit te besteden aan achtergrondprocessen verbetert Google de prestaties, betrouwbaarheid en nauwkeurigheid van dataverzameling, vooral in edge cases zoals snelle bounces of instabiele verbindingen. Dit betekent echter ook dat sommige verzoeken niet meer zichtbaar zijn in het traditionele Network-tabblad.
Voor specialisten in digitale analytics betekent dit:
Naarmate deze functionaliteit zich verder ontwikkelt, is het essentieel om te begrijpen hoe gtag en GTM Service Workers inzetten voor correcte debugging en betrouwbare data.
Opmerkingen