Playwright, Selenium, Cypress, WebdriverIO: что реально известно о скорости в 2026 году (и как намерить свои цифры)

Значимый прорыв формирует отрасль ИИ: TFStudio 14 минут назад Playwright, Selenium, Cypress, WebdriverIO: что реально известно о скорости в 2026 году (и как намерить свои цифры) Средний 8 мин 530 Браузеры Качество кода * Веб-разработка * Проектирование и рефакторинг * Тестирование IT-систем * Аналитика За последний месяц я насчитал минимум семь свежих статей с заголовком в духе "Playwright быстрее Selenium на N%". Проблема в том, что N у всех разный: 23%, 42%, 63%, "1. Методология почти нигде не раскрыта дальше фразы "controlled environment".

Для решения, которое определяет CI-бюджет и архитектуру тестов на годы вперёд, это не цифры — это шум. Здесь — что из этого шума реально на что-то опирается, почему остальное несопоставимо, и рабочий бенчмарк-харнесс, который вы можете прогнать на своём стеке за один CI-job и получить именно свои числа, а не чужие проценты. Почему вообще должна быть разницаВсе четыре инструмента по-разному говорят с браузером, и это архитектурное решение — не деталь, а главная причина разницы в скорости.

Технические детали

Selenium работает через протокол WebDriver: команда из теста идёт HTTP-запросом к драйверу браузера (chromedriver/geckodriver), тот транслирует её в нативный вызов. Каждое действие — это запрос-ответ по HTTP, и эта связка добавляет задержку на каждом шаге. Selenium 4 добавил протокол BiDi (двунаправленный, поверх WebSocket) для части операций — сетевого перехвата, логов консоли, — но базовое исполнение команд по-прежнему идёт через HTTP-слой WebDriver.

Cypress в принципе не выходит за пределы браузера: тестовый раннер исполняется в том же event loop, что и тестируемое приложение, без какого-либо внешнего протокола между ними. Это даёт нулевую сетевую задержку на каждое действие, но ценой архитектурных ограничений — Cypress не может по-настоящему управлять вторым табом, потому что сам раннер занимает iframe рядом с приложением. Playwright подключается к браузерам напрямую по их нативным debug-протоколам — Chrome DevTools Protocol для Chromium, патченый Marionette для Firefox, WebKit Inspector Protocol для WebKit — через постоянное WebSocket-соединение.

HTTP-слоя между тестом и браузером нет в принципе. WebdriverIO — особый случай: он может работать и через классический WebDriver-протокол (тогда архитектурно близок к Selenium), и через DevTools/BiDi-протокол. Поэтому в части бенчмарков WDIO попадает в категорию "быстрый", а в части — в категорию "как Selenium", и это зависит исключительно от того, какой драйвер выбрал автор теста.

Из этого уже можно сделать архитектурный вывод без единого замера: WebSocket-протоколы (Playwright, WDIO в DevTools-режиме) структурно не могут быть медленнее, чем HTTP-polling (классический WebDriver), при прочих равных. Вопрос не "будет ли разница", а "насколько она проявится на конкретном тест-сьюте".

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.