Stealth-браузер від BrowserAct пройшов перевірку на виявлення ботів, тоді як стандартний headless-режим Playwright був ідентифікований як бот, хоча обидва скрипти виконали однаковий процес входу. Цей контраст демонструє, чому агентний підхід може бути безпечнішим, коли потрібно взаємодіяти з сайтами, що захищаються від автоматизації.
Чому цей тест важливий
Інструменти автоматизації забезпечують тестування, збір даних та управління обліковими записами. Більшість розробників обирають фреймворки на основі селекторів, такі як Playwright, тому що вони дозволяють писати точні інструкції — «натиснути кнопку з цим CSS-селектором» — і швидко перевіряти результати. Однак сучасні сайти вбудовують скрипти, які виявляють headless-браузери за такими ознаками: загальний рядок user-agent, властивість webdriver або відсутність патернів взаємодії, притаманних людині. Коли з'являються ці сигнали, сайт блокує запит або видає CAPTCHA, фактично знешкоджуючи скрипт.
Агентні браузери намагаються імітувати поведінку людини, не покладаючись на заздалегідь написані селектори. Вони сприймають сторінку як набір елементів, з якими можна взаємодіяти, обираючи потрібний за його позицією у внутрішньому індексі, а не за CSS-шляхом. У тесті порівнювалися два підходи на сторінці входу з рендерингом JavaScript та на сайті, який навмисно перевіряє користувачів на наявність ботів.
Експеримент
Я написав два скрипти, які виконували однакові кроки: завантаження сторінки входу, введення облікових даних, відправка форми та перехід на сторінку інвентарю. Один скрипт використовував Playwright у стандартному headless-режимі; інший — stealth-браузер від BrowserAct, який маскує відбитки (fingerprints), що активують виявлення ботів.
Обидва скрипти пройшли автентифікацію на пісочниці (sandbox site), довівши, що основний процес входу працює незалежно від інструменту. Розбіжність з'явилася, коли скрипти перейшли на спеціальну сторінку перевірки ботів, яка повертає JSON-прапорець isBot. Playwright повідомив isBot: true, пройшовши п'ять окремих перевірок на виявлення. BrowserAct повернув isBot: false, що означало, що сторінка сприйняла його як звичайного відвідувача-людину.
Я з'ясував причину різниці у двох технічних деталях. Стандартна конфігурація Playwright надсилає загальний рядок user-agent і залишає відкритим прапорець webdriver — обидві ознаки легко помітити скрипту виявлення. Stealth-режим BrowserAct перезаписує user-agent, видаляє властивість webdriver і узгоджує свій відбиток із відбитком типового десктопного браузера.
Як інструменти відрізняються «під капотом»
| Аспект | Playwright (стандартний) | BrowserAct (stealth) |
|---|---|---|
| Модель взаємодії | На основі селекторів, детермінована | На основі агентів, на основі індексу |
| Необхідність заздалегідь написаних селекторів | Обов'язково; скрипт має знати точну структуру DOM | Не обов'язково; агент знаходить елементи для взаємодії під час виконання |
| Обробка змін макета | Перестає працювати, якщо селектори зміщуються | Продовжує роботу, поки позиції елементів залишаються в індексованому списку |
| Вразливість до перевірок на ботів | User-agent та webdriver залишаються без змін |
Відбитки навмисно маскуються |
| Типовий сценарій використання | Внутрішні сайти, стабільний інтерфейс, швидкі цикли тестування | Публічні сайти з засобами проти автоматизації, сторінки, що постійно змінюються |
У таблиці відображено практичні компроміси. Playwright найкраще підходить, коли ви контролюєте сайт і можете гарантувати стабільність ідентифікаторів елементів. Агентний браузер незамінний, коли ви не можете передбачити структуру сторінки або коли сайт активно намагається блокувати скрипти.
Кому це вигідно і хто під загрозою
Розробники, які створюють набори регресійних тестів для власних застосунків, можуть мінімізувати витрати та підтримувати високу швидкість тестування, використовуючи Playwright. Його детермінована природа дозволяє чітко вказувати на регресії в коді, а відсутність додаткових рівнів маскування зменшує складність.
Навпаки, команди, які займаються парсингом даних, автоматизацією створення облікових записів або моніторингом сайтів конкурентів, часто стикаються з перешкодами, оскільки цільові сторінки часто змінюються або мають агресивні системи виявлення ботів. У таких сценаріях агентний браузер дозволяє уникнути миттєвого тупика «ви — бот» і продовжує шлях до потрібних даних.
Приховані витрати успішного виконання («it worked»)
Я застерігаю: успішний код завершення не гарантує, що автоматизація спрацювала так, як планувалося. Під час запуску Playwright скрипт завершився без помилок, проте сторінка все одно вважала запит ботом. Результатом став прихований збій: наступні етапи, які покладаються на контент, доступний лише людям, так і не отримали очікуваних даних.
Щоб виявити такі приховані помилки, перевіряйте дані сторінки після кожного запуску: позицію прокрутки, висоту документа та мережеві запити. Якщо DOM виглядає інакше, ніж те, що бачить людина, або якщо мережевий трафік містить неочікувані перенаправлення на перевірки, автоматизація, ймовірно, не досягла своєї мети.
Підсумок
Якщо ви володієте сайтом і можете писати скрипти, використовуючи стабільні селектори, Playwright залишається прагматичним вибором — швидким, дешевим і простим у інтеграції в CI-пайплайни. Коли ви стикаєтеся з невідомими макетами, агресивним захистом від автоматизації або частими змінами UI, браузерний агент, такий як BrowserAct, пропонує більш стійкий шлях. Не довіряйте успішному запуску сліпо; переконайтеся, що сторінка поводилася так, як це зробила б людина, і обирайте інструмент, який відповідає профілю ризиків вашого цільового сайту.