Оптимизация метрик веба через аудит в Google Tag Manager: реальность или вымысел?

После внедрения процесса тестирования рекламных тегов на сайте из инструмента аналитики, 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 — маленькое снижение, это классно аффектит на пользователя, ведь основной контент (для КК это плеер) стал отрисовываться чуть быстрее на первом экране.

Делаем выводы

1. Скорость загрузки скрипта GTM с основным контейнером напрямую зависит от наполнения взятого контейнера. При удалении лишних данных и сокращении неактуальных тегов показатели приблизились к данным при отключенном GTM.

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

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

4. Снижение метрики Player Ready на КК доказывает, что альтернативный способ работы с метриками веба через аудит GTM реален. 

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

Заключение

И в заключении хотелось бы сказать, что поиск альтернативных методик улучшение метрик — это интересное и трудоёмкое занятие. С учетом первого пункта в блоке «Делаем выводы» было принято решение об увеличении частоты проводимых очисток в GTM для поддержания достигнутых значений метрик. Хотя это не принесло баснословных результатов, нам кажется, что такой опыт стоит передать другим и, конечно же, не останавливаться на достигнутом и дальше пробовать улучшать метрики не только привычными нам способами.

В общем попрощаемся как обычно, не стойте на месте, с удовольствием изучайте новое и улучшайте себя! До новых встреч на Хабре!