Удалил Яндекс Метрика | Постоянно глючит | Скорость сразу выросла

Мысль «удалить счётчик ради скорости» приходит в голову почти каждому владельцу сайта, который впервые открыл отчёт PageSpeed Insights и увидел красную зону с упоминанием стороннего скрипта. Кажется, что решение найдено: убираем чужой код, страница взлетает, оценка становится зелёной. На практике после удаления счётчика оценка меняется на единицы, а бизнес теряет единственный источник данных о том, откуда приходят клиенты и сколько стоит заявка. Ниже — честный разбор того, сколько на самом деле весит счётчик, почему он так удобно выглядит виновником, как измерить его вклад без самообмана и что делать вместо удаления.

Что физически загружается вместе со счётчиком

Счётчик Метрики — это небольшой фрагмент кода на странице, который подтягивает внешний файл с домена аналитики и после загрузки отправляет данные о визите. Технически на странице появляются три вещи: инлайн-инициализация в HTML, запрос к стороннему домену за скриптом и последующие сетевые запросы с данными о поведении посетителя.

• Инлайн-фрагмент — несколько сотен байт в исходном коде страницы, величина, которая не влияет ни на что.
• Внешний файл трекера — десятки килобайт в сжатом виде, загружается с CDN аналитики, кешируется браузером.
• Сетевые обращения с данными — короткие запросы, часть из них уходит уже после события load.
• Дополнительные модули — запись сессий, карты кликов и скроллинга, отслеживание форм. Именно они увеличивают и объём кода, и количество запросов.

Ключевой момент: базовый счётчик и счётчик со всеми включёнными модулями записи — это два разных по нагрузке объекта. Когда владелец сайта говорит «Метрика тормозит», в половине случаев речь идёт о вебвизоре, который непрерывно пишет действия пользователя и шлёт данные на сервер во время просмотра страницы.

Блокирующая и отложенная загрузка: в чём принципиальная разница

Скрипт может подключаться по-разному, и от этого зависит, увидит ли посетитель задержку. Браузер обрабатывает HTML сверху вниз. Если он натыкается на обычный тег скрипта без атрибутов, разбор документа останавливается, пока файл не будет скачан и выполнен. Это и есть блокирующая загрузка — худший сценарий для любого стороннего кода.

Современные варианты подключения снимают проблему. Атрибуты async и defer позволяют браузеру продолжать строить страницу параллельно. Загрузка после события load или по первому действию пользователя выносит скрипт вообще за пределы отрисовки первого экрана. Стандартный код счётчика уже подключается асинхронно, но многие сайты собраны так, что скрипт попадает в шапку в блокирующем виде — через кривой плагин, через менеджер тегов, через кастомную вставку в шаблон.

Как счётчик влияет на лабораторные метрики

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

Метрика	На что смотрит	Насколько на неё влияет счётчик
Время до первого байта	Скорость ответа сервера	Никак — счётчик грузится уже после ответа сервера
Первая отрисовка контента	Момент появления первого текста или картинки	Практически никак при асинхронном подключении, заметно при блокирующем
Отрисовка крупного элемента	Загрузка главной картинки или заголовка первого экрана	Косвенно, если счётчик конкурирует за канал с изображением героя
Общее время блокировки	Загруженность основного потока	Заметно при включённом вебвизоре и множестве трекеров
Сдвиг макета	Прыжки контента при загрузке	Никак, счётчик не занимает места в вёрстке
Отклик на действие	Задержка реакции интерфейса	Возможен вклад, если обработчики событий записывают каждое движение

Отдельно про показатель отклика. Он измеряет, сколько миллисекунд проходит между кликом или касанием и видимой реакцией страницы. Скрипты аналитики вешают собственные обработчики на клики, скроллы и ввод. Если основной поток уже перегружен темой на jQuery, слайдером и десятком плагинов, добавка от счётчика может стать той самой каплей, которая выводит показатель из зелёной зоны. Но виновата в этом перегрузка потока в целом, а не счётчик сам по себе.

Почему в отчёте виноватым выглядит именно счётчик

