Playwright против Selenium: практическое сравнение для веб-скрапинга и автоматизации

Мы установили оба инструмента, выполнили одни и те же задачи автоматизации и скрейпинга, подключили оба к прокси и сравнили, что произошло на практике.

Большинство сравнений Playwright и Selenium в интернете - это списки функций, скопированные из документации. Вам говорят, что у Playwright есть автоматическое ожидание, а у Selenium более крупная экосистема, и на этом всё.

Мы установили Playwright и Selenium на одной и той же машине, построили в обоих один и тот же простой сценарий автоматизации, подключили оба к прокси и собрали данные с одной и той же страницы. Каждое утверждение, подкреплённое практическим тестом, помечено. Там, где мы ещё не проводили тест, вы увидите заполнитель, а не догадку.

Сравнение охватывает настройку, динамические сайты, скрейпинг, интеграцию прокси и повседневный опыт разработчика. Если вы выбираете между Playwright и Selenium для проекта по скрейпингу, набора QA-тестов или стека автоматизации на прокси, этот материал призван помочь вам определиться, опираясь на то, что произошло на практике.

Скрейпите веб в больших объёмах? Попробуйте резидентные и мобильные прокси NodeMaven за $3.50 и получите 750MB трафика

Попробовать сейчас

Краткий ответ: Playwright или Selenium?

На основе практического тестирования в этой статье:

• Выбирайте Playwright если вы начинаете новый проект по автоматизации или скрейпингу, особенно на сайтах с обилием JavaScript. Ему не понадобилось ни одного явного ожидания, чтобы пройти сценарий входа в систему и тест динамического контента из четырёх случаев, который Selenium прошёл только после добавления логики WebDriverWait.
• Выбирайте Selenium если у вас уже развернута инфраструктура Selenium, вы используете Selenium Grid или вам нужна максимально широкая поддержка браузеров и языков. Он собрал те же 60 элементов, что и Playwright, и в нашем запуске завершил работу быстрее.
• Самый заметный результат: настройка прокси с аутентификацией. Playwright принял учетные данные прокси прямо в конфигурации запуска. Selenium потребовал ручного взаимодействия с диалогом аутентификации Chrome, и наша попытка автоматизировать этот шаг не дала стабильного результата.

Это краткая сводка по тестам ниже, а не их замена. Полный разбор, включая все замеры времени и сообщения об ошибках, приведен далее.

Playwright и Selenium: краткое сравнение

Таблица выше - это отправная точка. Настоящий ответ дают практические разделы ниже.

Что мы тестировали

Оба инструмента прошли один и тот же базовый сценарий, на одном языке и на одной машине:

1. Открыть сайт
2. Найти элемент
3. Кликнуть по нему
4. Ввести данные
5. Дождаться динамического контента
6. Извлечь информацию
7. Подключить прокси

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

Установка и первая настройка

Playwright устанавливается одним пакетом, который также загружает собственные бинарные файлы браузеров, поэтому отдельный шаг с драйвером для Chromium, Firefox или WebKit не нужен.

Selenium в большинстве случаев тоже больше не требует ручного управления драйверами. Selenium Manager, входящий в пакет Selenium начиная с версии 4.6, определяет установленный браузер и автоматически загружает подходящий драйвер. Ручная загрузка драйверов сейчас нужна в основном для нестандартных случаев, особых версий драйверов или сред без доступа к сети.

Установка и первичная настройка: Playwright

Для практического теста мы установили Playwright в чистое виртуальное окружение Python. В тесте использовался Python 3.14.7 и Playwright 1.62.0.

Сама установка пакета заняла 16.57 секунды. Затем Playwright потребовал дополнительного шага установки браузеров. Выполнение playwright install заняло 1 минуту 39 секунд.

После установки мы запустили Chromium небольшим скриптом на Python и открыли example.com. Первый успешный запуск браузера занял 9.33 секунды.

Полные результаты были такими:

Playwright отделяет Python-пакет от управляемых им бинарных файлов браузеров. Это добавляет дополнительный шаг установки, но при этом дает Playwright контроль над версиями браузеров, используемых в автоматизации.

Для этого теста Playwright потребовал одной установки пакета и одного шага установки браузеров. Отдельный WebDriver или ручная загрузка драйвера не понадобились.

Установка и первичная настройка: Selenium

Для того же практического теста мы установили Selenium в новом виртуальном окружении Python. Мы использовали ту же версию Python, что и в тесте Playwright, Python 3.14.7. Установленная версия Selenium была 4.47.0.

Установка пакета Selenium заняла 32,15 секунды. Ошибок при установке не возникло.

В отличие от Playwright, Selenium в этом тесте не потребовал отдельной загрузки браузера. У нас уже был установлен Chrome, и Selenium Manager автоматически подобрал нужный драйвер при запуске браузера из скрипта. Мы не устанавливали ChromeDriver вручную.

Первый успешный запуск Chrome и загрузка страницы заняли 8,93 секунды.

Полные результаты были такими:

Результаты показывают иной подход к установке по сравнению с Playwright. Python-пакет Selenium в нашем тесте устанавливался дольше, но отдельной загрузки браузера не потребовалось, поскольку Chrome уже был установлен. Selenium Manager также избавил от необходимости вручную устанавливать ChromeDriver.

Вердикт по итогам практики: Selenium устанавливался как Python-пакет немного дольше, но в этой среде потребовал меньше первоначальной настройки. Так как Chrome уже был установлен, Selenium Manager автоматически подобрал драйвер и запустил браузер за 8.93 секунды. Playwright в целом занял больше времени, поскольку его установка включала загрузку управляемых им бинарных файлов браузера.

Запускаете Playwright или Selenium с прокси? Получите резидентные и мобильные прокси NodeMaven за $3.50 и 750MB трафика

Попробовать сейчас

Пишем одну и ту же автоматизацию на Playwright и Selenium

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

Чтобы честно сравнить Playwright и Selenium, мы построили один и тот же сценарий на Python с помощью обоих инструментов. Целью была форма входа на тестовом сайте The Internet.

Сценарий был простым:

1. Открыть страницу входа.
2. Ввести имя пользователя.
3. Ввести пароль.
4. Нажать Login.
5. Прочитать сообщение об успешном входе.
6. Закрыть браузер.

Мы также проверили, что происходит, когда в сценарии возникает проблема.

Реализация на Playwright

В версии на Playwright использовался следующий код:

Реализация содержит 12 непустых строк кода. Явного ожидания нет.

Скрипт открыл страницу, заполнил оба поля, отправил форму и успешно извлёк итоговое сообщение с первой попытки.

Успешный запуск дошёл до Secure Area и вывел сообщение с подтверждением:

Вы вошли в защищённую зону!

Это было первое практическое преимущество, которое мы заметили. Базовый сценарий потребовал очень немного кода для настройки. К тому же действия читаются близко к тому, что реально делает браузер.

Реализация на Selenium

Затем мы воспроизвели тот же сценарий в Selenium.

Первоначальная версия выглядела так:

Первоначальная реализация на Selenium также содержала 12 непустых строк.

Однако первый запуск не завершился успешно.

Браузер открыл страницу, заполнил оба поля и нажал Login. Сбой произошёл, когда Selenium сразу попытался найти #flash элемент.

Он вернул NoSuchElementException.

Это была не ошибка в селекторе, а вопрос тайминга. Страница ещё не отобразила элемент к тому моменту, когда Selenium вызвал find_element().

Добавление явного ожидания

Мы исправили версию на Selenium, добавив явное ожидание:

Итоговая версия на Selenium содержит 15 непустых строк.

Три дополнительные строки связаны с явным ожиданием и необходимыми для него импортами.

После добавления ожидания тот же сценарий завершился успешно.

Результаты внедрения

Это не значит, что Selenium всегда требует явного ожидания. Это значит, что именно в этом сценарии мгновенного поиска элемента в Selenium оказалось недостаточно.

