⚡ GTM ja lehe kiirus: testid, leiud ja 8 viisi saidi kiirendamiseks

Turundajad kordavad sageli: „Google Tag Manager kiirendab veebisaite, GTM-iga lehed laadivad kiiremini." Arendajad vaidlevad tavaliselt vastu: „GTM ainult aeglustab asju." Tõde jääb nagu alati nende äärmuste vahele.

Tegime rea teste erinevate GTM-i konfiguratsioonidega: tühi konteiner, 8 jälgimiskoodiga konteiner, otse koodi lisatud sildid, erinevad käivitamise hetked, kümned kohandatud HTML-sildid DOM-i manipuleerimistega. Mõõtsime kiirust webpagetest.org ja Lighthouse'i abil. Tulemused osutusid vähem sirgjooneliseks, kui GTM-i esitlused väidavad.

Leidsime järgmist: GTM-i konteiner ise ei aeglusta peaaegu midagi, kuid see, mida sa sinna paned, võib lehe laadimisele lisada 3 või 10 sekundit. Ja võtmetähtsusega on see, et sa saad seda kontrollida.

💡 Kiire ülevaade:

Tühi GTM-i konteiner lisab lehe laadimisele umbes 100 millisekundit
Kaheksa jälgimissilti läbi GTM-i aeglustavad lehte 3 sekundit kiire 3G korral ja kuni 10 sekundit aeglaste ühenduste puhul
Samad 8 silti otse saidi koodi lisatuna aeglustavad asju veelgi rohkem
Mida hiljem sildid käivituvad, seda väiksem on nende mõju: 1,5-sekundiline viivitus pärast Window Loaded sündmust vähendab laadimisaega 6 sekundit aeglase 3G korral
Hästi planeeritud käivitajate konfiguratsioon ja konteineri puhastamine taastavad kiiruse ilma andmekadudeta

Kuidas me testisime

Metoodika on lihtne, kuid põhjalik. Iga testi jooksime vähemalt kolm korda ja arvutasime keskmise.

Tööriistad: webpagetest.org (server Iirimaal, EC2, Chrome ja Firefox lauaarvutile, OnePlus 5 mobiilitestideks) ja sisseehitatud Lighthouse'i audit Chrome DevToolsis. Lighthouse'is vaatasime nii mobiili kui ka lauaarvuti aruandeid. Chrome käivitati inkognito režiimis, ilma laiendusteta, sülearvuti jõudlus maksimumil.

Mõõdikud, mida mõõtsime:

webpagetest.org-s: Document complete (sekundid staatilise sisu, piltide, stiilide laadimiseni) ja Fully loaded (punkt pärast onLoad sündmust, kui võrgutegevus vaibub 2 sekundiks). Lighthouse'is: First Meaningful Paint, Time to Interactive, First CPU Idle ja Max Potential First Input Delay (FID).

Jälgimiskoodid testides: Google Analytics (gtag.js), Facebook Pixel, Reddit Pixel, Quora Pixel, LinkedIn Insights, Twitter Universal Tag, Google Ads Remarketing (gtag.js), Hotjar. Kaheksa laialdaselt kasutatavat skripti.

Stsenaariumid, mida võrdlesime:

Puhas leht ilma kolmanda osapoole skriptide ja GTM-ita
Leht 8 jälgimiskoodiga otse enne </head> lisatuna, ilma GTM-ita
Tühi GTM-i konteiner ilma siltideta
Kõik 8 silti läbi GTM-i, All Pages käivitaja (tuntud ka kui gtm.js)
Samad 8 silti läbi GTM-i, DOM Ready käivitaja (gtm.dom)
Samad 8 silti läbi GTM-i, Window Loaded käivitaja (gtm.load)
Samad 8 silti, käivitudes 1,5 sekundit pärast Window Loaded sündmust
GTM-i konteiner eelvaate ja silumisrežiimiga
GTM-i konteiner 100 kohandatud HTML-sildiga, mis lisavad elemente <body> lõppu
GTM-i konteiner 100 kohandatud HTML-sildiga, mis lisavad elemente lehe kindlasse kohta (pärast H2)
GTM-i konteiner 100 kohandatud HTML-sildiga, mis otsivad kõiki linke ja lisavad elemendi pärast 21. linki
GTM-i konteiner 1976 konstantse muutujaga (täidetud mahupiirini, 200 KB)

Mida testid näitasid

Asünkroonne ei tähenda „tagajärgedeta"

Asünkroonsed skriptid ei blokeeri renderdamist otseselt. Kuid nad vajavad siiski protsessori ressursse, mis tähendab, et saidi peamised skriptid täidetakse aeglasemalt. Praktikas: Document Complete sündmus puhtal lehel toimus 4 sekundi pärast. Kaheksa sildiga 7,7 sekundi pärast. Erinevus 3,7 sekundit lihtsalt seetõttu, et protsessor on hõivatud kolmanda osapoole skriptidega.

