Парсинг сайтов на React и Angular

Сайты на React и Angular часто “ломают ожидания” тех, кто привык к классическому парсингу HTML. Вы открываете исходный код страницы — а там почти нет контента: пару контейнеров, подключение скриптов и минимум разметки. Данные появляются позже, уже в браузере, когда приложение подгрузило их через API и “собрало” интерфейс.

Поэтому ключевая мысль простая: парсинг таких сайтов — это не “считать страницу”, а понять, откуда и как приходят данные. И только потом выбрать стратегию, которая будет устойчивой и экономичной.

Что происходит на React/Angular-сайтах простыми словами

В типичном случае интерфейс работает как приложение:

• браузер получает небольшой HTML-скелет;
• дальше фронтенд загружает данные отдельными запросами (чаще всего это JSON);
• и уже из этих данных рисует карточки, списки, фильтры, цены и т.д.

Есть два режима, которые важно различать:

• SPA: контент формируется на стороне клиента (в браузере). HTML “пустой”.
• SSR: сервер сразу отдает готовую страницу с данными. Парсинг обычно проще, потому что контент виден в HTML сразу.

Что обычно парсят на таких сайтах

• каталоги и карточки товаров (цены, наличие, характеристики);
• объявления (недвижимость, авто, услуги);
• вакансии и списки компаний;
• расписания, события, афиши;
• результаты поиска и фильтров (важно: это “дорогая” зона);
• личные кабинеты — как правило, красная зона без официального доступа или договоренности.

Стратегии корректного получения данных

Ниже — 4 подхода “от лучшего к худшему” с точки зрения устойчивости и стоимости поддержки.

1) Официальный API или выгрузка

Если у сервиса есть официальный API, партнерская выгрузка или открытые наборы данных — это почти всегда лучший вариант.

Плюсы: стабильность, меньше поломок, проще поддержка, понятные форматы.
Минусы: не всегда доступно, могут быть ограничения по полям или частоте.

2) Работа с сетевыми запросами приложения

Если данных нет в официальном API, часто они все равно приходят в приложение отдельными запросами (обычно JSON). В этом случае цель — получать данные из публично доступных запросов без обхода ограничений доступа.

Плюсы: быстрее и дешевле, чем “рендерить страницу”; меньше зависимости от верстки.
Минусы: структура запросов может меняться при обновлении фронтенда; нужно строить контроль качества.

3) Парсинг SSR-страниц

Если сайт использует SSR, то данные уже в HTML.

Плюсы: проще, чем SPA; меньше технической сложности.
Минусы: не все страницы SSR; часть данных может всё равно подгружаться позже.

4) Headless browser

Это запуск браузера без интерфейса, который реально “открывает страницу” и ждет, пока контент появится.

Плюсы: помогает, когда данные появляются только после сложного рендера.
Минусы: самый дорогой по ресурсам и поддержке путь; медленнее; больше факторов нестабильности.

Практический вывод: headless browser — это не “по умолчанию”, а “когда без него нельзя”.

 

Подводные камни React/Angular-парсинга

1. Сессии и токены: могут ограничивать доступ к данным (без обходов — просто учитывайте, что часть данных не публична).
2. Изменение структуры запросов при релизах фронтенда.
3. Бесконечная прокрутка вместо нормальной пагинации.
4. Поиск и фильтры как “дорогие” эндпоинты — легко создать лишнюю нагрузку и получить ошибки.
5. Персонализация и гео: разные пользователи видят разные цены/наличие/условия.
6. Кэш и задержки обновления: “сейчас” может быть не “в ту же секунду”.
7. Ограничения по частоте запросов (rate limit) — нужно уметь замедляться и планировать частоту.
8. A/B тесты: разные варианты интерфейса и данных.
9. Нестабильность селекторов: в SPA структура DOM может меняться чаще, чем в классическом HTML.

 

Таблица №1: метод → когда выбирать → плюсы → минусы

Метод	Когда выбирать	Плюсы	Минусы
Официальный API/выгрузка	доступно у источника	самая стабильная схема	не всегда есть нужные поля
JSON-запросы приложения	SPA, “пустой” HTML	быстро, меньше зависимость от верстки	меняется схема при релизах
SSR-парсинг HTML	страницы рендерятся сервером	проще и дешевле	не весь контент SSR
Headless browser	данные только после рендера	“видит” то, что видит пользователь	дорого и медленно
Комбо: API + HTML	часть данных в API, часть в HTML	оптимальный баланс	нужна интеграция источников
Комбо: JSON + SSR	часть SSR, часть через JSON	меньше headless	сложнее тестировать
Headless только на часть страниц	редкие “сложные” страницы	снижает стоимость	архитектура усложняется
Кеш + инкремент	регулярный мониторинг	меньше нагрузка и затрат	нужен контроль истории

 

Как сделать сбор устойчивым

Удобная базовая схема:

Сбор → Валидация → Нормализация → История → Выгрузка → Мониторинг

Что важно в практике:

• храните сырой ответ (HTML или JSON) и отдельно — нормализованные поля (таблица/JSON-схема);
• ставьте “quality gates”: доля пустых полей, выбросы цен, резкие изменения распределений;
• версионируйте схему данных: когда меняется структура — меняется версия;
• делайте инкремент (обновлять только изменения), а не обходить всё каждый раз;
• добавляйте алерты: если резко выросли пустые значения или ошибки — процесс должен остановиться/перейти в безопасный режим.

Таблица №2: симптом → причина → что делать

Симптом	Возможная причина	Что делать
В HTML нет данных	SPA	идти в API/JSON-запросы
Вчера работало, сегодня пусто	релиз фронтенда, сменилась схема	мониторинг качества + обновить схему
Иногда данные пустые	персонализация/гео/кэш	фиксировать контекст, повторная проверка
Сбор дорогой и медленный	headless везде	минимизировать headless, использовать JSON/SSR
Много ошибок при частом обновлении	rate limit	снижать частоту, распределять окна, инкремент
Падает поиск/фильтры	“дорогие” запросы	ограничить, не перебирать параметры
Дубли в данных	бесконечная прокрутка/пагинация	дедуп по ID/URL и stop-условия
“Скачет” цена	разные варианты/условия	фиксировать вариант, гео, условия
Данные разъезжаются по полям	нет нормализации	справочники, единицы, типы
Частые мелкие поломки	нет мониторинга	алерты на пустые поля и ошибки

 

Чек-лист перед запуском

• цель и список полей зафиксированы;
• определен источник данных: API/JSON/SSR/headless;
• выбрана частота и необходимость истории;
• учтены ограничения по нагрузке и rate limit;
• определены “дорогие” зоны (поиск/фильтры) и правила обращения с ними;
• настроены валидация и алерты на качество;
• определен формат результата (CSV/Sheets/API);
• есть план поддержки изменений (релизы фронтенда неизбежны).