⚡ GTM og sidehastighet: tester, funn og 8 måter å øke farten på nettstedet ditt

Markedsførere gjentar ofte: «Google Tag Manager gjør nettsider raskere, sider med GTM laster raskere.» Utviklere hevder gjerne: «GTM gjør ting bare tregere.» Sannheten ligger som alltid et sted midt imellom.

Vi kjørte en serie tester med ulike GTM-konfigurasjoner: en tom container, en container med 8 sporingskoder, hardkodede tagger, ulike tidspunkt for utløsing av triggere, dusinvis av egendefinerte HTML-tagger med DOM-manipulasjoner. Vi målte hastighet gjennom webpagetest.org og Lighthouse. Resultatene viste seg å være mindre entydige enn det GTM-presentasjoner hevder.

Her er hva vi fant: selve GTM-containeren bremser knapt noe som helst, men det du putter inn i den kan legge til 3 eller 10 sekunder på sidelastingen. Og det viktigste er at du kan kontrollere dette.

💡 Rask oversikt:

En tom GTM-container legger til omtrent 100 millisekunder på sidelastingen
Åtte sporingstagger gjennom GTM bremser siden med 3 sekunder på raskt 3G og opptil 10 sekunder på trege tilkoblinger
De samme 8 taggene hardkodet direkte inn på nettstedet bremser ting enda mer
Jo senere tagger utløses, desto mindre påvirkning har de: en forsinkelse på 1,5 sekunder etter Window Loaded reduserer lastetiden med 6 sekunder på tregt 3G
Godt planlagt triggerkonfigurasjon og opprydding i containeren gjenoppretter hastighet uten tap av data

Slik testet vi

Metodikken er enkel, men grundig. Vi kjørte hver test minst tre ganger og beregnet gjennomsnittet.

Verktøy: webpagetest.org (server i Irland, EC2, Chrome og Firefox for desktop, OnePlus 5 for mobiltester) og den innebygde Lighthouse-revisjonen i Chrome DevTools. I Lighthouse så vi på både mobil- og desktoprapporter. Chrome ble startet i inkognitomodus, uten utvidelser, med maksimal bærbar PC-ytelse.

Måleparametere vi brukte:

I webpagetest.org: Document complete (sekunder til statisk innhold, bilder, stiler er lastet) og Fully loaded (tidspunktet etter onLoad når nettverksaktiviteten roer seg i 2 sekunder). I Lighthouse: First Meaningful Paint, Time to Interactive, First CPU Idle og Max Potential First Input Delay (FID).

Sporingskoder i testene: Google Analytics (gtag.js), Facebook Pixel, Reddit Pixel, Quora Pixel, LinkedIn Insights, Twitter Universal Tag, Google Ads Remarketing (gtag.js), Hotjar. Åtte mye brukte skript.

Scenarioer vi sammenlignet:

Ren side uten tredjepartsskript og uten GTM
Side med 8 sporingskoder hardkodet rett før </head>, uten GTM
Tom GTM-container uten tagger
Alle 8 tagger gjennom GTM, All Pages-trigger (også kjent som gtm.js)
De samme 8 taggene gjennom GTM, DOM Ready-trigger (gtm.dom)
De samme 8 taggene gjennom GTM, Window Loaded-trigger (gtm.load)
De samme 8 taggene, som utløses 1,5 sekunder etter Window Loaded
GTM-container med forhåndsvisnings- og feilsøkingsmodus aktivert
GTM-container med 100 egendefinerte HTML-tagger som legger til elementer på slutten av <body>
GTM-container med 100 egendefinerte HTML-tagger som legger til elementer på et spesifikt sted på siden (etter H2)
GTM-container med 100 egendefinerte HTML-tagger som søker gjennom alle lenker og setter inn et element etter den 21.
GTM-container med 1976 konstante variabler (fylt til kapasitet, 200 KB)

Hva testene viste

Asynkront betyr ikke «uten konsekvenser»

Asynkrone skript blokkerer ikke rendering direkte. Men de trenger fortsatt CPU-ressurser, noe som betyr at nettstedets hovedskript kjører saktere. I praksis: Document Complete-hendelsen på en ren side inntraff etter 4 sekunder. Med åtte tagger, etter 7,7 sekunder. En forskjell på 3,7 sekunder bare fordi prosessoren er opptatt med tredjepartsskript.

Sammenligning av Document Complete-tid uten tagger og med tagger

Selv en tom GTM-container økte lastetiden noe, med omtrent 100 millisekunder.

Effekten av tom GTM-beholder på lastetid

Det handler ikke om GTM, men hva du putter inn i den

En tom GTM-container legger til omtrent 100 millisekunder på sidelastingen, noen ganger er det ingen forsinkelse i det hele tatt. Problemene starter når du fyller containeren med tagger. Men selv her er ikke ting lineære.