Dokumendi laadimisaja võrdlus siltideta ja siltidega

Isegi tühi GTM-i konteiner suurendas laadimisaega veidi, umbes 100 millisekundit.

Asi pole GTM-is, vaid selles, mida sa sinna paned

Tühi GTM-i konteiner lisab lehe laadimisele umbes 100 millisekundit, mõnikord pole viivitust üldse. Probleemid algavad siis, kui täidad konteineri siltidega. Kuid isegi siin pole asjad lineaarsed.

Kaheksa jälgimissilti aeglustasid lehte umbes 3 sekundit kiire 3G ühenduse korral ja 10 sekundit aeglaste ühenduste puhul. Iga silt tõmbab oma skripti ja brauser kulutab aega nende täitmisele.

Dokumendi laadimine siltideta ja 8 sildiga GTM-is

Kuid konteiner, mis oli täidetud 1976 konstantse muutujaga (200 KB, GTM-i limiit), lisas ainult 0,1-0,3 sekundit. Muutujad ei laadi väliseid skripte ega manipuleeri DOM-iga, seega on nende mõju minimaalne.

Järeldus: oluline pole konteineri suurus, vaid see, milliseid toiminguid selle elemendid sooritavad.

Otse koodi lisatud sildid aeglustavad rohkem kui samad sildid läbi GTM-i

Kui lisasime 8 jälgimisskripti otse saidi koodi, aeglustus leht veelgi märgatavamalt. Kiire 3G korral lisasid otse koodi pandud sildid umbes 600 millisekundit rohkem viivitust võrreldes samade siltidega, mis käivitati läbi GTM-i.

Otse lehele lisatud ja GTM-i kaudu laetud siltide võrdlus

Teisel graafikul on sama pilt teise nurga alt: otse koodi lisatud skriptid kaotavad järjekindlalt GTM-ile Document Complete ajas.

Dokumendi laadimine - otse lisatud sildid versus GTM

GTM tõesti aitab lehtedel laadida veidi kiiremini kui siis, kui skriptid lisatakse otse koodi. Kuid see pole universaalne reegel. On stsenaariume, kus JS-i käivitamist ilma GTM-ita saab rakendada tõhusamalt ja Simo Ahava, üks juhtivaid GTM-i eksperte, nõustub sellega.

Siltide käivitamise ajastus on oluline

Mida hiljem silt käivitub, seda vähem mõjutab see lehe esialgset laadimist. Testisime nelja hetke:

Page View (gtm.js), kohe kui konteiner laadib
DOM Ready (gtm.dom), kui DOM on üles ehitatud
Window Loaded (gtm.load), kui kõik ressursid on laaditud
afterLoad, 1,5 sekundit pärast Window Loaded sündmust (kohandatud käivitaja)

Kohandatud afterLoad käivitaja kood:

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>

Tulemus: DOM Ready ja Window Loaded andsid väikese paranemise. Kuid kõige olulisem võit tuli afterLoad'ist. Aeglasel 3G-l vähenes viivitus Page View trigeriga võrreldes 6 sekundit. Kiirel 3G-l 600 millisekundit.

Täieliku laadimise võrdlus erinevatel sildi käivitamise hetkedel

Miks see toimib? Lehel võib olla elemente, mis laaditakse dünaamiliselt alles pärast kõigi ressursside täielikku laadimist. Kui sildid aeglustavad esialgset laadimist, ilmuvad ka need elemendid hiljem. Mittekriitilisi silte edasi lükates lased põhisisul laadida ilma häireteta.

Kuid siin on üks konks: kui lükkad edasi silte, mille täpsusest sõltub (Google Analytics), võivad mõned külastajad lehelt lahkuda enne, kui loendur käivitub. Sinu aruannetest kaob osa andmeid. Otsus silte edasi lükata tuleks teha meeskonnaga, mitte arendaja või turundaja ühepoolselt.

Jälgimissildid pole ainsad süüdlased

Teine rühm „raskeid" silte on need, mis manipuleerivad DOM-iga. Näiteks kohandatud HTML-sildid, mis lisavad või muudavad lehel elemente.

Testisime mitut varianti:

100 kohandatud HTML-silti, mis lisavad elemente <body> lõppu. Iga silt käivitas lihtsa console.log('hello') skripti ja lõi <div>Hello!</div> elemendi, täpsustamata konkreetset sisestamise asukohta. Mõju lehe laadimiskiirusele osutus minimaalseks, elemendid lihtsalt lisati lõppu.

100 kohandatud HTML-silti, mis lisavad elemente lehe kindlasse kohta. Iga silt otsis esimest h2 ja sisestas selle järele h3. 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>

See lisas lehe laadimisele mitusada millisekundit. Kuigi skript on primitiivne, nõuab elemendi otsimine ja selle sisestamine ressursse.

