⚡ GTM ja sivun nopeus: testit, havainnot ja 8 tapaa nopeuttaa sivustoasi

Markkinoijat toistelevat usein: "Google Tag Manager nopeuttaa sivustoja, GTM:ää käyttävät sivut latautuvat nopeammin." Kehittäjät yleensä väittävät: "GTM vain hidastaa asioita." Totuus on, kuten aina, näiden ääripäiden välissä.

Teimme sarjan testejä erilaisilla GTM-konfiguraatioilla: tyhjä säiliö, säiliö jossa on 8 seurantakoodia, kovakoodatut tagit, erilaiset liipaisuhetket, kymmeniä mukautettuja HTML-tageja DOM-manipulaatioineen. Mittasimme nopeutta webpagetest.org-palvelun ja Lighthousen avulla. Tulokset osoittautuivat vähemmän suoraviivaisiksi kuin mitä GTM-esittelyissä väitetään.

Tässä mitä havaitsimme: itse GTM-säiliö tuskin hidastaa mitään, mutta se, mitä sinne laitat, voi lisätä sivun latausaikaan 3 tai 10 sekuntia. Ja olennaista on, että voit hallita tätä.

💡 Pikakatsaus:

Tyhjä GTM-säiliö lisää sivun latausaikaan noin 100 millisekuntia
Kahdeksan seurantatagia GTM:n kautta hidastaa sivua 3 sekuntia nopealla 3G:llä ja jopa 10 sekuntia hitailla yhteyksillä
Samat 8 tagia kovakoodattuna suoraan sivustolle hidastavat asioita vielä enemmän
Mitä myöhemmin tagit laukeavat, sitä pienempi niiden vaikutus on: 1,5 sekunnin viive Window Loaded -tapahtuman jälkeen vähentää latausaikaa 6 sekuntia hitaalla 3G:llä
Hyvin suunniteltu liipaisinkonfiguraatio ja säiliön siivous palauttavat nopeuden ilman datan menetystä

Miten testasimme

Metodologia on yksinkertainen mutta perusteellinen. Ajoimme jokaisen testin vähintään kolme kertaa ja laskimme keskiarvon.

Työkalut: webpagetest.org (palvelin Irlannissa, EC2, Chrome ja Firefox työpöydälle, OnePlus 5 mobiilitesteihin) ja Chrome DevToolsin sisäänrakennettu Lighthouse-auditointi. Lighthousessa tarkastelimme sekä mobiili- että työpöytäraportteja. Chrome käynnistettiin incognito-tilassa, ilman laajennuksia, kannettavan tietokoneen suorituskyky maksimissa.

Mittaamamme metriikat:

webpagetest.org-palvelussa: Document complete (sekuntia, kunnes staattinen sisältö, kuvat ja tyylit on ladattu) ja Fully loaded (piste onLoad-tapahtuman jälkeen, kun verkkotoiminta rauhoittuu 2 sekunniksi). Lighthousessa: First Meaningful Paint, Time to Interactive, First CPU Idle ja Max Potential First Input Delay (FID).

Testien seurantakoodit: Google Analytics (gtag.js), Facebook Pixel, Reddit Pixel, Quora Pixel, LinkedIn Insights, Twitter Universal Tag, Google Ads Remarketing (gtag.js), Hotjar. Kahdeksan laajalti käytettyä skriptiä.

Vertailumme skenaariot:

Puhdas sivu ilman kolmannen osapuolen skriptejä ja ilman GTM:ää
Sivu, jossa 8 seurantakoodia kovakoodattuna suoraan ennen </head>-tagia, ilman GTM:ää
Tyhjä GTM-säiliö ilman tageja
Kaikki 8 tagia GTM:n kautta, All Pages -liipaisin (tunnetaan myös nimellä gtm.js)
Samat 8 tagia GTM:n kautta, DOM Ready -liipaisin (gtm.dom)
Samat 8 tagia GTM:n kautta, Window Loaded -liipaisin (gtm.load)
Samat 8 tagia, laukeavat 1,5 sekuntia Window Loaded -tapahtuman jälkeen
GTM-säiliö esikatselu- ja debug-tila päällä
GTM-säiliö, jossa 100 mukautettua HTML-tagia lisäämässä elementtejä <body>-tagin loppuun
GTM-säiliö, jossa 100 mukautettua HTML-tagia lisäämässä elementtejä tiettyyn kohtaan sivulla (H2-otsikon jälkeen)
GTM-säiliö, jossa 100 mukautettua HTML-tagia etsimässä kaikkia linkkejä ja lisäämässä elementin 21. linkin jälkeen
GTM-säiliö, jossa 1976 vakiomuuttujaa (täytetty äärirajoille, 200 kt)

