⚡ GTM і швидкість сторінки: тести, висновки та 8 способів прискорити сайт

Маркетологи люблять повторювати: «Google Tag Manager пришвидшує сайт, сторінки з GTM завантажуються швидше». Розробники зазвичай сперечаються: «GTM тільки гальмує». Правда, як завжди, між цими крайнощами.

Ми провели серію тестів із різними конфігураціями GTM: порожній контейнер, контейнер із 8 трекінговими кодами, жорстко вшиті теги, різні моменти спрацювання тригерів, десятки кастомних HTML-тегів із маніпуляціями DOM. Заміряли швидкість через webpagetest.org і Lighthouse. Результати виявилися не такими однозначними, як пишуть у презентаціях GTM.

Ось що ми з’ясували: сам по собі контейнер GTM майже не гальмує, а от те, що ви в нього кладете, може додати і 3, і 10 секунд до завантаження. І головне: цим можна керувати.

💡 Швидкий огляд:

Порожній контейнер GTM додає до завантаження близько 100 мілісекунд
Вісім трекінгових тегів через GTM уповільнюють сторінку на 3 секунди при швидкому 3G і до 10 секунд при повільному
Ті самі 8 тегів, вшиті напряму в код сайту, гальмують ще сильніше
Що пізніше спрацьовують теги, то менший вплив: затримка на 1,5 секунди після Window Loaded скорочує час завантаження на 6 секунд на повільному 3G
Продумане налаштування тригерів і чистка контейнера від сміття повертають швидкість без втрати даних

Як ми тестували

Методика проста, але доскіплива. Кожен тест проганяли щонайменше тричі й рахували середнє.

Інструменти: webpagetest.org (сервер в Ірландії, EC2, Chrome і Firefox для десктопа, OnePlus 5 для мобільних тестів) і вбудований аудит Lighthouse у Chrome DevTools. У Lighthouse дивилися і мобільні, і десктопні звіти. Chrome запускали в режимі інкогніто, жодних розширень, продуктивність ноутбука на максимумі.

Метрики, які ми заміряли:

У webpagetest.org: Document complete (секунди до завантаження статичного контенту, зображень, стилів) і Fully loaded (точка після onLoad, коли мережева активність затихає на 2 секунди). У Lighthouse: First Meaningful Paint, Time to Interactive, First CPU Idle і Max Potential First Input Delay (FID).

Трекінгові коди в тестах: Google Analytics (gtag.js), Facebook Pixel, Reddit Pixel, Quora Pixel, LinkedIn Insights, Twitter Universal Tag, Google Ads Remarketing (gtag.js), Hotjar. Вісім повсюдно використовуваних скриптів.

Які сценарії ми порівняли:

Чиста сторінка без сторонніх скриптів і без GTM
Сторінка з 8 трекінговими кодами, вшитими напряму перед </head>, без GTM
Порожній контейнер GTM без тегів
Усі 8 тегів через GTM, тригер All Pages (він же gtm.js)
Ті самі 8 тегів через GTM, тригер DOM Ready (gtm.dom)
Ті самі 8 тегів через GTM, тригер Window Loaded (gtm.load)
Ті самі 8 тегів, спрацювання через 1,5 секунди після Window Loaded
Контейнер GTM з увімкненим режимом попереднього перегляду та налагодження
Контейнер GTM зі 100 кастомними HTML-тегами, що додають елементи в кінець <body>
Контейнер GTM зі 100 кастомними HTML-тегами, що додають елементи в конкретне місце сторінки (після H2)
Контейнер GTM зі 100 кастомними HTML-тегами, що шукають усі посилання і вставляють елемент після 21-го
Контейнер GTM із 1976 постійними змінними (заповнений під зав’язку, 200 КБ)

Що показали тести

Асинхронний не означає «без наслідків»

Асинхронні скрипти не блокують рендеринг напряму. Але їм усе одно потрібні ресурси процесора, а це означає, що основні скрипти сайту виконуються повільніше. На практиці: подія Document Complete на чистій сторінці наставала через 4 секунди. З вісьмома тегами, через 7,7 секунди. Різниця в 3,7 секунди лише від того, що процесор зайнятий сторонніми скриптами.

