Одним из главных пунктов продажи Google Tag Manager для маркетологов (что можно заметить даже на их целевой странице) является то, что он оптимизирует скорость страниц или страницы могут загружаться быстрее. Но так ли это на самом деле? GTM (или любое другое решение для управления тегами) действительно дает крылья вашему сайту?

Время от времени я замечаю на форуме темы и чаты, где люди (обычно цифровые маркетологи) получают жалобы от своих ИТ-отделов (что GTM замедляет работу сайта), и они ищут несколько советов о том, как повысить скорость страниц.

Хотя я знаю основные рекомендации по запуску GTM на вашем сайте, я понял, что в моих знаниях по-прежнему есть некоторые пробелы в отношении производительности GTM и страниц.

Что именно и как GTM (и различные теги) влияет на скорость страницы? Этот вопрос застрял у меня в голове довольно давно, и совсем недавно я решил провести кучу тестов с различными настройками GTM, чтобы испытать скорость самостоятельно.

Особая благодарность Симо Ахаве. Во время написания этого поста (и сбора данных) я обратился к нему, потому что у меня были некоторые сомнения относительно этой статьи (и не пропускаю ли я что-то). Как всегда, он любезно дал несколько советов и идей. Некоторые из них были а-ха! моменты для меня, другие подняли еще больше вопросов, которые требуют дальнейшего изучения.

Но, в конце концов, я определенно рад новым знаниям, полученным в результате этого длительного процесса исследований. Надеюсь, вы тоже найдете что-то полезное.

Отказ от ответсвенности

Вы должны прочитать это руководство и взять мои выводы с солью. Не принимайте все как абсолютную правду. Когда речь идет о скорости страницы и производительности сайта, на результаты влияют многие нюансы, и я не охватил все из них. На самом деле, я думаю, что я просто царапал поверхность.

Тем не менее, мои выводы могут быть хорошей отправной точкой и ориентиром для тех, кто совсем не знаком с оптимизацией скорости страниц и только начинает.

Краткое резюме для тех, кто спешит (TL, DR)

Это руководство очень длинное. Если у вас есть время, я определенно рекомендую прочитать его от начала до конца.

Если у вас есть всего пара минут, вот что вы должны знать:

Даже асинхронные теги влияют на скорость загрузки сайта.
Пустой контейнер GTM оказал минимальное влияние на скорость страницы. Крупнейшими нарушителями могут быть теги, которые вы добавляете в этот контейнер. Но каждый тег различен, и влияние может отличаться. Следовательно, конечный результат – «Зависит от ситуации».
8 тегов отслеживания, которые я использовал в некоторых тестах, оказали более негативное влияние, будучи жестко закодированными в тегах против 8, реализованных с помощью GTM. Но это не категорически верно для каждого случая.
Чем позже ваши огненные теги, тем меньше негативное влияние они могут оказать (если только вы не загрузите несколько пользовательских HTML-тегов в одностраничное приложение. Тогда влияние можно почувствовать даже после начальной загрузки страницы. Примечание: в этом руководстве Я сосредоточился только на начальной загрузке страницы.)
Будьте осторожны с манипуляциями с DOM. Им требуются ресурсы браузера, и в одном из моих экспериментов они добавили 3 секунды к метрике времени до интерактива .
Отслеживание на стороне сервера (когда GTM выпустит это) должно определенно улучшить производительность страницы. Надеюсь, эта функция будет выпущена позже в этом году.
Вы не должны измерять скорость страницы при включенном режиме предварительного просмотра и отладки GTM (поскольку это добавляет дополнительную нагрузку на браузер, которую ваши посетители не будут испытывать).
Удалите ненужные (или не относящиеся к делу) предметы в вашем контейнере. Это облегчит вашу работу с менеджером тегов и потенциально может повысить скорость страницы (хотя это не всегда так).

А если у вас будет больше времени, давайте углубимся, и я покажу вам, чему научился.

Часть № 1. Как проводились мои тесты?

Давайте начнем с объяснения моих методов и настроек. Если вас не волнует настройка, перейдите к главе 2 этого блога, где я рассмотрю свои выводы.

Настройка

Чтобы измерить временные параметры скорости страницы, я использовал webpagetest.org и встроенный инструмент аудита скорости сайта Lighthouse в консоли разработчика Chrome (после того, как вы откроете инструменты разработчика, перейдите на вкладку Audits ).

В webpagetest.org я использовал:

Ирландия (EC2, Chrome, Firefox) в качестве места тестирования (для настольных компьютеров), устройство Oneplus 5 (для мобильных испытаний)
3G Fast и 3G Slow для подключения
Было 3 теста в каждом прогоне
Другие настройки были по умолчанию

В Lighthouse я использовал отчеты как для мобильных, так и для настольных компьютеров (так как настроек не так много).

Чтобы изолировать возможное влияние расширений Chrome на результаты тестирования, я использовал его в инкогнито. Это означает, что никаких расширений браузера не было. Производительность ноутбука была установлена на максимум.

