Сторонние скрипты — это скрытая плата, которую несёт каждая commerce-команда

Аналитика, живой чат, платформы A/B-тестирования, рекламные пиксели, виджеты программ лояльности, системы отзывов — средний commerce-сайт загружает 40 и более сторонних скриптов. Каждый — это налог на производительность, который платят ваши пользователи, зависимость по надёжности, на которую ваша команда не соглашалась, и поверхность атаки, которую команда безопасности, скорее всего, никогда не аудировала.

Налог на производительность в цифрах

По данным Google, медианное время загрузки стороннего скрипта — около 400 мс на скрипт. Магазин с 10 неасинхронными скриптами может добавить 3–4 секунды общего времени блокировки. Большая часть этого никогда не попадает на чей-либо радар — скрипты добавляются маркетингом, продуктом и клиентской поддержкой без инженерной проверки, и к тому моменту, когда кто-то замечает медлительность страницы, их уже 30.

Самые вредные скрипты необязательно самые тяжёлые. Платформы A/B-тестирования, которым нужно манипулировать DOM до отрисовки, вызывают сдвиги макета и задерживают FCP. Виджеты чата, загруженные синхронно, блокируют рендеринг полностью. Рекламные пиксели, подтягивающие дополнительные ресурсы — шрифты, SDK, трекинговые изображения — множат эффект. Мы видели единственный неправильно настроенный виджет чата, добавлявший больше секунды времени блокировки сам по себе.

Три категории риска

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

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

Риск безопасности получает меньше всего внимания. Сторонние скрипты выполняются в контексте вашей страницы с полным доступом к DOM, пользовательским данным и вводам форм. Атаки Magecart внедряют код для скимминга карт именно через скомпрометированные сторонние зависимости. Если вы запускаете 30 сторонних скриптов, вы расширяете доверие на security-постуру 30 вендоров — большинство из которых вы никогда не аудировали.

С чего начать

Начните с инвентаризации. Знайте, что загружается, кто за это отвечает и зачем это вообще есть. Почти всегда найдутся скрипты, добавленные под кампанию, которая завершилась полгода назад и которую никто не убрал. WebPageTest и панель Coverage в Chrome делают это прямолинейным — полдня аудита обычно выявляют худших виновников.

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

Governance — сложная часть

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

Для этого нужна поддержка маркетинга и продукта. Это сложнее, чем любая техническая работа. Обходного пути нет.