⚡ GTM och sidhastighet: tester, resultat och 8 sätt att snabba upp din sajt

Marknadsförare upprepar ofta: "Google Tag Manager snabbar upp webbplatser, sidor med GTM laddar snabbare." Utvecklare brukar invända: "GTM gör bara saker långsammare." Sanningen ligger som vanligt någonstans mittemellan.

Vi körde en serie tester med olika GTM-konfigurationer: en tom container, en container med 8 spårningskoder, hårdkodade taggar, olika tidpunkter för triggning, dussintals anpassade HTML-taggar med DOM-manipulationer. Vi mätte hastighet via webpagetest.org och Lighthouse. Resultaten visade sig vara mindre entydiga än vad GTM-presentationer påstår.

Här är vad vi fann: själva GTM-containern saktar knappt ner någonting, men det du stoppar i den kan lägga till 3 eller 10 sekunder på sidladdningen. Och det viktiga är att du kan styra detta.

💡 Snabb översikt:

En tom GTM-container lägger till ungefär 100 millisekunder på sidladdningen
Åtta spårningstaggar via GTM saktar ner sidan med 3 sekunder på snabbt 3G och upp till 10 sekunder på långsamma anslutningar
Samma 8 taggar hårdkodade direkt på sajten saktar ner saker ännu mer
Ju senare taggar avfyras, desto mindre påverkan har de: en fördröjning på 1,5 sekunder efter Window Loaded minskar laddtiden med 6 sekunder på långsamt 3G
Välplanerad triggerkonfiguration och containerstädning återställer hastigheten utan dataförlust

Så här testade vi

Metodiken är enkel men grundlig. Vi körde varje test minst tre gånger och beräknade genomsnittet.

Verktyg: webpagetest.org (server i Irland, EC2, Chrome och Firefox för desktop, OnePlus 5 för mobila tester) och den inbyggda Lighthouse-granskningen i Chrome DevTools. I Lighthouse tittade vi på både mobila och desktop-rapporter. Chrome startades i inkognitoläge, inga tillägg, bärbar dator på maximal prestanda.

Mätvärden vi mätte:

I webpagetest.org: Document complete (sekunder tills statiskt innehåll, bilder, stilar är laddade) och Fully loaded (punkten efter onLoad när nätverksaktiviteten lugnar ner sig i 2 sekunder). I Lighthouse: First Meaningful Paint, Time to Interactive, First CPU Idle och Max Potential First Input Delay (FID).

Spårningskoder i testerna: Google Analytics (gtag.js), Facebook Pixel, Reddit Pixel, Quora Pixel, LinkedIn Insights, Twitter Universal Tag, Google Ads Remarketing (gtag.js), Hotjar. Åtta vanligt använda skript.

Scenarier vi jämförde:

Ren sida utan tredjepartsskript och utan GTM
Sida med 8 spårningskoder hårdkodade direkt före </head>, utan GTM
Tom GTM-container utan taggar
Alla 8 taggar via GTM, All Pages-trigger (även känd som gtm.js)
Samma 8 taggar via GTM, DOM Ready-trigger (gtm.dom)
Samma 8 taggar via GTM, Window Loaded-trigger (gtm.load)
Samma 8 taggar, avfyras 1,5 sekunder efter Window Loaded
GTM-container med förhandsgransknings- och felsökningsläge aktiverat
GTM-container med 100 anpassade HTML-taggar som lägger till element i slutet av <body>
GTM-container med 100 anpassade HTML-taggar som lägger till element på en specifik plats på sidan (efter H2)
GTM-container med 100 anpassade HTML-taggar som söker igenom alla länkar och infogar ett element efter den 21:a
GTM-container med 1976 konstanta variabler (fylld till maxgränsen, 200 KB)

Vad testerna visade

Asynkront betyder inte "inga konsekvenser"

Asynkrona skript blockerar inte renderingen direkt. Men de behöver fortfarande CPU-resurser, vilket innebär att sajtens huvudskript körs långsammare. I praktiken: händelsen Document Complete på en ren sida inträffade efter 4 sekunder. Med åtta taggar, efter 7,7 sekunder. En skillnad på 3,7 sekunder bara för att processorn är upptagen med tredjepartsskript.

Jämförelse av Document Complete-tid utan taggar och med taggar