Åtte sporingstagger bremset siden med omtrent 3 sekunder på en rask 3G-tilkobling og med 10 sekunder på trege tilkoblinger. Hver tagg henter sitt eget skript, og nettleseren bruker tid på å kjøre dem.

Document Complete uten tagger og med 8 tagger i GTM

Men en container fylt med 1976 konstante variabler (200 KB, GTM-grensen) la bare til 0,1-0,3 sekunder. Variabler laster ikke eksterne skript og manipulerer ikke DOM-en, så påvirkningen deres er minimal.

Konklusjon: det som betyr noe er ikke størrelsen på containeren, men hvilke handlinger elementene i den utfører.

Hardkodede tagger bremser ting mer enn de samme taggene gjennom GTM

Da vi la til 8 sporingsskript direkte i nettstedskoden, ble siden enda merkbart tregere. På raskt 3G la hardkodede tagger til omtrent 600 millisekunder mer forsinkelse sammenlignet med de samme taggene startet gjennom GTM.

Sammenligning av hardkodede tagger og tagger via GTM

På den andre grafen, det samme bildet fra en annen vinkel: hardkodede skript taper konsekvent mot GTM i Document Complete-tid.

Document Complete hardkodede tagger versus GTM

GTM hjelper virkelig sider med å laste litt raskere enn når skript legges direkte inn i koden. Men dette er ikke en universell regel. Det finnes scenarioer der oppstart av JS uten GTM kan implementeres mer effektivt, og Simo Ahava, en av de ledende GTM-ekspertene, er enig i dette.

Tidspunktet for når taggen utløses har betydning

Jo senere en tagg utløses, desto mindre påvirker den den første sidelastingen. Vi testet fire tidspunkter:

Page View (gtm.js), umiddelbart når containeren lastes
DOM Ready (gtm.dom), når DOM-en er bygget
Window Loaded (gtm.load), når alle ressurser er lastet
afterLoad, 1,5 sekunder etter Window Loaded (egendefinert trigger)

Egendefinert afterLoad-triggerkode:

1 <script>
2   (function() {
3     try {
4       window.setTimeout(function(){
5         dataLayer.push({
6           'event': 'afterLoad'
7         });
8       }, 1500);
9     } catch (err) {}
10   })();
11 </script>

Resultat: DOM Ready og Window Loaded ga en liten forbedring. Men den mest betydelige gevinsten kom fra afterLoad. På tregt 3G ble forsinkelsen redusert med 6 sekunder sammenlignet med Page View-utløseren. På raskt 3G, med 600 millisekunder.

Sammenligning av Fully Loaded for ulike tag-avfyringstidspunkter

Hvorfor virker dette? Siden kan ha elementer som lastes dynamisk først etter at alle ressurser er fullstendig lastet. Hvis tagger bremser den innledende lastingen, dukker disse elementene også opp senere. Ved å utsette ikke-kritiske tagger lar du hovedinnholdet lastes uten forstyrrelser.

Men det finnes et forbehold: hvis du utsetter tagger som nøyaktigheten avhenger av (Google Analytics), kan noen besøkende forlate siden før telleren utløses. Rapportene dine vil miste noe data. Beslutningen om å utsette tagger bør tas sammen med teamet, ikke ensidig av en utvikler eller markedsfører.

Sporingstagger er ikke de eneste synderne

En annen gruppe «tunge» tagger er de som manipulerer DOM-en. For eksempel tilpassede HTML-tagger som legger til eller endrer elementer på siden.

Vi testet flere varianter:

100 tilpassede HTML-tagger som legger til elementer på slutten av <body>. Hver tagg kjørte et enkelt console.log('hello')-skript og opprettet en <div>Hello!</div>. Uten å spesifisere et bestemt innsettingssted. Påvirkningen på sideinnlastingshastighet viste seg å være minimal, elementer ble ganske enkelt lagt til på slutten.

100 tilpassede HTML-tagger som legger til elementer på et bestemt sted på siden. Hver tagg søkte etter den første h2-en og satte inn en h3 etter den. Skript:

1 <script>
2   (function() {
3     var h3 = document.createElement('h3');
4     h3.innerText = "An additional element";
5     var title = document.querySelector('h2');
6     if (title) {
7       title.parentElement.insertBefore(h3, title.nextSibling);
8     }
9   })();
10 </script>

Dette la til flere hundre millisekunder til sideinnlastingen. Selv om skriptet er primitivt, krever det ressurser å søke etter et element og sette det inn.

Effekten av 100 tagger med DOM-manipulasjoner på Fully Loaded

100 tilpassede HTML-tagger som søker gjennom alle lenker på siden og setter inn et element etter den 21. Skript:

1 <script>
2   (function() {
3     var h3 = document.createElement('h3');
4     h3.innerText = "An additional element";
5     var element = document.querySelectorAll('a')[20];
6     if (element) {
7       element.parentElement.insertBefore(h3, element.nextSibling);
8     }
9   })();
10 </script>

Forskjell fra forrige eksperiment: querySelectorAll itererer gjennom alle elementer på siden, sjekker hvert enkelt, noe som er mer kostbart. I webpagetest.org var forskjellen liten (100-200 ms), men Lighthouse viste en økning på 2-3 sekunder i Time to Interactive. Dette betyr at under sideinnlasting er nettleseren så opptatt med å sette inn elementer at den ikke responderer på brukerhandlinger.

Time to Interactive med tunge DOM-manipulasjoner

Ja, 100 identiske skript er overdrevent. Men poenget er at selv noen få komplekse tagger som manipulerer DOM-en kan produsere en lignende effekt.

Hvordan redusere GTMs påvirkning på hastighet: 8 teknikker

Rens containeren jevnlig for forlatte tagger

Revisjonserfaring viser: opptil en tredjedel av sporingskodene på nettsteder tilhører verktøy selskapet ikke lenger bruker. Du byttet fra analyseverktøy X til Z, men X-kodene lastes fortsatt på hver side og bremser den.

Hva du bør gjøre:

Be en utvikler om å gi en liste over alle HTTP-forespørsler og skript på siden
Google domenene til disse forespørslene, identifiser hvilke verktøy de tilhører
Spør kolleger fra ulike avdelinger hvilke verktøy som fortsatt er i bruk
Finn «foreldreløse» skript som ikke står på listen over brukte verktøy
Hvis et skript er implementert via GTM, sett det på pause i en måned; hvis ingen klager, slett det helt
Hvis et skript er hardkodet, be utvikleren om å midlertidig kommentere det ut, og slett det deretter etter en måned

GTM-beholder før revisjon for forlatte tagger

Utsett ikke-kritiske tagger

Jo færre tagger på utløseren All Pages, desto raskere blir den første innlastingen. Ikke alle tagger kan utsettes, men hvis du bruker denne tilnærmingen på i det minste noen av dem, vil forbedringen være merkbar.

Slik implementerer du utsettelse (Pavel Brechiks metode):

Trinn 1. Opprett en egendefinert HTML-tagg med kode:

1 <script>
2   (function() {
3    try {
4      window.setTimeout(
5       function(){
6        dataLayer.push({'event': 'afterLoad'});
7       }, 1500);
8     } catch (err) {}
9   })();
10 </script>

Trinn 2. Start denne taggen på utløseren Window Loaded.

Sette opp Window Loaded-utløser for tilpasset HTML-tagg

Trinn 3. Opprett en egendefinert utløser for hendelsen afterLoad.

Opprette tilpasset afterLoad-utløser i GTM

Trinn 4. Tilordne denne utløseren til tagger som kan utsettes.

Resultat på tregt 3G: forsinkelse redusert med 6 sekunder, på raskt 3G, med 600 millisekunder.

Fully Loaded ved ulike tag-avfyringstidspunkter

Hvilke tagger som kan utsettes og hvilke som ikke kan det, bør avgjøres sammen med teamet. Utviklere ville ideelt sett fjernet alt for hastighet, markedsførere ville lagt til alt for datanøyaktighet. Sannheten ligger et sted midt imellom.

Bruk tagger kun på sidene du trenger

Ikke hver tagg trenger å avfyres på hele nettstedet. En Google Ads remarketing-piksel kan starte kun på kampanjelandingssider, ikke over hele nettstedet. LinkedIn Insights, kun på sider der LinkedIn-trafikk ankommer. Sett opp ekskluderinger i utløsere, dette vil redusere antall skript som kjøres på en typisk side.

Sette opp utløser kun for spesifikke sider i GTM

Unngå tunge DOM-manipulasjoner

Hvis du trenger en egendefinert HTML-tagg som legger til noe på siden, prøv å gjøre det så lett som mulig. Unngå querySelectorAll med iterasjon gjennom alle elementer. Ikke sett inn dusinvis av identiske elementer på ulike steder på siden. Hver DOM-manipulasjon bruker nettleserressurser i et øyeblikk når den allerede er opptatt med å rendre siden.

Eksempel på optimalisert tilpasset HTML-tagg i GTM

Ikke mål hastighet med forhåndsvisningsmodus aktivert

Forhåndsvisnings- og feilsøkingsmodus i GTM legger til ekstra belastning på nettleseren som ekte besøkende ikke har. Hvis du måler hastighet med forhåndsvisning aktivert, vil resultatene være dårligere enn virkeligheten. Før en hastighetsrevisjon, slå alltid av feilsøkingsmodus.

