Назад в блог

Как проверить сторонние скрипты на сайте

·17 мин чтения·Rendframe·Производительность сайта, Безопасность ecommerce, Приватность, Продуктовая разработка

Сайт может быть аккуратным в репозитории и совершенно другим в браузере клиента. Менеджер тегов подгружает пиксель, тот вызывает библиотеку, чат добавляет iframe, а платежный модуль обновляется со своего CDN. Именно эту исполняемую версию и нужно проверять.

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

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

В браузере появляется скрытая цепочка поставщиков

Сторонний скрипт — код внешнего сервиса или код, который загружается от его имени. Онлайн-запись, карта, отзывы, аналитика, защита от мошенничества и платежная форма часто рационально отдаются специализированным провайдерам. Но загруженный JavaScript может видеть доступное ему содержимое страницы, создавать новые сетевые запросы, занимать основной поток, менять DOM и вызывать следующих поставщиков.

Масштаб явления хорошо показывает исследование Web Almanac 2024: хотя бы один сторонний ресурс присутствовал на 92% страниц выборки, а скрипты стали крупнейшей категорией запросов к третьим сторонам. Медианная мобильная страница в главе о JavaScript загружала 375 КБ стороннего кода. Эти цифры описывают массив сайтов и не являются целевым бюджетом.

ОбластьПроверяемПочему это важно
ЦенностьИспользование функции, решения, продажи, обращенияОправдана ли интеграция
СкоростьЗапросы, байты, выполнение, long tasksМожет ли клиент быстро действовать
ДанныеПолучатели, payload, storage, consent stateСоответствует ли поведение обещанию
ИзмененияДоступы, версии, integrity, мониторинг, fallbackЧто произойдет без вашего релиза

Поэтому вопрос «что тормозит?» нельзя полностью отделить от вопросов «кто получает данные?» и «кто способен изменить страницу?». Один runtime-инвентарь служит основой для продуктового, performance, privacy и security-разбора.

Проверяйте не URL, а пользовательские сценарии

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

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

Набор ресурсов может зависеть от страны, UTM-метки, устройства, поведения, согласия и варианта эксперимента. Tag manager или первый vendor-loader добавит код, которого нет в HTML. Поэтому единственный Lighthouse run или поиск по исходникам дает только часть картины.

Соберите инвентарь исполнения

В инструментах разработчика сохраните Network log, перезагрузите страницу и выполните целевое действие. Учитывайте scripts, iframes, XHR/fetch, beacon, шрифты, redirects и WebSocket-соединения. По Initiator восстановите цепочку: кто загрузил конкретный ресурс. Сохраненный HAR удобен для анализа, но может содержать адреса, идентификаторы и тестовые токены — храните его соответственно.

Руководство web.dev предлагает сопоставлять Network с Performance, группировать работу по провайдеру, а затем блокировать выбранные домены и повторять измерение. Это практический способ отделить стоимость конкретной интеграции от всего JavaScript сайта.

Сценарий: оформление заказа
Скрипт: https://vendor.example/sdk.js
Инициатор: GTM container v42
Задача: ремаркетинг брошенной корзины
Условие: согласие на marketing
Данные: сумма, валюта, campaign ID
Бизнес-владелец: performance lead
Проверено: 2026-08-29
Без скрипта: заказ оформляется
Решение: перенести событие после успешной оплаты

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

Каждая интеграция должна отвечать на конкретный вопрос

Фраза «это нужно маркетингу» скрывает отсутствие решения. Уточните: какая кампания, отчет или продуктовая гипотеза пострадает без инструмента? Когда результат смотрели в последний раз? Heatmap без исследования, платформа экспериментов без экспериментов и две системы аналитики с одинаковой задачей — кандидаты на тестовое отключение.

  1. Критический: без него невозможно выполнить выбранную пользователем функцию, например открыть платежный метод.
  2. Доказанно полезный: поддерживает названное решение или результат, за которым следит владелец.
  3. Условный: нужен на части шаблонов, после взаимодействия либо после корректного согласия.
  4. Необоснованный: никто не знает актуальную цель, данные, стоимость или последствия удаления.

Отключайте контролируемо. Снимите baseline, выключите один инструмент в staging или на части трафика, пройдите ключевые функции, проверьте downstream-отчеты и сравните показатели. Подготовьте rollback. Невидимый тег иногда нужен для партнерской атрибуции или сверки расходов после завершения покупки.

Стоимость видна в тесте «с ним / без него»

Скрипт тратит время на DNS и соединение, загрузку, parsing, выполнение и изменения страницы. async позволяет браузеру продолжать разбор HTML во время загрузки, но не отменяет конкуренцию за сеть и CPU. defer меняет момент и порядок выполнения, поэтому может сломать зависимость, если добавить его без разбора.

Сравнивайте на одинаковой странице, профиле устройства, скорости сети, локации и состоянии кэша. Делайте несколько прогонов. Записывайте число запросов, общий вес, JavaScript execution time, long tasks, LCP, INP и CLS. В актуальной документации Google Search хорошими значениями на 75-м перцентиле считаются LCP не более 2,5 секунды, INP менее 200 мс и CLS не более 0,1.

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

Хорошая политика — не запрет внешнего кода, а бюджет: essential-функции первыми, optional позже, никакого дублирования и предел для main-thread time. На ecommerce-сайте дополните измерение аудитом брошенного оформления, чтобы видеть не только балл, но и завершенные заказы.

Cookie-сканер не показывает весь поток данных