100 DOM-manipulatsiooniga sildi mõju täielikule laadimisele

100 kohandatud HTML-silti, mis otsivad lehelt kõik lingid ja sisestavad elemendi pärast 21. linki. 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>

Erinevus eelmisest katsest: querySelectorAll itereerib läbi kõik lehe elemendid, kontrollib igaühte, mis on kulukam. webpagetest.org-s oli erinevus väike (100-200 ms), kuid Lighthouse näitas Time to Interactive 2-3 sekundilist kasvu. See tähendab, et lehe laadimise ajal on brauser nii hõivatud elementide sisestamisega, et ei reageeri kasutaja tegevustele.

Kasutusvalmiduse aeg ulatuslike DOM-manipulatsioonide korral

Jah, 100 identset skripti on liialdus. Kuid mõte on selles, et isegi mõned keerukad DOM-iga manipuleerivad sildid võivad tekitada sarnase efekti.

Kuidas vähendada GTM-i mõju kiirusele: 8 tehnikat

Puhasta konteinerit regulaarselt mahajäetud siltidest

Auditikogemus näitab: kuni kolmandik saitide jälgimiskoodidest kuulub tööriistadele, mida ettevõte enam ei kasuta. Vahetasite analüütikatööriista X Z vastu, kuid X-i koodid laadivad endiselt igal lehel ja aeglustavad seda.

Mida teha:

Paluge arendajal esitada nimekiri kõigist lehe HTTP-päringutest ja skriptidest
Googeldage nende päringute domeene, tuvastage, millistele tööriistadele need kuuluvad
Küsige eri osakondade kolleegidelt, milliseid tööriistu veel kasutatakse
Leidke „orvuks jäänud" skriptid, mis ei ole kasutatavate tööriistade nimekirjas
Kui skript on juurutatud GTM-i kaudu, peatage see kuuks ajaks; kui keegi ei kurda, kustutage see täielikult
Kui skript on otse koodi kirjutatud, paluge arendajal see ajutiselt kommentaariks muuta, seejärel kuu aja pärast kustutada

GTM-konteiner enne mahajäetud siltide auditit

Viivitage mittekriitilisi silte

Mida vähem silte on All Pages triggeril, seda kiirem on esmane laadimine. Kõiki silte ei saa viivitada, kuid kui rakendate seda lähenemist vähemalt mõnele neist, on paranemine märgatav.

Kuidas viivitust rakendada (Pavel Brechiku meetod):

1. samm. Looge kohandatud HTML-silt koodiga:

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

2. samm. Käivitage see silt Window Loaded triggeril.

Window Loaded päästiku seadistamine kohandatud HTML-sildile

3. samm. Looge kohandatud trigger afterLoad sündmuse jaoks.

Kohandatud afterLoad-päästiku loomine GTM-is

4. samm. Määrake see trigger siltidele, mida saab viivitada.

Tulemus aeglase 3G korral: viivitus vähenes 6 sekundit, kiire 3G korral 600 millisekundit.

Täielik laadimine erinevatel sildi käivitamise hetkedel

Milliseid silte saab viivitada ja milliseid mitte, tuleks otsustada meeskonnaga. Arendajad eemaldaksid ideaalis kõik kiiruse nimel, turundajad lisaksid kõik andmete täpsuse nimel. Tõde on kusagil keskel.

Kasutage silte ainult vajalikel lehtedel

Iga silt ei pea käivituma kogu saidil. Google Ads'i remarketingi piksel võib käivituda ainult kampaania maandumislehtedel, mitte kogu saidil. LinkedIn Insights ainult lehtedel, kuhu LinkedIni liiklus saabub. Seadistage triggerites välistused, see vähendab tüüpilisel lehel käivituvate skriptide arvu.

Ainult kindlatele lehtedele päästiku seadistamine GTM-is

Vältige raskeid DOM-i manipuleerimisi

Kui vajate kohandatud HTML-silti, mis lisab lehele midagi, proovige seda teha võimalikult kergelt. Vältige querySelectorAll kasutamist koos itereerimisega läbi kõigi elementide. Ärge sisestage kümneid identseid elemente lehe eri kohtadesse. Iga DOM-i manipuleerimine tarbib brauseri ressursse hetkel, mil see on juba hõivatud lehe renderdamisega.

Optimeeritud kohandatud HTML-sildi näide GTM-is

Ärge mõõtke kiirust, kui eelvaate režiim on sisse lülitatud

GTM-i eelvaate ja silumise režiim lisab brauserile lisakoormust, mida tegelikel külastajatel ei ole. Kui mõõdate kiirust eelvaate režiimiga, on tulemused tegelikkusest halvemad. Enne kiiruse auditit lülitage alati silumisrežiim välja.