Deaktivere GTM-forhåndsvisningsmodus for hastighetstester

Test hastighet etter hver containerendring

La til en ny tagg eller endret en utløser, sjekk sidehastigheten umiddelbart via webpagetest.org eller Lighthouse. Ta målinger før og etter. Dette lar deg fange opp en problematisk tagg umiddelbart, i stedet for å lure senere på hvorfor nettstedet begynte å laste 2 sekunder tregere.

Hold containeren slank

Slett ubrukte tagger, utløsere og variabler. Dette handler ikke så mye om hastighet (som testen med 1976 variabler viste), men om håndterbarhet. I en container med hundre tagger er det lett å miste et problematisk skript. I en container med to dusin er hver enhet synlig.

Skill klinten fra hveten: hva som virkelig sparer lastetid

La oss sette strek under eksperimentene. Her er hva som gir maksimal effekt i synkende rekkefølge:

Oppsummeringstabell over ulike faktorers innvirkning på lastehastighet

Ifølge våre målinger kommer den mest betydelige forbedringen fra å utsette tagger via afterLoad, opptil 6 sekunder på trege tilkoblinger. På andreplass, fjerning av forlatte sporingskoder. På tredjeplass, begrensning av taggers virkeområde til spesifikke sider.

⁉️🤔 Ofte stilte spørsmål

Bremser en tom GTM et nettsted?

Praktisk talt nei. I våre tester la en tom container til omtrent 100 millisekunder til sideinnlastingen. Noen ganger var det ingen forsinkelse i det hele tatt. Dette er innenfor feilmarginen, merkbart verken for brukere eller søkemotorer.

Hva bremser ting mer: GTM eller hardkodede skript?

Hardkodede skript bremser ting litt mer. I vår test bremset 8 sporingskoder lagt direkte i koden siden med omtrent 600 millisekunder mer enn de samme taggene via GTM. Men dette er ingen universell regel, velskrevet egendefinert JS kan være mer effektivt enn GTM.

Kan du utsette alle tagger?

Teknisk sett, ja. Men du vil miste data: noen besøkende vil forlate siden før tellere avfyres. Google Analytics og lignende verktøy vil underrapportere trafikk. Utsett kun tagger som ikke krever høy nøyaktighet, for eksempel chat-widgeter eller remarketing-piksler. Det er bedre å la analyseverktøy stå på Page View.

Hvordan sjekker du hvilke tagger i GTM som virkelig bremser ting?

Kjør en Lighthouse-revisjon med Nettverk-fanen åpen. Se hvilke skript som laster lengst og hvilke som blokkerer rendring. Match domenene til disse skriptene med tagger i containeren. Eller kjør en A/B-test: deaktiver mistenkelige tagger midlertidig én etter én og mål hastighet.

Hva med server-side GTM?

Server-side GTM flytter taggbehandling fra brukerens nettleser til din server. Nettleseren mottar kun én container i stedet for et dusin tredjepartsskript. Dette reduserer belastningen på klientsiden radikalt. Hvis du har dusinvis av sporingstagger, er server-side GTM verdt å vurdere. Teknologien har vært tilgjengelig siden 2020, og innen 2026 har implementeringen blitt merkbart enklere.

Konklusjon: gjør GTM nettstedet raskere eller tregere?

Verken i ren form. GTM er en dispatcher: i seg selv er den nesten vektløs, og sidehastigheten bestemmes av hvilke tagger og i hvilket omfang du sender gjennom den.

Åtte standard sporingstagger gjennom GTM legger til 3-10 sekunder på sidelastingen. Men de samme taggene hardkodet bremser ting enda mer. Utsatt oppstart via afterLoad vinner tilbake opptil 6 sekunder. Fjerner du forlatte tagger, sparer du noen sekunder til. Totalt sett kan GTM med smart konfigurasjon utkonkurrere hardkodede skript, og uten konfigurasjon tape fullstendig mot en tom side.

Hovedregelen er enkel: det er ikke GTM som lager nettstedet, men du selv. Gå gjennom containeren, fjern søppel, utsett ikke-kritiske tagger, sett opp sideekskluderinger, så vil hastigheten på nettstedet ditt takke deg.

1	<script>
2	(function() {
3	try {
4	window.setTimeout(function(){
5	dataLayer.push({
6	'event': 'afterLoad'
7	});
8	}, 1500);
9	} catch (err) {}
10	})();
11	</script>

1	<script>
2	(function() {
3	var h3 = document.createElement('h3');
4	h3.innerText = "An additional element";
5	var title = document.querySelector('h2');
6	if (title) {
7	title.parentElement.insertBefore(h3, title.nextSibling);
8	}
9	})();
10	</script>

Alt om WordPress, webutvikling — og mer til

🚀 Google Tag Manager og sidehastighet: hva testene sier