Метрика

Чтобы измерить воздействие, я проверял следующие показатели.

Webpagetest.org:

Document complete (в секундах). Он показывает, когда загружен статический контент сайта (например, изображения). Это обычно происходит после того, как все изображения загружены, но может не включать в себя содержимое, которое запускается при выполнении JavaScript. Чем больше секунд требуется для полной загрузки, тем хуже.
Fully loaded (в секундах). Это точка после onLoad, когда сетевая активность останавливается на 2 секунды (обычно любое действие здесь происходит из-за того, что javascript на странице делает что-то динамическое. Чем больше секунд требуется для полной загрузки, тем хуже.

Lighthouse (встроенный инструмент Chrome для аудита сайтов):

First meaningful paint (в секундах). Он измеряет время в секундах между пользователем, инициирующим загрузку страницы, и страницей, отображающей основной объем содержимого выше (подробнее ). Чем больше секунд требуется для полной загрузки, тем хуже.
Time to interactive (в секундах). Он измеряет, сколько времени требуется странице, чтобы стать полностью интерактивной (узнать больше ). Страница считается полностью интерактивной, когда:
- На странице отображается полезный контент
- Страница реагирует на взаимодействие с пользователем в течение 50 миллисекунд
First CPU idle (в секундах). Он измеряет, сколько требуется времени, чтобы страница стала минимально интерактивной (когда большинство элементов пользовательского интерфейса на экране реагируют на ввод пользователя в разумные сроки). Узнайте больше.
Max potential First Input Delay (FID) (в миллисекундах). Он измеряет потенциальное время с момента, когда пользователь впервые взаимодействует с вашим сайтом (т. Е. Когда он нажимает на ссылку), до времени, когда браузер действительно может ответить на это взаимодействие. Например, если браузер реагирует на ваш щелчок только через 1 секунду, значение FID равно 1000. Подробнее.

Коды отслеживания

Вот коды отслеживания, которые я использовал в некоторых из моих экспериментов:

Тег просмотра страницы Google Analytics (gtag.js)
Основной код пикселя Facebook (который отслеживает просмотр страницы)
Reddit Pixel тег преобразования
Quora pixel (отслеживает просмотр страницы)
Тег LinkedIn Insights
Универсальный тег Twitter (просмотр страницы треков)
Тег ремаркетинга Google Ads (gtag.js)
Hotjar основной код отслеживания

Какие тесты я проводил?

Вот список всех тестов, которые я провел. Я измерил скорость страницы двумя вышеупомянутыми инструментами в следующих ситуациях:

На странице нет сторонних кодов отслеживания и нет решения для управления тегами
На странице есть жестко закодированные сторонние коды отслеживания (до закрывающего тега

) и нет решения для управления тегами. «Жестко» означает, что теги были добавлены непосредственно в исходный код сайта.
На странице есть пустой контейнер GTM (и без жестко закодированных тегов )
Все 8 тегов отслеживания реализованы через GTM, запуск по триггеру All Pages (aka gtm.js )
Все теги реализованы через GTM, запуск по триггеру DOM Ready (он же gtm.dom )
Все теги реализованы через GTM, стрельба по триггеру Window Loaded (aka gtm.load )
Все теги реализованы через GTM, срабатывают через 1,5 секунды после запуска Window Loaded (идея этого пользовательского решения была заимствована у Павла Бречика )
Отладка полного контейнера GTM с включенными режимами предварительного просмотра и отладки (позже я объясню, почему я это сделал). Кроме того, я сравнил результаты с аналогичной настройкой, но режим P & D отключен.
Контейнер GTM с 100 пользовательскими тегами HTML (все используют один и тот же простой скрипт). Метки отслеживания были удалены из контейнера. Дальнейшие тесты не включали отслеживание тегов.
Контейнер GTM с 100 пользовательскими тегами HTML (все используют один и тот же простой скрипт, который также добавляет дополнительные элементы внизу тела страницы).
Контейнер GTM с 200 пользовательскими тегами HTML (все используют тот же простой скрипт, что и в предыдущем эксперименте).
Контейнер GTM с 100 пользовательскими тегами HTML, которые вставляют элемент после заголовка 2. Каждый тег содержит этот скрипт (заимствовано здесь ):
Контейнер GTM с 100 пользовательскими тегами HTML, которые вставляют элемент после 21-й ссылки на странице. Это требует от браузера перебирать больше элементов на странице, поэтому требует больше ресурсов. Каждый тег содержал этот скрипт:
Полный контейнер GTM со статическим содержимым (это означает, что он достиг 100% своей максимальной емкости (200 КБ)). Но я хотел рассмотреть только его размер и изолировать некоторые потенциально дорогостоящие задачи для браузера, поэтому я создал контейнер, полный только постоянных переменных (каждая содержала ~ 1000 символов). Любопытно, сколько таких переменных помещается в один контейнер GTM? В моем случае это был номер 1976 года.

Я проводил каждый тест как минимум 3 раза, а затем вычислял среднее время.

Что я имею в виду, говоря «Page Speed»

Каждый раз, когда я упоминаю скорость страницы в этом сообщении, я концентрируюсь на производительности страницы, которая связана с начальной загрузкой страницы, а не на том, что происходит после этого. Но не думайте, что это не повлияет на производительность после загрузки всех ресурсов.

Наоборот. И это особенно важно для одностраничных приложений, когда GTM может добавлять дополнительные узлы в документ страницы, что требует дополнительных ресурсов компьютера для обработки всего.

Симо упоминает эту проблему в нескольких сообщениях в блогах, например, в этом и этом.

Часть № 2: Результаты и идеи

Если вы хотите проверить более подробные данные о времени каждого эксперимента, вы можете проверить эту таблицу. И вот некоторые ключевые выводы, на которые я хочу обратить внимание. Большинство из них доставлены вам Капитаном Очевидностью (в то время как другие могут научить вас чему-то новому).

Асинхронный не означает, что не влияет на скорость страницы

Во-первых, давайте быстро познакомимся с синхронными и асинхронными сценариями. Синхронный сценарий означает, что браузер не будет загружать дополнительные ресурсы веб-сайта (например, изображения и т.д. ), Пока этот синхронный сценарий не будет загружен. Это может сильно повлиять на производительность сайта и пользовательский опыт.

Представьте себе, что на странице есть куча синхронных скриптов, которые блокируют рендеринг страницы на 15 секунд, и все, что вы видите, это просто белый экран.

Асинхронные сценарии, с другой стороны, загружаются одновременно с другими компонентами веб-страницы. Это означает, что во время загрузки сценария содержимое главной страницы также загружается и не блокируется.

Звучит потрясающе. Вы можете загрузить свои коды отслеживания, не оказывая никакого влияния на загрузку изображений и контента веб-сайта, верно? Ну не совсем.

Несмотря на то, что элементы не блокируются напрямую, асинхронные сценарии все еще требуют ресурсов компьютера, а это означает, что выполнение основных файлов / сценариев веб-сайта замедляется.

Несколько примеров, чтобы доказать это:

Событие Document Loaded веб-сайта произошло через 4 секунды, когда теги не были внедрены (ячейка B5 на этом листе )
Это число увеличилось до 7,7 секунд, когда в тег было добавлено несколько тегов (ячейка B7).

Синхронизация событий «Документ завершен» (в секундах). Нет тегов против 8 жестко закодированных тегов.

Даже добавление пустого контейнера Google Tag Manager немного увеличило время загрузки страницы (ячейки B6-E6) на ~ 0,1 сек.

Это не само GTM, это то, что вы вкладываете в него

В моих экспериментах (и я проводил один и тот же тест несколько раз) пустой контейнер GTM, добавленный на веб-сайт, вызывал очень минимальную задержку, ~ 100 миллисекунд (иногда даже без видимой задержки). Это потому, что вы только что добавили один скрипт на страницу.

Влияние на скорость страницы сайта начинается, когда вы добавляете дополнительные элементы в контейнер. Однако все предметы не равны. Это действительно зависит от того, что делают эти элементы (например, теги или переменные). Например, когда я добавил 8 контейнеров отслеживания в контейнер, скорость страницы замедлилась на ~ 3 секунды в быстром 3G (ячейки B8-C8) и на ~ 10 секунд в медленном 3G (ячейки D8-E8).

Синхронизация событий «Документ завершен» (в секундах). Нет тегов против 8 тегов отслеживания в GTM

Однако, если вы думаете, что просто добавив несколько элементов в контейнер, сайт всегда значительно замедляется, это не так. В другом эксперименте у меня было только 1976 постоянных переменных (контейнер достиг предела размера 200 КБ), время загрузки страницы увеличилось всего на 0,1-0,3 секунды (ячейки B17-E17).

Эти переменные не вызывали сложные функции, не загружали скрипты и не добавляли / не манипулировали элементами веб-сайта, поэтому их влияние было не таким заметным, как при использовании 8 тегов (GA, FB Pixel, тег Twitter и т.д. ).

« Подождите минутку, – подумаете вы, – всего лишь 8 тегов замедлили сайт на столько? Я думал, что GTM должен был оптимизировать скорость загрузки страниц ». Продолжайте чтение.

Твердо закодированные теги (в веб-сайт замедлился больше (по сравнению с GTM + эти теги)

Вы не должны ожидать от GTM какого-то волшебного решения, которое поможет вашему сайту мгновенно загрузиться. Если вы добавите те же самые 8 сценариев (которые я использовал в предыдущем примере) непосредственно в исходный код веб-сайта, результаты, вероятно, будут еще хуже. Потому что, как я уже говорил, не GTM сам тормозит ваш сайт, а то, что вы вкладываете в него.

И это именно то, что произошло в моих экспериментах.

Когда я добавил 8 сценариев отслеживания непосредственно в код сайта (до закрытого тега </ head>), страница еще больше замедлилась. Вместо увеличения времени загрузки страницы на 3 секунды, жестко закодированные теги добавили 600 миллисекунд для быстрого соединения 3G (ячейка B7-C7).

Синхронизация событий «Документ завершен» (в секундах). Нет тегов против 8 жестко закодированных тегов и 8 тегов отслеживания в GTM

По крайней мере, исходя из моего эксперимента, GTM действительно помогает сайтам загружаться немного быстрее (по сравнению с тестом, в котором те же теги были жестко закодированы).

Но это НЕ категорически верно в каждом случае. Когда я упомянул об этом результате и о своем заключении для Симо, он сказал, что есть случаи, когда вполне возможно запустить сам JS на сайте без GTM способом, который намного более оптимален, чем с использованием GTM. Поэтому, это один из тех случаев, когда вы можете взять мои выводы с крошкой соли.

Идите и проверьте это самостоятельно. Может быть, вы обнаружите что-то интересное.

Момент срабатывания метки имеет значение

Чем позже вы это сделаете, тем лучше. Об этом также рассказывается в руководстве Павла Бречика. Суть в том, что чем позже вы активируете свой тег, тем меньше будет влияние на скорость загрузки страницы.

Я взял те же самые 8 тегов (FB Pixel и т.д.) И запустил их все в разные моменты. Вы, наверное, уже знакомы с 3-мя триггерами, связанными с просмотром страницы, представлением страницы (gtm.js ), DOM Ready (gtm.dom ), Window Loaded (gtm.load ). Итак, я применил эти 8 тегов к этим трем различным моментам (например, в одном эксперименте были задействованы все 8 тегов при запуске Pageview, затем в следующем эксперименте я использовал DOM Ready и т.д. ).

Кроме того, я позаимствовал совет Павла и добавил 4-й момент, когда метка может быть запущена – через 1,5 секунды после Window Loaded .

Кстати, вот код, который использовал Павел:

Результат?

Хотя использование тегов в DOM Ready или Window Loaded лишь немного сократило время загрузки страницы, наиболее значительное улучшение было замечено в событии afterLoad. Это означает, что мои теги были запущены только тогда, когда другие компоненты веб-страницы уже были загружены, поэтому они не влияли на начальный процесс загрузки.

«Полностью загруженные» события (в секундах). «Просмотр страницы» и «Готовность к DOM», «Загрузка окна» и триггеры «afterLoad»

Почему задержка тегов хороша в первую очередь? Поскольку на веб-сайте могут быть некоторые компоненты / элементы, которые загружаются на страницу динамически только после загрузки всех ресурсов (включая сценарии). Если из-за ваших тегов страница загружается медленнее, это означает, что эти (возможно, важные) элементы веб-сайта также загрузятся позже, чем ожидалось.

Таким образом, если вы задерживаете некоторые теги и запускаете их ПОСЛЕ того, как все другие ресурсы были загружены, вы не сильно задерживаете появление этих других компонентов.

Однако имейте в виду, что если вы задержите отслеживание тегов, от которых требуется точность (например, Google Analytics), такая задержка приведет к большей неточности в ваших отчетах. Зачем? Потому что некоторые посетители даже не будут ждать полной загрузки вашего сайта (если это займет слишком много времени) и покинут сайт еще до того, как вы запустите GA.

Конечный результат? Ваши отчеты не будут даже знать, что посетитель X когда-либо был на вашем сайте.

Если задержка тегов звучит как решение для вас, не спешите реализовывать это прямо сейчас. Во-первых, вы должны обсудить со своей командой / компанией, какие теги менее критичны и могут быть отложены. Все участники должны быть на борту. Одностороннее решение может привести к неожиданной потере данных или даже прибыли.

Теги отслеживания – не единственные нарушители

Другая группа тегов, которые влияют на скорость страницы (при загрузке), – это теги, которые манипулируют объектной моделью документа (DOM) (например, редактируют или добавляют новые элементы на страницу).

Однако, как и во всем этом руководстве, масштаб влияния на скорость страницы зависит от различных факторов. В экспериментах № 10-13 я попробовал несколько вариантов:

Добавление элементов без указания местоположения (это означает, что они будут добавлены внизу страницы)
Добавление элементов в определенную часть страницы (это означает, что сценарий должен проверить страницу и найти правильное место (для этого автоматически требуется больше ресурсов)).

Очевидно, я зашел слишком далеко (используя 100-200 пользовательских тегов HTML, которые добавляют элементы), но в то же время «тяжесть» этих тегов была низкой.

Тем не менее, когда ваш тег должен вставить элемент в определенную часть страницы, он потребует больше ресурсов компьютера. Если ваш сценарий, например, использует document.querySelectorAll (имеется в виду, что он ищет все элементы на странице, которые соответствуют определенным критериям) и выполняет итерацию по каждому элементу, это потребует еще больше времени / ресурсов от вашего браузера.

В экспериментах № 10 и № 11 я не указывал, куда добавлять элементы, поэтому GTM вставил их в конец.

Это не оказало существенного влияния на скорость загрузки страницы.

В эксперименте № 12 я указал, куда я хочу добавить новые элементы. Я не использовал метод querySelectorAll. Но даже без этого 100 одинаковых тегов (которые добавляли элементы в определенную часть страницы) добавляли несколько сотен миллисекунд ко времени загрузки страницы. И сценарий, который я использовал, был довольно простым:

Вот влияние:

«Полностью загруженные» события (в секундах). Пустой контейнер GTM против 100 пользовательских HTML-тегов, которые выполняют базовые манипуляции с DOM

Эксперимент № 13 был построен как немного более ресурсоемкий. У меня было 100 пользовательских HTML-тегов, которые искали все ссылки на странице, а затем после 21-го элемента добавлялся заголовок 3 с примером текста.

Разница между этим и № 12 экспериментом заключается в том, что этот элемент выполняет итерацию по элементам веб-сайта, проверяет каждый из них, а затем добавляет элемент, если критерий удовлетворен. Хотя результаты на webpagetest.org не были новаторскими (к загрузке страницы была добавлена небольшая задержка (100-200 мс)), с Lighthouse (встроенным средством аудита сайтов Chrome) все стало интереснее.

Как на настольном компьютере, так и на мобильном устройстве эти теги добавляли 2-3 секунды к метрике «Время для интерактива», что означает, что во время загрузки страницы браузер очень занят, добавляя эти элементы заголовка 3 на страницу, поэтому сайт может не отвечать на запросы посетителя. в течение более длительного времени.

«Время до интерактивности» (в секундах), когда имеет место более тяжелое манипулирование DOM

Конечно, я зашёл слишком далеко, добавив один и тот же скрипт 100 раз, но это всего лишь подтверждение концепции. Возможно, ваш контейнер будет иметь меньше тегов, которые манипулируют DOM, но их влияние будет больше (из-за их сложности).

Часть № 3. Советы о том, как минимизировать влияние Google Tag Manager на скорость страницы

А теперь давайте перейдем к той части, которая вас, вероятно, больше всего интересует, чтобы свести к минимуму влияние.

Есть несколько возможных быстросъемные победы, но в то же время, вы должны будете обсуждать вещи внутри вашей команды / компании и искать компромиссы (в одной области скорость страницы будет принесена в жертву, в другом – точность данных).

# 1. Регулярно проверяйте ваш контейнер и ищите заброшенные теги в нем

Я помню, как слышал в одной из презентаций MeasureCamp 2019 в Лондоне (я полагаю, что это был Энди Дэвис, но не уверен на 100%), что некоторые аудиты показали, что ~ 30% кодов отслеживания (все еще загружаемых на странице) принадлежали поставщикам, которые уже не используются компанией больше.

Представьте себе: вы переходите от аналитического инструмента X к новому инструменту Z. Но коды инструмента X все еще были активированы. Не говоря уже о том, что сайт все еще отправляет (возможно, личные) данные третьим лицам, эти теги также влияют на скорость страницы.

Идентификация таких кодов отслеживания (особенно в больших контейнерах GTM) может быть довольно быстрым выигрышем для повышения скорости страницы.

Если вы не уверены, как проверить скрипты самостоятельно, попросите разработчика предоставить вам список скриптов / HTTP-запросов, которых, по его мнению, можно избежать.
Затем гуглите домены этих запросов и попытайтесь определить, к каким инструментам они относятся.
Кроме того, поговорите с различными отделами / коллегами о том, какие инструменты все еще используются.
После того, как вы поговорите со всеми, посмотрите, есть ли в списке какие-то одинокие инструменты, которые вы получили от разработчика на шаге 1.
1. Если сценарии этого инструмента реализованы через GTM, приостановите эти сценарии. Держите их таким образом, скажем, в течение месяца и посмотрите, жалуется ли кто-нибудь на недостающие данные или что-то еще. Если никаких претензий не возникает, полностью удалите скрипты из GTM.
2. Если сценарии отсутствуют в GTM (или любом другом используемом вами решении для управления тегами), обратитесь к разработчику и попросите временно отключить эти сценарии (например, превратив их в комментарии ). Если никто не жалуется на это в течение месяца, попросите разработчика полностью удалить их из кода.

# 2. Задержка тегов, которые менее важны (или требуют меньшей точности)

Чем меньше тегов вы используете на всех страницах или в пользовательском триггере просмотра страниц , тем лучше будет время загрузки страницы (по крайней мере, исходя из моих экспериментов).

Теперь я полностью понимаю, что вы не сможете сделать это со всеми из них, но если вы примените этот подход хотя бы к некоторым из них, вы можете ожидать некоторого улучшения производительности.

Судя по моим тестам, задержка запуска тегов в DOM Ready (вместо Pageview) принесла лишь небольшие улучшения. Но если вы перенесете некоторые из своих тегов в Window Loaded, время загрузки страниц улучшится, особенно при медленных соединениях 3G.

Однако это относится только к событию «Документ завершен» в отчетах webpagetest.org, а не «Полностью загружен».

Если возможно, попробуйте отложить некоторые теги еще больше. Павел Бречик описал в своем блоге методику, при которой он запускает теги через 1,5 секунды после события Window Loaded. Сначала я кратко объясню настройку, затем обсужю результаты.

Шаг № 1: Создайте пользовательский тег HTML со следующим кодом

Шаг № 2: Запустите этот тег в пользовательском триггере Window Loaded

Шаг № 3: Создайте пользовательский триггер для события afterLoad (с учетом регистра)

Шаг № 4: Назначьте это событие afterLoad Custom Event тем тегам, которые вы готовы отложить на 1,5 секунды после загрузки окна.

И результаты были намного лучше, если мы посмотрим на метрики полностью загруженных .

На медленном 3G-соединении это улучшение сократилось на 6 секунд (в то время как на быстром 3G-соединении было сэкономлено 600 миллисекунд).

Как вы решаете, какие теги могут быть отложены? Если вы не группа из одного человека, вы определенно не делаете это в одиночку. Обсудите со своими товарищами по команде / клиентами, менеджерами и т.д. Каждая позиция / мнение должны быть услышаны, чтобы прийти к консенсусу.

Вообразите это:

Если бы разработчики решили все самостоятельно, они просто удалили бы все маркетинговые теги (или значительно задержали их), потому что они мотивированы для оптимизации производительности. Но это негативно скажется на маркетинговых усилиях и, в конечном итоге, на доходах (если, скажем, вы сильно инвестируете в онлайн-рекламу).
Если бы маркетологи все решили сами, они бы просто заполнили веб-сайт десятками (если не сотнями) тегов отслеживания, запустили их как можно скорее и, следовательно, снизили бы производительность сайта. Это еще одна крайность.

Вот почему разные лагеря должны прийти к соглашению о том, как они подходят к задерживающим меткам, обсудить возможные последствия и решить, какие метки можно «пожертвовать», чтобы отложить.

Например, если вы реализовали виджет чата через GTM (хотя я думаю, что это плохая идея, и такие инструменты должны быть реализованы непосредственно в коде), я думаю, что сценарий виджета может быть определенно задержан и запущен через x секунд после Window Loaded .

Другим возможным примером может быть тег ремаркетинга. Лично я хотел бы перенастроить тех людей, которые действительно потратили много времени на страницу. Пребывание на странице хотя бы до срабатывания события afterLoad будет лучшим индикатором для ретаргетинга, а не для отслеживания просмотра страницы как можно скорее. Но еще раз, это всего лишь предложение, и вам нужно решить, что подходит для бизнеса.

Просто помните одну вещь: будут жертвы. Это может быть производительность страницы, это может быть точность данных (и, возможно, доход). Моя позиция здесь не в том, чтобы слепо пытаться достичь идеального результата (например, в Lighthouse, это 100), а вместо этого сосредоточиться на конечном результате для бизнеса.

Все дело в компромиссах. С каждым сценарием, который можно добавить на сайт, вы (как пользователь GTM, который добавляет этот сценарий) должны учитывать преимущества раннего запуска этого сценария по сравнению с его задержкой (во имя производительности).

Во-первых, вам нужно будет решить в вашей организации, что может быть отложено.

# 3. Может быть, некоторые теги можно использовать только на определенных страницах?

У вас есть теги в контейнере, которые появляются на каждой странице? Они действительно должны стрелять на каждой странице? Может быть, они нужны вам только на нескольких целевых страницах, но из-за нехватки времени вы выбрали триггер «Все страницы»?

Попробуйте создать более точные триггеры, которые ограничивают теги только набором страниц, если это возможно. Тогда остальные веб-страницы не будут затронуты.

# 4. Старайтесь избегать тяжелых манипуляций с DOM (как долгосрочное решение)

Я упомянул «долгосрочное решение» в подзаголовке по причине. GTM, безусловно, является отличным инструментом для проверки концепции (например, временно манипулировать определенными элементами веб-страницы и посмотреть, улучшил ли это коэффициент конверсии или что-то еще). Но как только вы подтвердите идею, это улучшение в конечном итоге должно быть реализовано разработчиком и удалено из GTM.

Разработчик сделает это более оптимальным способом и (возможно) без манипуляций с DOM.

Это особенно относится к тем манипуляциям, которые требуют, чтобы браузер просматривал каждый элемент и проверял, соответствует ли он критериям. Хотя мой эксперимент № 13 не оказал значительного влияния на результаты webpagetest.org, на метрику Time To Interactive оказали серьезное влияние (~ 2-3 секунды было добавлено к времени загрузки), что означает, что страница не отвечает в течение большего времени.

# 5. (на будущее) Отслеживание на стороне сервера с помощью Google Tag Manager

В январе 2020 года команда Google Tag Manager объявила на SuperWeek, что они работают над функциями отслеживания на стороне сервера в GTM. Несмотря на то, что до сих пор не так много деталей (функция все еще находится на очень ранних стадиях разработки), это выглядит многообещающе для оптимизации скорости страницы.

Вместо того, чтобы загружать кучу отслеживающих тегов на стороне клиента (это означает, что все происходит в браузере посетителя, а ресурсы компьютера требуются для обработки всей нагрузки), вы сможете перенести это, скажем, в Google Cloud и значительно уменьшить количество задач, которые должны выполнить браузеры ваших посетителей.

Что вы можете сделать с этим прямо сейчас? Ничего особенного, просто подожди. Если вам ДЕЙСТВИТЕЛЬНО интересно узнать об этой идее в целом, Дэвид Вальехо планирует написать в блоге сообщение о своем собственном серверном решении для GTM. Просто имейте в виду, что его решение не является официальным функционалом GTM.

# 6. Не измеряйте скорость страницы при включенном режиме предварительного просмотра GTM

Когда вы включили режим предварительного просмотра и отладки GTM, это значительно увеличивает нагрузку на браузер. Чем больше предметов у вас в контейнере, тем больше этот груз.

Кроме того, в каждом dataLayer.push переоценивается КАЖДАЯ переменная в контейнере GTM, что означает еще большую работу для браузера.

Я не смог найти простой способ проверить влияние режима предварительного просмотра с webpagetest.org, но я легко сделал это с Lighthouse.

В эксперименте № 8 у меня был полный контейнер GTM с не очень тяжелыми тегами и триггерами, и я проверил скорость страницы с включенными режимами предварительного просмотра и отладки. Результат? Двойные цифры в метрике Time To Interactive (это означает, что веб-страница медленно реагирует в течение достаточно долгого времени.

Кроме того, Max FID (Максимальная задержка при первом входе) была в тысячах миллисекунд, а не в сотнях. Этот показатель означает, что если посетитель нажимает на ссылку во время загрузки страницы, потенциальная задержка между кликом и перенаправлением (или чем-то, что делает этот клик) составляет ~ 3,3-3,5 секунды.

Затем я проверил скорость того же контейнера (но без включенного режима предварительного просмотра GTM), и результаты были намного лучше (имейте в виду, что мы говорим здесь о полном контейнере GTM).

«Время до интерактивности» (в секундах): когда включен режим предварительного просмотра или отключен

Кроме того, Симо добавил, что вы не должны измерять скорость страницы с помощью фрагмента среды, потому что среда (например, подготовка, разработка) требует, чтобы GTM работал более эффективно, особенно во время начальной загрузки и выполнения JS.

# 7. Проверьте скорость страницы самостоятельно после внесения изменений в контейнер

Надеюсь, я представлю концепцию скорости страницы как дополнительную проблему для некоторых маркетологов и аналитиков, и они будут более осознанными, прежде чем добавлять что-то новое в контейнер.

После того, как вы опубликуете новую контейнерную версию, рекомендуется проверить ее с помощью Lighthouse и webpagetest.org. Тест веб-страницы также позволяет регулировать скорость соединения, поэтому старайтесь проверять не только быстрые, но и медленные соединения.

# 8. Всегда старайтесь держать свой контейнер стройным и удаляйте ненужные предметы

Это всегда хорошая практика, чтобы держать контейнер как можно меньше и удалять все ненужные предметы. Если вы нашли не относящийся к делу элемент (например, тег), просто удалите его. Даже если его влияние на скорость будет минимальным, всегда лучше оставаться как можно меньше. Это также облегчит управление тегами в интерфейсе GTM.

Поговорите со своими коллегами и спросите, все ли еще используется поставщик X или Y. Если нет, удалите их теги из вашей настройки.

Может быть, у вас есть триггеры или переменные, которые нигде не используются (они просто занимают место)? В этом случае Simo gtmtools.com может помочь идентифицировать их.

Перейдите на gtmtools.com, выберите учетную запись GTM и контейнер, который вы хотите проверить. Затем нажмите «Визуализация»> «Начать визуализацию».

Инструмент возьмет все элементы в вашем контейнере и проанализирует, как они связаны. В середине визуализации нажмите «Выбрать узлы отшельника».

… и он выделит все элементы, которые не имеют никаких связей, например:

Теги, которые не имеют триггеров
Триггеры, которые не назначены никаким тегам
Переменные, которые не используются в других тегах, триггерах или переменных

Вы удаляете их, чтобы освободить место. Хотя это (вероятно) не окажет ЭТО значительного влияния на скорость загрузки вашей страницы, это немного облегчит вашу работу с GTM, добавив больше пространства для дыхания.

Альтернативное решение (в том же gtmtools.com) заключается в следующем: вместо перехода в режим визуализации перейдите в режим рабочей области, и вы увидите эту таблицу. Нажмите на теги.

А затем в столбце Ссылки вы увидите, сколько других элементов (например, триггеров) связано с ним. Если этот тег не имеет отношения к ЛЮБОЙ другой сущности в контейнере, вы увидите кнопку Удалить . Нажмите эту кнопку и повторите тот же процесс для всех тегов, триггеров и переменных.

Как только вы закончите удаление элементов, пришло время отправить эти изменения в контейнер. В левом верхнем углу таблицы нажмите зеленую кнопку Обновить рабочее пространство, выполните дальнейшие шаги и все готово! Ваш контейнер только что стал стройнее.

Менеджер тегов Google против скорости страницы: последние слова

И это конец еще одного сообщения в блоге GTM. Хотя я не могу вспомнить, когда в последний раз я проводил так много времени в блоге, в то же время я чувствую, что многому научился.

Возвращаться туда-сюда, читать кучу ресурсов, пытаться переварить все, а затем исправить некоторые мои предубеждения (и предубеждения), было бесценным опытом. Еще раз спасибо Симо за то, что он показал направление на некоторых перекрестках, с которыми я столкнулся.

Вот ключевые выводы, которые я бы хотел взять из этого поста в блоге:

Замедляет ли Google Tag Manager сайт? Самый абсолютный ответ – да. Как и любая дополнительная строка кода, добавляемая на сайт, это окажет некоторое влияние на скорость загрузки страницы. Однако масштаб этого воздействия зависит от различных аспектов.
Хотя пустой контейнер GTM (добавленный на сайт) незначительно влияет на скорость загрузки страницы, на самом деле важно то, что вы помещаете в него.
Каждая настройка отличается, и могут быть разные нарушители, которые негативно влияют на скорость вашей страницы.
Асинхронные запросы также влияют на производительность страницы. Несмотря на то, что они не блокируют отображение страницы, им все еще требуются ресурсы компьютера, которые могут замедлить весь процесс загрузки. Наиболее распространенными нарушителями являются теги отслеживания, которые вы внедряете на сайте (например, пиксель FB, тег Twitter или даже GA).
В моих экспериментах коды отслеживания, добавленные через GTM, работали лучше, чем жестко закодированные теги (я имею в виду, что показатели загрузки страниц были лучше). Но, по словам Симо, это не совсем верно для всех случаев.
Если возможно, задержите хотя бы некоторые из ваших тегов. Вместо того, чтобы активировать их на всех страницах (или просмотр страницы ), переместите их в Window Loaded или даже после этого. Это важно, потому что могут быть некоторые компоненты страницы, которые загружаются только после того, как другие ресурсы готовы (например, скрипты). С тегами отслеживания этот «готовый» момент откладывается, что означает, что некоторые важные функции сайта начинают работать позже, чем должны.
Кроме того, манипуляции с DOM (когда вы редактируете, удаляете, создаете элементы) являются довольно дорогими операциями (более дорогостоящими, чем попытка прочитать значение существующего элемента).
Отслеживание на стороне сервера уменьшит нагрузку, которую браузеры в настоящее время имеют дело с #waitingForThatNewFeatureFromGTM
Это все о компромиссах и жертвах. В организации должен быть сбалансированный консенсус. Прежде чем добавлять какие-либо новые функции отслеживания, команда / организация должны взвесить все за и против. Да, эта настройка, вероятно, повлияет на скорость загрузки страницы. Но, может быть, это принесет большую пользу бизнесу, и, в итоге, выручка будет увеличена? Или может быть что-то еще может быть удалено / приостановлено, чтобы компенсировать влияние на производительность?
Не надо слепо гоняться за идеальным показателем скорости страницы. Лучше помнить о приоритетах бизнеса и стараться балансировать. Говоря об отличных результатах, вот пример веб-сайта с оценкой 100:

единственная вещь, которая является той, что страница, – это текст Hello World. Нет кодов отслеживания, не JavaScript, ничего больше. Идеальный результат? Да. Будет ли этот сайт зарабатывать деньги? Нет. Я знаю, что здесь я приду к крайностям, но если, например, на сайт будет добавлен JavaScript, который позволит измерить эффективность рекламы, а затем перераспределить бюджет для лучших исполнителей, следовательно, увеличит доход / прибыль (но отрицательно скажется на скорости страницы). ), Я думаю, что это справедливая торговля (до тех пор, пока бизнес достигает своей цели – дохода).
Не будь жадным и небрежным. Вы действительно нуждаетесь в 15 отслеживающих продавцах, внедренных на сайте? Вам действительно нужен большой пользовательский код JavaScript (который вы нашли в Интернете), реализованный на сайте? Вы показали этот код разработчику? (это может сломать вещи, о которых вы даже не подозреваете).
Проверяйте скорость своей установки более одного раза в жизни. Не делайте этого только тогда, когда ИТ-отдел поднимает красные флажки. Делайте это время от времени.
Проверка скорости страницы после каждого изменения контейнера была бы идеальной, но делать это, по крайней мере, после серьезных изменений, было бы достаточно.