Google Analytics приводит к сбою основных веб-показателей: следующие шаги

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

Google Core Web Vitals — официальный показатель того, насколько приятен ваш веб-сайт реальным пользователям. Он представляет собой набор из трех показателей производительности:

• Largest Contentful Paint (LCP) измеряет начальное время загрузки.
• Взаимодействие с следующей отрисовкой (INP) измеряет скорость реагирования.
• Совокупный сдвиг макета (CLS) измеряет стабильность макета.

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

Поэтому стало большой неожиданностью, когда собственная аналитика Google стала причиной неудачных оценок Core Web Vitals.

Давайте расследовать!

Как работает Google Analytics?

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

Этот фрагмент JavaScript, также известный как глобальный тег сайта (gtag.js), помещается в раздел вашего сайта на каждой веб-странице, которую вы хотите отслеживать:

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

Все идет нормально.

Теперь давайте посмотрим, что происходит под капотом.

Влияние на производительность (пристальный взгляд)

При ближайшем рассмотрении с отключенным кешем и без активной оптимизации производительности мы видим, что gtag.js загружается как один HTTP-запрос весом всего 111 КБ вместе с gtag Microsoft Clarity размером 769 КБ.

Что касается начальной загрузки страницы, код отслеживания Google Analytics отображает ожидаемое поведение и не способствует чрезмерным HTTP-запросам, неиспользованному JavaScript или блокировке основного потока.

Откуда же тогда это заблуждение?

Действительно ли Google Analytics влияет на основные веб-показатели?

Добавление отслеживания Google Analytics на ваш веб-сайт само по себе не рискует провалить оценку Core Web Vitals (или, в частности, Lagest Contentful Paint). Это просто потому, что фрагмент, помещенный в заголовок веб-страницы, чрезвычайно легок и не блокирует ни один из жизненно важных процессов при отображении содержимого страницы.

Итак, почему владельцы сайтов связывают неудачные основные веб-показатели с Google Analytics?

Разница между лабораторными и полевыми данными

Наш опыт показывает, что по-прежнему существует значительное недопонимание, когда дело доходит до чтения отчетов Google PageSpeed. Главным образом из-за того, как отчет менялся с течением времени.

Давайте проясним путаницу.

После внедрения Core Web Vitals команда Google усердно работала над тем, чтобы переключить внимание на то, что мы называем «полевыми данными», которые теперь отображаются в самом верху вашего отчета как оценка Core Web Vitals.

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

Оценка Core Web Vitals на основе полевых данных для amazon.com

До того, как Google Core Web Vitals стал стандартом для обеспечения максимального удобства пользователей, мы полагались на показатель производительности (измеряется от 0 до 100), который теперь отображается после оценки CWV.

Оценка производительности на основе лабораторных данных для amazon.com.

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

Как вы можете видеть на скриншотах выше, Amazon с честью проходит основные веб-показатели, но в контролируемой среде проблемы с общим временем блокировки (TBT), индексом скорости (SI) и LCP помечаются для дальнейшего улучшения. Это отличный способ изолировать конкретные проблемы и поработать над их оптимизацией.

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

Окончательный вердикт

В заключение, если у вас не работают основные веб-показатели, вряд ли причиной может быть отслеживание Google Analytics. Вместо этого убедитесь, что вы читаете не лабораторные результаты, а полевые, и прокрутите отчет PSI еще раз, чтобы изучить разделы «Возможности» и «Диагностика».

А как насчет Диспетчера тегов Google и Google AdSense?

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

Диспетчер тегов Google и Google AdSense — популярные инструменты для онлайн-бизнеса, которые хотят отслеживать определенные события и размещать рекламу на своих веб-сайтах для получения дополнительного дохода от входящего трафика.

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

Используя наш предыдущий пример с kiteworks.com , мы видим, что при взаимодействии с домашней страницей из Диспетчера тегов запускается цепочка дополнительных тегов событий (gtm.js).

А это много лишних тегов gtm.js, отсюда и чрезмерное количество HTTP-запросов.

Поскольку код Google Analytics загружается раньше всего остального, и когда на вашем веб-сайте много тегов событий, вы можете ожидать, что фрагмент GA будет вызывать все остальные gtm.js, что приведет к задержкам загрузки и ухудшению результатов в таких показателях, как:

• Самая большая содержательная краска
• Общее время блокировки
• Первая содержательная краска (FCP)

В вашем отчете PSI такая строка будет помечена предупреждением «Уменьшить неиспользуемый JavaScript»:

И если ваш Диспетчер тегов Google выглядит примерно так, пришло время навести порядок и реорганизовать:

Исправление «Уменьшения количества неиспользуемого JavaScript», вызванного диспетчером тегов Google

Ваш первый шаг — задержать сторонние скрипты с атрибутами async или defer и позволить им загружаться в фоновом режиме. Эти атрибуты по сути превращают скрипты в неблокирующие и снижают общее влияние стороннего кода.

Несмотря на схожесть, эти атрибуты имеют важные различия:

• Скрипты с атрибутом defer сохраняют свой относительный порядок. Браузер не ждет, пока они отобразят страницу, а выполняет их по порядку. Например, у нас есть два сценария — сценарий 1 и сценарий 2 — именно в таком порядке. Если мы отложим оба варианта, браузер всегда будет сначала выполнять сценарий 1, даже если сначала был загружен сценарий 2.
• Скрипты с атрибутом async полностью независимы. То, что загружается первым, выполняется первым.

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

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

Сократите количество неиспользуемого JavaScript и оптимизируйте все ресурсы вашего сайта с помощью NitroPack →

Риски и компромиссы с Google AdSense

Когда владельцы сайтов размещают на веб-странице рекламные блоки в различных форматах, Google AdSense предоставляет фрагменты кода (HTML/JavaScript) для каждого рекламного блока, которые вставляются в HTML-код страниц их веб-сайта, где должны появляться объявления.

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

К сожалению, из-за своей способности блокировать рендеринг объявления AdSense могут влиять на производительность сайта (и особенно на веб-показатели, такие как LCP и CLS).

С помощью NitroPack владельцы сайтов могут выбрать «Оптимизировать рекламу», при этом JS будет задерживаться до взаимодействия с пользователем. Но поскольку AdSense работает на основе показов, это может привести к некоторым потерям доходов от рекламы.

В этом случае, исходя из поведения вашей аудитории, вам следует решить, что выгоднее для вашего бизнеса:

1) оптимальная производительность для лучшего просмотра

или

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

Часто задаваемые вопросы

Стоит ли использовать Google Analytics на собственном хостинге?

Хотя некоторые владельцы сайтов рассматривают возможность самостоятельного размещения отслеживания Google Analytics для достижения оптимальных основных веб-показателей, в этом нет особой необходимости. Вместо усложнения, затрат и потенциальных ограничений по сравнению с использованием инфраструктуры Google сосредоточьтесь на оптимизации событий Диспетчера тегов Google для соответствия стандартам Core Web Vitals.