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

Четыре уровня работы со сторонними скриптами: P0 — ключевые, P1 — вспомогательные, P2 — экспериментальные, P3 — лишние

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

Сначала вывод: Сторонние скрипты — самая незаметная статья расходов на производительность сайта. По данным HTTP Archive, на каждой странице в среднем висит больше десяти сторонних скриптов, а на B2B-сайтах из-за аналитики, чатов, пикселей, тепловых карт и A/B-тестов их часто больше 12, и половина блокирует главный поток на первом экране. Работать с ними нужно в четыре шага: сначала выгрузите все скрипты через аудит «Стороннее использование» в Lighthouse и разбейте их на уровни от P0 до P3. Для P0 — ключевых скриптов — async и preconnect, для P1 — вспомогательных — задержка 2–3 секунды, для P2 — экспериментальных — загрузка после действия пользователя, для P3 — лишних — полное удаление. Контринтуитивный вывод: если запихнуть все скрипты в GTM, это не оптимизация производительности. GTM — всего лишь диспетчер, время выполнения самих скриптов никуда не девается.

1. Почему сторонние скрипты — чёрная дыра производительности

Свой код вы контролируете: что-то объединить, что-то сжать, что-то отложить через defer. Сторонние скрипты пишут другие, вы лишь вставляете фрагмент embed-кода в head, а что внутри, сколько он выполняется и сколько запросов тянет — вы почти не видите. Типичный embed-код Hotjar выглядит как 1 КБ, но после загрузки он подтягивает ещё 5 JS-файлов, 2 CSS и 1 worker — в сумме больше 300 КБ, а главный поток блокируется на 300–800 мс.

Типичный набор сторонних скриптов на сайте: Google Analytics 4, Google Tag Manager, пиксель Google Ads, Meta Pixel, LinkedIn Insight, Hotjar или Microsoft Clarity, чат Intercom или Zendesk, всплывающие окна HubSpot, кнопка записи Calendly, комментарии Disqus, разные инструменты A/B-тестов. При установке каждый обещает «5 минут — и готово», а через полгода на главной висит 12 сторонних скриптов. Про пороги Core Web Vitals читайте Оптимизация Core Web Vitals а про управление GTM —Управление GTM.

Тип скрипта	Типичный объём	Блокировка главного потока	Риск
GA4	50–100 КБ	50–100 мс	Относительно контролируемо
Контейнер GTM	от 30 до 80KB	30–80 мс	Внутри ещё другие скрипты
Hotjar/Clarity	200–400 КБ	300–800 мс	Постоянная запись, нагружает CPU
Intercom/Zendesk	150–300 КБ	200–500 мс	Всплывающее окно перекрывает первый экран
Пиксели Meta/LinkedIn	50–150 КБ	50–150 мс	Для отслеживания рекламы
Инструменты A/B-тестов	100–300 КБ	200–600 мс	Ещё и меняют DOM, вызывая CLS

2. Аудит тегов: сначала выгрузите все скрипты и разбейте их по уровням

Первый шаг — не оптимизация, а аудит. Прогоните главную страницу через Lighthouse и посмотрите аудит «Сторонние ресурсы»: он перечислит все сторонние скрипты, сгруппирует их и покажет, сколько времени занимает каждый. Затем откройте панель Performance в DevTools, посмотрите flame chart главного потока, отсортируйте по self time и найдите скрипты, которые съедают главный поток.

Классифицируйте по двум критериям: «необходимость для бизнеса» и «вред для производительности». P0 — ядро: GA4, пиксели ключевых конверсий, всё для безопасности сайта. Их оставляем, но меняем способ загрузки. P1 — вспомогательные: карты кликов, чат, подписка на email. Их можно отложить. P2 — экспериментальные: A/B-тесты, теги временных кампаний. Отработали — удаляем. P3 — лишние: скрипты, данные которых вы ни разу не смотрели после установки. Их просто снимаем. Пример: полгода назад команда поставила Hotjar для анализа поведения, а записи смотрели всего дважды. Это P3. После удаления TBT сразу упал на 300 мс. Как управлять пикселями и рекламой, читайте в разделе Отслеживание пикселей.

Уровень	Критерий оценки	Что делать	Типичные скрипты
P0 Ядро	Без них бизнес ослепнет	async + preconnect, загружать сразу	GA4, пиксели конверсий
P1 Вспомогательные	Полезны, но не срочны	Задержка 2–3 секунды или idle	Чат, карты кликов, email-попапы
P2 Эксперименты	Для временных тестов	Загружать после действия пользователя, удалять после теста	A/B-тесты, теги кампаний
P3 Лишние	Данные не смотрели 30 дней	Просто удалить	Заброшенные карты кликов, старые пиксели