Отчёты о скорости устроены так, что сторонний код всегда бросается в глаза. У него отдельный домен, отдельная строка в списке ресурсов и часто отдельная рекомендация вроде «сократите влияние стороннего кода». Собственные файлы сайта при этом размазаны по десяткам строк: тут тема, тут плагин галереи, тут шрифт, тут иконочный набор. Глазу не за что зацепиться, а чужой домен читается мгновенно.

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

Что на самом деле замедляет типовой сайт

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

Причина	Характер вклада	Сложность исправления
Изображения в исходном размере	Основной вес страницы, часто больше всего остального вместе взятого	Низкая: пережать, задать размеры, перевести в современный формат
Отсутствие ленивой загрузки картинок	Браузер тянет всё, включая то, что ниже экрана	Низкая: атрибут loading или штатная функция движка
Наборы шрифтов по пять начертаний	Задержка отрисовки текста, лишние обращения к внешнему домену	Низкая: оставить два начертания, положить локально, добавить swap
Слайдер на главной	Тяжёлая библиотека плюс несколько полноразмерных картинок	Средняя: заменить статичным первым экраном
Десяток плагинов с собственными стилями	Каждый добавляет файлы на все страницы, даже там, где не нужен	Средняя: аудит, отключение лишних, условная подгрузка
Тяжёлая универсальная тема	Конструктор тянет за собой избыточный код на каждой странице	Высокая: смена темы или переработка шаблонов
Слабый или перегруженный хостинг	Долгий ответ сервера, который портит все метрики разом	Средняя: переезд на нормальный тариф или площадку
Устаревшая версия PHP	Медленная генерация страниц, отсутствие современных оптимизаций	Низкая: обновление в панели после проверки совместимости
Отсутствие кеширования и сжатия	Каждая страница собирается заново, файлы отдаются без компрессии	Низкая: настройка кеша, gzip или brotli, заголовков кеша
Пять и более трекеров и пикселей	Множество сторонних соединений и обработчиков	Низкая: убрать неиспользуемые, оставить нужные
Один счётчик аналитики	Небольшая добавка к сетевым запросам	Низкая, но платится потерей данных

Обратите внимание на последнюю строку. Один счётчик — не ноль, но это последний пункт списка, а не первый. Браться за него, пока на главной висит слайдер с четырьмя неоптимизированными фотографиями, всё равно что снимать пылинку с крыла самолёта, у которого спущены шасси.

Если нужны детали, смотрите «Яндекс Метрика — тормозит скорость сайта».

Как честно измерить вклад счётчика

Спорить о влиянии бессмысленно, когда его можно измерить. Правильный замер устроен просто: одна и та же страница, одни и те же условия, разница только в наличии счётчика.

1. Выберите конкретную страницу, а не сайт целиком. Лучше самую посещаемую или главную.
2. Прогоните тест три-пять раз подряд и запишите медиану, а не единичный результат. Разброс между прогонами бывает больше, чем весь эффект от счётчика.
3. Отключите счётчик временно — через режим отладки, тестовую копию или временное удаление кода из шаблона.
4. Повторите тот же цикл прогонов в тех же условиях: тот же инструмент, то же устройство, тот же тип соединения.
5. Сравните медианы по каждой метрике отдельно, а не итоговый балл, который складывается из весов и легко скачет.
6. Обязательно сравните время ответа сервера в обоих замерах. Если оно отличается, условия не были равными и сравнение недействительно.

Отдельный слой — полевые данные, то есть статистика реальных посетителей с их устройствами и связью. Лабораторный тест на эмуляции медленного телефона рисует одну картину, реальные пользователи с прогретым кешем и нормальным интернетом — другую. Решение принимайте по полевым данным, если они накоплены, а лабораторные используйте для поиска конкретных узких мест.

Помогу с продвижением: вывод сайта в ТОП Яндекса — вывожу сайты в топ Яндекса белыми методами.

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

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

Чем бизнес расплачивается за удаление счётчика

Скорость измеряется в миллисекундах, а потери от слепоты — в деньгах и в невозможности принимать решения. Вот что исчезает вместе со счётчиком.