Till och med en tom GTM-container ökade laddtiden något, med ungefär 100 millisekunder.

Påverkan av tom GTM-behållare på laddningstid

Det handlar inte om GTM, utan vad du stoppar i den

En tom GTM-container lägger till ungefär 100 millisekunder på sidladdningen, ibland blir det ingen fördröjning alls. Problemen börjar när du fyller containern med taggar. Men inte ens här är det linjärt.

Åtta spårningstaggar saktade ner sidan med ungefär 3 sekunder på en snabb 3G-anslutning och med 10 sekunder på långsamma anslutningar. Varje tagg hämtar sitt eget skript, och webbläsaren lägger tid på att köra dem.

Document Complete utan taggar och med 8 taggar i GTM

Men en container fylld med 1976 konstanta variabler (200 KB, GTM:s gräns) lade bara till 0,1-0,3 sekunder. Variabler laddar inga externa skript och manipulerar inte DOM:en, så deras påverkan är minimal.

Slutsats: det som spelar roll är inte containerns storlek, utan vilka åtgärder dess element utför.

Hårdkodade taggar saktar ner mer än samma taggar via GTM

När vi lade till 8 spårningsskript direkt i sajtens kod saktades sidan ner ännu mer märkbart. På snabbt 3G lade hårdkodade taggar till ungefär 600 millisekunder mer fördröjning jämfört med samma taggar startade via GTM.

Jämförelse av hårdkodade taggar och taggar via GTM

På den andra grafen, samma bild från en annan vinkel: hårdkodade skript förlorar konsekvent mot GTM i Document Complete-tid.

Document Complete hårdkodade taggar kontra GTM

GTM hjälper verkligen sidor att ladda något snabbare än när skript läggs till direkt i koden. Men detta är ingen universell regel. Det finns scenarier där det går att implementera JS utan GTM mer effektivt, och Simo Ahava, en av de ledande GTM-experterna, håller med om detta.

Tidpunkten för taggavfyrning spelar roll

Ju senare en tagg avfyras, desto mindre påverkar den den initiala sidladdningen. Vi testade fyra tidpunkter:

Page View (gtm.js), omedelbart när containern laddas
DOM Ready (gtm.dom), när DOM:en är uppbyggd
Window Loaded (gtm.load), när alla resurser är laddade
afterLoad, 1,5 sekunder efter Window Loaded (anpassad trigger)

Kod för anpassad afterLoad-trigger:

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 och Window Loaded gav en liten förbättring. Men den största vinsten kom från afterLoad. På långsamt 3G minskade fördröjningen med 6 sekunder jämfört med Page View-triggern. På snabbt 3G, med 600 millisekunder.

Jämförelse av Fully Loaded vid olika avfyrningstillfällen för taggar

Varför fungerar detta? Sidan kan ha element som laddas dynamiskt först efter att alla resurser är fullständigt inlästa. Om taggar saktar ner den initiala laddningen dyker dessa element också upp senare. Genom att skjuta upp icke-kritiska taggar låter du huvudinnehållet laddas utan störningar.

Men det finns en hake: om du skjuter upp taggar som noggrannheten beror på (Google Analytics), kan vissa besökare lämna sidan innan räknaren hinner avfyras. Dina rapporter kommer att förlora en del data. Beslutet att skjuta upp taggar bör fattas tillsammans med teamet, inte ensidigt av en utvecklare eller marknadsförare.

Spårningstaggar är inte de enda bovarna

En annan grupp av "tunga" taggar är de som manipulerar DOM:en. Till exempel anpassade HTML-taggar som lägger till eller ändrar element på sidan.

Vi testade flera varianter:

100 anpassade HTML-taggar som lägger till element i slutet av <body>. Varje tagg körde ett enkelt console.log('hello')-skript och skapade en <div>Hello!</div>. Utan att ange en specifik plats för infogning. Påverkan på sidans laddningstid visade sig vara minimal, element lades helt enkelt till i slutet.

100 anpassade HTML-taggar som lägger till element på en specifik plats på sidan. Varje tagg sökte efter den första h2:an och infogade en h3 efter 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>

Detta lade till flera hundra millisekunder på sidladdningen. Även om skriptet är primitivt kräver sökning efter ett element och infogning av det resurser.