Playwright справился с тем же переходом без дополнительного кода ожидания.

Эта разница становится важной по мере роста скрипта автоматизации. Несколько дополнительных инструкций ожидания сами по себе не проблема. Затраты на поддержку становятся заметнее, когда тест содержит множество динамических элементов и изменений состояния.

Тестирование сломанного селектора

Мы также хотели сравнить процесс отладки, а не просто сопоставить успешные запуски.

Тестирование сломанного селектора в Playwright

Для Playwright мы намеренно изменили селектор поля username с:

до:

Теперь селектор был неверным.

Playwright открыл нужную страницу входа, но ждал отсутствующий локатор. Через 30 секунд он выдал:

В момент возникновения ошибки браузер всё ещё находился на странице входа.

Ошибка была подробной. В ней указывались сбойная операция, селектор и журнал вызовов. Однако из-за таймаута по умолчанию в 30 секунд диагностика простой опечатки в селекторе оказалась сравнительно медленной.

Тот же сломанный селектор в Selenium

Мы допустили точно такую же ошибку в Selenium:

Selenium завершился с ошибкой сразу же. Ошибка указывала на строку 10 и показывала селектор, который Selenium пытался найти.

Это дало интересный контраст.

Playwright ждал отсутствующий локатор, а затем вернул подробную ошибку таймаута. Прямой find_element() в Selenium сразу завершился с ошибкой NoSuchElementException.

При опечатке в селекторе мгновенный сбой Selenium может быстрее указать на проблему. Однако на асинхронных страницах тот же мгновенный поиск может стать проблемой, если элементу просто нужно больше времени, чтобы появиться.

Наш вывод по итогам практики

После использования обоих инструментов в одном и том же рабочем сценарии Playwright оказался удобнее в этом конкретном тесте.

Главная причина не в количестве команд, необходимых для запуска Chrome. Оба инструмента быстро открывали браузер. Разница проявилась, когда страница изменила состояние после нажатия Login.

Playwright прошёл весь сценарий без добавления явной логики ожидания. Selenium сначала давал сбой в той же точке и потребовал WebDriverWait чтобы сценарий работал стабильно.

Тест на отладку оказался более неоднозначным. Selenium сразу сообщил об отсутствующем селекторе. Playwright дождался истечения тайм-аута по умолчанию, а затем выдал подробный отчёт о тайм-ауте с журналом вызовов локатора.

Автоматизируете работу в вебе в больших масштабах? Начните с резидентных прокси NodeMaven за $3.50 и 750MB трафика

Попробовать сейчас

Практические результаты кратко

Динамические сайты и ожидания

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

Именно здесь Playwright и Selenium используют заметно разные подходы.

Playwright автоматически ждёт, пока элементы придут в состояние, готовое к действию, прежде чем выполнять такие действия, как click() или fill(). Во многих типичных сценариях это означает, что отдельный код ожидания не требуется.

Selenium даёт более явный контроль над синхронизацией. Типичный подход — WebDriverWait в сочетании с ожидаемыми условиями, такими как element_to_be_clickable() или visibility_of_element_located(). Это делает поведение ожидания явным, но добавляет в автоматизацию дополнительный код.

Практический тест: поведение ожидания

Чтобы сравнить два подхода, мы создали локальную тестовую страницу, содержащую четыре разные ситуации:

1. Элемент, доступный сразу
2. Элемент, появляющийся с задержкой
3. Контент, отрисованный динамически с помощью JavaScript
4. Кнопка, которая становится активной после изменения состояния

Затем мы запустили одни и те же четыре теста в обоих фреймворках.

Результат Playwright

Playwright прошёл все четыре случая без добавления в тест явной логики ожидания.

Полный тест завершился за 2,56 секунды.

Важная часть теста состояла в том, что обычные действия Playwright можно было использовать напрямую. Его встроенное поведение ожидания само обрабатывало готовность элементов, не требуя отдельного механизма в стиле WebDriverWait.