Что теряется	Практическое последствие	Можно ли заменить
Источники трафика	Неясно, что приносит людей: поиск, реклама, соцсети, прямые заходы	Частично, по логам сервера, но грубо и без деталей
Цели и конверсии	Нельзя посчитать, сколько заявок дал каждый канал	Нет, кроме ручной отметки в CRM
Отправки форм	Не видно, сколько людей начали заполнять и бросили	Только собственным логированием на бэкенде
Вебвизор	Нельзя посмотреть, где посетитель запутался и ушёл	Нет
Карты кликов и скроллинга	Не видно, докручивают ли до блока с ценами и куда жмут	Нет
Поведение по страницам	Неясно, какие страницы работают, а какие только висят балластом	Частично по логам, без учёта времени и глубины
Сегменты аудитории	Нельзя отделить новых от вернувшихся, мобильных от десктопных	Ограниченно
Оценка работы подрядчика	Нечем подтвердить или опровергнуть результат продвижения	Нет
Историческая база	Пропадает возможность сравнить сезон с сезоном и год с годом	Нет, восстановлению не подлежит
Данные для рекламных кампаний	Ретаргетинг и оптимизация по целям остаются без сигнала	Нет

Почему исторические данные не восстанавливаются

Это тот пункт, который стоит осознать до, а не после удаления. Счётчик не хранит прошлое сайта — он записывает происходящее в момент визита. Если кода на странице нет, визит просто не фиксируется нигде. Верните счётчик через полгода, и статистика начнётся с нуля, с даты возврата.

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

При этом сам счётчик, оставаясь на сайте, копит историю бесплатно и без вашего участия. Единственное, что требуется, — не мешать ему.

Что делать вместо удаления

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

Подробнее об этом — в статье «Яндекс Метрика опять не работает (25.03.2021)».

Вариант	Что даёт	Что теряется	Кому подходит
Проверить асинхронность подключения	Снимает блокировку разбора HTML	Ничего	Всем, это базовая гигиена
Отложить загрузку до события load	Скрипт не конкурирует за канал с первым экраном	Ничего существенного	Всем, у кого тяжёлый первый экран
Загружать по первому действию пользователя	Основной поток свободен до первого скролла или клика	Часть очень коротких визитов может не зафиксироваться	Сайтам, борющимся за показатель отклика
Отключить вебвизор	Убирает самую тяжёлую часть трекинга	Записи сессий	Тем, кто не смотрит записи месяцами
Отключить карты кликов и скроллинга	Меньше обработчиков и отправок	Тепловые карты	Сайтам со стабильной вёрсткой
Включать вебвизор периодами	Данные для разбора юзабилити без постоянной нагрузки	Непрерывная запись	Почти всем как компромисс
Убрать неиспользуемые пиксели и трекеры	Минус несколько сторонних доменов разом	Ничего, если каналы не работают	Сайтам с историей рекламных экспериментов
Объединить и почистить свои скрипты	Меньше запросов и меньше кода в основном потоке	Ничего при аккуратной сборке	Сайтам с десятком плагинов
Заняться реальными тормозами	Кратно больший выигрыш, чем от любых манипуляций с аналитикой	Ничего	Всем без исключения
Удалить счётчик полностью	Минимальный выигрыш в лабораторном тесте	Вся аналитика и вся будущая история	Практически никому

Отложенная загрузка: как это выглядит на практике

Смысл приёма в том, чтобы счётчик грузился не одновременно с содержимым страницы, а после того, как посетитель уже всё увидел. Варианты по нарастанию агрессивности:

• Штатное асинхронное подключение — минимум, который должен быть везде.
• Запуск после события полной загрузки страницы — скрипт не конкурирует с картинками и шрифтами первого экрана.
• Запуск через небольшую задержку после загрузки — дополнительно освобождает основной поток в самый нагруженный момент.
• Запуск по первому взаимодействию — скролл, клик, касание, движение мыши. Самый лёгкий для метрик и самый рискованный для полноты данных.

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

Сколько счётчиков и пикселей нужно сайту