Порівняння часу Document Complete без тегів і з тегами

Навіть порожній контейнер GTM трохи збільшував час завантаження, приблизно на 100 мілісекунд.

Вплив порожнього контейнера GTM на час завантаження

Справа не в GTM, а в тому, що ви в нього кладете

Порожній контейнер GTM додає до завантаження приблизно 100 мілісекунд, іноді затримки взагалі немає. Проблеми починаються, коли ви наповнюєте контейнер тегами. Але й тут не все лінійно.

Вісім трекінгових тегів уповільнили сторінку приблизно на 3 секунди при швидкому 3G-з’єднанні та на 10 секунд при повільному. Кожен тег тягне свій скрипт, а браузер витрачає час на їх виконання.

Document Complete без тегів і з 8 тегами в GTM

А от контейнер, заповнений 1976 постійними змінними (200 КБ, межа GTM), додав усього 0,1-0,3 секунди. Змінні не завантажують зовнішні скрипти й не маніпулюють DOM, тому їхній вплив мінімальний.

Висновок: важливий не розмір контейнера, а те, які дії виконують його елементи.

Жорстко вшиті теги гальмують сильніше, ніж ті самі теги через GTM

Коли ми додали 8 трекінгових скриптів напряму в код сайту, сторінка сповільнилася ще помітніше. На швидкому 3G жорстко вшиті теги додали приблизно на 600 мілісекунд більше затримки порівняно з тими самими тегами, запущеними через GTM.

Порівняння жорстко вшитих тегів і тегів через GTM

На другому графіку та сама картина в іншому розрізі: жорстко вшиті скрипти стабільно програють GTM за часом Document Complete.

Document Complete жорстко вшиті теги проти GTM

GTM справді допомагає завантажуватися трохи швидше, ніж при прямому додаванні скриптів у код. Але це не універсальне правило. Є сценарії, де запуск JS без GTM можна реалізувати ефективніше, з цим згоден і Сімо Ахава, один із провідних експертів із GTM.

Момент спрацювання тега вирішує

Що пізніше спрацьовує тег, то менше він впливає на початкове завантаження. Ми протестували чотири моменти:

Page View (gtm.js), одразу при завантаженні контейнера
DOM Ready (gtm.dom), коли DOM побудований
Window Loaded (gtm.load), коли всі ресурси завантажені
afterLoad, через 1,5 секунди після Window Loaded (кастомний тригер)

Код кастомного тригера afterLoad:

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>

Результат: DOM Ready і Window Loaded дали невелике покращення. Але найзначніший виграш дав саме afterLoad. На повільному 3G затримка скоротилася на 6 секунд порівняно з тригером Page View. На швидкому 3G, на 600 мілісекунд.

Порівняння Fully Loaded для різних моментів спрацьовування тегів

Чому це працює? На сторінці можуть бути елементи, які завантажуються динамічно лише після повного завантаження ресурсів. Якщо теги сповільнюють початкове завантаження, ці елементи теж з’являються пізніше. Відкладаючи некритичні теги, ви даєте основному контенту завантажитися без перешкод.

Але є нюанс: якщо ви відкладаєте теги, від яких залежить точність даних (Google Analytics), частина відвідувачів може піти зі сторінки до спрацювання лічильника. Ваші звіти втратять частину даних. Рішення про затримку тегів має ухвалюватися разом із командою, а не одноосібно розробником чи маркетологом.

Трекінгові теги, не єдині порушники

Інша група «важких» тегів, ті, що маніпулюють DOM. Наприклад, кастомні HTML-теги, які додають або змінюють елементи на сторінці.

Ми протестували кілька варіантів:

100 кастомних HTML-тегів, що додають елементи в кінець <body>. Кожен тег виконував простий скрипт console.log('hello') і створював <div>Hello!</div>. Без зазначення конкретного місця вставки. Вплив на швидкість завантаження виявився мінімальним, елементи просто дописувалися в кінець.

100 кастомних HTML-тегів, що додають елементи в конкретне місце сторінки. Кожен тег шукав перший h2 і вставляв після нього h3. Скрипт:

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>