Mitä testit osoittivat

Asynkroninen ei tarkoita "ei seurauksia"

Asynkroniset skriptit eivät estä renderöintiä suoraan. Mutta ne tarvitsevat silti suoritinresursseja, mikä tarkoittaa, että sivuston pääskriptit suoritetaan hitaammin. Käytännössä: Document Complete -tapahtuma puhtaalla sivulla tapahtui 4 sekunnin kuluttua. Kahdeksalla tagilla 7,7 sekunnin kuluttua. Ero on 3,7 sekuntia pelkästään siksi, että prosessori on varattuna kolmannen osapuolen skripteille.

Document Complete -ajan vertailu ilman tageja ja tagien kanssa

Jopa tyhjä GTM-säiliö pidensi latausaikaa hieman, noin 100 millisekuntia.

Kyse ei ole GTM:stä, vaan siitä mitä sinne laitat

Tyhjä GTM-säiliö lisää sivun latausaikaan noin 100 millisekuntia, joskus viivettä ei ole lainkaan. Ongelmat alkavat, kun täytät säiliön tageilla. Mutta tässäkään asiat eivät etene lineaarisesti.

Kahdeksan seurantatagia hidasti sivua noin 3 sekuntia nopealla 3G-yhteydellä ja 10 sekuntia hitailla yhteyksillä. Jokainen tagi hakee oman skriptinsä, ja selain käyttää aikaa niiden suorittamiseen.

Document Complete ilman tageja ja 8 tagilla GTM:ssä

Mutta säiliö, joka oli täytetty 1976 vakiomuuttujalla (200 kt, GTM:n raja), lisäsi vain 0,1-0,3 sekuntia. Muuttujat eivät lataa ulkoisia skriptejä eivätkä manipuloi DOMia, joten niiden vaikutus on minimaalinen.

Johtopäätös: merkitystä ei ole säiliön koolla, vaan sillä, mitä toimintoja sen elementit suorittavat.

Kovakoodatut tagit hidastavat enemmän kuin samat tagit GTM:n kautta

Kun lisäsimme 8 seurantaskriptiä suoraan sivuston koodiin, sivu hidastui vielä huomattavammin. Nopealla 3G:llä kovakoodatut tagit lisäsivät noin 600 millisekuntia enemmän viivettä verrattuna samoihin GTM:n kautta käynnistettyihin tageihin.

Kovakoodattujen tagien ja GTM:n kautta ladattavien tagien vertailu

Toisessa kuvaajassa sama tilanne eri kulmasta: kovakoodatut skriptit häviävät johdonmukaisesti GTM:lle Document Complete -ajassa.

Document Complete kovakoodatuilla tageilla vs. GTM

GTM todella auttaa sivuja latautumaan hieman nopeammin kuin silloin, kun skriptit lisätään suoraan koodiin. Mutta tämä ei ole yleispätevä sääntö. On skenaarioita, joissa JS:n käynnistäminen ilman GTM:ää voidaan toteuttaa tehokkaammin, ja Simo Ahava, yksi johtavista GTM-asiantuntijoista, on tästä samaa mieltä.

Tagien laukeamisajankohdalla on merkitystä

Mitä myöhemmin tagi laukeaa, sitä vähemmän se vaikuttaa sivun alkuperäiseen lataukseen. Testasimme neljää hetkeä:

Page View (gtm.js), heti kun säiliö latautuu
DOM Ready (gtm.dom), kun DOM on rakennettu
Window Loaded (gtm.load), kun kaikki resurssit on ladattu
afterLoad, 1,5 sekuntia Window Loaded -tapahtuman jälkeen (mukautettu liipaisin)

Mukautetun afterLoad-liipaisimen koodi:

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>