Три. Порядок загрузки: задержка, idle и триггеры по действию пользователя

Не все скрипты нужно грузить на первом экране. Скрипты P1 и P2 можно отложить тремя способами: setTimeout с задержкой 2–3 секунды, requestIdleCallback — ждём, пока браузер освободится, или загрузка после действия пользователя (скролл, клик). Эти три способа никак не влияют на сбор данных: за первые 2 секунды пользователь всё равно не нажмёт кнопку чата.

Конкретная настройка: скрипт чата Intercom по умолчанию грузится сразу — переключите на загрузку после скролла до 30% страницы или после 3 секунд на сайте. Hotjar переведите на requestIdleCallback: инициализация только когда главный поток свободен. GA4 — это P0, но и его можно отложить на 0,5 секунды через триггер «После загрузки страницы» в GTM, на полноту данных это не влияет. Контринтуитивный вывод:Отложенная загрузка скриптов не влияет на точность данных— если пользователь в итоге вызвал скрипт, события всё равно соберутся; а те, кто закрыл страницу в первые 2 секунды, и так не были вашим полезным трафиком. Как настроить кэширование в WP, читайте в разделе Стратегия кэширования сайта.

Способ задержки	Когда отправлять	Подходящие скрипты	На что обратить внимание
async, сразу	Во время разбора HTML	Скрипты ядра P0	Не блокирует, но всё равно грузит главный поток
Задержка через setTimeout	Через 2–3 секунды после загрузки страницы	Чат, попапы	Просто и эффективно
requestIdleCallback	Когда главный поток свободен	Карты кликов, аналитика	Для старых браузеров нужен polyfill
Триггер по скроллу	Скролл 25–30%	Чат, подписка на email	Не перекрывает первый экран
Триггер по клику	Клик по кнопке «Чат»	Плагин чата	Минимум нагрузки, почти не влияет на конверсию

4. Удаление: скрипты, не использовавшиеся 30 дней, — сразу в корзину

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

Удаление эффективнее отложенной загрузки. Отложенный скрипт всё равно скачивается, выполняется и занимает память, а удалённый не делает ничего. Типичный случай: один B2B-сайт удалил инструмент, на котором полгода назад проводили A/B-тесты, заброшенный Hotjar и ненужный чат Zendesk. Число сторонних запросов на главной упало с 18 до 7, TBT — с 800 мс до 150 мс, LCP — с 4,2 до 2,4 секунды. Как выбрать инструмент для A/B-тестов, читайте Инструменты A/B-тестов а про инструменты тепловых карт —инструменты тепловых карт.

Вопросы для решения об удалении	Да	Нет
Вы смотрели его данные за последние 30 дней?	Оставить, оптимизировать загрузку	Перейти к следующему вопросу
Его отчёт обсуждают на планёрке?	Оставить, грузить отложенно	Перейти к следующему вопросу
Кто-нибудь заметит, если он перестанет работать?	Оставить, но следить	Просто удалить

5. Замена: какие сторонние скрипты можно перевести на первую сторону

Некоторым сторонним скриптам третья сторона не нужна. Аналитику можно разместить у себя: скрипт GA4 разворачивается на том же домене — экономия на DNS и TLS-рукопожатии. Вместо Hotjar для тепловых карт подойдёт Microsoft Clarity — вдвое меньше по размеру. Вместо Intercom для чата — кнопка WhatsApp: ни скриптов, ни загрузки. Вместо стороннего сервиса попапов — собственный JS на 1 КБ.

Ещё одно направление — делегирование событий. Соберите все сторонние скрипты в лёгкий загрузчик на первой стороне и инициализируйте их пакетом после взаимодействия пользователя, а не позволяйте каждому скрипту захватывать первый экран. Конкретный приём: планировать загрузку через контейнер GTM, но сам контейнер GTM тоже грузить отложенно — не ставьте GTM синхронно в head. Как это сочетать с CDN и кэшированием, читайте Глобальное ускорение CDN. Мониторинг сайта — см.Оповещения мониторинга сайта.