Påverkan av 100 taggar med DOM-manipulationer på Fully Loaded

100 anpassade HTML-taggar som söker igenom alla länkar på sidan och infogar ett element efter den 21:a. 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>

Skillnad från föregående experiment: querySelectorAll itererar genom alla element på sidan, kontrollerar varje enskilt, vilket är mer kostsamt. I webpagetest.org var skillnaden liten (100-200 ms), men Lighthouse visade en ökning på 2-3 sekunder i Time to Interactive. Detta innebär att under sidladdningen är webbläsaren så upptagen med att infoga element att den inte svarar på användarinteraktioner.

Time to Interactive med tunga DOM-manipulationer

Ja, 100 identiska skript är overkill. Men poängen är att även ett fåtal komplexa taggar som manipulerar DOM:en kan ge en liknande effekt.

Hur du minskar GTM:s påverkan på hastigheten: 8 tekniker

Rensa regelbundet containern från övergivna taggar

Granskningar visar: upp till en tredjedel av spårningskoderna på webbplatser tillhör verktyg som företaget inte längre använder. Du bytte från analysverktyg X till Z, men X-koderna laddas fortfarande på varje sida och saktar ner den.

Så här gör du:

Be en utvecklare ta fram en lista över alla HTTP-förfrågningar och skript på sidan
Googla domänerna för dessa förfrågningar, identifiera vilka verktyg de tillhör
Fråga kollegor från olika avdelningar vilka verktyg som fortfarande används
Hitta "föräldralösa" skript som inte finns med på listan över använda verktyg
Om ett skript är implementerat via GTM, pausa det i en månad; om ingen klagar, ta bort det helt
Om ett skript är hårdkodat, be utvecklaren att tillfälligt kommentera bort det och sedan ta bort det efter en månad

GTM-behållare före granskning för övergivna taggar

Fördröj icke-kritiska taggar

Ju färre taggar på triggern All Pages, desto snabbare blir den initiala laddningen. Alla taggar kan inte fördröjas, men om du tillämpar detta tillvägagångssätt på åtminstone några av dem blir förbättringen märkbar.

Så här implementerar du fördröjning (Pavel Brechiks metod):

Steg 1. Skapa en anpassad HTML-tagg med kod:

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

Steg 2. Starta denna tagg på triggern Window Loaded.

Konfigurering av Window Loaded-utlösare för anpassad HTML-tagg

Steg 3. Skapa en anpassad trigger för händelsen afterLoad.

Steg 4. Tilldela denna trigger till taggar som kan fördröjas.

Resultat på långsamt 3G: fördröjningen minskade med 6 sekunder, på snabbt 3G med 600 millisekunder.

Fully Loaded vid olika avfyrningstillfällen för taggar

Vilka taggar som kan fördröjas och vilka som inte kan det bör avgöras tillsammans med teamet. Utvecklare skulle helst ta bort allt för hastighetens skull, marknadsförare skulle lägga till allt för datanoggrannhetens skull. Sanningen ligger någonstans mittemellan.

Använd taggar endast på de sidor du behöver

Alla taggar behöver inte aktiveras över hela webbplatsen. En remarketingpixel från Google Ads kan starta endast på kampanjens landningssidor, inte över hela webbplatsen. LinkedIn Insights, endast på sidor där LinkedIn-trafik anländer. Ställ in undantag i triggers, detta minskar antalet skript som körs på en typisk sida.

Konfigurering av utlösare endast för specifika sidor i GTM

Undvik tunga DOM-manipulationer

Om du behöver en anpassad HTML-tagg som lägger till något på sidan, försök att göra det så lättviktigt som möjligt. Undvik querySelectorAll med iteration genom alla element. Infoga inte dussintals identiska element på olika platser på sidan. Varje DOM-manipulation förbrukar webbläsarresurser i ett ögonblick då den redan är upptagen med att rendera sidan.

Exempel på optimerad anpassad HTML-tagg i GTM

Mät inte hastigheten med förhandsgranskningsläget aktiverat

Förhandsgransknings- och felsökningsläget i GTM lägger till extra belastning på webbläsaren som riktiga besökare inte har. Om du mäter hastighet med förhandsgranskning aktiverad blir resultaten sämre än verkligheten. Stäng alltid av felsökningsläget före en hastighetsrevision.

