Отложенное подключение Яндекс.Метрики: есть ли реальная польза?

В этой статье рассмотрим, насколько отложенное подключение Яндекс.Метрики — целесообразное мероприятие. Рассмотрим сценарии для разных сайтов: лендинг, блог, интернет-магазин

Лендинг (одностраничный сайт)

Одностраничные сайты обычно нацелены на быструю конверсию и часто получают трафик из рекламы. Для них и доли секунды задержки имеют значение: пользователю должны мгновенно показаться ключевые элементы. Отложенная загрузка Метрики способна немного ускорить визуальную отдачу страницы, убрав лишний запрос в начале. Поэтому на лендингах, ориентированных на максимальный PageSpeed Score и мгновенный LCP, можно рассмотреть ленивую загрузку. Например, загрузить счетчик через setTimeout спустя 0.5–1 секунду после Onload или при первом скролле/клике пользователя.

var fired = false;
 
window.addEventListener('scroll', () => {
    if (fired === false) {
        fired = true;
        
        setTimeout(() => {
            // Сюда вставляете метрики без тегов <script>           
        }, 1000)
    }
});

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

Минус в том, что рекламодателю важно знать точный процент таких мгновенных отказов, чтобы оценивать эффективность канала трафика. Потеря данных по незаинтересованным посетителям может помешать оптимизации рекламной кампании. Поэтому для критически важных сайтов (где каждое посещение на счету) чаще рекомендуется не откладывать Метрику, а ставить ее стандартно. Если же скорость превыше всего (например, лендинг участвует в AMP-экспериментах или нужно максимально поднять Mobile Speed Score для Google Ads), то откладывать счетчик можно – но с минимальной задержкой и тщательной проверкой, что все целевые действия (клики по CTA, отправка формы) все равно попадают в аналитику.

Контентный сайт или блог. На информационных сайтах, новостях, блогах – особенно без монетизации трафика – точность веб-аналитики не так критична для дохода, как на коммерческих ресурсах. Здесь упор делается на опыте читателя и SEO. Многие такие сайты стремятся к максимальной скорости, чтобы не отпугивать посетителей и получить бонусы в поисковой выдаче.

Ленивая загрузка Метрики для блога – вполне оправданный шаг, если основная задача – ускорить отображение статьи. Пользовательский контент (текст, изображения) гарантированно загрузится без вмешательства сторонних скриптов, а Метрика подключится чуть позже и соберет данные о тех, кто действительно начал потреблять контент (прокрутил страницу, задержался более пары секунд). Потеря данных о мгновенных уходах для блога не смертельна: важно количество прочтений, глубина, время на странице у заинтересованных читателей.

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

Интернет-магазин (e-commerce). В интернет-магазине на первый план выходят транзакции и конверсия. Каждый этап воронки (просмотр товара, добавление в корзину, переход к оформлению) отслеживается, и потеря данных даже о части пользователей может осложнить оптимизацию продаж. Кроме того, e-commerce сайты обычно перегружены внешними скриптами: здесь и аналитика, и пиксели ремаркетинга, и A/B-тестеры, и виджеты отзывов – экономия на одном счетчике погоды может не сделать.

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

Если магазин и так тяжелый, лучше работать над основными причинами медлительности (например, оптимизировать фотографии товара, внедрять CDN, lazy-load для отзывов и пр.). Стандартная Метрика унесет доли секунд, но даст полный обзор на поведение покупателей. К тому же Метрика в интернет-магазинах часто используется для E-commerce отчетов, фильтров сегментации, ретаргетинговых сегментов – это все требует максимально полного сбора данных.

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

Плюсы и минусы каждого способа

Стандартное подключение (по инструкции Яндекса, код в <head> или сразу в HTML):

