Скрипт счётчика Яндекс Метрики весит около 93 килобайт и по умолчанию стартует в том же окне, где браузер рисует первый экран. Мы подняли его после отрисовки страницы: по событию полной загрузки, но раньше, если посетитель уже скроллит или нажимает, чтобы не потерять быстрые действия. Отдельно выключили Вебвизор, который добавлял ещё один скрипт и служебный кадр - суммарно около 108 килобайт в шести запросах, а клик по кнопке согласия поднимает счётчик сразу, потому что страница к этому моменту уже отрисована.
Вопрос обычно всплывает не заранее, а после того, как владелец сайта открывает отчёт о скорости и видит счётчик аналитики в списке того, что тормозит первый экран. Код Метрики вставляют в head по инструкции из личного кабинета, и там он честно работает - просто ценой части бюджета загрузки, который мог бы уйти на сам контент. На домашнем wifi разница незаметна, на мобильном интернете превращается в лишние доли секунды до того, как человек увидит текст.
Как счётчик оказывается в критическом пути
Браузер строит страницу в том порядке, в котором встречает ресурсы в HTML. Если тег Метрики стоит в head перед стилями и шрифтами, браузер сначала запрашивает и выполняет его, а потом продолжает разбирать остальной документ. Для скрипта весом 93 килобайта это не бесплатно даже на приличном соединении. На мобильном - тем более.
У нас в практике был разбор со стартовым результатом мобильный PageSpeed 69: в том отчёте счётчик аналитики стоял в списке ресурсов, которые блокируют отрисовку, наравне со шрифтами и несжатыми стилями. Убрать его из этого списка можно одним способом - перестать грузить сразу.
Стоит сверяться и с общим списком техник ускорения: часть приёмов для картинок и шрифтов из статьи как ускорить сайт до 1,5 секунды работает по тому же принципу - убрать из первого экрана всё, что не нужно для самого первого кадра, и вернуть это чуть позже.
Три способа отложить старт и почему нужны все сразу
Событие полной загрузки. Самый простой вариант - подписаться на load и запускать счётчик после него. Предсказуемо работает, но если страница тяжёлая и load наступает поздно, аналитика стартует позже, чем хотелось бы.
Первое действие посетителя. Скролл, клик, нажатие клавиши - любое из этих событий может поднять счётчик раньше load, если человек начал взаимодействовать со страницей до того, как она полностью догрузилась. Это подстраховывает от случая, когда посетитель уходит за секунду до load и вовсе не попадает в статистику.
Таймер как страховка. Отдельный отложенный запуск на несколько секунд на случай, если не сработали ни load, ни действие - например, человек читает статью и никак не взаимодействует со страницей минуту-другую.
По отдельности любое из трёх условий оставляет дыру. Событие загрузки без остального теряет быстрые уходы, действие без остального теряет пассивных читателей, таймер без остального превращается в фиксированную задержку без всякой связи с реальным поведением. Вместе они закрывают почти все сценарии, а счётчик стартует по первому из трёх событий, какое наступит раньше.
Что теряется при отложенном старте
Часть очень коротких визитов не попадает в статистику вовсе: если человек закрыл вкладку раньше, чем сработало любое из трёх условий, визит для Метрики просто не случился. На обычных визитах, где посетитель проводит на странице хотя бы несколько секунд, разница почти не заметна.
Смещается и время на странице: отсчёт для Метрики начинается не с момента открытия страницы, а с момента запуска счётчика. На коротких визитах это искажает метрику заметнее, чем на длинных. Прежде чем полагаться на такие данные для целей и конверсий, стоит свериться с настройками из статьи про цели в Яндекс.Метрике - там разбирали, какие события считать конверсией и как их не терять.
Сравнить отчёты за пару недель до переноса счётчика и после - самый прямой способ увидеть реальный эффект. Если число визитов и конверсий заметно просело именно в сегменте очень коротких сессий, это ожидаемо и объяснимо переносом, а не поводом для тревоги. Если просело всё подряд, вероятно, дело не в отложенном старте, а в чём-то другом.
Где граница разумного
Бесконечно откладывать счётчик не стоит: чем дальше сдвигается старт, тем больше визитов рискует пропасть из статистики целиком, а не просто сместиться по времени на странице. Разумный ориентир - секунды, а не десятки секунд: событие загрузки обычно наступает быстро, а таймер-страховка ставится с запасом в пять-десять секунд, не больше.
Скорость страницы и полнота данных аналитики тянут в разные стороны, и универсально правильной точки здесь нет. Для сайта с высокой ценой заявки, где каждый пропущенный визит заметен на воронке продаж, лучше держать таймер короче. Для контентного проекта, где важнее скорость чтения, можно позволить себе задержку побольше. Скорость страницы официально входит в число факторов, которые Google учитывает при оценке качества страницы для поиска - подробности в документации Google Search Central, поэтому счётчик стоит откладывать на секунды, а не на десятки секунд.
Cookie-баннер и почему решение нельзя принять на сервере
Запуск счётчика у нас завязан на скорость и на согласие посетителя на cookie. Логично было бы решать на сервере: если посетитель раньше отказался, вообще не печатать код счётчика в HTML. На практике эта развилка ломается о кэш страниц - многие сайты отдают одну и ту же собранную HTML-страницу всем посетителям подряд, и в кэше застынет решение того, кто зашёл первым.
Поэтому разметка всегда одинаковая: счётчик и код баннера присутствуют в HTML у всех, а решение - грузить ли аналитику - принимает уже браузер конкретного посетителя: он смотрит на cookie с согласием и решает сам. Подробный разбор вариантов cookie-баннера и того, что требует закон, есть в статье про cookie-баннер на сайте. Отложенный старт по событию загрузки и решение о согласии - это две независимые развилки, которые в коде удобно свести в одну точку: счётчик поднимается либо когда наступило нужное событие и согласие уже дано, либо сразу в момент, когда посетитель нажимает "принять".
Вебвизор - самая тяжёлая часть
Если базовый скрипт счётчика весит около 93 килобайт, то включённый Вебвизор добавляет к этому ещё один скрипт и служебный кадр синхронизации - в сумме порядка 108 килобайт в шести дополнительных запросах. Для сайта с мобильным трафиком это заметная добавка сверх и так небесплатного счётчика. На десктопе почти не видно.
Мы Вебвизор в постоянном режиме не держим. Он даёт записи сессий и карты кликов, которые реально полезны, когда разбираешь конкретную гипотезу - например, почему форма на определённой странице теряет заполнения. В остальное время эта нагрузка ложится на всех посетителей ради задачи, которая не решается прямо сейчас.
Чек-лист: как перенести счётчик у себя
- Снять текущий результат отчёта о скорости и отметить, где в списке стоит счётчик аналитики.
- Проверить, где в HTML стоит код Метрики - в head или ближе к концу страницы, это меняет масштаб проблемы.
- Добавить условие запуска по трём событиям: load, первое действие посетителя, таймер-страховка на несколько секунд.
- Свести это с логикой cookie-баннера: запуск только после согласия и только когда сработало одно из трёх условий отложенного старта.
- Решить, нужен ли Вебвизор постоянно, или включать его точечно на время конкретного разбора.
- Через одну-две недели сравнить отчёты по визитам и целям с прежним периодом. Если аналитика встроена в более широкий контур - например, как в статье про сквозную аналитику - проверить, что данные из Метрики по-прежнему корректно попадают в остальные отчёты.
- Зафиксировать итоговую разницу в отчёте о скорости и приложить её к общему списку изменений.
Что осталось в критическом пути после переноса счётчика
После переноса счётчика в критическом пути первого экрана остаются только стили, шрифты и разметка самой страницы - аналитика туда больше не попадает вообще. 93 килобайта скрипта и до 108 килобайт Вебвизора сверху больше не входят во время до отрисовки: они догружаются позже, когда страница уже показана человеку. Статистика при этом почти не меняется - теряется небольшая часть самых коротких визитов, а данные по целям и конверсиям остаются рабочими. Решение простое технически, но требует свести вместе три вещи сразу: событие запуска, согласие на cookie и режим Вебвизора. После этого к правке обычно не возвращаются.
Если планируете новый сайт или доработку текущего, прикиньте порядок бюджета в калькуляторе стоимости: он считает вилку по типу сайта и набору опций, а работу со скоростью можно обсудить отдельно на этапе технического задания.
