Яндекс Метрика — тормозит скорость сайта

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

Из чего вообще складывается нагрузка от счётчика

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

• Инициализирующий фрагмент — тот самый кусок кода, который вы вставляете в шаблон. Он крошечный, но именно он запускает всё остальное.
• Основной скрипт — библиотека, которая скачивается с домена Яндекса, парсится и исполняется. Это главный вклад в CPU-нагрузку на слабых телефонах.
• Дополнительные модули — запись сессий, карта кликов, карта скроллинга, отслеживание форм. Каждый включённый модуль подтягивает свой код и добавляет обработчики событий.
• Сетевые запросы во время визита — отправка хита, событий, целей, пакетов записи поведения. Эти запросы идут уже после отрисовки, но конкурируют за канал и за процессор.
• Слушатели событий на странице — подписки на клики, скролл, ввод в поля, изменения DOM. Их не видно в весе, но они выполняются на каждое движение пользователя.
• Яндекс Метрика не работает: счётчик стоит, а данных нет

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

Что происходит в браузере после установки кода. Последовательность стоит понимать, потому что от неё зависит, куда вообще можно вмешаться. Браузер встречает ваш фрагмент кода, создаёт тег скрипта и уходит за библиотекой на сторонний домен. Здесь тратится время на DNS-резолв, установку соединения и TLS-рукопожатие — для нового посетителя это ощутимая пауза, даже если файл маленький. Дальше скрипт исполняется, читает переданные настройки, регистрирует обработчики и отправляет первый хит. Если включены тяжёлые модули, следом подтягивается дополнительный код.

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

Модули счётчика: что даёт и чем платите

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

Модуль	Что даёт	Чем нагружает
Базовый счётчик визитов	Посещаемость, источники, география, устройства, отказы, глубина просмотра	Загрузка и парсинг основной библиотеки, один хит на просмотр. Минимально необходимая база
Запись сессий (Вебвизор)	Видеозапись поведения: движения мыши, скролл, ввод в поля, переходы	Самый тяжёлый модуль. Постоянный сбор событий мыши и изменений DOM, регулярная отправка пакетов данных на сервер
Карта кликов	Тепловая карта нажатий по всем элементам страницы	Обработчик на каждый клик по документу, дополнительные отправки. Нагрузка умеренная, но постоянная
Карта скроллинга	Глубина прокрутки, где именно пользователь останавливается	Подписка на событие прокрутки — самое частое событие в браузере. На мобильных даёт заметный вклад в дёрганый скролл
Отслеживание форм	Кто начал заполнять форму, где бросил, какие поля вызывают отвал	Слушатели на поля ввода и фокус, работа при каждом наборе символов
Отслеживание хеша адресной строки	Учёт переходов внутри одностраничных приложений	Почти бесплатно, но бессмысленно на обычных многостраничных сайтах
Отправка целей и событий	Конверсии, заявки, звонки, шаги воронки	По одному короткому запросу на срабатывание. Практически не влияет на загрузку
Электронная коммерция	Товары, корзина, выручка, ассортиментная аналитика	Передача массива данных о товарах. Ощутимо только на больших каталожных страницах

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

Запись сессий: самый дорогой модуль

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

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

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

Карта кликов, карта скроллинга и отслеживание форм

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

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

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

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

Ещё нюанс: отслеживание форм подписывается на события ввода, а поля ввода — самое чувствительное к задержкам место интерфейса. Лишние миллисекунды на каждый символ на слабом устройстве превращаются в ощущение, что клавиатура залипает. Для форм заявок это прямая потеря конверсии — то есть модуль, поставленный ради роста конверсии, работает против неё.

Смежный материал по теме — «Удалил Яндекс Метрика | Постоянно глючит | Скорость сразу выросла».

Как включать тяжёлые модули на время исследования

Схема, которая экономит скорость и при этом ничего не отнимает у аналитики:

1. Сформулируйте вопрос. Не «посмотрю, что там происходит», а конкретно: «почему на странице услуги высокий отказ» или «где отваливаются в форме расчёта».
2. Включите нужный модуль. Только тот, который отвечает на вопрос: запись сессий — для поведения, карту скроллинга — для длины страницы, формы — для длинной формы.
3. Наберите материал. Ориентир — несколько десятков записей по нужному сегменту или пара недель данных, если трафик небольшой. Важнее не срок, а достаточная выборка.
4. Сегментируйте выборку. Смотрите не всё подряд, а конкретный сегмент: мобильные, конкретная страница входа, визиты без достижения цели.
5. Запишите выводы и внесите правки. Выводы должны превратиться в задачи, иначе исследование бессмысленно.
6. Выключите модуль. Этот шаг забывают чаще всего — и модуль остаётся включённым на годы.

Поставьте себе напоминание на дату выключения прямо в момент включения. Это единственный способ не забыть.

Отложенная загрузка счётчика

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

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

Самый простой вариант — привязаться к моменту полной загрузки страницы:

<script>
window.addEventListener('load', function () {
  setTimeout(initMetrika, 2000);
});
</script>

Где initMetrika — функция, внутри которой лежит стандартный код счётчика. Задержку подбирают по ситуации: чем она больше, тем чище метрики скорости и тем больше потерь в статистике.