Inaktivera GTM-förhandsgranskningsläge för hastighetstester

Testa hastigheten efter varje containerändring

Lade du till en ny tagg eller ändrade en trigger? Kontrollera omedelbart sidhastigheten via webpagetest.org eller Lighthouse. Gör mätningar före och efter. Detta gör att du kan fånga en problematisk tagg omedelbart, istället för att senare undra varför webbplatsen började ladda 2 sekunder långsammare.

Håll containern slimmad

Ta bort oanvända taggar, triggers och variabler. Detta handlar inte så mycket om hastighet (som testet med 1976 variabler visade), utan om hanterbarhet. I en container med hundra taggar är det lätt att tappa bort ett problematiskt skript. I en container med två dussin är varje enhet synlig.

Separera agnarna från vetet: vad som verkligen sparar laddningstid

Låt oss dra ett streck under experimenten. Här är vad som ger maximal effekt i fallande ordning:

Sammanfattningstabell över olika faktorers påverkan på laddningshastighet

Enligt våra mätningar kommer den mest betydande förbättringen från att fördröja taggar via afterLoad, upp till 6 sekunder på långsamma anslutningar. På andra plats kommer borttagning av övergivna spårningskoder. På tredje plats kommer begränsning av taggars omfattning till specifika sidor.

⁉️🤔 Vanliga frågor

Saktar en tom GTM ner en webbplats?

Praktiskt taget nej. I våra tester lade en tom container till cirka 100 millisekunder till sidladdningen. Ibland uppstod ingen fördröjning alls. Detta är inom felmarginalen, märkbart varken för användare eller sökmotorer.

Vad saktar ner mest: GTM eller hårdkodade skript?

Hårdkodade skript saktar ner lite mer. I vårt test saktade 8 spårningstaggar som lades till direkt i koden ner sidan med cirka 600 millisekunder mer än samma taggar via GTM. Men detta är ingen universell regel, välskriven anpassad JS kan vara mer effektiv än GTM.

Kan man fördröja alla taggar?

Tekniskt sett, ja. Men du kommer att förlora data: vissa besökare lämnar sidan innan räknarna aktiveras. Google Analytics och liknande verktyg kommer att underrapportera trafik. Fördröj endast taggar som inte kräver hög noggrannhet, till exempel chattwidgetar eller remarketingpixlar. Det är bättre att lämna analys på Page View.

Hur kontrollerar man vilka taggar i GTM som verkligen saktar ner saker?

Kör en Lighthouse-revision med fliken Nätverk öppen. Se vilka skript som laddar längst och vilka som blockerar rendering. Matcha domänerna för dessa skript med taggar i containern. Eller kör ett A/B-test: inaktivera tillfälligt misstänkta taggar en efter en och mät hastigheten.

Hur är det med server-side GTM?

Server-side GTM flyttar tagghanteringen från användarens webbläsare till din server. Webbläsaren tar endast emot en container istället för ett dussin tredjepartsskript. Detta minskar belastningen på klientsidan radikalt. Om du har dussintals spårningstaggar är server-side GTM värt att överväga. Tekniken har funnits tillgänglig sedan 2020, och fram till 2026 har dess implementering blivit märkbart enklare.

Slutsats: snabbar GTM upp eller saktar ner?

Inte heller i ren form. GTM är en dirigent: i sig själv är det nästan viktlöst, och sidhastigheten avgörs av vilka taggar och i vilken mängd du skickar genom det.

Åtta standard tracking-taggar via GTM lägger till 3-10 sekunder på sidladdningen. Men samma taggar hårdkodade saktar ner saker ännu mer. Fördröjd laddning via afterLoad vinner tillbaka upp till 6 sekunder. Rensa bort övergivna taggar, ytterligare några sekunder. Totalt sett kan GTM med smart konfiguration överträffa hårdkodade skript, och utan konfiguration förlora helt mot en tom sida.

Huvudregeln är enkel: det är inte GTM som gör sajten, utan du själv. Granska containern, rensa bort skräp, fördröj icke-kritiska taggar, sätt upp sidexkluderingar, så kommer din sajts hastighet att tacka dig.

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>

Allt om WordPress, webbutveckling — och mer därtill

🚀 Google Tag Manager och sajtens hastighet: vad testerna säger