Це додало кілька сотень мілісекунд до завантаження. Хоча скрипт примітивний, пошук елемента та вставка потребують ресурсів.

Вплив 100 тегів з маніпуляціями DOM на Fully Loaded

100 кастомних HTML-тегів, які шукають усі посилання на сторінці та вставляють елемент після 21-го. Скрипт:

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>

Різниця з попереднім експериментом: querySelectorAll перебирає всі елементи на сторінці, перевіряє кожен — це дорожче. У webpagetest.org різниця була невеликою (100-200 мс), але Lighthouse показав зростання показника Time to Interactive на 2-3 секунди. Це означає, що під час завантаження сторінки браузер настільки зайнятий вставкою елементів, що не реагує на дії користувача.

Time to Interactive при важких маніпуляціях DOM

Так, 100 однакових скриптів — це перебір. Але суть у тому, що навіть кілька складних тегів, які маніпулюють DOM, можуть дати схожий ефект.

Як зменшити вплив GTM на швидкість: 8 прийомів

Регулярно чистіть контейнер від занедбаних тегів

Практика аудитів показує: до третини трекінгових кодів на сайтах належать інструментам, якими компанія вже не користується. Ви перейшли з аналітичного інструмента X на Z, а коди X досі завантажуються на кожній сторінці та гальмують її.

Що робити:

Попросіть розробника надати список усіх HTTP-запитів і скриптів на сторінці
Загугліть домени цих запитів, визначте, до яких інструментів вони належать
Запитайте в колег із різних відділів, які інструменти ще використовуються
Знайдіть «сирітські» скрипти, яких немає в списку використовуваних
Якщо скрипт реалізовано через GTM, призупиніть його на місяць; якщо ніхто не скаржиться, видаліть повністю
Якщо скрипт вшито в код, попросіть розробника тимчасово закоментувати, через місяць видалити

GTM контейнер перед аудитом на закинуті теги

Відкладайте некритичні теги

Що менше тегів на тригері All Pages, то швидше початкове завантаження. Не всі теги можна відкласти, але якщо застосувати цей підхід хоча б до частини, поліпшення буде помітним.

Як реалізувати затримку (спосіб Павла Бречика):

Крок 1. Створіть кастомний HTML-тег із кодом:

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. Запустіть цей тег на тригері Window Loaded.

Налаштування тригера Window Loaded для кастомного HTML-тегу

Крок 3. Створіть кастомний тригер для події afterLoad.

Створення кастомного тригера afterLoad в GTM

Крок 4. Призначте цей тригер тегам, які можна відкласти.

Результат на повільному 3G: затримка скоротилася на 6 секунд, на швидкому 3G, на 600 мілісекунд.

Fully Loaded при різних моментах спрацьовування тегів

Які теги можна відкласти, а які ні, вирішуйте з командою. Розробники в ідеалі прибрали б усе заради швидкості, маркетологи додали б усе заради точності даних. Істина посередині.

Використовуйте теги лише на потрібних сторінках

Не кожному тегу потрібно спрацьовувати на всьому сайті. Pixel ремаркетингу Google Ads може запускатися лише на посадкових сторінках кампаній, а не на всьому сайті. LinkedIn Insights, лише на сторінках, куди йде трафік із LinkedIn. Налаштуйте винятки в тригерах — це знизить кількість виконуваних скриптів на типовій сторінці.

Налаштування тригера тільки для певних сторінок в GTM

Уникайте важких маніпуляцій із DOM

Якщо вам потрібен кастомний HTML-тег, який щось додає на сторінку, намагайтеся робити це максимально легко. Уникайте querySelectorAll із перебором усіх елементів. Не вставляйте десятки однотипних елементів у різні місця сторінки. Кожна маніпуляція з DOM від'їдає ресурси браузера в момент, коли він і так зайнятий рендерингом сторінки.

Приклад оптимізованого кастомного HTML-тегу в GTM

Не заміряйте швидкість з увімкненим режимом попереднього перегляду

Режим Preview and Debug у GTM додає додаткове навантаження на браузер, якого немає в реальних відвідувачів. Якщо ви вимірюєте швидкість з увімкненим прев'ю, результати будуть свідомо гіршими за реальні. Перед аудитом швидкості завжди вимикайте режим налагодження.