Чем вы рискуете. Посетители, которые закрыли вкладку раньше срабатывания таймера, в статистику не попадут вообще. Это не абстрактный сценарий: часть людей уходит с сайта за первые секунды — ошиблись ссылкой, увидели не то, передумали. Именно эти визиты формируют показатель отказов, и без них картина становится лучше, чем на самом деле.

Побочные эффекты, о которых узнают уже потом:

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

Загрузка по первому действию пользователя

Более аккуратный вариант — стартовать счётчик не по таймеру, а по первому признаку жизни: прокрутка, движение мыши, касание экрана, нажатие клавиши.

<script>
var mLoaded = false;
function loadMetrika() {
  if (mLoaded) return;
  mLoaded = true;
  initMetrika();
}
['scroll', 'mousemove', 'touchstart', 'keydown'].forEach(function (e) {
  window.addEventListener(e, loadMetrika, { once: true, passive: true });
});
window.addEventListener('load', function () {
  setTimeout(loadMetrika, 5000);
});
</script>

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

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

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

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

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

Правильная установка: скучная база, которая решает больше всего

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

Если нужны детали, смотрите «Скорость загрузки сайта в Яндекс | Как проверить?».

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

Конфликты с кэшем и оптимизаторами

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

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

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

Почему два счётчика — это двойная нагрузка и разные цифры

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

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

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

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

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

Типичные ошибки установки

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

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

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

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

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

Если тормозит не счётчик

Если нужна помощь по теме — курсы SEO-оптимизации.

Чаще всего вклад аналитики измеряется десятками миллисекунд, а страница грузится секунды. Значит, дело в другом. Вот список типичных виновников по убыванию вклада — проходите его сверху вниз.

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

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

Почему удаление аналитики ради балла — плохая сделка

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

Подробнее об этом — в статье «Скорость загрузки сайта — обман: настоящая метрика, которая решает позиции, прячется в другом месте».

Что происходит через месяц после удаления аналитики:

• Нет данных о том, откуда приходят заявки — рекламный бюджет распределяется вслепую.
• Непонятно, какие страницы приводят клиентов, а какие только тратят краулинговый бюджет.
• Падение трафика замечают по выручке, а не по отчёту, — то есть с задержкой в недели.
• Нельзя сравнить «до» и «после» ни одного изменения на сайте: базы для сравнения нет.
• История не восстанавливается. Данные за период без счётчика не появятся задним числом никогда.
• Яндекс Метрика не работает: счётчик стоит, а данных нет

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

Цели, которые приносят пользу

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

Что стоит настроить в первую очередь:

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

Пример отправки цели при клике по кнопке:

<script>
document.querySelectorAll('.js-call-btn').forEach(function (btn) {
  btn.addEventListener('click', function () {
    if (typeof ym === 'function') {
      ym(XXXXXXXX, 'reachGoal', 'CALL_CLICK');
    }
  });
});
</script>

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

И главное правило: у каждой цели должен быть ответ на вопрос «какое решение я приму, глядя на эту цифру». Если ответа нет — цель не нужна.

Чек-лист: аналитика есть, скорость не пострадала

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

Порядок действий, если нужно решить проблему сегодня:

1. Проверьте, сколько раз номер счётчика встречается в коде страницы. Уберите дубли.
2. Зайдите в настройки и выключите запись сессий, карту скроллинга и отслеживание форм, если сейчас не идёт конкретное исследование.
3. Добавьте счётчик в исключения плагина оптимизации, чтобы он не участвовал в объединении и повторной отсрочке.
4. Замерьте скорость по методике «три прогона до, три после» и посмотрите, изменилось ли что-нибудь.
5. Если разница мизерная — переходите к списку типичных виновников и работайте с изображениями, сервером и сторонними виджетами.
6. Если разница есть и она вам критична — внедряйте загрузку по первому действию со страховочным таймером, но заранее зафиксируйте дату внедрения, чтобы объяснить будущий провал в цифрах.
7. Через две недели сверьте динамику визитов и конверсий, чтобы убедиться, что вы не потеряли больше, чем выиграли.

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

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

Можно ли включить запись сессий только для части посетителей?
Штатной настройки «писать каждый десятый визит» в интерфейсе нет, но задачу решают на своей стороне: подключать счётчик с включённой записью только на нужных шаблонах или по своему условию в коде. Проще и надёжнее другой путь — включить модуль на ограниченный срок, набрать выборку и выключить. Для большинства проектов этого достаточно.

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

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

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

Разбор живого сайта: что мешает ему продвигаться:

2:29

Коротко

• Нагрузка складывается из библиотеки, дополнительных модулей, обработчиков событий и сетевых запросов; тяжелее всего — запись сессий, карта скроллинга и отслеживание форм.
• Тяжёлые модули включают под конкретный вопрос, набирают выборку и выключают — держать их постоянно нет смысла, потому что записи почти никто не смотрит.
• Отложенная загрузка и старт по первому действию убирают влияние на первый экран, но стоят части визитов и ломают сравнение периодов — фиксируйте дату внедрения.
• Один счётчик, одна вставка, все шаблоны, исключения в оптимизаторе: базовая гигиена установки даёт больше, чем любые хитрые схемы отсрочки.
• Прежде чем трогать аналитику, измерьте её вклад тремя прогонами до и после и пройдите список типичных виновников — картинки, сервер и сторонние виджеты почти всегда весомее счётчика.
• Яндекс Метрика не работает: счётчик стоит, а данных нет

Настроить аналитику без потери скорости помогу на SEO-консультации.