Настоящая проблема со сторонним кодом почти никогда не в одном счётчике, а в накопленном за годы зоопарке. Пиксель рекламной сети, которой не пользуются два года. Виджет обратного звонка, отключённый в интерфейсе, но с оставшимся кодом в шаблоне. Второй счётчик аналитики, поставленный подрядчиком, который давно не работает. Скрипт чата, замененный на другой, но не удалённый.

Разумный минимум для сайта малого бизнеса выглядит так:

• Один счётчик веб-аналитики — основной источник данных о поведении.
• Пиксели рекламных систем — только тех, где сейчас действительно идут кампании.
• Один виджет коммуникации, если он реально нужен: чат или обратный звонок, не оба сразу.
• Всё остальное — под нож после проверки, что оно ни к чему не подключено.

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

Серверная аналитика и логи: дополнение, а не замена

Если нужна помощь по теме — обучение SEO-продвижению.

Аргумент «уберу счётчик, буду смотреть логи сервера» звучит логично, пока не столкнёшься с тем, что логи показывают. Серверный лог фиксирует факт запроса: адрес, время, страницу, код ответа, реферер и строку браузера. Этого хватает для технических задач и не хватает для маркетинговых.

Задача	Логи сервера	Счётчик на странице
Проверить, заходил ли поисковый робот	Да, это их сильная сторона	Нет
Найти страницы с ошибками ответа	Да	Косвенно
Отделить людей от ботов	Плохо, требует ручной фильтрации	Да, штатными средствами
Понять источник перехода	Частично, реферер часто пустой	Да, с разметкой кампаний
Измерить время на странице и глубину	Нет	Да
Зафиксировать отправку формы как цель	Только через собственное логирование	Да
Посмотреть, где посетитель запнулся	Нет	Да, в записях и картах
Собрать аудиторию для ретаргетинга	Нет	Да

Логи и серверные счётчики отлично дополняют клиентскую аналитику: они видят то, что не видит браузерный скрипт, — роботов, ошибки, запросы к файлам. Но заменить аналитику поведения они не могут в принципе, потому что не знают, что происходило внутри страницы после её отдачи.

Тему разбирал отдельно: «Влияет ли Яндекс Метрика на ранжирование | Новый эксперимент».

Как принимать решение

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

• Разница на уровне погрешности между прогонами — оставляем счётчик, вопрос закрыт.
• Разница заметная, но включён вебвизор — отключаем модуль записи и меряем снова.
• Разница заметная при базовом счётчике — почти наверняка проблема в блокирующем подключении или в общей перегрузке основного потока, разбираемся там.
• На странице пять и более трекеров — чистим лишние, счётчик аналитики не трогаем.
• Скорость критична для конверсии — переносим счётчик на отложенную загрузку и контролируем полноту данных.

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

Порядок работ по ускорению

Ускорение — это последовательность шагов от самых выгодных к самым мелким. Счётчик стоит в конце не потому, что он не важен, а потому что его вклад несопоставим с тем, что выше.

Шаг	Что делаем	Ожидаемый эффект
1	Проверить время ответа сервера, при долгом — разбираться с хостингом	Улучшает все метрики разом, ничто другое не поможет при медленном сервере
2	Обновить PHP до актуальной поддерживаемой версии	Быстрее генерация страниц, безопаснее движок
3	Включить кеширование страниц, сжатие и заголовки кеша для статики	Крупный выигрыш при минимальных затратах
4	Пережать изображения, задать размеры, включить ленивую загрузку	Обычно наибольший вклад в вес страницы
5	Сократить набор шрифтов, положить локально, добавить swap	Текст появляется раньше, меньше внешних обращений
6	Провести аудит плагинов, отключить неиспользуемые	Меньше файлов и запросов на каждой странице
7	Убрать или заменить слайдер и тяжёлые эффекты первого экрана	Быстрее отрисовка главного блока
8	Собрать и почистить собственные стили и скрипты	Меньше запросов, легче основной поток
9	Удалить неиспользуемые пиксели и виджеты	Минус несколько сторонних доменов
10	Настроить отложенную загрузку счётчика и отключить лишние модули	Небольшой, но бесплатный выигрыш без потери данных
11	Пересчитать метрики и сравнить с исходными	Понимание, что сработало, а что нет