Tulos: DOM Ready ja Window Loaded toivat pienen parannuksen. Merkittävin hyöty tuli kuitenkin afterLoad-liipaisimesta. Hitaalla 3G:llä viive pieneni 6 sekuntia verrattuna Page View -liipaisimeen. Nopealla 3G:llä ero oli 600 millisekuntia.

Fully Loaded -ajan vertailu eri tagien laukaisuhetkillä

Miksi tämä toimii? Sivulla voi olla elementtejä, jotka latautuvat dynaamisesti vasta, kun kaikki resurssit on ladattu täysin. Jos tagit hidastavat alkulatausta, nämäkin elementit ilmestyvät myöhemmin. Viivästämällä ei-kriittisiä tageja annat pääsisällön latautua ilman häiriöitä.

Tässä on kuitenkin varjopuoli: jos viivästät tageja, joiden tarkkuus siitä riippuu (Google Analytics), osa kävijöistä saattaa poistua sivulta ennen kuin laskuri ehtii laueta. Raporttisi menettävät osan datasta. Päätös tagien viivästämisestä tulee tehdä tiimin kanssa, ei yksipuolisesti kehittäjän tai markkinoijan toimesta.

Seurantatagit eivät ole ainoita syyllisiä

Toinen "raskaiden" tagien ryhmä ovat DOMia muokkaavat tagit. Esimerkiksi mukautetut HTML-tagit, jotka lisäävät tai muuttavat elementtejä sivulla.

Testasimme useita variaatioita:

100 mukautettua HTML-tagia, jotka lisäävät elementtejä <body>-elementin loppuun.* Jokainen tagi suoritti yksinkertaisen console.log('hello')-skriptin ja loi <div>Hello!</div>-elementin. Ilman tiettyä lisäyspaikkaa. Vaikutus sivun latausnopeuteen osoittautui minimaaliseksi, elementit vain liitettiin loppuun.

100 mukautettua HTML-tagia, jotka lisäävät elementtejä tiettyyn kohtaan sivulla. Jokainen tagi etsi ensimmäisen h2-elementin ja lisäsi h3-elementin sen jälkeen. Skripti:

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>

Tämä lisäsi useita satoja millisekunteja sivun latausaikaan. Vaikka skripti on yksinkertainen, elementin etsiminen ja lisääminen vaatii resursseja.

100:n DOM-manipulaatioita sisältävän tagin vaikutus Fully Loaded -aikaan

100 mukautettua HTML-tagia, jotka etsivät kaikki sivun linkit ja lisäävät elementin 21. linkin jälkeen. Skripti:

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>

Ero edelliseen kokeeseen: querySelectorAll käy läpi kaikki sivun elementit ja tarkistaa jokaisen, mikä on raskaampaa. webpagetest.org-palvelussa ero oli pieni (100-200 ms), mutta Lighthouse näytti 2-3 sekunnin kasvua Time to Interactive -arvossa. Tämä tarkoittaa, että sivun latauksen aikana selain on niin kiireinen lisätessään elementtejä, ettei se vastaa käyttäjän toimiin.

Time to Interactive raskailla DOM-manipulaatioilla

Kyllä, 100 identtistä skriptiä on ylilyönti. Pointti on kuitenkin se, että jo muutama monimutkainen DOMia muokkaava tagi voi tuottaa samankaltaisen vaikutuksen.

Miten vähentää GTM:n vaikutusta nopeuteen: 8 tekniikkaa

Puhdista säiliö hylätyistä tageista säännöllisesti

Auditointikokemus osoittaa: jopa kolmannes sivustojen seurantakoodeista kuuluu työkaluille, joita yritys ei enää käytä. Vaihdoit analytiikkatyökalusta X työkaluun Z, mutta X:n koodit latautuvat yhä jokaisella sivulla ja hidastavat sitä.

Mitä tehdä:

Pyydä kehittäjää toimittamaan lista kaikista sivun HTTP-pyynnöistä ja skripteistä
Googlaa näiden pyyntöjen verkkotunnukset ja tunnista, mihin työkaluihin ne kuuluvat
Kysy eri osastojen kollegoilta, mitkä työkalut ovat vielä käytössä
Etsi "orvot" skriptit, jotka eivät ole käytettyjen työkalujen listalla
Jos skripti on toteutettu GTM:n kautta, keskeytä se kuukaudeksi; jos kukaan ei valita, poista se kokonaan
Jos skripti on kovakoodattu, pyydä kehittäjää kommentoimaan se väliaikaisesti pois ja poista se sitten kuukauden kuluttua

