Мне довелось провести достаточно много времени в Slack-комнатах инженерных команд, чтобы понять, как обычно начинается этот спор: кто-то кидает ссылку на очередную подборку «лучших веб-скрейперов», и сразу три инженера пишут: «а почему там ни слова о Colly?». И это не случайность. Я посмотрел на четыре статьи, которые сейчас ранжируются по запросу «Thunderbit vs Colly», и во всех четырёх Thunderbit сравнивают только с другими no-code инструментами — Crawl4AI, Browse AI, rtrvr.ai, Chat4Data. Colly не упоминается вообще.
И это немного странно, потому что у Colly есть своя реальная и очень лояльная аудитория на r/golang и в Go-командах, которым нужны быстрые краулеры, полностью находящиеся под контролем разработчика. Поэтому эта статья действительно отвечает на вопрос, а не является переупакованным сравнением «AI-инструментов» с подставленным названием Colly.
Короткий ответ
Если вам нужен краткий вывод между встречами: Thunderbit — это управляемый агентный веб-скрейпер, который запускается в один клик: без селекторов, без кода, с выполнением в браузере или в облаке, а также с Web App, Open API, MCP Server и CLI для случаев, когда разработчикам нужен программный доступ. Colly — это open-source Go-фреймворк: вы сами пишете краулер, сами владеете логикой и сами настраиваете параллелизм.
По сути, это не прямые конкуренты в классическом смысле. Один — продукт. Другой — библиотека. Сравнивать их напрямую имеет смысл только тогда, когда вы стоите на развилке и выбираете путь под свою реальную задачу — именно с этим я и хочу помочь разобраться.
Краткое сравнение
| Параметр | Thunderbit | Colly |
|---|---|---|
| Основные пользователи | Бизнес-пользователи, операционные команды, разработчики, которым важна скорость | Go-разработчики |
| Запуск | Нажать One Click Extract на странице | go get github.com/gocolly/colly + написать Go-код |
| Время до первого результата | От секунд до минут, агент запускается автоматически | Зависит от того, как быстро вы напишете callback'и |
| Язык | Не требуется при работе в браузере | Go |
| Модель краулинга | Агентный анализ страницы, поддержка пагинации и подпагин | Ручные callback'и Collector + OnHTML/OnResponse |
| Рендеринг | Управляемый браузер / облачное выполнение | В основном HTTP/HTML; для JS-страниц нужны дополнительные инструменты |
| Правила извлечения | Агент предлагает поля, пользователь может их уточнить | Разработчик вручную пишет CSS-селекторы |
| Параллелизм | Управляется платформой | Полный ручной контроль через goroutines |
| Хранение/экспорт | Экспорт в таблицы, spreadsheets и другие поддерживаемые направления | Создаётся разработчиком: файлы, базы данных, Redis и т. д. |
| Развёртывание | Расширение браузера, Web App, API, MCP, CLI | Самостоятельно размещаемый Go-бинарник / скрипт |
| Поддержка | Управляемая логика извлечения; при этом всё равно зависит от совместимости сайта | Разработчик исправляет селекторы, когда сайт меняется |
| Лицензия / стоимость | Планы на основе кредитов (актуальные тарифы — на pricing) | Apache-2.0, бесплатно — но не инфраструктура и не время разработки |
Что такое Thunderbit?
У Thunderbit стандартный сценарий работы действительно сводится к одному клику. Вы открываете страницу, к которой у вас есть доступ, нажимаете One Click Extract, и агент читает страницу, понимает, что из неё стоит извлечь, и предлагает поля. Есть кнопка Run Now, но, если честно, она чаще нужна просто для спокойствия — если вы ничего не трогаете, извлечение стартует само. Никаких селекторов, никакой ручной настройки схемы — на тех страницах, которые агент поддерживает.
После этого вы можете доработать поля, если агент не попал в цель, а на совместимых сайтах он умеет проходить пагинацию или заходить в подпагины для обогащения данных — например, собирать дополнительные детали с каждой карточки товара в списке. Когда данные готовы, экспорт идёт в привычные инструменты: Excel, Google Sheets и несколько других поддерживаемых направлений.
Но расширение браузера — это лишь входная дверь. Если вы разработчик, есть Open API для запуска извлечения из собственного кода, MCP Server для подключения извлечения к Claude, Cursor или Windsurf как вызываемого инструмента, а также CLI для работы в терминале и в сценариях с coding-agent. Я упоминаю это потому, что во многих разговорах в духе «no-code против code» Thunderbit до сих пор воспринимают как игрушку только для бизнес-пользователей, а это уже давно не так.
Что такое Colly?
Colly — это Go-библиотека, и точка. Здесь нет дашборда, нет облачного сервиса, нет AI-слоя, который сам решает, что скрейпить. Вы пишете Go-код, создаёте Collector и навешиваете callback'и вроде OnHTML и OnResponse, чтобы точно задать, что делать при загрузке страницы.
Примерно это выглядит так:
c := colly.NewCollector()
c.OnHTML("a[href]", func(e *colly.HTMLElement) {
link := e.Attr("href")
c.Visit(e.Request.AbsoluteURL(link))
})
c.OnResponse(func(r *colly.Response) {
fmt.Println("Visited", r.Request.URL)
})
c.Visit("https://example.com")
Вся логика именно такая: определить, что искать, определить, что делать после нахождения, и дать коллектору краулить. Под капотом вы получаете синхронный, асинхронный и параллельный краулинг, лимитирование запросов по доменам, автоматическую работу с cookies и сессиями, кэширование запросов, поддержку robots.txt, ротацию прокси и подключаемые backend'ы для хранения, включая Redis для распределённых сценариев.
Важно честно сказать и о другом: Colly — это в первую очередь HTTP/HTML-фреймворк. Он не запускает полноценный браузер, как это делает Playwright. Если ваш сайт сильно зависит от JavaScript-рендеринга, вам либо придётся искать его подлежащий JSON API, либо использовать Colly вместе с отдельным инструментом браузерной автоматизации. Это не недостаток Colly, а просто другая философия дизайна по сравнению с полностью агентным продуктом, который «понимает» браузер.
Ключевое различие: управляемое агентное извлечение против Go-фреймворка
Время до первой таблицы
Вот где разница ощущается особенно сильно. В Thunderbit «время до первого результата» — это время, необходимое, чтобы нажать кнопку и подождать, пока агент дочитает страницу: обычно от нескольких секунд до пары минут, в зависимости от сложности. В Colly же «время до первого результата» включает написание collector'а, поиск правильных селекторов (что обычно означает несколько итераций в dev tools), самостоятельную реализацию логики пагинации и запуск всего этого. Для разовой задачи это вполне реальная стоимость по времени даже для опытного Go-разработчика.
Производительность и контроль
По уровню контроля Colly выигрывает без вопросов. Поскольку вы пишете логику сами, именно вы определяете, сколько goroutines работает одновременно, насколько агрессивным будет rate limiting, что кэшируется и как выполняются повторы при ошибках. В документации проекта есть упоминание более 1000 запросов в секунду на одном ядре для подходящих статических целей — это заявленный бенчмарк Colly, а не сравнение один к одному с Thunderbit, и я не буду делать вид, что это не так. Но это всё же говорит о важной вещи: для HTTP-friendly целей хорошо настроенный Go-параллелизм очень сложно обойти.
Thunderbit, в свою очередь, обменивает такой гранулярный контроль на управляемое выполнение. Вам не нужно настраивать пулы goroutine — вы полагаетесь на браузерные и облачные сценарии платформы, а также на scheduled extraction, если это предусмотрено вашим планом. Это правильный выбор, если вы не хотите тащить на себе инфраструктурные решения, и неправильный — если ваша работа буквально состоит в том, чтобы выжать максимум пропускной способности из краулера.
Развёртывание и ответственность за поддержку
Есть ещё один аспект, о котором говорят недостаточно. Colly «бесплатен» в том смысле, что лицензия Apache-2.0 ничего не стоит. Но кто-то всё равно должен это написать, разместить, мониторить и — что самое важное — чинить, когда сайт-цель меняет HTML. Селекторы ломаются тихо. Никто не присылает уведомление: «эй, у этого сайта изменился дизайн страницы товара». Разработчик просто замечает, что пайплайн замолчал или начал возвращать мусор, и потом идёт исправлять.
У Thunderbit логика извлечения управляется платформой, а его агентный анализ страницы рассчитан на адаптацию к вариациям верстки на поддерживаемых и разрешённых страницах. Но здесь я хочу быть аккуратным: это не означает абсолютную гарантию на любой сайт. Страницы с жёсткой антибот-защитой, контент за логином вне разрешённого доступа или сайты, с которыми агент просто работает плохо, — это реальные ограничения. Честная формулировка такая: с Colly исправлять всегда будете вы. С Thunderbit нагрузка меньше, но «меньше» не значит «ноль» — успех всё равно зависит от того, насколько хорошо Thunderbit поддерживает конкретную страницу.
Практические сценарии
Разовое извлечение каталога или списка товаров
Представьте, что вам нужно к концу дня собрать таблицу из 200 товаров со страницы каталога конкурента, а вы не разработчик (или разработчик, но у вас есть дела важнее). Это родная среда Thunderbit — нажали кнопку, агент предложил поля, при необходимости уточнили, экспортировали в Sheets. Написать скрипт на Colly для одноразового извлечения технически возможно, но по ощущениям это всё равно что пилить бонсай бензопилой.
Высоконагруженный кастомный Go-краулер
А теперь наоборот: вы строите мониторинговый пайплайн, который обходит тысячи URL в день, у вас уже есть Go-стек, и вам нужен точный контроль над логикой повторов, распределённым хранением через Redis и лимитами по доменам, чтобы не словить бан. Это уже территория Colly. Вы не платите подписку, владеете каждой строкой логики и можете оптимизировать под собственный паттерн трафика так, как управляемый продукт просто не обязан позволять.
Цель с тяжёлым JavaScript
Если страница целиком рендерится на клиенте и сильно завязана на JS, одного Colly, скорее всего, будет недостаточно — придётся либо искать JSON API, либо добавлять слой браузерной автоматизации. У Thunderbit управляемое выполнение в браузере и в облаке как раз и рассчитано на такие страницы, хотя повторю: прежде чем делать выводы, обязательно проверьте совместимость на конкретном сайте.
Интеграция с API или AI-агентом
Если вы строите внутренний инструмент, в котором AI-агент, например в Claude или Cursor, должен забирать структурированные данные как часть более крупного процесса, то здесь MCP Server у Thunderbit действительно полезен — он делает извлечение вызываемым инструментом внутри agent workflow. У Colly такого сценария нет нативно, потому что это самостоятельная библиотека, а не инструмент, который AI-агент может просто вызвать из коробки.
Надёжность, масштаб и поддержка
Я хочу развести две вещи, которые часто смешивают: чистую пропускную способность и общий процент успешных запусков на реальных сайтах. Colly может работать очень быстро на статических HTTP-friendly страницах — это заложено в саму архитектуру. Но «быстро» не означает автоматически «будет работать через три месяца», когда сайт выпустит редизайн. Каждый селектор, который вы писали, теперь потенциально устарел, и никто вам не сообщит об этом, пока ваш пайплайн тихо не начнёт отдавать пустые значения.
Агентный подход Thunderbit означает, что вы не поддерживаете селекторы вручную, но я бы возразил против любых формулировок — включая, честно говоря, и маркетинг самого Thunderbit — которые намекают на универсальную надёжность вообще на любом сайте, особенно если там есть агрессивная антибот-защита или контент за авторизацией, к которому у вас нет разрешённого доступа. Если вы выбираете между этими инструментами, правильный вопрос звучит так: «кто чинит это, когда оно ломается, и сколько времени это занимает», а не просто «как быстро оно работает в первый день».
Стоимость, лицензия и совокупные затраты
Colly — open-source под лицензией Apache 2.0, то есть сама библиотека бесплатна. Но общая стоимость владения включает часы разработчиков на написание и отладку краулера, вычислительные ресурсы для его работы, затраты на прокси, если нужна ротация IP, и постоянное время на поддержку, когда сайт-цель меняется и ломает селекторы. Для команды, которая уже свободно работает с Go, это может быть действительно дёшево на масштабе. Для команды без такого опыта «бесплатно» очень быстро превращается в «дорого в скрытых расходах».
Thunderbit работает по кредитной модели — проверьте актуальную страницу pricing, потому что тарифы и лимиты кредитов — это как раз то, что меняется, и я бы не хотел называть вам цифру, которая устареет к моменту чтения. Компромисс здесь в том, что вы платите за меньшее количество ручной поддержки на поддерживаемых страницах, а не за полное отсутствие поддержки вообще везде.
Если хотите честную модель оценки, составьте для своей ситуации простую таблицу: время на запуск, затраты на инфраструктуру и прокси, время на исправления и стоимость подписки. Что победит в этой таблице для ваших реальных навыков и нагрузки — то и будет ответом, а не общее рассуждение в духе «open source всегда дешевле».
Кому стоит выбрать Thunderbit?
Если вы бизнес-пользователь, специалист по операционным процессам или член growth-команды, которому нужны структурированные данные прямо сейчас и который не хочет трогать код, браузерное расширение Thunderbit — очевидный выбор. Если вы разработчик, которому нужно использовать извлечение как строительный блок — через API, CLI или внутри AI-агента через MCP, — Thunderbit тоже подходит, просто через другой вход, не через point-and-click.
Кому стоит выбрать Colly?
Если вы Go-разработчик (или вся ваша команда работает на Go) и вам нужен кастомный, высокопроизводительный краулер, где вы контролируете каждый запрос, каждый retry и каждую ротацию прокси, — Colly создан именно под такую задачу. Это также правильный выбор, если вы хотите владеть кодом без зависимости от подписки и у вас есть инженерный ресурс, чтобы всё это поддерживать.
Могут ли команды использовать оба решения?
Честно говоря, да, и я не считаю этот ответ уходом от темы. В инженерных командах очень часто один устойчивый, масштабный Colly-краулер обслуживает ключевой data pipeline, а другие команды — продажи, операции, маркетинг — используют Thunderbit для разовых задач по извлечению, которые не стоит превращать в отдельный скрипт и поддерживать его. Я не буду выдумывать здесь какую-то «официальную интеграцию» между ними — насколько мне известно, её нет, — но архитектурно ничто не мешает обеим системам жить в одной компании и решать разные задачи.
Итог
Выбирайте исходя из того, кто будет делать работу и что для него важнее. Если у вас есть Go-навыки, нужны кастомные сценарии и вы готовы владеть поддержкой в обмен на полный контроль и нулевую стоимость подписки, Colly — правильный инструмент. Если вам нужны данные быстро, вы не хотите писать и поддерживать код, и вас устраивает обмен части низкоуровневого контроля на управляемый опыт — включая возможность подключить извлечение к API или AI-агенту, — Thunderbit подойдёт лучше. Ни один из них не «лучше» вообще; они созданы для разных людей, решающих разные задачи.
FAQ
Colly бесплатен?
Да — Colly распространяется как open-source под лицензией Apache 2.0, поэтому сама библиотека ничего не стоит. Реальные затраты появляются из-за времени разработчиков, хостинга, прокси при необходимости и постоянной поддержки, когда сайт-цель меняется.
Умеет ли Colly рендерить JavaScript?
Нативно — нет. Colly в первую очередь работает как HTTP/HTML-фреймворк, поэтому для сайтов с тяжёлым JS обычно нужно либо находить лежащий под ним JSON API, либо использовать Colly вместе с отдельным инструментом браузерной автоматизации.
Поддерживает ли Thunderbit API и MCP-доступ для разработчиков?
Да. У Thunderbit есть Open API для программного извлечения и MCP Server, который делает извлечение вызываемым инструментом внутри совместимых AI-agent workflow, например в Claude, Cursor или Windsurf.
Что быстрее для старта?
Thunderbit — по задумке. Поток One Click Extract в браузерном расширении даёт результат за секунды или минуты без кода. Colly требует сначала написать и протестировать Go-код, и только потом вы увидите первый результат.
Что даёт больше низкоуровневого контроля над самим краулингом?
Однозначно Colly. Вы напрямую управляете параллелизмом через goroutines, лимитами запросов, кэшированием, ротацией прокси и backend'ами хранения — такого уровня настройки управляемый продукт вроде Thunderbit не предоставляет по своей природе.