Скрипт способен отправить запрос без знакомого cookie. Сравните сетевое поведение до и после выбора: адресат, метод, параметры URL, request body, headers, local storage и идентификаторы, созданные другими тегами. Проверьте отзыв согласия, повторный визит и изменение настроек.

Юридическая оценка зависит от рынка, назначения, технологии и состава данных. В качестве официального примера британский ICO указывает, что для необязательного хранения или доступа обычно требуется понятное активное согласие и такое действие не должно происходить заранее. Это не универсальная консультация для любой страны; фактические потоки нужно сопоставлять с применимыми правилами вместе с профильным специалистом.

В техническом смысле проверка проще: баннер, privacy notice, правила контейнера и Network log должны рассказывать одну историю. Если после отказа браузер передает advertising ID, корректировать только формулировку интерфейса бессмысленно.

На странице оплаты действует более жесткий отбор

Дополнение PCI Security Standards Council по защите платежных страниц связывает требования PCI DSS v4.x 6.4.3 и 11.6.1 с авторизацией скриптов, обеспечением их целостности и обнаружением несанкционированных изменений скриптов и влияющих на безопасность HTTP headers.

По этой статье нельзя определять свой PCI scope. Redirect к провайдеру, форма внутри iframe и поля карты на merchant-сайте дают разные обязанности. В FAQ по SAQ A от февраля 2025 года PCI SSC отдельно разъясняет защиту merchant page, в которую встроена платежная форма стороннего процессора. Выбор анкеты и доказательств согласуйте с эквайером, платежным брендом, провайдером или квалифицированным оценщиком.

Разумный технический default не зависит от анкеты: уберите с checkout рекламные эксперименты, социальные embeds, лишний чат и дублирующие trackers. Утвердите короткий список разрешенных скриптов с владельцами, наблюдайте за новыми origins и security headers, тестируйте оплату при задержке или блокировке обязательного сервиса.

Защитные механизмы не взаимозаменяемы

OWASP Third Party JavaScript Management Cheat Sheet выделяет риски доступности, неожиданных изменений и доступа к данным. Один инструмент закрывает только часть.

  • Content Security Policy: начните с report-only, разберите отчеты, сократите источники и только затем включайте блокировку. Огромный allowlist и unsafe-директивы дают мало реальной защиты.
  • Subresource Integrity: фиксирует ожидаемый hash стабильного файла. MDN описывает проверку и требования CORS. Часто меняющийся vendor-loader без версий поддерживать так трудно.
  • Sandboxed iframe: отделяет совместимый виджет и ограничивает его возможности. После настройки проверьте focus, клавиатуру, accessibility, resize и обмен сообщениями.
  • Управление доступом: право публикации в tag manager должно быть ограничено, защищено сильной аутентификацией и попадать в журнал согласований.
  • Устойчивость: optional-сервис обязан завершаться по timeout, не мешая оплате, записи или отправке заявки.

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

После аудита нужен барьер для следующего тега

Короткая заявка на интеграцию должна фиксировать инициатора, страницы, назначение, поля данных, категорию consent, ожидаемый эффект, performance budget, владельца поставщика, дату пересмотра и rollback. Проверять нужно и pull request, и workspace менеджера тегов: оба способны изменить то, что получит браузер.

Для критических шаблонов сохраните одобренный baseline. Следите за новыми script origins, frames, connections и изменениями security headers. Не каждое обновление — атака, поэтому уведомления нужно классифицировать. Повторяйте synthetic journey после обновления темы или плагина, смены CMP, платежного SDK и логики checkout.

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

Первый проход за полтора часа

0–20 минВыбратьШаблоны, устройства, consent, account и payment states
20–45 минЗаписатьNetwork, initiators, frames, storage, long tasks
45–70 минСопоставитьЦель, владелец, данные, стоимость, checkout
70–90 минРешитьУбрать дубль, сузить scope, назначить проверки

Финал — три очереди. «Оставить» содержит нужные интеграции с владельцами. «Протестировать без» — устаревшие heatmaps, лишние trackers и неиспользуемые widgets. «Расследовать сейчас» — неизвестный origin на оплате, запрос до согласия вопреки настройкам или скрипт без понятного источника.

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

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

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

Любой сторонний JavaScript вреден для скорости?

Нет. Компактный специализированный компонент может быть выгоднее собственной разработки. В контролируемом тесте заблокируйте его домен и измерьте прирост запросов, байтов и main-thread work, а затем сравните стоимость с полезным результатом.

Решает ли проблему атрибут async?

Только частично. Он не останавливает parsing HTML во время загрузки, но выполнение по-прежнему занимает CPU, расходует сеть, меняет страницу и может вызвать новые ресурсы. Важны scope, момент запуска, consent и поведение при отказе.

Нужен ли SRI каждому внешнему файлу?

SRI полезен для стабильных ресурсов с подходящей CORS-конфигурацией. Для динамического loader, который часто меняется, он может быть непрактичен. Сочетайте его с CSP, инвентарем, ограничением доступов, мониторингом и минимизацией checkout.

Hosted checkout полностью снимает риск?

Он способен уменьшить PCI scope, но все зависит от модели. Окружающая iframe merchant page может быть атакована или нарушить оплату. Подтвердите архитектуру и применимые критерии у провайдера и организации, которая принимает вашу PCI validation.

Скрипт без владельца со временем становится риском

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

Rendframe может восстановить browser supply chain, связать стоимость скриптов с Core Web Vitals и конверсией, исправить consent и tag logic, усилить критические страницы и внедрить постоянные проверки. Посмотрите услугу продуктового инжиниринга или пришлите одну страницу и export менеджера тегов для предметного первого разбора.