Сторонні скрипти — це прихована плата, яку несе кожна commerce-команда

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

Податок на продуктивність у цифрах

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

Найбільш шкідливі скрипти не обов'язково є найбільшими. Платформи A/B-тестування, яким потрібно маніпулювати DOM до відмальовки, викликають зсуви макету і затримують FCP. Віджети чату, завантажені синхронно, повністю блокують рендеринг. Рекламні пікселі, що завантажують додаткові підресурси, посилюють ефект.

Три категорії ризику

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

Ризик надійності менш очевидний. Якщо сторонній сервіс падає або деградує, ваша сторінка або ламається, або зависає в очікуванні таймауту. Скрипт віджета чату, що завантажується з CDN із 5-секундним таймаутом, змусить ваш чекаут займати на 5 секунд більше для користувачів, які не можуть досягти цього CDN. Це трапляється, і це важко діагностувати постфактум.

Ризик безпеки недооцінюється. Сторонні скрипти виконуються в контексті вашої сторінки з доступом до DOM, даних користувачів і введень форм. Атаки Magecart — які впроваджують скрипти для скімінгу карток у e-commerce сторінки — зазвичай роблять це через скомпрометовані сторонні залежності. Запуск 30 сторонніх скриптів означає довіру практикам безпеки 30 вендорів.

Що реально допомагає

Найефективніше втручання — інвентаризація та процес аудиту: знайте, які скрипти завантажуються, хто ними володіє, навіщо вони існують і яка їхня вартість продуктивності. Скрипти, додані для кампанії, що закінчилася кілька місяців тому, — звичайна справа. Інструменти на кшталт WebPageTest та панелі Coverage в Chrome спрощують аудит.

Стратегії завантаження мають значення. Скрипти, що не вимагають виконання до першої взаємодії, мають використовувати defer або async. Скрипти, які важливі лише після взаємодії користувача (живий чат, наприклад), можна завантажувати за вимогою. Бюджет завантаження скриптів — застосовуваний у CI — запобігає регресії.

Governance — складна частина

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

Для цього потрібна підтримка маркетингу та продукту. Це складніша розмова, ніж будь-яка технічна робота. Обхідного шляху немає.