Результат Selenium

Selenium также успешно прошёл все четыре случая, но реализация потребовала явной синхронизации с использованием WebDriverWait и ожидаемых условий.

Тест завершился за 3,96 секунды.

В реализации на Selenium использовались такие условия, как:

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

Результаты тестов

В этом конкретном запуске Selenium занял на 1,40 секунды больше. Это не следует воспринимать как общий бенчмарк производительности фреймворков, поскольку тест был небольшим и выполнялся только один раз. Более значимым отличием было количество необходимого кода синхронизации.

Что показал тест

Оба фреймворка успешно справились со всеми четырьмя динамическими сценариями. Разница заключалась в основном в том, какую долю ответственности за синхронизацию приходилось брать на себя разработчику.

Драматург: меньше кода для типичных динамических взаимодействий, поскольку ожидание встроено в его действия.

Selenium: более явный контроль над условиями ожидания, но ценой дополнительного кода и логики селекторов.

Для современных сайтов с большим объёмом JavaScript, где элементы часто появляются или динамически меняют состояние, встроенное ожидание Playwright позволяет быстрее написать первоначальный код автоматизации и делает его более читаемым. Явный подход Selenium может оказаться полезнее, когда проекту нужен точный контроль над тем, в какой именно момент элемент следует считать готовым.

Нужны надёжные прокси для автоматизации браузера? Попробуйте резидентные и мобильные прокси NodeMaven за $3.50

Попробовать сейчас

Веб-скрейпинг с Playwright и Selenium

И Playwright, и Selenium умеют управлять настоящим браузером и извлекать данные с отрисованных страниц. Это важно, когда сайт полагается на JavaScript или на поведение браузера, которое простой HTTP-запрос воспроизвести не может.

Для сравнения мы собрали один и тот же небольшой скрапер на обоих инструментах. Мы использовали Books to Scrape, публичный сайт, созданный для практики скрапинга. Скрапер посещал три страницы и извлекал одни и те же три поля для каждой книги:

• Заголовок
• Цена
• ссылка на товар

Каждая страница содержала 20 книг, поэтому ожидаемым результатом было 60 элементов.

Скрапер на Playwright

Реализация на Playwright использовала навигацию по браузеру, CSS-селекторы и локаторы элементов для извлечения данных:

Скрапер обработал все три страницы и извлёк 60 из 60 элементов без ошибок.

Вывод в терминале подтвердил полное извлечение данных:

Обработано страниц: 3

Извлечено элементов: 60

Первые пять названий и цен также были извлечены корректно.

Скрапер на Selenium

Затем мы создали такой же скрапер на Selenium:

Selenium также извлёк 60 из 60 элементов со всех трёх страниц.

Первые пять названий и цен совпали с результатами Playwright.

Вывод Selenium также вернул абсолютные URL товаров, тогда как реализация на Playwright вернула относительные href значения со страницы. Это связано с тем, как каждая реализация получает атрибут ссылки, и не является значимой разницей в точности скрапинга.

Результаты скрапинга

Нужна надёжная аутентификация прокси для автоматизации браузера? Попробуйте резидентные прокси NodeMaven за $3.50

Попробовать сейчас

Что показал тест

Для этой простой задачи скрапинга оба инструмента оказались надёжными.

Ни одному из фреймворков не потребовалась особая обработка пагинации. Структура страницы была единообразной, и оба инструмента успешно нашли все карточки товаров и извлекли запрошенные поля.

Объём кода также был примерно одинаковым. Основное различие заключалось в API, который используется для работы с наборами элементов.

Playwright использует локаторы:

а затем работает с отдельными карточками через:

Selenium возвращает коллекцию объектов WebElement:

Затем версия на Selenium работает напрямую с каждым элементом из полученного списка.

Наш вывод: Playwright против Selenium для веб-скрапинга

В случае этого конкретного скрапера разница между двумя инструментами оказалась меньше, чем мы ожидали.

