Когда в ТЗ написано «спарсить цены с сайта на React» или «прогнать сценарий записи на Tilda после каждого деплоя», первый вопрос - хватит ли обычных requests или без Selenium - автоматизации браузера с полноценным рендерингом JS - тут не обойтись. За несколько лет работы с парсингом, ботами на aiogram и сценариями в n8n я отвечаю на этот вопрос за пять минут: открываю страницу с отключённым JS в DevTools и смотрю, остаётся ли на месте нужный контент.
Requests против Selenium: где заканчивается HTML и начинается браузер
Requests с BeautifulSoup или lxml тянут HTML-документ ровно таким, каким его отдаёт сервер до выполнения скриптов. Для статичных страниц с готовой разметкой - блог на WordPress, каталог на чистом PHP, RSS-лента - этого хватает, и связка отрабатывает за миллисекунды на запрос.
Сложности начинаются там, где контент собирается прямо в браузере после загрузки: SPA на React или Vue, каталоги с бесконечной подгрузкой через XHR, личные кабинеты, где данные приходят уже после авторизации через JS-сессию. На одном проекте цена и остаток товара в каталоге подтягивались отдельным запросом через секунду после рендера страницы - requests получал пустой div с нужным id, а цифры появлялись в DOM только после выполнения скрипта. Здесь и нужен Selenium: он запускает настоящий движок Chrome или Firefox, ждёт события, кликает по элементам и возвращает итоговый DOM, а не сырой ответ сервера.
Как Selenium 4 запускает браузер и находит элементы
С версии 4.6 в библиотеку встроен Selenium Manager - он сам подбирает и скачивает нужную сборку chromedriver под установленный браузер, вручную драйвер качать не приходится. Установка сводится к pip install selenium и запуску Chrome или Firefox в обычном либо headless-режиме.
Базовый сценарий такой: открыть страницу, дождаться появления элемента через WebDriverWait (обычный time.sleep на нестабильных сайтах то зависает, то отдаёт пустые результаты), найти элемент через By.CSS_SELECTOR или By.XPATH, кликнуть по нему или прочитать текст.
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
options = webdriver.ChromeOptions()
options.add_argument("--headless=new")
driver = webdriver.Chrome(options=options)
driver.get("https://example.com/catalog")
price = WebDriverWait(driver, 10).until(
EC.presence_of_element_located((By.CSS_SELECTOR, ".product-price"))
)
print(price.text)
driver.quit()Вложенные iframe, модалки с согласием на cookies, ленивая подгрузка через Intersection Observer - со всем этим Selenium справляется штатно, потому что видит страницу так же, как обычный посетитель в браузере, а не как HTTP-клиент, разбирающий текстовый ответ сервера.
Практические кейсы: где браузерная автоматизация закрывает задачу
На практике браузерная автоматизация чаще всего закрывает пять типов задач, и почти в каждой requests просто не справится:
- Мониторинг цен и остатков на сайтах конкурентов, где данные подгружаются через JS и открыты без авторизации - Selenium дожидается нужного блока и снимает цифры раз в несколько часов по расписанию.
- Регрессионное тестирование форм на Tilda после доработки скрипта: заполняю поля, отправляю форму, проверяю редирект и запись в CRM - вручную такой прогон занимает 20-30 минут, скриптом - полторы минуты.
- Действия в личном кабинете СДЭК, где для нужной операции нет открытого API - эмулирую последовательность оператора: логин, выбор накладной, скачивание этикетки.
- Сквозное тестирование сценариев бота на aiogram через веб-версию Telegram: проверяю, что бот отвечает на команду и присылает нужную клавиатуру, без ручного клика в приложении на телефоне.
- Триггер для n8n: HTTP Request node закрывает большинство интеграций, но там, где источник отдаёт данные только после рендера, ставлю отдельный Selenium-воркер, который n8n дёргает по вебхуку и получает готовый JSON в ответ.
Часть таких сценариев я уже собирал раньше и оформил в рабочие заготовки - в библиотеке готовых скриптов есть шаблоны под мониторинг цен и автозаполнение форм, которые быстрее адаптировать под свой сайт, чем писать логику с нуля.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Ограничения: скорость, память и честная автоматизация
У Selenium есть цена за возможности. Запуск браузера - это секунды, а не миллисекунды: на холодный старт headless Chrome уходит 1-2 секунды, на такой же запрос через requests - 50-150 мс. Для обхода каталога из 10 000 страниц разница выливается в часы против минут, если сайт вообще отдаёт нужные данные без рендера в JS.
Память тоже ощутимая: один инстанс headless Chrome ест 150-300 МБ, десять параллельных воркеров на сервере - уже 2-3 ГБ, и бюджетный VPS такую нагрузку не потянет, нужен инстанс помощнее.
Вёрстка сайта-источника меняется без предупреждения - ломаются селекторы, и скрипт нужно поддерживать так же, как любой другой код в проде. Для задач сбора открытых данных без авторизации закладываю рандомизацию отпечатка браузера (размер окна, user-agent, часовой пояс), паузы между действиями и соблюдение rate-limit - это снижает число ложных блокировок и не создаёт лишней нагрузки на чужой сервер. Собираю только то, что доступно без авторизации, и с оглядкой на robots.txt - это вопрос не только этики, но и стабильности самого скрипта в долгую.
Selenium, Playwright и requests - что выбрать
| Инструмент | Выполняет JS | Скорость | Когда беру |
|---|---|---|---|
| requests + BeautifulSoup | Нет | Миллисекунды на запрос | Статичный HTML, открытые API, RSS-ленты |
| Selenium | Да, полноценный браузер | Секунды на страницу | Legacy-проекты, широкая поддержка браузеров, готовая инфраструктура Selenium Grid |
| Playwright | Да, полноценный браузер | Секунды на страницу, старт чуть быстрее Selenium | Новые проекты, встроенное ожидание элементов, стабильная работа с несколькими вкладками |
На новых проектах я всё чаще беру Playwright - меньше шаблонного кода на ожидания и стабильнее работа с несколькими вкладками и контекстами одновременно. Но там, где уже развёрнут Selenium Grid, тесты написаны на Java или в контракте прямо указан Selenium (в корпоративных проектах такое встречается регулярно), меняю инструмент только если это оправдано бюджетом и сроками.
Сроки и стоимость внедрения
Простой скрипт на Selenium - открыть страницу, собрать 5-10 полей, сохранить в таблицу или отправить в CRM - занимает 2-3 дня вместе с тестированием на реальных данных сайта-источника. У меня такая задача стоит от 20 000 ₽ (услуга «Парсинг/автоматизация на Python»).
Интеграция с личным кабинетом СДЭК или другой закрытой системой, где нужно логиниться, обрабатывать сессию и держать скрипт устойчивым к изменениям верстки, - это уже комплексная доработка, от 40 000 ₽. Если результат работы Selenium-скрипта нужно встроить в цепочку n8n или в Telegram-бота на aiogram, стоимость самой автоматизации в n8n (от 25 000 ₽) или бота (от 30 000 ₽) считаю отдельно, в зависимости от того, что уже есть у клиента.
На рынке у фрилансеров и в студиях цена похожей задачи гуляет широко - от 10 000 до 150 000 ₽ в зависимости от того, входит ли в неё только код или ещё сервер, мониторинг и правка селекторов при изменении разметки источника. Я обычно закладываю техподдержку отдельно (от 15 000 ₽/мес), потому что сайты меняют вёрстку без предупреждения, и скрипт, который стабильно отработал полгода, может сломаться в любой момент из-за чужого редизайна.
Данные и процессы на автопилоте
Парсинг / Автоматизация
от 20 000 ₽
Подробнее →Частые вопросы
Чем Selenium отличается от Playwright?
Оба запускают настоящий браузер и выполняют JS, разница в API и деталях: у Playwright встроенное ожидание элементов, почти никогда не нужно вручную городить WebDriverWait, из коробки работает с несколькими вкладками и контекстами. Selenium старше, стабильнее на legacy-проектах и шире по поддержке языков и связке с Selenium Grid для распределённого запуска тестов на разных браузерах.
Нужен ли Selenium для парсинга интернет-магазина на Tilda?
Зависит от конкретного блока. Каталог на стандартном движке Tilda обычно отдаёт товары в HTML сразу, requests с этим справляется без браузера. А вот кастомные виджеты с ценами, подгруженными через отдельный JS-скрипт (частый случай при интеграции с CRM или сторонним прайсом), требуют браузера - Selenium дожидается, пока скрипт отработает, и только потом снимает данные.
Можно ли запускать Selenium на сервере без графического интерфейса?
Да, для этого есть headless-режим - браузер стартует без окна, ресурсов уходит чуть меньше, а логика скрипта не меняется. На проде обычно ставлю Chrome в Docker-контейнере с headless-флагом и лимитом памяти, чтобы несколько воркеров не положили сервер при параллельном запуске.
Сколько времени занимает поддержка Selenium-скрипта после сдачи?
Зависит от того, как часто меняется сайт-источник. Спокойный проект требует правки раз в 2-3 месяца, если верстка нестабильна - поломку можно поймать раз в 2-3 недели. Поэтому для регулярного мониторинга рекомендую держать техподдержку, а не чинить скрипт разово каждый раз с нуля.