Современный сайт редко работает в одиночку.
К нему подключают аналитику. Затем рекламные пиксели. Онлайн-чат. Обратный звонок. Карту. Видео. Виджет отзывов. Антиспам. Систему аналитики поведения. Форму стороннего сервиса. Менеджер тегов.
Каждое решение по отдельности выглядит вполне разумно.
Проблема появляется через год или два, когда никто уже точно не помнит, зачем половина этого установлена, кто за неё отвечает и что на самом деле происходит в браузере посетителя.
Сам WordPress может быть быстрым. Сервер – нормально настроенным. Изображения – оптимизированными. Но после открытия страницы браузер начинает загружать и выполнять код нескольких сторонних компаний.
По данным Web Almanac 2025, сторонние ресурсы встречаются как минимум на 90% исследованных страниц. Медианное число сторонних запросов составило 83 на десктопе и 79 на мобильных устройствах. Причём крупнейшей отдельной категорией таких запросов стали именно скрипты – 24,8%.
Поэтому сторонний код давно перестал быть мелкой технической деталью. Это отдельная часть инфраструктуры сайта.
Что мы называем сторонними скриптами
Это код, который сайт получает или выполняет для работы внешнего сервиса.
Аналитика и реклама
Google Analytics 4, Google Tag Manager, рекламные пиксели, системы аналитики поведения, рекламные сети.
Интерактивные сервисы
Онлайн-чаты, обратный звонок, карты, видеоплееры, формы внешних сервисов.
Доверие и защита
Виджеты отзывов, антиспам, CAPTCHA и другие внешние компоненты.
Маркетинговые инструменты
Системы A/B-тестирования, персонализации и другие подключаемые решения.
Сам факт наличия стороннего кода не является проблемой.
GA4 может быть нужен для аналитики. Чат – приносить обращения. Карта – помогать клиенту найти офис. Рекламный пиксель – использоваться для действующей кампании.
Проблема начинается тогда, когда скрипт существует на сайте по инерции, а его польза, стоимость и поведение больше никем не контролируются.
Один установленный скрипт – не всегда один скрипт
Это один из моментов, которые часто упускают при проверке сайта.
Допустим, в коде страницы мы нашли Google Tag Manager. Можно сделать вывод: «Здесь подключён один сторонний скрипт».
Но контейнер GTM способен запускать другие теги. Те обращаются к другим доменам. Какой-нибудь виджет создаёт iframe. Внутри него выполняется собственный JavaScript. Тот, в свою очередь, обращается ещё к нескольким сервисам.
OWASP отдельно рассматривает косвенную загрузку стороннего JavaScript через менеджеры тегов: один контейнер способен отдавать браузеру код нескольких поставщиков, причём конфигурация может меняться без изменения самой страницы сайта.
Почему исходного кода страницы недостаточно
Предположим, разработчик проверил шаблон WordPress и нашёл семь подключений. Но это ещё не означает, что посетитель взаимодействует только с семью внешними ресурсами.
Часть компонентов появляется после выполнения другого JavaScript, согласия на cookie, прокрутки страницы, нажатия кнопки, открытия формы, запуска видео, только для определённого устройства, страны или при выполнении заданного условия в GTM.
Поэтому нормальная инвентаризация стороннего кода должна отвечать не только на вопрос «Что написано в HTML?». Нужен второй: «Что произошло после того, как браузер выполнил этот HTML?»
Именно там часто обнаруживается настоящий технический долг.
У каждого стороннего скрипта есть цена
Причём мы не сводим её к скорости загрузки. У внешнего компонента как минимум четыре вида стоимости.
Производительность
Загрузка, разбор и выполнение JavaScript, запросы к серверам и изменение страницы.
Данные
Какие сведения о странице, событиях, устройстве и посетителе получает внешний сервис.
Надёжность
Что произойдёт с сайтом, если чат, карта, виджет или внешний сервер перестанут отвечать.
Безопасность
Какой внешний код получает право выполняться в браузере посетителя и как контролируются изменения.
1. Производительность
Скрипт нужно загрузить, разобрать, выполнить, иногда дождаться ответа сервера и изменить страницу. На слабом смартфоне несколько тяжёлых компонентов могут ощущаться значительно сильнее, чем на компьютере разработчика.
Особенно неприятна ситуация, когда страница визуально уже загрузилась, но основной поток браузера занят выполнением JavaScript. Человек видит кнопку. Нажимает её. А сайт реагирует с задержкой.
Поэтому сторонний код способен влиять не только на первоначальную загрузку, но и на отзывчивость уже открытой страницы.
2. Данные
Сторонний скрипт работает в браузере посетителя и в зависимости от реализации может получать сведения о странице, событиях, устройстве, источнике перехода и других доступных ему данных.
Для аналитики это часто и является целью.
3. Надёжность
Сайт может работать исправно, а сторонний сервис – нет. Например: чат завис → карта не отвечает → виджет выдаёт ошибку → внешний сервер медленно отдаёт JavaScript.
Чем больше внешних зависимостей, тем больше частей сайта находятся за пределами собственного сервера.
4. Безопасность
Здесь есть принципиальная особенность. Подключая JavaScript стороннего поставщика, мы разрешаем браузеру выполнять код, который контролируется не только нами.
OWASP выделяет среди основных рисков потерю контроля над изменениями клиентской части, выполнение стороннего кода и возможную передачу информации третьим сторонам.
Самая опасная ошибка – считать сторонний код неизменным
Допустим, виджет проверили в момент установки. Он работал нормально. Прошло полгода. Поставщик обновил JavaScript.
Сам сайт при этом никто не менял. Но код, выполняющийся у посетителя, уже другой.
Это фундаментальное отличие внешнего JavaScript от кода, который хранится и выпускается вместе с сайтом.
В сентябре 2026 года Cloudflare описала четыре обнаруженные в реальных интернет-магазинах вредоносные JavaScript-кампании. Внешне страницы могли продолжать работать нормально, в то время как код вмешивался в клики, поиск, аналитику или обращался к удалённому серверу за дальнейшими инструкциями.
Для владельца бизнеса здесь важен не конкретный сценарий атаки. Важен принцип:
Менеджер тегов – это инструмент, а не склад забытых пикселей
Google Tag Manager удобен именно тем, что позволяет централизованно управлять тегами. Но удобство создаёт другую проблему.
Добавить новый тег гораздо проще, чем потом вспомнить, зачем он был добавлен.
Например: в январе запускается рекламная кампания; для неё ставится пиксель; кампания заканчивается в марте; в октябре пиксель продолжает загружаться; через два года никто уже не знает, кому он принадлежит.
Так появляется технический долг без единой «ошибки».
Все когда-то принимали разумные решения. Просто у решений не было срока пересмотра.
Поэтому для временных интеграций мы считаем обязательными три вещи: кто установил → зачем → когда пересмотреть необходимость.
Если у временного скрипта нет даты пересмотра, у него очень хорошие шансы стать постоянным.
Паспорт стороннего скрипта
Для сайтов, на которых накопилось много интеграций, мы предлагаем не начинать с удаления. Сначала составляется реестр.
| Что проверяем | Что нужно знать |
|---|---|
| Сервис | Что это |
| Назначение | Какую задачу решает |
| Ответственный | Кто понимает, зачем он нужен |
| Источник | Где установлен |
| Страницы | Где должен работать |
| Запуск | Когда начинает загружаться |
| Зависимости | Что загружает дальше |
| Данные | Что получает |
| Передача | Куда отправляет данные |
| Производительность | Как влияет на страницу |
| Отказ | Что произойдёт, если сервис недоступен |
| Дата установки | Когда появился |
| Последняя проверка | Когда проверяли |
| Срок пересмотра | Когда снова оценивать необходимость |
| Решение | Что делаем дальше |
Главная строка здесь даже не «производительность». Это ответственный.
Если никто не может объяснить, зачем конкретный тег работает на сайте, это уже основание для проверки.
Не обязательно для немедленного удаления. Но для проверки – точно.
Семь решений вместо «оставить или удалить»
После инвентаризации необязательно делить всё на полезное и бесполезное. Мы используем семь вариантов.
Такой подход позволяет не заставлять каждого посетителя оплачивать ресурсами браузера функцию, которой он может вообще не воспользоваться.
Почему нельзя оценивать проблему количеством скриптов
Можно было бы установить правило: «На странице должно быть не больше пяти сторонних скриптов».
Но технического смысла в такой цифре мало.
Один тяжёлый виджет способен создать больше нагрузки, чем несколько простых аналитических запросов.
Поэтому мы оцениваем не количество логотипов сервисов, а стоимость функции.
До установки нового компонента желательно иметь состояние страницы до. После установки – измерить после.
- число дополнительных запросов;
- объём переданных данных;
- работу процессора;
- длинные задачи;
- LCP;
- INP;
- CLS;
- поведение на мобильных устройствах;
- работу форм и кнопок.
Получается технический бюджет.
Если новый чат приносит обращения, его стоимость может быть оправданна.
Если виджет добавляет нагрузку всему сайту, а им никто не пользуется, ситуация уже другая.
Скрипт может не тормозить загрузку – и всё равно мешать пользователю
Это особенно важно для INP.
Представим: страница уже появилась; посетитель начал читать; в этот момент запускается тяжёлый сторонний JavaScript; посетитель нажимает меню или кнопку; браузер сначала заканчивает предыдущую работу; только затем обрабатывает действие.
На графике загрузки всё может выглядеть терпимо. Для человека сайт «задумался».
Поэтому проверять сторонний код только по времени первоначальной загрузки недостаточно.
Нас интересует и то, что происходит после загрузки страницы, когда пользователь начинает с ней работать.
Это особенно важно на формах → корзине → оформлении заказа → фильтрах → мобильном меню → калькуляторах → интерактивных элементах.
Именно там задержка превращается из технической характеристики в потерянное действие.
Если нужно проверить не только внешние интеграции, но и всю техническую часть проекта, см. техническую SEO-оптимизацию сайта.
Cookie-баннер ещё не означает, что всё настроено правильно
На сайте появляется окно: «Мы используем файлы cookie». Пользователь выбирает вариант.
Но дальше возникает технический вопрос: какие скрипты уже успели запуститься до этого выбора?
Механизм согласия имеет смысл только тогда, когда фактическое поведение тегов соответствует выбранному состоянию.
Само наличие красивого баннера ничего не доказывает.
На VozniNet настройка cookie-согласия, GA4 и GTM вынесена в отдельный практический материал, поэтому здесь важен только общий принцип:
Настройка cookie-согласия, GA4 и GTM →
Что именно сторонний код получает от страницы
Этот вопрос редко задают при установке.
Обычно схема такая: «Скопируйте этот код и вставьте перед </head>».
Но технически нас должно интересовать другое.
- читает ли скрипт адрес страницы;
- получает ли параметры URL;
- работает ли с cookie;
- использует ли локальное хранилище браузера;
- видит ли события формы;
- получает ли содержимое слоя данных;
- какие внешние домены вызываются;
- какие данные уходят в запросах.
Для аналитической системы передача определённых событий закономерна.
Но если внешний сервис получает информацию, которая ему для заявленной функции не нужна, возникает вопрос о конфигурации.
Почему платёжные страницы особенно показательны
В платёжной индустрии проблема стороннего JavaScript уже настолько серьёзна, что PCI DSS формализует контроль скриптов на платёжных страницах.
Там требуется, в частности, понимать, какие скрипты разрешены, зачем они необходимы и не были ли они неожиданно изменены.
Это не означает, что требования PCI DSS автоматически распространяются на любой корпоративный сайт.
Но сам принцип полезен значительно шире:
Для обычного коммерческого сайта это хорошая модель управления даже без платёжной формы.
Защита – это не один плагин
Когда речь заходит о стороннем JavaScript, иногда ищут одну настройку, которая решит проблему.
Так не работает.
В зависимости от архитектуры применяются разные механизмы.
CSP помогает определить, каким источникам браузеру вообще разрешено загружать и выполнять определённые ресурсы.
SRI позволяет проверить целостность конкретного внешнего файла по криптографическому отпечатку.
sandbox для iframe ограничивает возможности встроенного содержимого.
Контроль изменений позволяет заметить, что фактически выполняемый код изменился.
Но в обычной работе мы начинаем не с CSP.
Мы начинаем с более простого вопроса:
Защищать неизвестный список зависимостей значительно сложнее, чем сначала привести его в порядок.
Как мы проверяем сторонний код сайта
Для первичной проверки необязательно сразу проводить большой технический аудит.
Мы идём последовательно.
- Составляем известный список. Проверяем WordPress → плагины → тему → вставки кода → GTM → рекламные кабинеты → сервисы аналитики. Записываем всё, что ожидаем увидеть.
- Открываем сайт как обычный посетитель. Не ограничиваемся административной частью. Нас интересует реальный браузер.
- Проверяем внешние запросы. Смотрим, к каким доменам обращается страница. Здесь часто появляется то, чего не было в первоначальном списке.
- Строим цепочки. Нужно понять не только «Загружается example.com», а кто инициировал этот запрос: страница, GTM, другой внешний скрипт или iframe.
- Повторяем проверку после взаимодействия. Открываем меню, прокручиваем страницу, запускаем видео, открываем чат, заполняем форму, принимаем или отклоняем cookie. Некоторые компоненты появятся только сейчас.
- Проверяем производительность. Ищем длинные задачи и смотрим, какой код занимал основной поток браузера. Особое внимание – моментам реального взаимодействия.
- Проверяем мобильную версию. На мощном рабочем компьютере проблема может почти не ощущаться. На смартфоне результат бывает другим.
- Сверяем техническую стоимость с бизнес-пользой. Чатом пользуются? Пиксель относится к действующей рекламе? Виджет нужен? События аналитики кто-то анализирует? Сервис вообще ещё оплачен и используется?
И только после этого принимаем решение.
Для общей проверки перед запуском или после серьёзных изменений можно использовать наш чек-лист проверки сайта.
PageSpeed не даст полного ответа
PageSpeed Insights полезен.
Но невозможно проверить всю систему стороннего кода одной цифрой.
Он не ответит: кто владелец пикселя; зачем нужен старый тег; какие данные должен получать чат; кто сможет отключить проблемный виджет; что загрузится только после открытия формы; что изменил поставщик вчера; нужна ли бизнесу эта интеграция вообще.
Поэтому высокий балл производительности ещё не означает, что сторонние зависимости находятся под контролем.
И наоборот – наличие внешних скриптов само по себе не означает плохой сайт.
Нужен управляемый состав.
У каждого важного скрипта должен быть аварийный выключатель
Представим, что сегодня утром внешний виджет:
- начал перекрывать кнопку заказа;
- вызывает ошибки;
- перестал отвечать;
- создаёт десятки лишних запросов;
- нарушает работу формы.
Возникают очень практические вопросы.
- Кто может его отключить?
- Где он установлен?
- Есть ли доступ к GTM?
- Нужно ли ждать разработчика?
- Можно ли отключить компонент, не ломая остальные?
- Есть ли предыдущая версия контейнера?
Если ответы неизвестны, проблема уже организационная.
Сторонний скрипт должен иметь срок пересмотра
Есть ещё одно простое правило, которое предотвращает накопление мусора.
При установке временного инструмента сразу определяем: зачем установили → кто отвечает → когда пересмотреть.
Например: рекламный пиксель – кампания до 30 ноября – пересмотр 5 декабря.
Или: виджет обратного звонка – тестируем три месяца – после теста сравниваем обращения.
Так техническая интеграция получает жизненный цикл.
Без этого сайт постепенно превращается в архив всех маркетинговых экспериментов за последние пять лет.
Что проверять перед установкой нового виджета
Мы бы не начинали с вопроса: «Как его вставить?»
Сначала девять вопросов.
- Какую бизнес-задачу он решает?
- Кто отвечает за результат?
- На каких страницах он действительно нужен?
- Нужно ли загружать его сразу?
- Какие данные он получает?
- Какие дополнительные ресурсы загружает?
- Как изменяется производительность страницы?
- Что произойдёт при недоступности поставщика?
- Как быстро мы сможем его отключить?
Если на эти вопросы есть ответы, интеграция становится управляемой.
Когда сторонний код уже превратился в технический долг
Есть несколько характерных признаков.
- Никто не знает, зачем установлен тег.
- Нет человека, отвечающего за сервис.
- В GTM десятки старых тегов и триггеров.
- Один и тот же инструмент подключён несколькими способами.
- Скрипт работает на всём сайте, хотя нужен на одной странице.
- После отказа от cookie продолжают появляться неожиданные запросы.
- Маркетинговая кампания закончилась, а её код остался.
- При отключении никто не знает, что сломается.
- Сторонний сервис существенно изменяет производительность, но его польза не измеряется.
- Поставщик давно сменился, а старый код всё ещё присутствует.
По отдельности это мелочи.
Вместе они означают, что сайт больше не контролируется как единая техническая система.
Не нужно удалять всё стороннее
После такого разбора легко прийти к другой крайности: «Лучший сторонний скрипт – удалённый скрипт».
Нет.
Сторонние сервисы дают сайту функции, которые было бы дорого или бессмысленно разрабатывать самостоятельно.
Задача не в стерильности.
Задача в том, чтобы для каждого внешнего компонента можно было быстро ответить:
- зачем он нужен;
- кто за него отвечает;
- где он работает;
- что он делает;
- сколько стоит сайту;
- какие данные получает;
- что произойдёт без него;
- как его отключить.
Сайт нужно проектировать с учётом будущих интеграций
Лучший момент для наведения порядка – не тогда, когда на сайте уже накопилось 30 неизвестных компонентов.
Если сайт создаётся или серьёзно переделывается, правила стороннего кода лучше определить сразу.
- единый способ подключения;
- понятный слой данных;
- управление согласием;
- разделение обязательных и необязательных компонентов;
- ограничение скриптов нужными страницами;
- контроль производительности;
- ответственных за интеграции;
- возможность быстро отключить внешний компонент.
Тогда новый чат или пиксель становится управляемым изменением, а не ещё одной строчкой, происхождение которой через год никто не вспомнит.
Такой подход мы закладываем и при создании сайтов: внешние интеграции должны быть частью архитектуры, а не случайным набором вставок.
Короткая проверка своего сайта
Если хочется быстро понять масштаб проблемы, можно начать с пяти вопросов:
- Сколько сторонних доменов вызывается при обычном открытии страницы?
- Можем ли мы объяснить назначение каждого?
- Знаем ли, какой код загрузил каждый из них?
- Есть ли у каждого бизнес-владелец или ответственная задача?
- Можем ли мы безопасно отключить любой необязательный компонент?
Если уже на втором вопросе появляется: «Вот этот домен знакомый, но откуда он взялся – непонятно», инвентаризация точно не будет лишней.
Главное
Технический долг сторонних скриптов редко появляется в один день.
Он накапливается постепенно.
Сегодня добавили аналитику.
Через месяц – пиксель.
Потом чат.
Потом новый рекламный кабинет.
Потом другой подрядчик поставил ещё один тег.
Каждая отдельная операция выглядит безобидно.
Через несколько лет браузер посетителя выполняет систему, которую никто целиком уже не проектировал.
Тогда чат остаётся чатом, аналитика – аналитикой, а менеджер тегов – инструментом управления.
А не складом цифровых решений, которые когда-то кому-то понадобились.
Частые вопросы
Нужно ли удалять сторонние скрипты ради скорости сайта?
Не автоматически. Сначала нужно определить назначение и фактическую стоимость каждого компонента. Полезный сервис может оправдывать дополнительную нагрузку. Ненужный скрипт не оправдывает её даже при небольшом влиянии.
Google Tag Manager сам по себе является проблемой?
Нет. Это инструмент управления тегами. Проблема возникает, когда контейнер превращается в неконтролируемое хранилище старых тегов, пользовательского кода и интеграций без ответственных и срока пересмотра.
async и defer решают проблему сторонних скриптов?
Они могут улучшить порядок загрузки и выполнения определённых сценариев, но не отвечают на вопросы необходимости, передачи данных, безопасности, бизнес-пользы и дальнейших зависимостей.
Можно ли увидеть все сторонние скрипты через PageSpeed Insights?
Нет. PageSpeed полезен для оценки производительности, но полноценная инвентаризация требует анализа фактических сетевых запросов, инициаторов, менеджеров тегов и поведения страницы после взаимодействия.
Что проверять в первую очередь?
Скрипты без понятного назначения, дублирующиеся системы, старые рекламные теги, глобально загружаемые виджеты, компоненты с высокой стоимостью выполнения и интеграции, за которые никто больше не отвечает.
Нужно ли переносить аналитику на сервер?
Не всегда. Серверная обработка может дать преимущества, но сама по себе не решает вопрос необходимости тегов и корректности передаваемых данных. Сначала следует привести в порядок архитектуру измерения.
Как часто проводить ревизию стороннего кода?
Универсального срока нет. Но ревизия особенно нужна после смены подрядчика, редизайна, изменения аналитики, завершения крупных рекламных кампаний и подключения новых маркетинговых систем. Для временных интеграций дату пересмотра лучше определить ещё при установке.
Сторонний код должен быть управляемой частью сайта
Если на сайте накопились чаты, пиксели, виджеты, аналитика и старые интеграции, сначала нужно понять фактическую цепочку загрузки и только затем решать, что оптимизировать, ограничивать или удалять.