Selenium оказался простым в использовании, как только стали известны структура страницы и селекторы. Его find_elements() API позволяет легко собрать список подходящих элементов и пройтись по ним в цикле.

API локаторов в Playwright тоже оказался лаконичным и хорошо справился с повторяющимися карточками товаров.

Для простой статической цели скрапинга вроде Books to Scrape мы не стали бы выбирать между Playwright и Selenium, опираясь только на скрапинг. Оба извлекли 100% ожидаемых элементов в нашем тесте.

Поддержка прокси: Playwright против Selenium

Чтобы честно сравнить поддержку прокси, мы протестировали оба фреймворка с одним и тем же прокси NodeMaven и с одной и той же целью, https://api.ipify.org/?format=json. Сравнение было сосредоточено на прокси с аутентификацией по имени пользователя и паролю, поскольку это распространённая конфигурация, когда провайдер прокси требует учётные данные.

Это выявило одно из самых наглядных практических различий между двумя инструментами.

Поддержка прокси в Playwright

Playwright позволил указать прокси-сервер, имя пользователя и пароль прямо в конфигурации запуска браузера. Тест завершился успешно без какого-либо дополнительного механизма аутентификации.

Результат

• Подключение через прокси: Пройдено
• Определённый IP: 109.127.17.1
• Время выполнения: 7,94 секунды
• Дополнительная настройка аутентификации: Нет

Полученный IP отличался от локального подключения, что подтверждает: трафик шёл через прокси.

Поддержка прокси в Selenium

Тест с Selenium выявил важное практическое различие.

Сначала мы настроили Chrome с хостом и портом прокси NodeMaven. Chrome успешно подключился к прокси, но показал встроенное диалоговое окно аутентификации с запросом имени пользователя и пароля прокси.

После ручного ввода учётных данных страница успешно загрузилась и вернула:

{“ip”:”188.64.10.56″}

Это подтвердило, что браузер Selenium мог успешно использовать тот же прокси при наличии аутентификации.

Затем мы попытались автоматизировать аутентификацию через расширение Chrome. Несмотря на несколько итераций, автоматизированный вариант продолжал возвращаться к локальному IP вместо надёжной аутентификации через прокси.

Поэтому мы не считать автоматизированный результат Selenium успешным тестом прокси.

Важное исключение для Selenium: добавление IP в белый список

Наш тест прокси с аутентификацией проходил в одинаковых условиях для обоих фреймворков. Playwright справился с аутентификацией по имени пользователя и паролю намного проще, тогда как автоматическая аутентификация в Selenium в нашем тесте не работала стабильно.

Однако Selenium может хорошо работать с прокси, когда Белый список IP-адресов доступен. Вместо передачи учётных данных через браузер провайдер авторизует ваш публичный IP, что позволяет избежать диалога аутентификации Chrome.

Мы протестировали добавление IP в белый список отдельно с NodeMaven, и Selenium подключился успешно, вернув IP, отличный от прямого соединения.

Это был отдельный тест, поэтому он не включён в сравнение методов аутентификации. Для настройки Selenium, включая добавление IP в белый список, проверку IP, sticky-сессии и ротацию, см. наше Руководство по прокси для Selenium.

Итоговое сравнение: Playwright и Selenium при работе с прокси

Что показал тест

Самое большое различие заключалось не в производительности браузера. Дело было в сложности настройки.

В Playwright учётные данные прокси с аутентификацией являются частью конфигурации запуска браузера:

В Selenium настройка самого прокси была простой, но работа с прокси, требующим аутентификации, потребовала дополнительного механизма, специфичного для Chrome. Наш ручной тест сработал, а попытка автоматизировать эту аутентификацию не дала надёжного результата.

По результатам реального теста Playwright оказался существенно проще в настройке для прокси с аутентификацией.

Запускаете Playwright или Selenium с прокси? Получите резидентные и мобильные прокси NodeMaven за $3.50 и 750MB трафика

Попробовать сейчас

Выбор типа прокси для автоматизации на Playwright или Selenium

