Почти у каждого обзора в духе «лучшие open-source скрейперы» есть одна неочевидная проблема: инструменты никто не гоняет по одним и тем же страницам. Scrapy обычно проверяют на новостной статье, Playwright — на каком-нибудь демо интернет-магазине, Colly — на том, что автор нашёл под рукой, а потом всё это сравнивают лоб в лоб, будто такие цифры вообще можно сопоставлять. На самом деле такой рейтинг говорит не о самих инструментах, а о страницах.
Поэтому я сделал скучную, но очевидную вещь, которую обычно пропускают списки: собрал один набор тестовых страниц и прогнал через него все девять инструментов — статический каталог, каталог, отрисованный JavaScript, статью, спрятанную среди навигации и футера, специально сломанный HTTP 500, небольшой граф внутренних ссылок, а также два публичных тренировочных сайта. Одинаковые исходные данные, одинаковые метрики, каждый запуск. Скрипты и сырые результаты лежат в публичном репозитории бенчмарка, так что ты можешь перепроверить всё сам. Итог оказался совсем не похож на аккуратную таблицу лидеров, которую обещают подборки: единого победителя нет. Есть три разные задачи, и девять инструментов почти сами собой раскладываются по ним.
Попробовать Thunderbit для извлечения веб-данных
Как работал стенд и одно ограничение, которое я скажу прямо
Все инструменты получали одинаковые типы тестовых страниц: 12 статических товаров, разбитых на две страницы; 8 товаров, подгружаемых через JavaScript с задержкой; статью с тремя настоящими абзацами, обрамлённую навигацией и футером; намеренно сломанный сервер с ответом 500; и граф внутренних ссылок. Именно это и делает результаты сопоставимыми — «8/8 динамических товаров» означает одно и то же, независимо от того, сделал это Puppeteer или Crawlee.
Но есть граница, которую большинство обзоров обходят стороной. У каждого инструмента свой собственный пакет с копией этих тестов, поэтому абсолютные значения по символам строго между инструментами не сравниваются — считай их только внутри одного инструмента, а не как общий скоринг. Сопоставимы тут recall/полнота извлечения, как скорость выполнения, успех или провал JavaScript-теста и структурное поведение. И ещё одна оговорка в том же духе: в Crawl4AI статический каталог проверялся только на первой странице, поэтому его 6/6 — это полная полнота на более узком срезе, тогда как остальные инструменты проходили обе страницы и показывали 12/12 — меньший охват, а не частичный промах. Полное объяснение по каждому тесту есть в описании методологии.
И ещё один важный момент перед цифрами. В каждом пакете есть также промежуточная исследовательская оценка, но я специально не вывожу её в виде таблицы лидеров. Это был внутренний ориентир, чтобы сверять каждый инструмент с его же доказательствами, а не турнирная таблица — публиковать её как рейтинг означало бы ровно ту ложную точность, от которой и нужен весь этот эксперимент. Это выводы по бенчмарку, а не пьедестал.
Весь набор инструментов на одном стенде
Посмотри на два столбца этой таблицы — «Рендерит JS?» и «Встроенная очередь обхода» — и три типа задач становятся очевидны сами по себе.
| Инструмент | Язык | Рендерит JS? | Полнота на статике | Структурированный вывод | Встроенная очередь обхода | Сложность установки | Лицензия |
|---|---|---|---|---|---|---|---|
| Crawl4AI | Python | Да (браузер) | 6/6 (страница 1) | CSS-схема | BFS/DFS встроены | Высокая (2 браузерных стека) | Apache-2.0 |
| Firecrawl | Самохостинг | Да (playwright-service) | Полный Markdown | Да | /v1/crawl | Самая тяжёлая (6 контейнеров) | AGPL-3.0 |
| trafilatura | Python | Нет | 3/3 статьи | Нет (только текст) | Нет | Лёгкая | Apache-2.0 |
| Crawlee | Node/TS | Опционально через движок | 12/12 | Через extraction | Да (RequestQueue) | Средняя (+~80 МиБ) | Apache-2.0 |
| Playwright | Node/мульти | Да | 12/12 | Ручной вывод | Нет (BFS пишется вручную) | Средняя (браузер) | Apache-2.0 |
| Puppeteer | Node | Да (Chrome) | 12/12 | Ручной вывод | Нет (BFS пишется вручную) | Средняя (Chrome) | Apache-2.0 |
| Scrapy | Python | Нет | 12/12 | Экспорт лент (JSON/CSV/XML) | Да (встроенная) | Средняя (зависимости Twisted) | BSD-3 |
| Colly | Go | Нет | 12/12 | Через callback-функции | Контроль глубины | Лёгкая (1 бинарник + Go) | Apache-2.0 |
| Scrapling | Python | Нет (HTTP fetcher) | 12/12 | Да | Нет | Средняя ([fetchers]) | BSD-3 |
Небольшая ремарка о метаданных в этой таблице и везде ниже: количество звёзд и номера версий были зафиксированы в начале июля 2026 года, а потом всё быстро меняется. Перед тем как считать эти данные актуальными, проверь их на GitHub и в карточке пакета каждого проекта.
Индекс обзоров по каждому инструменту
У каждого проекта в этом обзоре есть отдельный подробный разбор:
- Обзор Crawl4AI
- Обзор Firecrawl
- Обзор trafilatura
- Сравнение Playwright и Puppeteer
- Обзор Crawlee
- Обзор Scrapy
- Обзор Colly
- Обзор Scrapling
Вот их обложки — плюс два реальных скриншота из теста с рендерингом JavaScript, чтобы утверждение про «8/8 динамических» было не просто цифрой на странице.
Задача 1: превратить страницу в текст, готовый для LLM
Если тебе нужен чистый Markdown для RAG-пайплайна, то здесь конкурируют три инструмента — и устроены они совершенно по-разному.
Crawl4AI — по сути браузерный генератор Markdown, как бы ни звучал его маркетинг. Стоит сразу развеять историю про «adaptive intelligence self-learning selector», которая тянется за ним в поиске: ничего подобного у него нет — это трюк совсем другой библиотеки (к ней мы ещё вернёмся, когда дойдём до Scrapling). Но то, что он реально делает, он делает хорошо. На тренировочном сайте Books to Scrape он выдал 13 476 символов Markdown, умеет CSS-schema-извлечение для структурированных данных, а встроенный BFS-глубокий обход прошёл 5 страниц на графе переходов, одновременно отрендерив JavaScript-страницу и сделав скриншот. Но есть и два реальных минуса. В сыром Markdown остаются служебные блоки страницы, если не включить фильтр контента, а намеренный ответ 500 вернулся как success=false — не потому, что Crawl4AI аккуратно поймал HTTP-ошибку, а потому что его собственная контент-эвристика посмотрела на короткое тело ошибки и пометила его как minimal_text ... blocked. Плюс к этому установка приносит на диск два браузерных стека. Версия 0.9.0, Apache-2.0, примерно 71 тыс. звёзд на начало июля.
Firecrawl — тяжеловес этого набора, и самохостинг у него действительно работает. И я говорю именно «действительно», потому что стек из шести контейнеров (api, playwright-service, redis, rabbitmq, nuq-postgres и foundationdb) реально поднялся и выдал 9 222 символа LLM-ready Markdown со страницы Books to Scrape. Он отрендерил JavaScript-страницу через встроенный playwright-service, и цитата Эйнштейна, подгружаемая после скрипта, появилась в выводе — это подтвердило, что рендер действительно произошёл. Две проблемы, с которыми я столкнулся, были вызваны окружением, а не Firecrawl, и я хочу уточнить это максимально точно, чтобы никто не пытался повторить неправильный фикс: сборка из исходников споткнулась о сбой snapshotter в containerd под colima (я переключился на готовые образы), а диапазон DNS 198.18.x.x в colima сработал на SSRF-защиту Firecrawl, которую я обошёл через ALLOW_LOCAL_WEBHOOKS=true — это временный локальный обход, а не настройка, которую стоит отключать в реальном проде. В самохостинговом ядре также отсутствует Fire-engine — облачный слой анти-блокировки, — и облачный API я не тестировал. Но куда важнее лицензия: самохостинговое ядро Firecrawl распространяется под AGPL-3.0, а это уже не сноска, а полноценный юридический вопрос перед коммерческим использованием. На начало июля у проекта около 148 тыс. звёзд.
trafilatura — контрпример в этой тройке, и как раз тот инструмент, про который списки на волне AI-hype постоянно забывают. Без браузера. Без структурированных строк. Просто быстрый и чистый текст статьи на чистом Python. На тестовой статье он извлёк заголовок и все 3 из 3 настоящих абзацев, полностью убрал служебную обвязку — туда не попали ни «Login», ни «Subscribe», ни «Copyright» — и дополнительно достал автора и дату. На публичной товарной странице он вернул 1 324 символа чистого текста. Его предел ровно такой, какого и ждёшь от такой архитектуры: дай ему каталог, и он отдаст 12 названий товаров как текст, но 0 структурированных строк — текст есть, структуры нет, и JavaScript он не рендерит. Версия 2.1.0 (текущая), Apache-2.0, около 6,2 тыс. звёзд. Для чистого извлечения статей это первое, к чему я бы обратился.
Эти два значения по символам в Markdown — 13 476 у Crawl4AI и 9 222 у Firecrawl — получены на одной и той же публичной странице, но не стоит воспринимать их как разницу в качестве. Они показывают разные подходы к Markdown (сколько служебной обвязки страницы каждый сохраняет), а не ответ на вопрос, у кого результат «лучше». Это как раз то правило про сигналы внутри инструмента, о котором я говорил выше, только теперь оно видно на практике.
Задача 2: надёжно рендерить JavaScript
Иногда данные просто не лежат в HTML, пока не отработают скрипты, и вот тогда настоящий браузер перестаёт быть опцией по желанию. Эту задачу закрывают три инструмента — и два из них оказались почти одним и тем же решением.
Playwright и Puppeteer показали ничью по всем тестам, которые я на них бросил. Оба отрисовали 8/8 динамических товаров на локальной тестовой странице и 10 на публичном сайте Quotes JS, оба дали 12/12 на статике, и оба корректно обработали 500 (Puppeteer возвращает объект ответа вместо исключения). У обоих нет собственной очереди обхода, поэтому для графа из 12 страниц пришлось вручную писать BFS. Реальная разница только в охвате: Playwright управляет Chromium, Firefox и WebKit и работает с Python и .NET, а Puppeteer ориентирован прежде всего на Chrome и только на Node. Два уточнения, потому что здесь версии быстро меняются: я тестировал Playwright 1.56.0 против актуальной 1.61.1 и использовал только Chromium; Puppeteer — 24.16.0 против текущей 25.3.0, так что результаты стоит перепроверить или учитывать с поправкой. Оба под Apache-2.0; примерно 92 тыс. и 95 тыс. звёзд соответственно.
Crawlee — это инструмент, который закрывает проблему очереди, оставшуюся у предыдущей пары. Он объединяет движок Cheerio (HTTP) и Playwright (браузер) под одним API, и контраст на одной странице отлично показывает суть: движок Cheerio увидел 0 элементов, подгружаемых JavaScript, а движок Playwright увидел все 8/8 на локальном тесте (и 10 на публичном сайте), причём переключение между ними — это изменение одной строки. Плюс он даёт настоящую RequestQueue, и именно поэтому он попадает в эту задачу, а не в третью. Но есть и нюанс, о котором в заголовках обычно не пишут: для браузерного движка нужно отдельно ставить npx playwright install, то есть примерно 80 МиБ, которые npm install crawlee вам сам не докачает. Версия 3.17.0, TypeScript, Apache-2.0, около 24,6 тыс. звёзд.
Задача 3: быстро обойти сайт без браузера
Если на странице нет JavaScript, браузер становится дорогим и неоправданным излишеством. Здесь соревнуются три HTTP-first инструмента, по одному из каждой языковой философии, и различия между ними интересны.
Scrapy — это инструмент инженерного уровня: пауки, экспорт лент в JSON/CSV/XML, AutoThrottle и всё остальное. Он показал 12/12 на статике, забрал 3/3 абзаца статьи, прошёл 11 страниц на графе обхода по глубинам 0–2 и корректно поймал 500 через handle_httpstatus_list. Но важнее его подход к задаче: он не рендерит страницу, он воспроизводит запрос. Если дать ему JavaScript-страницу, он получит 0 узлов — а вот JSON API, стоящий за той же страницей, отдаст ему 8/8. В этом и заключается философия Scrapy: найти запрос, который делает страница, и повторить его, а не тащить браузер. Цена этого — немалый стек зависимостей (Twisted, lxml, parsel), и я тестировал его только на небольших наборах страниц. Версия 2.17.0, BSD-3-Clause, около 63 тыс. звёзд.
Colly — это Go-ответ, и он удивительно прямолинеен: один статически собираемый бинарник, callback-модель через OnHTML, OnResponse и OnError, плюс контроль глубины. Он уверенно взял 12/12 на статике, вытащил 8/8 из JSON API через OnResponse, поймал 500 через OnError и дошёл до 17 страниц на обходе глубины 2 — и я специально формулирую это именно так, потому что это счётчик самого тестового стенда, а не обещание полноты со стороны Colly. Чего он не делает — так это JavaScript: динамическая страница и сайт Quotes JS оба дали 0, и это ожидаемо. Для сборки нужен Go toolchain, а версия модуля (v2.3.0) сейчас опережает тегированный релиз (v2.2.0). Apache-2.0, примерно 25 тыс. звёзд.
Scrapling — узкий специалист, и этот ярлык он заслуживает. Его adaptive selectors умеют заново находить элемент после изменения разметки — так что когда я переименовал HTML-класс у цели с product-name на product-title, обычный селектор дал 0, а adaptive re-match всё равно восстановил нужный элемент. На обычном HTTP-извлечении он взял 12/12 на статике и 8/8 на JSON API. Но его документация не скрывает и ограничение: в синтетическом тесте с несколькими элементами он восстановил 1 из 3 — это устойчивое отслеживание элементов, а не полное восстановление, так что не стоит в голове завышать ожидания. Базовая установка через pip install scrapling также требует дополнительного пакета [fetchers], а StealthyFetcher — это скорее юридический и этический нюанс, чем функция, которую хотелось бы вынести на слайд. Версия 0.4.10 (текущая), BSD-3-Clause, около 68,7 тыс. звёзд.
Что стоит за этими тремя задачами
Если выстроить все девять инструментов в один ряд, картина становится очень ясной. Полная полнота на статике — ровные 12/12 — это уже базовый уровень для любого HTTP-first инструмента; никто из них не провалил простой кейс, так что на этом фоне они не отличаются. Браузерные решения оправдывают свой вес только тогда, когда в дело действительно вмешивается JavaScript, и все они платят за это установкой: браузерный стек, дополнительный инсталлятор или целый парк контейнеров. А столбец «встроенная очередь обхода» — это по сути граница между фреймворком и движком: Scrapy и Crawlee дают orchestration из коробки, а Playwright и Puppeteer заставляют писать BFS самостоятельно. Вот и вся форма поля. Никто не выигрывает вообще, потому что никто не играет в одну и ту же игру.
Так что же выбирать на практике
Этот бенчмарк отказывается короновать одного победителя, потому что правильный ответ — не инструмент, а вопрос: какую из трёх задач ты решаешь?
- Нужен Markdown, готовый для LLM? Берите trafilatura, если вам нужен чистый текст статьи; Crawl4AI, если вместе с этим важны CSS-извлечение и рендер JavaScript в одной библиотеке; Firecrawl, если нужен именно самохостинговый сервис и вы готовы принять и AGPL-3.0, и вес в шесть контейнеров.
- Нужно рендерить JavaScript? Playwright или Puppeteer — для самого рендеринга; выбирай по движку и языку, потому что по сути это ничья. А Crawlee берите тогда, когда нужна ещё и готовая оркестрация обхода, а не ручная реализация.
- Нужно быстро обходить статические страницы или воспроизводимые API на масштабе? Scrapy — если нужен полноценный Python-фреймворк; Colly — если нужен сырой Go-скоростной вариант в одном бинарнике; Scrapling — если твоя постоянная боль это устойчивость к дрейфу разметки.
Сопоставь инструмент с задачей — и каждый из этих вариантов будет вполне оправдан. Возьми инструмент не из той категории — браузерный для статических страниц или HTTP-парсер для JavaScript-приложения — и даже самый высоко оценённый пакет в мире тебя не спасёт.
Где вместо этого уместен управляемый AI API
Каждый инструмент выше — бесплатный, open-source и полностью в твоём распоряжении. Но именно здесь бенчмарк снова показывает общий компромисс: ты сам отвечаешь за браузерное окружение, код обхода, гонку вооружений с антибот-защитой и всё обслуживание. Для многих команд это как раз и есть преимущество, а карта лицензий становится важной, когда ты берёшь это на себя: большая часть поля — permissive-лицензии (Apache-2.0 у Crawl4AI, Crawlee, Playwright, Puppeteer и Colly; BSD-3 у Scrapy и Scrapling), а вот самохостинговое ядро Firecrawl под AGPL-3.0 требует реальной юридической проверки перед коммерческим использованием.
Но посмотри, что ещё показывает бенчмарк: чего эти инструменты не делают. Рендер, обход, структурирование и обход блокировок — редко всё сразу и почти никогда без твоей поддержки. Управляемый AI scraping API убирает этот стек в один вызов. Один из вариантов на нашей стороне — Thunderbit, и для технической аудитории важны именно API, MCP-сервер и CLI, а не браузерное расширение. POST /distill возвращает чистый Markdown, а POST /extract — JSON по заданной схеме; JavaScript-рендеринг и антибот-защита обрабатываются на сервере, а не на твоей машине. Есть официальный MCP-сервер для агентов и помощников по коду — thunderbit_suggest_fields можно запускать бесплатно для планирования извлечения, затем thunderbit_distill (1 кредит) и thunderbit_extract (20 кредитов) выполняют работу — а также CLI, который можно подключить через npx @thunderbit/thunderbit-cli для терминала и cron-задач. Для нетехнических коллег есть и no-code расширение Chrome, а на странице тарифов это всё покрыто.
Компромисс здесь тот же, вокруг которого крутится весь этот бенчмарк: либо ты сам запускаешь и обслуживаешь до девяти библиотек с нулевой ценой за каждый запрос, либо передаёшь всю инфраструктуру и платишь за запросы. Оба варианта нормальны. Всё упирается в то, сколько стека ты действительно хочешь держать у себя. Если хочешь посмотреть, как извлечение выглядит на практике, YouTube-канал Thunderbit всё это показывает.
{{INTERNAL_BLOG_LINKS}}
Итог
Единого лучшего open-source скрейпера не существует, и любой список, который уверенно называет тебе один, тихо прячет главный вопрос: какую именно из трёх задач ты решаешь? Превратить страницу в текст, отрендерить JavaScript или быстро обойти сайт без браузера — поле чётко делится на эти категории, и внутри каждой выбор сводится к языку и тяжести установки, а не к какому-то универсальному чемпиону.
Если и брать из этого текста одну привычку, то такую: тестируйте на своих страницах, прежде чем на чём-то останавливаться. Все цифры здесь воспроизводимы в репозитории бенчмарка именно по этой причине — потому что инструмент, который лидирует в общем обзоре, и инструмент, который реально выдержит твои страницы, не всегда один и тот же.
Попробовать Thunderbit для извлечения веб-данных Get Started Free
Часто задаваемые вопросы
Какой open-source веб-скрейпер лучший? Одного лучшего нет — всё зависит от задачи. Для текста, готового для LLM, подойдут trafilatura или Crawl4AI; для рендеринга JavaScript — Playwright, Puppeteer или Crawlee; для быстрого HTTP-обхода — Scrapy или Colly. На общем тестовом стенде каждый инструмент сильнее всего выглядел в своей категории и заметно слабел вне её, поэтому универсальные рейтинги легко вводят в заблуждение.
Какие open-source скрейперы рендерят JavaScript? JavaScript рендерят Crawl4AI, Firecrawl, Playwright, Puppeteer и движок Playwright в Crawlee. Scrapy, Colly, trafilatura и стандартный HTTP fetcher у Scrapling этого не делают — им либо нужен воспроизводимый API за страницей (это подход Scrapy, который взял 8/8 через JSON-endpoint), либо отдельный браузерный режим.
Нужен ли headless browser для скрейпинга сайта? Только если данные появляются после выполнения JavaScript. Если обычный HTTP-запрос плюс парсер уже дают доступ к контенту, браузер — это дорогое и избыточное решение. Для такого кейса Scrapy, Colly или Scrapling будут заметно легче и быстрее.
У кого из этих инструментов самая удобная лицензия для коммерческого использования? У большинства — permissive-лицензии: Apache-2.0 у Crawl4AI, Crawlee, Playwright, Puppeteer и Colly; BSD-3-Clause у Scrapy и Scrapling. Исключение — самохостинговое ядро Firecrawl под AGPL-3.0, и перед коммерческим продуктом на его базе эту лицензию нужно действительно проверить.
Можно ли воспроизвести эти результаты бенчмарка? Да. Все раннеры, тестовые страницы и сырые результаты лежат в публичном репозитории под лицензией MIT. Но есть одна оговорка: полноту извлечения и структурные результаты можно сравнивать между инструментами, а вот абсолютные значения по символам — только внутри одного инструмента, потому что у каждого пакета своя копия тестов, а не один канонический набор. Поэтому сравнивайте доли и проход/провал, а не сырое число символов.