Пройдя первые девять шагов, к десятому обычно приходят с мыслью «а счётчик-то и не мешал». Так и бывает: когда с страницы уходят лишние мегабайты и десятки запросов, вклад аналитики становится тем, чем он и был всё время, — фоновой величиной.

Частые заблуждения

• «Оценка в тесте — это и есть скорость сайта». Оценка — сводный балл по формуле, реальную скорость показывают полевые данные и поведение посетителей.
• «Красная строка про сторонний код означает, что счётчик критичен». Строка появляется при любом внешнем скрипте, включая шрифты и карты, и не измеряет реальную задержку для пользователя.
• «Уберу счётчик, поставлю обратно, когда захочу». Обратно поставить можно, а данные за период отсутствия не появятся никогда.
• «Один счётчик или два — разницы нет». Разница есть: второй домен, второе соединение, второй набор обработчиков. Дублирующую аналитику держать незачем.
• «Скорость важнее аналитики». Скорость — средство, аналитика — способ узнать, сработало ли средство.

Что проверить прямо сегодня

1. Откройте исходный код главной и найдите, как подключён счётчик — асинхронно или блокирующе.
2. Посмотрите в настройках, включены ли вебвизор и карты, и вспомните, когда вы в них последний раз заходили.
3. Соберите список всех сторонних доменов, к которым обращается страница, и вычеркните ненужные.
4. Прогоните тест скорости на главной три раза и запишите медиану — это ваша точка отсчёта.
5. Проверьте версию PHP и время ответа сервера — почти всегда там прячется больше, чем во всех скриптах вместе.

Частые вопросы

Сколько миллисекунд реально добавляет счётчик?
Ответ зависит от подключения и набора модулей, поэтому единой цифры не существует. Измеряйте на своей странице: три прогона со счётчиком, три без него, сравнение медиан. Если разница укладывается в разброс между прогонами, влияния практически нет.

Можно ли просто перенести счётчик в самый низ страницы?
Само по себе положение в HTML мало что решает, если скрипт подключён асинхронно, — браузер всё равно запросит его параллельно. Смысл имеет именно отложенный запуск: после события load или по первому действию посетителя.

Что делать, если на сайте стоят два счётчика аналитики?
Определите, какой из них смотрят и куда настроены цели, и оставьте его. Второй удалите, предварительно убедившись, что от него не зависят рекламные кампании или отчёты подрядчика.

Правда ли, что отключение вебвизора заметно облегчает страницу?
Из всех модулей запись сессий даёт самую ощутимую нагрузку, поэтому её отключение — первое, что стоит попробовать при подозрениях на аналитику. Компромиссный вариант: включать вебвизор на неделю раз в квартал, когда нужен разбор поведения.

Как понять, что тормозит хостинг, а не сайт?
Смотрите на время до первого байта. Если сервер отдаёт ответ долго на всех страницах, включая простые, дело в площадке или в тарифе, и никакая оптимизация фронтенда это не вылечит. Дополнительный признак — заметное различие в скорости в разное время суток.

О роли хостинга и настроек сервера в продвижении:

2:36

Коротко

• Один корректно подключённый счётчик почти не влияет на скорость: его вклад теряется на фоне картинок, шрифтов, плагинов и медленного сервера.
• В отчётах он выглядит виновником из-за отдельной строки про сторонний код, а не из-за реального веса.
• Проверяйте гипотезу замером: одна страница, несколько прогонов, медианы с счётчиком и без, с контролем времени ответа сервера.
• Удаление стоит дорого: пропадают источники, цели, вебвизор, карты, оценка подрядчика и вся будущая история, которая не восстанавливается.
• Вместо удаления — отложенная загрузка, отключение лишних модулей, чистка ненужных пикселей и работа с реальными тормозами; счётчик в списке работ идёт последним.

Разобрать, что действительно тормозит ваш сайт, помогу на SEO-консультации.