Онлайн-чат, Meta Pixel, аналітика, віджет відгуків, карта, платіжна форма — кожен інструмент колись додали заради конкретної користі. За рік вони перетворюються на другий програмний продукт усередині сайту, але без єдиного власника й переліку змін.
Почніть не з нового сервісу аудиту, а з браузера. Потрібно побачити код, який справді виконується на сторінці: до згоди на необов’язкові трекери, після відмови, у кошику, під час оплати й у кабінеті клієнта.
Один скрипт — чотири різні рахунки
Стороннім будемо називати код, який сайт отримує від іншого постачальника або завантажує від його імені. Він може показувати доступний час для запису, приймати оплату, вимірювати рекламу чи відкривати відео. Водночас такий код здатен запитувати інші домени, читати доступний JavaScript вміст сторінки, займати головний потік браузера, змінюватися без релізу сайту й падати разом із сервісом постачальника.
Це не аргумент відмовитися від інтеграцій. За даними Web Almanac 2024, сторонні ресурси були на 92% досліджених сторінок, а скрипти становили найбільшу категорію запитів до третіх сторін. Медіанна мобільна сторінка в окремому розділі дослідження завантажувала 375 КБ стороннього JavaScript. Це опис вибірки, а не допустима норма для вашого магазину.
| Вимір | Що перевіряємо | Наслідок для бізнесу |
|---|---|---|
| Користь | Використання функції, рішення, конверсії, звернення | Виручка або економія роботи |
| Швидкодія | Запити, кілобайти, виконання, довгі завдання | Затримка перегляду й покупки |
| Дані | Адресати, поля, сховище, стан згоди | Приватність і ризик постачальника |
| Зміни | Власник, версія, контроль цілісності, сповіщення | Безпека й доступність |
Тому окремий «аудит швидкості», перегляд cookie banner і пошук вразливих бібліотек дають лише фрагменти. Найкорисніший артефакт один: карта того, що браузер завантажує, виконує та надсилає у кожному важливому сценарії.
Не обмежуйтеся головною сторінкою
Складіть короткий список шаблонів: landing page з реклами, категорія, картка товару, пошук, кошик, оформлення, сторінка успішного замовлення, вхід, кабінет, форма заявки й запис на послугу. Не треба сканувати кожну URL-адресу; треба охопити місця, де змінюються гроші, довіра або персональні дані.
Кожен шаблон перевірте щонайменше у трьох станах: новий відвідувач до вибору трекерів, відмова від необов’язкових категорій і згода на потрібні категорії. Для checkout додайте справжню тестову оплату, для кабінету — авторизованого користувача, а для продуктивності — звичайний Android і повільніше мобільне з’єднання.
Статичний HTML не показує всього. Google Tag Manager, плагін WordPress, Shopify app або перший скрипт можуть додати наступні після завантаження. Набір ресурсів інколи залежить від регіону, кампанії, пристрою, вибору cookies чи дії користувача. Один звіт Lighthouse — корисний знімок, але не повний реєстр.
Збирайте перелік із фактичного виконання
Відкрийте DevTools, увімкніть збереження Network log, перезавантажте сторінку й пройдіть цільову дію. Запишіть scripts, iframes, XHR/fetch, beacon-запити, шрифти й переходи. Поле Initiator покаже, який ресурс викликав наступний. HAR-файл зручно аналізувати, але не пересилайте його бездумно: у URL, headers і payload можуть бути тестові адреси, токени й інші ідентифікатори.
Інструкція web.dev щодо стороннього JavaScript радить поєднати Network і Performance, згрупувати роботу за постачальниками, а потім тимчасово заблокувати підозрілий домен і виміряти сторінку ще раз. Так видно ланцюги, яких немає ані в шаблоні, ані в списку встановлених плагінів.
Сторінка: /checkout
Ресурс: https://vendor.example/sdk.js
Джерело: контейнер GTM v42
Призначення: ремаркетинг покинутого кошика
Умова: лише після згоди на marketing
Дані: сума, валюта, campaign ID
Власник: керівник performance marketing
Останній перегляд: 2026-08-29
Fallback: оформлення працює без скрипту
Рішення: не запускати до завершення замовленняРобочий реєстр містить не тільки URL. Додайте постачальника, домени, сторінки, призначення, бізнес-власника, технічного власника, спосіб завантаження, категорію згоди, поля даних, виміряну вартість, дату наступного перегляду й порядок вимкнення.
«Потрібно маркетингу» — не обґрунтування
Поставте просте запитання: яке рішення стане гіршим без цього інструмента? Heatmap без активного дослідження, A/B platform без експериментів, два analytics-рішення з однаковою метою або чат без відповідального оператора мають перейти до контрольованого тесту на вимкнення.
- Необхідний: без нього сторінка не виконує запитану функцію, наприклад не відкриває вибраний спосіб оплати.
- Корисний: підтримує конкретне рішення або результат, який хтось регулярно перевіряє.
- Умовний: потрібен лише на окремих шаблонах, після дії користувача чи належної згоди.
- Безгоспний: ніхто не може пояснити актуальну користь, дані, вартість або наслідок видалення.
Не видаляйте навмання. Зафіксуйте baseline, вимкніть один інструмент у staging або для контрольної частини трафіку, перевірте критичні події й порівняйте результат. Залиште швидкий rollback. Непомітний тег інколи живить звірку реклами, партнерські виплати або фінансовий звіт після завершення сесії.
Вимірюйте різницю після блокування
Сторонній код оплачується встановленням з’єднання, завантаженням, розбором, виконанням і змінами layout. Атрибут async не блокує розбір HTML під час завантаження, але виконання все одно забирає CPU й може конкурувати за мережу. defer змінює порядок запуску, тому його не можна механічно додати до невідомої залежності.
Порівнюйте до і після на однаковій сторінці, пристрої, мережі, локації та стані cache. Повторіть вимір кілька разів. Дивіться на кількість запитів і байтів, JavaScript execution time, long tasks, LCP, INP і CLS. В актуальній довідці Google про Core Web Vitals добрими польовими значеннями на 75-му перцентилі названо LCP до 2,5 секунди, INP до 200 мс і CLS до 0,1.
Лабораторний trace пояснює причину, а field data показує досвід клієнтів. Сегментуйте реальні дані за шаблоном і типом пристрою: швидка головна не виправдовує картку товару, яка зависає на бюджетному телефоні. Відео, мапу, відгуки або чат часто можна замінити легким preview і завантажити повний віджет після кліку.
Мета — не «нуль зовнішніх сервісів», а бюджет: критична функція першою, необов’язкове після неї, без дублів і з обмеженням на main-thread work. Після технічного тесту зіставте результат з аудитом причин покинутого checkout, щоб не оптимізувати лише оцінку в інструменті.
Перевіряйте запити, а не назви cookies
Передача даних можлива без знайомого cookie. Порівняйте Network до й після кожного вибору: домен, метод, query parameters, request body, headers, local storage та ідентифікатори, створені іншими тегами. Окремо перевірте відкликання згоди й повторний візит зі збереженими налаштуваннями.
Правова оцінка залежить від країни, мети, технології й складу даних. Як приклад офіційного підходу, британський ICO пояснює, що необов’язкове зберігання або доступ до інформації зазвичай потребує чіткої активної згоди й не має відбуватися раніше. Це не універсальний юридичний висновок для України чи всього ЄС; фактичні потоки слід звірити з вимогами ваших ринків разом із компетентним фахівцем.
Технічний критерій однозначний: consent interface, privacy notice, правила tag manager і фактичний мережевий trace не повинні суперечити одне одному. Якщо після «Відхилити» рекламний ідентифікатор усе одно надсилається, новий текст банера проблему не усуне.
Для оплати потрібен коротший allowlist
Рекомендації PCI Security Standards Council щодо e-skimming пояснюють: вимоги PCI DSS v4.x 6.4.3 і 11.6.1 стосуються авторизації скриптів платіжної сторінки, контролю їхньої цілісності та виявлення підміни скриптів і важливих security headers.
Не визначайте свій PCI scope за статтею. Redirect на сторінку провайдера, вбудована iframe-форма й поля картки, створені вашим сайтом, — різні моделі. У роз’ясненні SAQ A від лютого 2025 року PCI SSC окремо говорить про merchant page із вбудованою формою платіжного сервісу й способи підтвердити захист від script attacks. Потрібну форму та докази узгодьте з еквайром, платіжним брендом, провайдером або кваліфікованим оцінювачем.
Незалежно від формальної категорії приберіть з checkout усе, що не допомагає завершити оплату: соціальні embeds, експерименти, зайвий чат, дубльовану аналітику. Зберігайте погоджений список скриптів із метою й власником, відстежуйте нові домени та зміни headers, перевіряйте поведінку, коли обов’язковий провайдер відповідає повільно.
CSP, SRI та iframe — різні інструменти
OWASP Third Party JavaScript Management Cheat Sheet розглядає зовнішній код як ризик для доступності, даних і контролю змін. Один HTTP header не закриває всі три.
- Content Security Policy: спочатку ввімкніть report-only, розберіть порушення, скоротіть дозволені джерела й лише потім блокуйте. Широкий allowlist створює відчуття захисту без реального обмеження.
- Subresource Integrity: прив’язує стабільний файл до очікуваного hash. Довідка MDN описує перевірку й вимоги CORS. Для loader, який постачальник змінює без версії, цей підхід може бути непридатним.
- Sandboxed iframe: ізолює сумісний embed і дає йому тільки необхідні можливості. Після обмеження перевірте клавіатуру, focus, доступність, resize та обмін повідомленнями.
- Доступи: обмежте право publish у tag manager, увімкніть сильну автентифікацію, журнал погоджень і своєчасне видалення колишніх працівників.
- Fallback: необов’язкова інтеграція має завершитися за timeout, а покупка, запис чи заявка — працювати далі.
Self-hosting дає більше контролю, але переносить на вашу команду оновлення й виправлення вразливостей. Proxy приховає домен у браузері, але не обов’язково змінить одержувача та правову природу передачі даних. Обирайте контроль під конкретний ризик.
Реєстр без процесу застаріє після наступного релізу
Додайте коротку заявку на новий скрипт: ініціатор, сторінки, мета, поля даних, категорія згоди, очікувана користь, performance budget, відповідальний за постачальника, дата перегляду й rollback. Перевіряйте і код, і workspace менеджера тегів — браузер може змінитися з обох місць.
Для критичних шаблонів збережіть погоджений baseline і отримуйте сповіщення про нові origins, frames, connections або зміни security headers. Не кожне оновлення постачальника є атакою, тому алерти потребують triage. Повторюйте synthetic journey після оновлення теми чи плагіна, зміни consent, checkout або платіжного SDK.
У кожної інтеграції мають бути два власники. Бізнес-власник відповідає, чи приносить функція користь. Технічний — як вона завантажується, які дані бачить, як відмовляє та як її вимкнути. «Колись додала агенція» — лише запис в історії.
Перший аудит за 90 хвилин
На виході мають бути три списки: «залишити», «перевірити без нього» й «розслідувати негайно». Невідомий домен на сторінці оплати — у третій. Heatmap без дослідника — у другий. Платіжний SDK, потрібний обраному методу, залишається з відповідальним і тестом відмови.
Поширені запитання
Як знайти всі сторонні скрипти на сайті?
Пройдіть важливі сценарії у браузері зі збереженням Network log і використайте Initiator, щоб побачити непрямо завантажені ресурси. Повторіть до згоди, після відмови, на мобільному пристрої, у кабінеті та під час тестової оплати.
Чи всі зовнішні скрипти сповільнюють сайт?
Кожен має певну вартість, але корисний малий компонент може бути кращим за власну реалізацію. Заблокуйте його в контрольованому тесті, виміряйте різницю у requests, bytes і main-thread time та зіставте з реальною користю.
Чи достатньо додати async?
Ні. Завантаження перестає блокувати розбір HTML, але виконання використовує процесор, конкурує за мережу, може змінювати DOM і викликати інші ресурси. Важливі також сторінка, момент запуску, умова згоди й fallback.
Чи потрібен SRI для кожного зовнішнього скрипту?
SRI добре підходить стабільним файлам із належною підтримкою CORS. Він незручний для loader, який постачальник часто змінює. Використовуйте його там, де можете підтримувати hash, разом із CSP, реєстром, доступами й моніторингом.
Hosted payment повністю усуває ризик скриптів?
Він може суттєво зменшити scope, але все залежить від інтеграції. Сторінка навколо iframe все одно може бути атакована або зламати платіжний сценарій. Уточніть архітектуру й вимоги у провайдера та організації, що приймає PCI validation.
У кожного зовнішнього коду має бути вихід
Сайт легше захищати й розвивати, коли кожне доповнення можна пояснити та скасувати: що воно дає, де виконується, які дані бачить, скільки коштує на реальних пристроях, хто погоджує зміни й що станеться під час відмови постачальника.
Rendframe може скласти карту browser supply chain, зіставити сторонній код із Core Web Vitals і конверсіями, упорядкувати consent та tag logic, посилити критичні сторінки й налаштувати постійні перевірки. Перегляньте послугу продуктового інжинірингу або надішліть одну сторінку й export менеджера тегів для сфокусованого першого огляду. Ми працюємо з бізнесами в Україні та за кордоном.