• Плюсы: Простота и надежность – вставили готовый код, и всё работает. Официальный скрипт асинхронный, не блокирует страницу и не влияет на скорость загрузки сайта​. Обеспечивает максимально полный сбор данных: фиксируются все заходы (включая самые короткие) и все действия пользователей. Яндекс прямо заявляет, что обновленный код собирает больше коротких визитов, делая статистику точнее​. Показатель отказов и время на сайте рассчитываются корректно. Вебвизор, карты кликов, аналитика форм и прочие функции Метрики работают с начала сессии, давая полную картину пользовательского поведения. Нет риска пропустить срабатывание целей или событий – все аналитические события на странице будут отправлены. Код полностью поддерживается Яндексом, при проверке счетчика в Метрике он сразу обнаруживается без дополнительных действий. Наконец, вам не нужно тратить время на реализацию своего решения – следуя инструкции, вы получаете оптимизированный код, который Яндекс обновляет и улучшает автоматически (например, при переходе на Webvisor 2.0 это произошло без смены кода на сайте).
• Минусы: Наличию дополнительного скрипта на странице – пусть даже асинхронного – это всё же лишняя загрузка. Стандартный код добавляет один внешний запрос (к mc.yandex.ru) и небольшое выполнение JS. На быстрых соединениях и современных устройствах это практически незаметно, но на сверхмедленном интернете или устаревшем смартфоне каждый килобайт на счету. Lighthouse может снизить итоговый балл, указывая на присутствие стороннего кода (Яндекс.Метрики) и советуя “уменьшить влияние стороннего JS”. В метриках типа Total Blocking Time может появиться небольшое время, отведенное на выполнение кода Метрики (например, инициализация заняла условные 20-30 мс). То есть формально добавляется нагрузка на главный поток, хоть она и очень мала. Еще момент – пользователи с блокировщиками рекламы нередко блокируют и Я.Метрику; в таком случае все равно часть аудитории не будет учтена (но это справедливо и для отложенной загрузки – AdBlock заблокирует скрипт независимо от способа вставки). Из других минусов: некоторые проверки PageSpeed отмечают unused JavaScript, то есть Метрика может попасть в список того, что не используется при загрузке (ведь аналитика – не необходимый для рендеринга функционал). Впрочем, это скорее косметический нюанс оценки.

Отложенная (ленивая) загрузка Метрики:

• Плюсы: Позволяет устранить из критического пути загрузки еще один скрипт, за счет чего улучшаются показатели скорости отображения. В первые мгновения страница грузит только свой контент, а Метрика подключается позже – это дает выигрыш в FCP/LCP на тестах и снижает нагрузку на основной поток во время начальной отрисовки​. Пользователь быстрее получает интерактивный интерфейс. В отчете PageSpeed Insights уменьшается влияние стороннего кода: лениво загруженная Метрика не учитывается Lighthouse при расчете производительности, что может повысить балл (особенно на мобильном устройстве). Также откладывание выполнения скрипта немного сокращает Total Blocking Time, поскольку браузеру не нужно обрабатывать код счетчика до тех пор, пока вы сами не инициируете его загрузку. Итог – легче добиться «зеленой зоны» по Core Web Vitals и удовлетворить требования Google по скорости. Это особенно полезно, когда сайт нагружен разными аналитиками: суммарный эффект от их откладывания заметнее. Еще один плюс – снижение конкуренции за трафик при загрузке: одно дело, когда сразу стартуют запросы к нескольким аналитическим сервисам, и другое – когда сначала грузится только ваш контент, а через секунду – все счетчики. На медленном 3G отложка может немного ускорить появление основного контента, что положительно сказывается на UX.
• Минусы: Главный минус – неполнота собираемой статистики. Как мы разобрали выше, часть визитов не попадет в аналитику. Это делает показатели (особенно процент отказов) неточными. Вы можете увидеть улучшение метрик вовлеченности, но фактически оно будет вызвано потерей данных о самых нетерпеливых пользователях, а не реальным изменением поведения аудитории. Кроме того, Вебвизор не запишет первые секунды сессии (а если визит очень короткий – не запишет вообще ничего). Если пользователь закрыл страницу раньше, чем Метрика загрузилась, вы не узнаете об этом визите вовсе. Для маркетинга и UX-анализа это упущение: например, может казаться, что никто не уходит сразу, хотя на самом деле такие уходы есть, просто они не учитываются. Срабатывания целей до загрузки счетчика будут потеряны. Отложенную загрузку нужно очень тщательно вписывать в логику сайта: разработчику приходится писать дополнительный скрипт, слушать события (scroll, mousemove и т.п.), отслеживать, чтобы Метрика не загрузилась дважды, обрабатывать таймауты-фолбэки для тех, кто совсем не взаимодействует. Этот код сам по себе может стать источником ошибок, если его неправильно реализовать. К примеру, не все задумываются, что робот Яндекса, проверяющий установку счетчика, не будет эмулировать прокрутку. В готовых решениях эту проблему обходят: например, есть рекомендация не откладывать Метрику для «ЯндексBot», чтобы в панели Метрики горел зеленый индикатор​. Подобные тонкости усложняют внедрение. И еще: перенос загрузки не уменьшает объем кода. Скрипт все равно загрузится полностью (просто позже), то есть реальная экономия по трафику или времени работы движка отсутствует​. Если пользователь остается на странице достаточно долго, ваш сайт в итоге выполнит тот же объем работы, просто с задержкой. С точки зрения итогового потребления ресурсов за сессию, вы ничего не выиграли.