Выбранный фреймворк не меняет того, что должен делать сам прокси: сохранять авторизацию, не попадать под блокировки и удерживать сессию, когда этого требует рабочий процесс. В автоматизации на Playwright и Selenium регулярно встречаются несколько типов прокси:

• Резидентские прокси для скрапинга и автоматизации, которым нужен большой ротируемый пул реальных домашних IP.
• Мобильные прокси для процессов, завязанных на mobile-first платформы или требующих IP операторского уровня.
• ISP-прокси (статические резидентные) для длительных сессий, где один и тот же IP должен сохраняться на протяжении многошагового скрипта Playwright или Selenium.

Прежде чем запускать сессию автоматизации через любой прокси, стоит убедиться, что браузер не раскрывает ваш реальный IP в обход него. Инструмент NodeMaven бесплатный тест на утечку WebRTC проверяет это меньше чем за минуту и не требует регистрации.

В этой статье сравниваются фреймворки, а не шаги настройки прокси. Настройка прокси NodeMaven в Playwright или Selenium описана в отдельных пошаговых руководствах.

Итоговые результаты тестов Playwright против Selenium

Кому стоит выбрать Playwright?

В нашем тестировании Playwright лучше всего подошёл для:

• Новых проектов автоматизации или скрапинга, где нет уже принятого решения по фреймворку, под которое пришлось бы подстраиваться.
• Сайтов с большим объёмом JavaScript или динамическим содержимым, где наш сценарий входа в аккаунт и тест ожидания из четырёх случаев прошли без дополнительного кода синхронизации.
• Команд, которые хотят поддерживать меньше строк логики таймингов. Наш итоговый сценарий уложился в 12 строк, потому что явные ожидания не понадобились.
• Конфигураций с прокси, требующими авторизации, где в нашем тесте Playwright принимал учётные данные прокси прямо в конфигурации запуска браузера, без отдельного шага аутентификации.
• Проекты, которым выгодна изоляция контекстов браузера для запуска нескольких сессий без отдельных экземпляров драйвера.

Если ваш проект начинается с нуля и не зависит от уже используемой инфраструктуры Selenium, наши результаты указывают на Playwright как на вариант с меньшим сопротивлением.

Кому стоит выбрать Selenium?

Selenium остаётся разумным выбором, и наше тестирование подтверждает это в отдельных случаях:

• Существующие кодовые базы на Selenium. Здесь нет свидетельств того, что миграция уже сложившегося набора тестов окупится только за счёт стабильности или точности скрапинга.
• Selenium Grid или распределённая тестовая инфраструктура. В этой статье Grid напрямую не тестировался, но это зрелый, специально созданный элемент экосистемы Selenium, который Playwright и не стремится заменить.
• Широкое покрытие браузеров, включая Edge, Safari и IE через драйверы, помимо Chromium, Firefox и WebKit.
• Команды, которым нужен явный контроль над синхронизацией. WebDriverWait с expected conditions требует больше кода, но делает точное условие ожидания видимым в скрипте, а не скрытым внутри фреймворка.
• Статические или более простые цели скрапинга. В нашем тесте скрапинга Selenium извлёк все 60 элементов и завершил работу быстрее, чем Playwright, в этом единственном прогоне (17.49 сек против 27.00 сек).
• Немедленная ошибка при некорректных селекторах. В нашем тесте со сломанным селектором find_element() в Selenium сразу завершился ошибкой с понятным NoSuchElementException, тогда как Playwright дождался своего 30-секундного тайм-аута, прежде чем сообщить о той же проблеме.

Если у вас уже есть инфраструктура Selenium, широкая матрица тестируемых браузеров или команда, свободно владеющая WebDriver, наши результаты не дают весомых причин переходить на другое решение.

Готовы протестировать свой скрапер на реальных резидентных и мобильных IP? Попробуйте NodeMaven за $3.50 и получите 750MB трафика

Попробовать сейчас

Playwright vs Selenium FAQ