.4UVmK5aw_1uGpNi.svg){kind=small}
.AzQB9McO_PVSYK.svg){kind=small}
.DjhlE8MO_Z1DYVxU.svg){kind=small}
.DM2pllEO_1cxFXE.svg){kind=small}
.CvN5042A_Z10D5qc.svg){kind=small}
.Dcqs_gC__NRL3p.svg){kind=small}
<div id="root"></div> <!-- data still in the bundle -->
Сессии бесплатны — платите только за трафик
Облачный браузер для парсинга
Сессия облачного браузера загружает страницу так же, как для обычного посетителя, со всеми скриптами, и к моменту, когда ваш код её читает, контент уже на месте.
- Страницы на React, Vue и Angular отрисовываются полностью — без пустой оболочки
- Резидентские, мобильные или серверные IP — со sticky-сессиями или с ротацией
- Playwright и Puppeteer — обычно достаточно изменить одну строку
Парсинг
Ваш код управляет
браузером.
Подключайтесь по CDP к нашему Chromium вместо запроса HTML. Он загружает страницу как реальный посетитель — с выполнением всего JS, через наши прокси и с правдоподобным отпечатком, — а вы получаете уже отрисованный DOM.
Зачем использовать облачный браузер вместо обычных HTTP-запросов?
Обычный HTTP-запрос получает тот HTML, который отдаёт сервер, и ничего больше. Для статической страницы этого достаточно. Но на большей части современного веба такой подход не работает: сайты на React, Vue или Angular не присылают контент в первом ответе — они собирают его в браузере после выполнения JS. Если направить на такую страницу парсер, работающий только с запросами, вы получите пустую оболочку, а сами данные останутся внутри бандла, который никто не выполнил.
Парсинг через сессии облачного браузера снимает эту проблему. Страница загружается так же, как для обычного посетителя, со всеми скриптами, и к моменту, когда ваш код её читает, контент уже на месте. Не нужно гадать, какой эндпоинт наполняет страницу, и разбирать бандл в поисках схемы запросов — вы сразу получаете готовый результат.
Обход блокировок и защиты от ботов на уровне браузера
Раньше хватало отправить правильные заголовки, чтобы получить страницу. Теперь не так: сайты оценивают десятки мелких сигналов, прежде чем решить, похож ли запрос на настоящий:
-
Порядок заголовков, а не только их набор
-
Паузы между действиями
-
Похоже ли движение мыши и прокрутка на поведение человека
-
Особенности отпечатка: установленные шрифты, вывод canvas и тому подобное
Динамический рендеринг JavaScript и одностраничные приложения (SPA)
Одностраничные приложения загружаются один раз, а затем перестраиваются по мере кликов: открываются вкладки, применяются фильтры, обновляются результаты — и ничего из этого нет в первом ответе. Облачный браузер проходит тот же путь, что и посетитель, а затем считывает страницу, когда она перестаёт меняться. Если пропустить этот шаг, парсинг на сайтах с тяжёлой клиентской частью тихо ломается гораздо чаще, чем можно ожидать.
Автоматическое решение CAPTCHA и управление отпечатками
Шрифты, вывод canvas, поведение аудио, размер экрана — вместе они образуют отпечаток, который сверяется с тем, как должен выглядеть настоящий браузер. Если ошибиться, сайты быстро это замечают, иногда уже после одного-двух запросов. Называйте это облачным антидетект-браузером, антидетект-конфигурацией или просто невидимым режимом — задача одна: поддерживать убедительный отпечаток без ручной настройки. Решение CAPTCHA обычно идёт в той же сессии, поэтому задача не простаивает в ожидании ручного ввода каждый раз, когда появляется капча.
Интеграция с прокси с ротацией (резидентскими и серверными)
Сессия может работать через резидентские, мобильные или серверные IP — в зависимости от того, насколько чувствителен целевой сайт. IP можно закрепить на всю сессию или менять по таймеру, и этот выбор действительно важен. Парсинг за авторизацией требует одного и того же IP всё время, чтобы cookie и состояние сессии не рассыпались. Парсинг больших объёмов, наоборот, требует распределять запросы, чтобы нагрузка не ложилась на один адрес.
Работает с Playwright и Puppeteer
Чтобы всё это заработало, не нужно выбрасывать существующий код для парсинга. Playwright и Puppeteer подключаются по CDP вместо запуска локального Chrome, а всё остальное — селекторы, ожидания, извлечение данных — остаётся как было. В краулере, написанном два года назад под локальный headless Chrome, обычно достаточно изменить одну строку — переписывать его не придётся.
- Playwright
- Puppeteer
- Python
- Node.js
Быстрый старт: пример кода для подключения
Чтобы запустить сессию, хватит нескольких строк:
Укажите тип прокси и страну при открытии сессии — остальная часть скрипта почти не отличается от той, что и так запускалась бы локально.
scrape.js
const browser = await chromium.connectOverCDP(connectUrl);const page = await browser.newPage();await page.goto('https://example.com');const data = await page.textContent('body');scrape.js
const browser = await puppeteer.connect({ browserWSEndpoint: connectUrl });const page = await browser.newPage();await page.goto('https://example.com');const data = await page.evaluate(() => document.body.innerText);Сравнение эффективности: парсинг через запросы и облачный браузер
Парсинг через облачный браузер обходится дороже за страницу, чем обычный запрос, — этого не избежать, ведь полноценная сессия браузера выполняет больше работы. Вот в чём подходы действительно различаются:
| Обычные HTTP-запросы | Парсинг через облачный браузер Floppydata | |
|---|---|---|
| Страницы с рендерингом на JavaScript | Ответ приходит пустым | Отрисовываются полностью, как у реального посетителя |
| Стоимость за страницу | Ниже | Выше, но блокировка ненужных ресурсов её снижает |
| Контент за авторизацией | Сессия не сохраняется | Cookie и сессия сохраняются между страницами |
| Отпечаток против антибот-систем | Отсутствует, легко заметить | Обрабатывается автоматически |
| Трафик | Загружает всё | Можно пропускать изображения, шрифты и CSS |
Для статического контента без JavaScript и защиты от ботов обычные запросы по-прежнему выигрывают по стоимости — нет смысла запускать полноценный браузер для страницы, которой он не нужен. Во всех остальных случаях парсинг через облачный браузер часто выходит дешевле, если учесть повторные попытки, прокси и ручные доработки, которые всё равно понадобятся при работе только с запросами. Когда целевой сайт начинает активно сопротивляться, расчёт редко оказывается в пользу запросов.