Вимкнення режиму попереднього перегляду GTM для тестів швидкості

Тестуйте швидкість після кожної зміни контейнера

Внесли новий тег або змінили тригер, одразу перевірте швидкість сторінки через webpagetest.org або Lighthouse. Зробіть замір до і після. Це дасть змогу відловити проблемний тег одразу, а не гадати потім, чому сайт почав завантажуватися на 2 секунди довше.

Тримайте контейнер струнким

Видаляйте невикористовувані теги, тригери та змінні. Це не стільки про швидкість (як показав тест із 1976 змінними), скільки про керованість. У контейнері з сотнею тегів легко загубити проблемний скрипт. У контейнері з двома десятками кожна одиниця на виду.

Відділяйте зерна від полови: що реально економить час завантаження

Підіб'ємо підсумок експериментів. Ось що дає максимальний ефект у порядку спадання:

Зведена таблиця впливу різних факторів на швидкість завантаження

За результатами наших замірів, найзначніше поліпшення дає затримка тегів через afterLoad, до 6 секунд на повільному з'єднанні. На другому місці, видалення занедбаних трекінгових кодів. На третьому, обмеження області дії тегів конкретними сторінками.

⁉️🤔 Часті запитання

Чи сповільнює порожній GTM сайт?

Практично ні. У наших тестах порожній контейнер додавав близько 100 мілісекунд до завантаження. Іноді затримки взагалі не було. Це похибка, непомітна ні користувачеві, ні пошуковим системам.

Що сильніше гальмує: GTM чи жорстко вшиті скрипти?

Жорстко вшиті скрипти гальмують трохи сильніше. У нашому тесті 8 трекінгових тегів, доданих безпосередньо в код, сповільнили сторінку приблизно на 600 мілісекунд більше, ніж ті самі теги через GTM. Але це не універсальне правило: грамотно написаний кастомний JS може бути ефективнішим за GTM.

Чи можна відкласти взагалі всі теги?

Технічно, так. Але ви втратите дані: частина відвідувачів піде зі сторінки до спрацювання лічильників. Google Analytics та аналогічні інструменти недорахуються трафіку. Відкладайте лише ті теги, які не потребують високої точності, наприклад, віджети чатів або пікселі ремаркетингу. Аналітику краще залишити на Page View.

Як перевірити, які теги в GTM реально гальмують?

Запустіть аудит Lighthouse із відкритою вкладкою Network. Подивіться, які скрипти завантажуються найдовше та які блокують рендеринг. Зіставте домени цих скриптів із тегами в контейнері. Або проведіть A/B-тест: тимчасово вимикайте підозрілі теги по одному й заміряйте швидкість.

А що щодо server-side GTM?

Server-side GTM переносить обробку тегів із браузера користувача на ваш сервер. Браузер отримує лише один контейнер замість десятка сторонніх скриптів. Це радикально знижує навантаження на клієнтську сторону. Якщо у вас десятки трекінгових тегів, server-side GTM варто розглянути. Технологія доступна з 2020 року, і до 2026 року її впровадження стало помітно простішим.

Що в підсумку: GTM прискорює чи гальмує?

Ні те, ні інше в чистому вигляді. GTM — це диспетчер: сам по собі він майже невагомий, а швидкість сторінки визначає те, які теги та в якій кількості ви через нього запускаєте.

Вісім стандартних трекінгових тегів через GTM додають 3-10 секунд до завантаження. Але ті самі теги, вшиті напряму, гальмують ще сильніше. Відкладений запуск через afterLoad відіграє до 6 секунд. Видалення занедбаних тегів, ще кілька секунд. Отже, з розумним налаштуванням GTM може дати фору жорстко вшитим скриптам, а без налаштування, програти порожній сторінці всуху.

Головне правило просте: не GTM прикрашає сайт, а ви самі. Проведіть аудит контейнера, приберіть сміття, відкладіть некритичні теги, налаштуйте винятки за сторінками, і швидкість вашого сайту скаже вам спасибі.

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>

Все для WordPress, веб-розробки — і не тільки

🚀 Google Tag Manager і швидкість сайту: що кажуть тести