GTM тормозит сайт — пора удалять контейнер

GTM тормозит сайт — пора удалять контейнер

Этот тезис встречается в каждом втором отчёте по аудиту скорости загрузки. Клиент видит в Lighthouse рекомендацию «сократить время выполнения JavaScript» и указывает на GTM как на главного виновника. Специалисты по оптимизации действительно находят контейнеры, которые нагружают страницу на 500–800 мс. Но проблема не в инструменте, а в его настройке.

Откуда растёт миф. Google Tag Manager загружается асинхронно *из коробки*, то есть не блокирует рендеринг страницы. Однако разработчики часто засовывают в контейнер десятки тегов, часть из которых выполняется синхронно (например, старые версии отслеживания кликов через Custom HTML), или не используют триггеры с задержкой (DOM Ready, Window Loaded). В результате GTM превращается в «мусорный полигон», где мешаются A/B-тесты, пиксели соцсетей и ретаргетинговые скрипты, которые реально грузят процессор пользователя.

Почему это неправда. Сам по себе GTM — это диспетчер. Он ставит скрипты в очередь и загружает их только когда браузер готов. Если настроить контейнер по правилам:
— выставлять приоритеты тегов (теги первого экрана — синхронно на Page View, всё остальное — по условиям),
— использовать встроенные переменные и теги вместо кастомного HTML,
— удалять неиспользуемые теги и версии,
— раз в квартал чистить триггеры «All Pages» для тегов, которые нужны только на конкретных страницах,
то влияние GTM на Core Web Vitals станет ниже погрешности (FCP и LCP прибавляют не более 30–50 мс).

Что делать вместо. Возьми за правило архитектурный ревью контейнера раз в месяц. Отключай теги, которые дублируют друг друга. Используй Google Tag Manager для Server-side (ssGTM), чтобы выгрузить часть обработки на свой сервер — это снизит нагрузку на браузер и улучшит показатели безопасности. И главное: не суди по «публичному шаблону» — проверяй реальные тайминги тегов через вкладку Performance в DevTools. GTM не виноват, виноват тот, кто кидает в контейнер всё подряд без разбора.

— @GTMrecipesRuPro