GTM-säilö ennen auditointia hylättyjen tagien varalta

Viivästytä ei-kriittisiä tageja

Mitä vähemmän tageja All Pages-liipaisimella on, sitä nopeampi on alkulataus. Kaikkia tageja ei voi viivästyttää, mutta jos sovellat tätä lähestymistapaa ainakin osaan niistä, parannus on huomattava.

Miten viivästys toteutetaan (Pavel Brechikin menetelmä):

Vaihe 1. Luo mukautettu HTML-tagi koodilla:

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

Vaihe 2. Käynnistä tämä tagi Window Loaded -liipaisimella.

Window Loaded -laukaisimen määritys mukautetulle HTML-tagille

Vaihe 3. Luo mukautettu liipaisin afterLoad-tapahtumalle.

Mukautetun afterLoad-laukaisimen luominen GTM:ssä

Vaihe 4. Määritä tämä liipaisin tageille, joita voidaan viivästyttää.

Tulos hitaalla 3G:llä: viive pieneni 6 sekuntia, nopealla 3G:llä 600 millisekuntia.

Fully Loaded eri tagien laukaisuhetkillä

Mitkä tagit voidaan viivästyttää ja mitä ei, tulee päättää tiimin kanssa. Kehittäjät poistaisivat ihanteellisesti kaiken nopeuden vuoksi, markkinoijat lisäisivät kaiken datan tarkkuuden vuoksi. Totuus on jossain puolivälissä.

Käytä tageja vain tarvitsemillasi sivuilla

Jokaisen tagin ei tarvitse laueta koko sivustolla. Google Ads -remarketing-pikseli voi käynnistyä vain kampanjan laskeutumissivuilla, ei koko sivustolla. LinkedIn Insights vain sivuilla, joille LinkedIn-liikennettä saapuu. Määritä poissulkuja liipaisimiin, tämä vähentää tyypillisellä sivulla suoritettavien skriptien määrää.

Laukaisimen määritys vain tietyille sivuille GTM:ssä

Vältä raskaita DOM-manipulaatioita

Jos tarvitset mukautetun HTML-tagin, joka lisää jotain sivulle, yritä tehdä se mahdollisimman kevyesti. Vältä querySelectorAll-metodia, jossa iteroidaan kaikki elementit. Älä lisää kymmeniä identtisiä elementtejä eri puolille sivua. Jokainen DOM-manipulaatio kuluttaa selaimen resursseja hetkellä, jolloin se on jo kiireinen sivun renderöinnissä.

Esimerkki optimoidusta mukautetusta HTML-tagista GTM:ssä

Älä mittaa nopeutta esikatselutila päällä

GTM:n esikatselu- ja debug-tila lisää selaimeen ylimääräistä kuormaa, jota oikeilla vierailijoilla ei ole. Jos mittaat nopeutta esikatselu päällä, tulokset ovat todellisuutta huonommat. Ennen nopeusauditointia kytke aina debug-tila pois päältä.

GTM:n esikatselutilan poistaminen käytöstä nopeustestejä varten

Testaa nopeus jokaisen säiliömuutoksen jälkeen

Lisäsit uuden tagin tai muutit liipaisinta, tarkista heti sivun nopeus webpagetest.org-palvelulla tai Lighthousella. Ota mittaukset ennen ja jälkeen. Näin voit napata ongelmallisen tagin heti sen sijaan, että mietit myöhemmin, miksi sivusto alkoi latautua 2 sekuntia hitaammin.

Pidä säiliö kevyenä

Poista käyttämättömät tagit, liipaisimet ja muuttujat. Tässä ei ole kyse niinkään nopeudesta (kuten testi 1976 muuttujalla osoitti), vaan hallittavuudesta. Sadan tagin säiliössä ongelmallisen skriptin hukkaa helposti. Kahdenkymmenen tagin säiliössä jokainen yksikkö on näkyvissä.

Erottele jyvät akanoista: mikä todella säästää latausaikaa

