⚡ 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 и скорость сайта: что говорят тесты