сторонние скрипты	Альтернатива	Экономия размера
Intercom/Zendesk	Кнопка WhatsApp + mailto	от -150 до 300 КБ
Hotjar	Microsoft Clarity	-50%
Сторонний сервис попапов	Свой JS на 1 КБ	-80%
Синхронная загрузка GTM	GTM с отложенной загрузкой + preconnect	TBT первого экрана -100 мс
Несколько рекламных пикселей	Объединить в один серверный tag manager	-60% запросов

FAQ: частые вопросы

Если сложить все скрипты в GTM, производительность улучшится?

Нет. GTM — всего лишь планировщик, время на скачивание, разбор и выполнение скриптов никуда не девается. Сложить скрипты в GTM — значит заменить несколько тегов script одним контейнером GTM, а сам контейнер весит от 30 до 80 КБ, и вложенные скрипты всё равно выполняются. Настоящая оптимизация — это отложенная загрузка контейнера GTM, разделение тегов по триггерам и удаление скриптов P3 прямо из GTM.

Как провести аудит сторонних скриптов и где смотреть данные?

Три шага. Первый: прогоните главную страницу через Lighthouse и посмотрите аудит «Сторонние ресурсы» — он покажет все сторонние домены и время, которое каждый из них отнимает. Второй: запишите загрузку главной в панели Performance в DevTools и отсортируйте флеймграф главного потока по self time. Третий: отфильтруйте в панели Network запросы Third-party и посмотрите, сколько запросов отправляет каждый сторонний домен. Сведите эти три источника в одну таблицу — это и будет ваш список скриптов.

Влияет ли отложенная загрузка сторонних скриптов на точность данных?

Нет. Если скрипт успевает загрузиться до того, как пользователь вызовет нужное событие, данные собираются как обычно. Отложите чат, карты кликов и попапы на 2–3 секунды или до скролла — на события конверсий GA4 и события пикселей это не повлияет. Пользователи, которые закрывают страницу в первые 2 секунды, и так не дают ценных данных, и не платить за их первую отрисовку — разумный компромисс.

Обязательно ли загружать скрипт чата при первой отрисовке?

Нет. Загрузка чата при первой отрисовке — самая большая плата за производительность: 150–300 КБ и блокировка на 200–500 мс. Переключитесь на загрузку после прокрутки до 30% или через 3 секунды — конверсия почти не изменится, потому что те, кто действительно хочет написать, подождут эти 3 секунды. Ещё радикальнее — оставить только кнопку WhatsApp и подгружать скрипт чата по клику: объём экономится сразу.

Как часто проводить аудит сторонних скриптов?

Раз в квартал. Скрипты накапливаются постепенно: раз в месяц — слишком часто, раз в полгода — уже запущено. При квартальном аудите распределите скрипты по уровням от P0 до P3 и по каждому задайте три вопроса: смотрели ли его данные за последние 30 дней, обсуждают ли отчёт на еженедельной встрече, заметит ли кто-нибудь, если его отключить. Если на два вопроса ответа нет — удаляйте. Удаление одного скрипта улучшает TBT сильнее, чем отложенная загрузка трёх.

Можно ли отложить загрузку GA4 — не потеряются ли данные?

Можно отложить на 0,5–1 секунду, данные не потеряются. По умолчанию GA4 загружается синхронно в head; переключите его на асинхронную вставку после загрузки страницы — и событие page_view отправится, если пользователь не закрыл страницу в первые 0,5 секунды. Крайний случай — мгновенное закрытие: такой трафик и в любом другом счётчике будет неточным. На B2B-сайтах среднее время на странице — 2–3 минуты, так что задержка в 1 секунду почти не влияет на полноту данных.

В заключение

Суть работы со сторонними скриптами не в том, «как заставить их работать быстрее», а в том, «какие из них вообще не должны загружаться при первой отрисовке». Проводите аудит раз в квартал: скрипты уровня P3 удаляйте, P1 — откладывайте, у P0 оптимизируйте способ загрузки. За год производительность главной заметно вырастет, а бизнес-показатели не пострадают.

Три шага на практике. Первый: на этой неделе прогоните главную через Lighthouse и выгрузите список сторонних скриптов. Второй: распределите их по уровням от P0 до P3, скрипты P3 сразу удалите, P1 отложите на 2–3 секунды. Третий: переведите чат на загрузку по скроллу или на кнопку WhatsApp. Через две недели проверьте, улучшились ли TBT и INP.

Запомните одну вещь: GTM — это диспетчер, а не волшебная палочка. Проблемы производительности самого скрипта не спрячешь в GTM — ни секунды не сэкономишь.