Vedetään yhteen kokeiden tulokset. Tässä on se, mikä antaa suurimman vaikutuksen laskevassa järjestyksessä:

Yhteenvetotaulukko eri tekijöiden vaikutuksesta latausnopeuteen

Mittaustemme mukaan merkittävin parannus tulee tagien viivästyttämisestä afterLoad-tapahtuman avulla, jopa 6 sekuntia hitailla yhteyksillä. Toisella sijalla on hylättyjen seurantakoodien poistaminen. Kolmannella sijalla tagien käyttöalueen rajaaminen tietyille sivuille.

⁉️🤔 Usein kysytyt kysymykset

Hidastaako tyhjä GTM sivustoa?

Käytännössä ei. Testeissämme tyhjä säiliö lisäsi sivun latautumiseen noin 100 millisekuntia. Joskus viivettä ei ollut lainkaan. Tämä on virhemarginaalin sisällä, eivätkä käyttäjät tai hakukoneet huomaa sitä.

Mikä hidastaa enemmän: GTM vai kovakoodatut skriptit?

Kovakoodatut skriptit hidastavat hieman enemmän. Testissämme 8 suoraan koodiin lisättyä seurantatagia hidasti sivua noin 600 millisekuntia enemmän kuin samat tagit GTM:n kautta. Mutta tämä ei ole yleispätevä sääntö, hyvin kirjoitettu mukautettu JS voi olla GTM:ää tehokkaampi.

Voiko kaikkia tageja viivästyttää?

Teknisesti kyllä. Mutta menetät dataa: osa vierailijoista poistuu sivulta ennen kuin laskurit ehtivät laueta. Google Analytics ja vastaavat työkalut raportoivat liian vähän liikennettä. Viivästytä vain tageja, jotka eivät vaadi suurta tarkkuutta, esimerkiksi chat-widgettejä tai remarketing-pikseleitä. Analytiikka on parempi jättää Page View -liipaisimelle.

Miten tarkistat, mitkä GTM:n tagit todella hidastavat sivua?

Suorita Lighthouse-auditointi Network-välilehti auki. Katso, mitkä skriptit latautuvat pisimpään ja mitkä estävät renderöinnin. Yhdistä näiden skriptien verkkotunnukset säiliön tageihin. Tai suorita A/B-testi: poista epäilyttävät tagit väliaikaisesti käytöstä yksi kerrallaan ja mittaa nopeus.

Entä palvelinpuolen GTM?

Palvelinpuolen GTM siirtää tagien käsittelyn käyttäjän selaimesta palvelimellesi. Selain vastaanottaa vain yhden säiliön tusinan kolmannen osapuolen skriptin sijaan. Tämä vähentää radikaalisti asiakaspuolen kuormaa. Jos sinulla on kymmeniä seurantatageja, palvelinpuolen GTM:ää kannattaa harkita. Teknologia on ollut saatavilla vuodesta 2020, ja vuoteen 2026 mennessä sen käyttöönotto on helpottunut huomattavasti.

Lopputulos: nopeuttaako vai hidastaako GTM?

Ei puhtaassa muodossakaan. GTM on lähettäjä: yksinään se on lähes painoton, ja sivun nopeuden määrää se, mitä tageja ja missä määrin ajat sen läpi.

Kahdeksan vakio-seurantatagia GTM:n kautta lisäävät sivun latausaikaan 3-10 sekuntia. Mutta samat tagit kovakoodattuina hidastavat vielä enemmän. Viivästetty käynnistys afterLoad-tapahtumalla voittaa takaisin jopa 6 sekuntia. Hylättyjen tagien poistolla vielä muutaman sekunnin lisää. Kaikkiaan fiksulla konfiguraatiolla GTM voi päihittää kovakoodatut skriptit, ja ilman konfiguraatiota hävitä täysin tyhjälle sivulle.

Pääsääntö on yksinkertainen: sivuston tekee et GTM, vaan sinä itse. Auditoi kontti, poista roska, viivästä ei-kriittiset tagit, määritä sivupoikkeukset, ja sivustosi nopeus kiittää.

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>

Kaikki WordPressistä, web-kehityksestä — ja paljon muuta

🚀 Google Tag Manager ja sivuston nopeus: mitä testit sanovat