Выводы: когда какой метод лучше

1. Когда важна полная и точная аналитика – подключайте Метрику стандартно, без отложек. Если вы активно пользуетесь данными счетчика (анализируете поведение для SEO, считаете ROI рекламных каналов, смотрите записи Webvisor для улучшения юзабилити и т.п.), то точность данных критически важна. В таких случаях даже небольшая потеря информации нежелательна. Интернет-магазины, сервисы с авторизацией, высококонверсионные лендинги – во всех них лучше установить код Метрики по инструкции Яндекса, чтобы собирать максимум данных о пользователях. Скорость работы текущего асинхронного кода уже оптимизирована и не мешает загрузке​, а вот упущенные визиты или цели могут дорого обойтись. Многие специалисты прямо говорят, что ради такой мизерной выгоды в скорости жертвовать аналитикой не стоит​.
2. Когда на первом месте скорость и высокие показатели PageSpeed – можно использовать отложенную загрузку, но осторожно. Для лёгких промо-страниц, личных блогов, лендингов без сложной воронки продаж допустимо лениво подключать Метрику. Если цель – максимально ускорить загрузку и получить 100/100 в тестах, отложка счётчика поможет убрать последние «красные флажки» Google PSI. Однако важно не перестараться: делайте минимальную задержку. Практика показывает, что откладывать более чем на 1 секунду опасно – счетчик может не успеть собраться с данными​. Начните с 100–500 мс или с первого взаимодействия пользователя, этого достаточно, чтобы вынести Метрику за пределы метрик LCP/FID. Обязательно убедитесь, что при таком подходе все важные цели всё равно фиксируются (например, если у вас цель на клик по кнопке – вставьте загрузку счетчика до кода обработки клика). Отложенную загрузку стоит применять, только когда вы осознаете последствия и согласны с тем, что часть статистики будет упущена ради выигрыша в скорости.
3. Компромиссные варианты. Необязательно писать сложный код, чтобы немного отложить Метрику. Можно, например, поместить стандартный код в самый конец <body> – тогда он выполнится после основного контента. Или подключить файл tag.js через <script defer> без inline-инициализации (правда, тогда нужно самостоятельно вызвать ym(id, "init", ...) после загрузки). Такой подход проще и безопаснее: счетчик стартует автоматически, просто чуть позже, и при этом не требует ловить события. В PageSpeed Insights скрипт с defer уже не считается блокирующим и меньше влияет на оценки. Если вы не гонитесь за идеальными 100 баллами, а хотите просто ускорить сайт без потери данных – лучше выбрать такой компромисс, чем сложную ленивую загрузку.

В заключение: стандартный способ подключения подходит в большинстве случаев – он надежный, поддерживает все возможности Метрики и минимально влияет на скорость страницы. Отложенная загрузка – это нишевое решение для случаев, когда каждая миллисекунда на вес золота и можно пожертвовать частью данных. Используйте ее осознанно и тестируйте: сравните показатели отказов до и после, убедитесь, что важные для вас метрики не “сломались”. Помните, что Яндекс.Метрика – уже довольно легкий и умный скрипт​, и выигрыши от его откладывания часто измеряются долями секунды, тогда как стоимость потерянной информации может быть высока. Таким образом, если сомневаетесь, скорее всего лучше оставить стандартное подключение Метрики – так вы гарантированно получите полные данные и спокойствие, что аналитика отражает действительность. А вопросы скорости можно решать другими методами, не урезая наблюдательность вашего счетчика.​

P.S.: Текст оформлен при помощи нейросети. Авторский опыт, выводы и позиция — личные.