GTM-i eelvaatlusrežiimi keelamine kiirustestideks

Testige kiirust pärast iga konteineri muudatust

Lisati uus silt või muudeti triggerit, kontrollige kohe lehe kiirust webpagetest.org või Lighthouse'i kaudu. Tehke mõõtmised enne ja pärast. See võimaldab probleemse sildi kohe tabada, selle asemel et hiljem imestada, miks sait hakkas 2 sekundit aeglasemalt laadima.

Hoidke konteiner trimmina

Kustutage kasutamata sildid, triggerid ja muutujad. See ei puuduta niivõrd kiirust (nagu näitas test 1976 muutujaga), kuivõrd hallatavust. Saja sildiga konteineris on lihtne probleemset skripti kaotada. Kahe tosina sildiga konteineris on iga üksus nähtav.

Eraldage terad sõkaldest: mis tõesti säästab laadimisaega

Tõmbame katsetele joone alla. Siin on see, mis annab maksimaalse efekti kahanevas järjekorras:

Erinevate tegurite mõju laadimiskiirusele koondtabel

Meie mõõtmiste kohaselt tuleb kõige olulisem paranemine siltide viivitamisest afterLoad abil, kuni 6 sekundit aeglastel ühendustel. Teisel kohal on mahajäetud jälgimiskoodide eemaldamine. Kolmandal kohal on siltide ulatuse piiramine konkreetsete lehtedega.

⁉️🤔 Korduma kippuvad küsimused

Kas tühi GTM aeglustab saiti?

Praktiliselt mitte. Meie testides lisas tühi konteiner lehe laadimisele umbes 100 millisekundit. Mõnikord ei olnud viivitust üldse. See on veamarginaal, mis pole märgatav ei kasutajatele ega otsingumootoritele.

Mis aeglustab rohkem: GTM või otse koodi kirjutatud skriptid?

Otse koodi kirjutatud skriptid aeglustavad veidi rohkem. Meie testis aeglustasid 8 otse koodi lisatud jälgimissilti lehte umbes 600 millisekundit rohkem kui samad sildid GTM-i kaudu. Kuid see ei ole universaalne reegel, hästi kirjutatud kohandatud JS võib olla tõhusam kui GTM.

Kas kõiki silte saab viivitada?

Tehniliselt jah. Kuid kaotate andmeid: mõned külastajad lahkuvad lehelt enne, kui loendurid käivituvad. Google Analytics ja sarnased tööriistad alahindavad liiklust. Viivitage ainult silte, mis ei vaja suurt täpsust, näiteks vestlusvidinad või remarketingi pikslid. Analüütika on parem jätta Page View peale.

Kuidas kontrollida, millised sildid GTM-is tõesti aeglustavad?

Käivitage Lighthouse'i audit, hoides Network vahekaarti avatuna. Vaadake, millised skriptid laadivad kõige kauem ja millised blokeerivad renderdamist. Sobitage nende skriptide domeenid konteineris olevate siltidega. Või tehke A/B test: keelake ajutiselt kahtlased sildid ükshaaval ja mõõtke kiirust.

Aga serveripoolne GTM?

Serveripoolne GTM viib sildi töötlemise kasutaja brauserist teie serverisse. Brauser saab tosina kolmanda osapoole skripti asemel ainult ühe konteineri. See vähendab radikaalselt kliendipoolset koormust. Kui teil on kümneid jälgimissilte, tasub serveripoolset GTM-i kaaluda. Tehnoloogia on saadaval alates 2020. aastast ja 2026. aastaks on selle juurutamine muutunud märgatavalt lihtsamaks.

Kokkuvõte: kas GTM kiirendab või aeglustab?

Kumbki puhtal kujul. GTM on dispetšer: iseenesest on see peaaegu kaalutu ning lehe kiiruse määrab see, milliseid silte ja millises koguses sa selle kaudu käivitad.

Kaheksa standardset jälgimissilti GTM-i kaudu lisavad lehe laadimisele 3-10 sekundit. Samad sildid otse koodi kirjutatuna aeglustavad asja aga veelgi rohkem. Hilisem käivitamine afterLoad kaudu võidab tagasi kuni 6 sekundit. Mahajäetud siltide eemaldamine annab veel paar sekundit juurde. Kokkuvõttes võib GTM nutika seadistuse korral olla kiirem kui otse koodi kirjutatud skriptid, ilma seadistuseta aga kaotab täielikult tühjale lehele.

Peamine reegel on lihtne: lehe kiiruse määrab mitte GTM, vaid sina ise. Auditeeri konteinerit, korista rämps ära, lükka mittekriitilised sildid hilisemaks, sea üles lehevälised välistused ja sinu saidi kiirus tänab sind.

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>

Kõik WordPressist, veebiarendusest — ja mitte ainult

🚀 Google tag manager ja saidi kiirus: mida testid ütlevad