После внедрения процесса тестирования рекламных тегов на сайте из инструмента аналитики, GTM (предыдущая статья), мы задумались каких ресурсов он нам стоит, как уменьшить влияние GTM, и сформулировали гипотезу, что посредством аудита тегов можно улучшить метрики веба. Помимо этого мы хотели бы узнать:
Правда ли то, что ассинхронные сценарии настолько легкие для веба?
Правда ли то, что приостановленные теги == удаленным?
Этапы эксперимента и наши выводы читайте ниже. Будем рады, если в комментариях вы поделитесь своими мнениями, идеями или опытом. Давайте обсудим вместе!
Всем привет. Над экспериментом работали я — Даша, инженер по тестированию на платформе web в Иви, и Амина, контентный data-аналитик Иви. Мы расскажем вам, как пробовали оптимизировать метрики веба с помощью аудита в GTM и предоставим план эксперимента, на случай, если вы решите провернуть это у себя.
Точка С - "Эксперимент"
За последние полтора года платформа веб в Иви много работала над улучшением метрик: был проведен ряд работ для оптимизации метрик, и после мы также не переставали трудиться, чтобы LCP попала в зеленую зону (оптимальный показатель для зеленой зоны – до 2,5 сек) и держалась там. Так что, зная, как это сложно, мы не ожидали значительного улучшения метрик. Однако даже 200мс в мире скорости и качества технологий — это вечность.
Инструменты
Встроенные инструменты Chrome для аудита сайтов
Lighthouse
Performance
Grafana
Этапы эксперимента:
ЭТАП 1:
Замер метрик веба до очистки
Замер метрик веба с отключенным GTM
ЭТАП 2:
Аудит тегов в GTM
Составить таблицу со всеми тегами
Разделить теги на "активные" и "приостановленные"
Отдать "активные" теги отделу маркетинга для перепроверки
Замеряем метрики до приостановки неактуальных тегов
В случае необходимости приостановить ненужные теги
Замеряем метрики после приостановки
Отдать все "приостановленные" теги на утверждение и получение разрешение к удалению
ЭТАП 3:
Удаление тегов
Удаляем "приостановленные" неактуальные теги
Замеряем метрики
Удаляем "активные" неактуальные теги
Замеряем метрики
Делаем выводы
Метрики
Для облегченного восприятия все значения метрик на каждом этапе эксперимента были переведены в секунды. В определениях прописано в чем происходит измерение метрик для отрисовки графиков.
Performance
LCP(в секундах) смотрим в двух проекциях:
ЦП и Сеть — Без ограничений
ЦП — замедление 6х, Сеть — Медленный 3G
Скорость загрузки скрипта GTM (в секундах) с контейнером, наполненным тегами.
Lighthouse
First meaningful paint (в секундах). Он измеряет время в секундах между моментом, когда пользователь инициировал загрузку страницы, и моментом, когда на странице отображается основной объем содержимого. Чем больше секунд требуется для полной загрузки, тем хуже.
Time to interactive (в секундах). Он измеряет, сколько времени требуется странице, чтобы стать полностью интерактивной. Страница считается полностью интерактивной, когда:
на странице отображается полезный контент
страница реагирует на взаимодействие с пользователем в течение 50 миллисекунд
Grafana:
Largest Contentful Paint (в секундах). Она измеряет, как быстро отрисовывается основной контент на первом экране.
Player Ready. Искусственная метрика, измеряет время от начала загрузки страницы до готовности плеера к проигрыванию контента (отрисовки контроллов).
Подробнее об искусственной метрике Player Ready – на данный момент, чтобы улучшить метрику LCP на карточке контента в Иви отрисовывается не сам плеер с контроллами, а постер. И из-за особенностей работы WV мы создали синтетическую метрику, чтобы видеть когда на самом деле отрисован и готов к работе плеер с контроллами.
First Input Delay (в секундах). Метрика измеряет время отзывчивости сайта.
First Contentful Paint (в милисекундах). Улучшенная версия FMP, взяли для подтверждения результатов из Lighthouse.
dom_complete (в милисекундах). Метрика показывает время готовности DOM к взаимодействию.
dom_content_loaded (в милисекундах). Служит для измерения продолжительности обработки
DOMContentLoadedсобытий.dom_interactive (в милисекундах). Метрика служит для регистрации времени завершения построения DOM и возможности взаимодействия с ним. Это свойство передает когда построение DOM завершено и возможно взаимодействие с ним из JavaScript.
dom_load_time (в милисекундах). Показывает время построения DOM.
Подробнее о каждом этапе
Этап 1. Замер метрик веба с включенным и отключенным GTM
Цель: Получение данных по влиянию GTM на сайт. А также эти замеры будут отправной точкой для дальнейшего подсчета результата.
Для справки: Асинхронные сценарии имеют вес.
GTM и dataLayer используют асинхронные сценарии загрузки тегов. Асинхронные сценарии загружаются одновременно с содержимым веб-страницы и не блокируют его. Однако загрузка сценариев требует ресурсов компьютера, а значит выполнение файлов веб-сайта замедляется.
Подтверждение этому можно увидеть в результатах нашего эксперимента на этом этапе.
Подробности: Сам контейнер GTM вызывает минимальную задержку, иногда даже совсем незаметную. Получается, что влияние на метрики страницы происходит, когда вы что-то вкладываете в свой контейнер. Это можно легко отследить при просмотре результатов с включенным и выключенным Google Tag Manager на сайте.
Мы замеряли одни и те же метрики на 3х разных страницах:
Главная
Каталог "Сериалы"
Карточка контента (страница просмотра любого фильма, далее КК)
Дополнительно также проверяли мировую версию сайта.
Результаты этапа:
LCP с замедлением по ЦП 6х и сетью 3G снизилось:
На Главной 150 с снизилось до 47,62 с
На странице каталога с 192 с до 72 с
На графиках Player Ready и Dom Timings в Grafana были заметны явные улучшения во время отключения GTM:
Такие метрики как dom_interactive, dom_content_loaded улучшились.
dom_interactive с 1,3 стала 1,2,
dom_content_loaded с 1,7 стала 1,5.
Метрика dom_complete ожидаемо улучшилась из-за "исчезновения" прогрузки скрипта контейнера GTM на странице. Значение dom_complete до отключения было 6,4, а при отключении 1,9.
Значение метрики Player Ready на КК незначительно улучшилась за счет улучшения метрики dom_interactive. Было до отключения 2,4, а во время отключения 2,2. Что является совсем незначительным улучшением для статистики, но явно заметным для пользователя.
Обнаружили улучшения при замерах в Lighthouse на мировой версии сайта, что скорее всего объясняется тем, что на мировой версии у нас находится большее количество тегов.
Улучшение метрики FMP не было подтверждено в Grafana:
Значение метрики FMP на странице каталога "Сериалы" было 1,2, а после отключения стало 1,3. Также на единичной КК до начала 1,7, а во время отключения 1,3.
Метрика TTI показала явные улучшения, ведь до отключения была 2,7, а во время эксперимента стала 1,7. Также на единичной КК до отключения 3,3, а при отключении 1,8.
Этап 2 и 3. Аудит и удаление тегов в GTM
Цель: Очистить контейнер от "мусора" и подтвердить теорию о возможности оптимизировать метрики веба альтернативным способом — аудит контейнера в GTM.
Подробности: 91% тегов в контейнере был удален, что могло сказаться на метриках.
Результаты этапа:
Отчет об имеющихся тегах до и после удаления:
ДО:
всего тегов в контейнере - 503
активны - 140
приостановлены - 363
ПОСЛЕ:всего тегов в контейнере - 44
активны - 44
приостановлены - 0
Для справки:
При проведении эксперимента мы столкнулись с мифом о том, что приостановленные теги равны удаленным. Чтобы его развеять и убедиться, что просто приостановить ненужные теги недостаточно, были сняты замеры до (было 140 активных тегов) и после (стало 44 активных тега) приостановки неактуальных тегов. По результатам замеров было видно, что скорость загрузки контейнера не изменилась, следовательно статус тега никак не влияет на сам контейнер и вычислительные процессы, связанные с формированием переменных, после смены статуса никуда не деваются.
Порядка 363 тегов в статусе "приостановлено" были неактуальны. Также из 140 активных тегов 96 было неактуальных, а значит, что более 90% контейнера было заполнено тегами, которые занимали место и утяжеляли контейнер. Что приводило к увеличению времени загрузки скрипта на странице и замедлению файлов веб сайта. Влияние тегов на сайт позволяет отследить снижение некоторых значений метрик снятые до и после удаления неактуальных тегов:
Замер времени загрузки скрипта GTM с основным контейнером без ограничений по ЦП и сети:
На Главной странице Иви показал среднее значение 0,5 с до удаления неактуальных тегов и 0,49 с после
На странице каталога "Сериалы" показал среднее значение 0,52 с до и 0,38 с после
Замер времени загрузки скрипта GTM с основным контейнером с замедлением по ЦП 6х и сетью 3G(Slow):
На Главной странице Иви показал среднее значение 21,8 с до удаления и 22,44 с после
На странице каталога «Сериалы» показал среднее значение 11,4 с до и 11,75 с после
На карточке контента показал среднее значение 12,29 с до удаления тегов и 10 с после
Замер LCP с замедлением по ЦП 6х и сетью 3G(Slow):
На Главной странице Иви показал среднее значение 150 с до очистки контейнера и 78 с после
На странице каталога «Сериалы» показал среднее значение 192 с до удаления лишнего и 72 с после
Также было заметно на графике в Grafana небольшое уменьшение метрики Player Ready на КК, среднее значение показало снижение с 2,111 с до 2,048 с. Но, к сожалению, на саму метрику LCP на КК это повлияло незначительно. Но несмотря на то, что 0,063 — маленькое снижение, это классно аффектит на пользователя, ведь основной контент (для КК это плеер) стал отрисовываться чуть быстрее на первом экране.
Делаем выводы
Скорость загрузки скрипта GTM с основным контейнером напрямую зависит от наполнения взятого контейнера. При удалении лишних данных и сокращении неактуальных тегов показатели приблизились к данным при отключенном GTM.
К сожалению, большинство метрик в Grafana не показало явных результатов и находилось в пределах своих обычных колебаний, т.к. нашей заполненности контейнера не хватило для получения явных результатов.
Снижение количества неактуальных тегов до минимума хорошо показывает себя для пользователей с плохими показателями машин и интернета.
Снижение метрики Player Ready на КК доказывает, что альтернативный способ работы с метриками веба через аудит GTM реален.
По получению опыта в снятии метрик с использованием инструмента Lighthouse, хотелось бы предупредить, что метрики, снятые здесь, нуждаются в подтверждении через более устойчивые инструменты. Lighthouse является несомненно удобным и классным инструментом, но, к сожалению, сильно зависит от вашей сети и от вашей машинки. Поэтому в случае повторения нашего эксперимента, помните выражение "доверяй, но проверяй". В ином случае советуем замерять по 10-15 раз.
Заключение
И в заключении хотелось бы сказать, что поиск альтернативных методик улучшение метрик — это интересное и трудоёмкое занятие. С учетом первого пункта в блоке "Делаем выводы" было принято решение об увеличении частоты проводимых очисток в GTM для поддержания достигнутых значений метрик. Хотя это не принесло баснословных результатов, нам кажется, что такой опыт стоит передать другим и, конечно же, не останавливаться на достигнутом и дальше пробовать улучшать метрики не только привычными нам способами.
В общем попрощаемся как обычно, не стойте на месте, с удовольствием изучайте новое и улучшайте себя! До новых встреч на Хабре!
