После внедрения процесса тестирования рекламных тегов на сайте из инструмента аналитики, GTM (предыдущая статья), мы задумались каких ресурсов он нам стоит, как уменьшить влияние GTM, и сформулировали гипотезу, что посредством аудита тегов можно улучшить метрики веба. Помимо этого мы хотели бы узнать:
Правда ли то, что ассинхронные сценарии настолько легкие для веба?
Правда ли то, что приостановленные теги == удаленным?
Этапы эксперимента и наши выводы читайте ниже. Будем рады, если в комментариях вы поделитесь своими мнениями, идеями или опытом. Давайте обсудим вместе!
Всем привет. Над экспериментом работали я — Даша, инженер по тестированию на платформе web в Иви, и Амина, контентный data-аналитик Иви. Мы расскажем вам, как пробовали оптимизировать метрики веба с помощью аудита в GTM и предоставим план эксперимента, на случай, если вы решите провернуть это у себя.
![](https://habrastorage.org/getpro/habr/upload_files/b47/4c5/651/b474c5651b912c5e3cfce03379f0c3d4.png)
Точка С - "Эксперимент"
За последние полтора года платформа веб в Иви много работала над улучшением метрик: был проведен ряд работ для оптимизации метрик, и после мы также не переставали трудиться, чтобы 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. Что является совсем незначительным улучшением для статистики, но явно заметным для пользователя.
![График показателей на домене ru до и во время отключения GTM График показателей на домене ru до и во время отключения GTM](https://habrastorage.org/getpro/habr/upload_files/f51/903/583/f519035835b53ade6ecf3788ba8c293a.png)
Обнаружили улучшения при замерах в Lighthouse на мировой версии сайта, что скорее всего объясняется тем, что на мировой версии у нас находится большее количество тегов.
-
Улучшение метрики FMP не было подтверждено в Grafana:
Значение метрики FMP на странице каталога "Сериалы" было 1,2, а после отключения стало 1,3. Также на единичной КК до начала 1,7, а во время отключения 1,3.
Метрика TTI показала явные улучшения, ведь до отключения была 2,7, а во время эксперимента стала 1,7. Также на единичной КК до отключения 3,3, а при отключении 1,8.
![График показателей на домене tv до и во время отключения GTM График показателей на домене tv до и во время отключения GTM](https://habrastorage.org/getpro/habr/upload_files/84b/2a8/7d2/84b2a87d2813c23640ac13afe8fb68e0.png)
Этап 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 без ограничений по ЦП и сети до и после удаления неактуальных тегов из контейнера Время загрузки скрипта GTM без ограничений по ЦП и сети до и после удаления неактуальных тегов из контейнера](https://habrastorage.org/getpro/habr/upload_files/37a/023/757/37a02375705cf7482b5858725a7d8ec7.png)
-
Замер времени загрузки скрипта GTM с основным контейнером с замедлением по ЦП 6х и сетью 3G(Slow):
На Главной странице Иви показал среднее значение 21,8 с до удаления и 22,44 с после
На странице каталога «Сериалы» показал среднее значение 11,4 с до и 11,75 с после
На карточке контента показал среднее значение 12,29 с до удаления тегов и 10 с после
-
Замер LCP с замедлением по ЦП 6х и сетью 3G(Slow):
На Главной странице Иви показал среднее значение 150 с до очистки контейнера и 78 с после
На странице каталога «Сериалы» показал среднее значение 192 с до удаления лишнего и 72 с после
![Сравнение значений метрики LCP с замедлением по ЦП 6х и сетью 3G(Slow) до/после удаления неактуальных тегов из контейнера, а также при выкл. GTM на странице Сравнение значений метрики LCP с замедлением по ЦП 6х и сетью 3G(Slow) до/после удаления неактуальных тегов из контейнера, а также при выкл. GTM на странице](https://habrastorage.org/getpro/habr/upload_files/033/054/900/03305490061c2d401de076ca7e54e4c1.png)
Также было заметно на графике в Grafana небольшое уменьшение метрики Player Ready на КК, среднее значение показало снижение с 2,111 с до 2,048 с. Но, к сожалению, на саму метрику LCP на КК это повлияло незначительно. Но несмотря на то, что 0,063 — маленькое снижение, это классно аффектит на пользователя, ведь основной контент (для КК это плеер) стал отрисовываться чуть быстрее на первом экране.
![Сравнение значений искусственной метрики Player Ready на КК до и после удаления неактуальных тегов из контейнера Сравнение значений искусственной метрики Player Ready на КК до и после удаления неактуальных тегов из контейнера](https://habrastorage.org/getpro/habr/upload_files/cd7/2b1/56a/cd72b156abfd54d50ac10852225b6193.png)
Делаем выводы
Скорость загрузки скрипта GTM с основным контейнером напрямую зависит от наполнения взятого контейнера. При удалении лишних данных и сокращении неактуальных тегов показатели приблизились к данным при отключенном GTM.
К сожалению, большинство метрик в Grafana не показало явных результатов и находилось в пределах своих обычных колебаний, т.к. нашей заполненности контейнера не хватило для получения явных результатов.
Снижение количества неактуальных тегов до минимума хорошо показывает себя для пользователей с плохими показателями машин и интернета.
Снижение метрики Player Ready на КК доказывает, что альтернативный способ работы с метриками веба через аудит GTM реален.
По получению опыта в снятии метрик с использованием инструмента Lighthouse, хотелось бы предупредить, что метрики, снятые здесь, нуждаются в подтверждении через более устойчивые инструменты. Lighthouse является несомненно удобным и классным инструментом, но, к сожалению, сильно зависит от вашей сети и от вашей машинки. Поэтому в случае повторения нашего эксперимента, помните выражение "доверяй, но проверяй". В ином случае советуем замерять по 10-15 раз.
Заключение
И в заключении хотелось бы сказать, что поиск альтернативных методик улучшение метрик — это интересное и трудоёмкое занятие. С учетом первого пункта в блоке "Делаем выводы" было принято решение об увеличении частоты проводимых очисток в GTM для поддержания достигнутых значений метрик. Хотя это не принесло баснословных результатов, нам кажется, что такой опыт стоит передать другим и, конечно же, не останавливаться на достигнутом и дальше пробовать улучшать метрики не только привычными нам способами.
В общем попрощаемся как обычно, не стойте на месте, с удовольствием изучайте новое и улучшайте себя! До новых встреч на Хабре!
imvitalya
Одна из лучших статьей по теме оптимизации gtm! Благодарю, коллеги)