Если поискать «Colly», первое прилагательное в описаниях почти всегда одно и то же: быстрый. Быстрый Go-краулер, быстрый потому что компилируется, быстрый потому что ему не мешает браузер. Но почти никто не подкрепляет это цифрами.
Поэтому я решил не верить на слово. Я поднял небольшой тестовый сайт, скомпилировал под него Colly и посмотрел, что библиотека реально делает: какова полнота извлечения на обычных страницах, куда попадает запрос с ошибкой, насколько далеко уходит обход при ограничении глубины. Если коротко, еще до цифр: статическое извлечение дало полное покрытие, ошибка 500 ушла ровно туда, куда и должна, а обход с ограничением глубины дошел до 17 страниц из одного статического бинарника без подключенного браузера. При этом библиотека честно вернула ноль на всем, что рендерится JavaScript’ом — то есть именно на том, что любители слова «fast» обычно опускают.
Что такое Colly на самом деле — и чем он не является
Colly позиционируется как «элегантный фреймворк для скрейпинга и краулинга на Golang», и эта формулировка куда важнее, чем кажется. Это Go-библиотека — примерно ~25.4k звезд по состоянию на 2026-07-09 у gocolly/colly, под лицензией Apache-2.0. Это не отдельная командная утилита, которую можно скачать и сразу запустить на URL. Вы пишете на Go, подключаете пакет, настраиваете несколько callback’ов и собираете результат в один исполняемый файл.
Модель здесь событийная, и это сбивает с толку тех, кто привык к схеме «запросил — распарсил». Вы не проходите по ответу и не вытаскиваете поля построчно. Вы навешиваете обработчики на Collector, а библиотека вызывает их по мере обхода страниц. OnHTML запускает код извлечения каждый раз, когда встречается совпадающий CSS-селектор. OnResponse передает сырое тело ответа — это особенно полезно, когда вместо HTML приходит JSON. OnError ловит запросы, которые упали. С краулингом все так же: внутри обработчика ссылок вы вызываете Visit() для найденных URL, Colly ставит их в очередь, а MaxDepth определяет, насколько далеко можно уйти. Callback’и, очередь посещений, ограничение глубины, статическая сборка. Никакого интерпретатора, никакой runtime-среды, никакого headless Chrome в памяти.
Модель callback’ов и почему она меняет ощущение от извлечения данных
Callback’и — это и есть характер этого инструмента, поэтому их стоит разобрать чуть медленнее. Во всех тестах мне хватило трех.
OnHTML(selector, handler) — самый полезный вариант. Вы вешаете его на .product или article p, и Colly вызывает ваш обработчик для каждого совпавшего элемента, пока парсит DOM. Именно здесь живет структурированное извлечение: вы описываете, что хотите получить, а не пишете весь цикл обхода вручную.
OnResponse(handler) находится уровнем ниже и дает вам сырые байты из ответа. Когда целевой ресурс возвращает JSON вместо разметки, DOM вам вообще не нужен — вы сами распаковываете тело. Именно этот callback позволил Colly обработать JSON API в моем тесте, не разбирая ни кусочка HTML.
OnError(handler) — тот callback, о котором все забывают, пока скрейпер не падает в три часа ночи. Он срабатывает при сбое запроса и передает вам ответ, чтобы можно было посмотреть код статуса и решить, что делать дальше. Краулер, который тихо проглатывает ошибки, хуже, чем тот, который громко падает; Colly не делает ни того ни другого, и это важнее, чем кажется, когда задача работает без присмотра.
Есть еще две вещи поверх этих callback’ов, и в работе они очень важны. MaxDepth ограничивает обход, так что collector, который следует по ссылкам, не уходит в открытый интернет, а останавливается в заданных пределах. А результат сборки — это один статический Go-бинарник: собрали один раз, получили один файл без runtime-зависимостей, положили на сервер или в CI-задачу и запустили. Если вы когда-нибудь теряли полдня из-за Python virtualenv на чистой машине, такой сценарий разворачивания выглядит не как примечание, а как реальное преимущество.
Настройка — про Go toolchain, о котором обычно не говорят
История зависимостей короткая, но с одной важной оговоркой, поэтому скажу о ней сразу, до установки. На машине, где я тестировал, Go вообще не было, а Colly — это Go-библиотека, значит первым делом пришлось поставить toolchain — я установил Go 1.26.5 через Homebrew. Если ваша команда не живет в Go, вот это и есть настоящая сложность. Не библиотека. А языковая среда, без которой не скомпилируется ни одна строка.
С установленным Go все прошло гладко. go get github.com/gocolly/colly/v2 без проблем подтянул v2.3.0 — без браузера, без headless-режима, без всего лишнего, только скомпилированный бинарник в конце. На фоне Python-скрейперов, которые ставят парсер, а потом разваливаются на первом же запросе из-за цепочки недостающих пакетов, это было приятно скучно. А скучно — в данном случае комплимент.
Один важный технический момент, который стоит проговорить явно, чтобы потом не запутаться. Самая свежая версия модуля в Go proxy — v2.3.0, опубликована в декабре 2025 года. Самый новый тег релиза на GitHub — v2.2.0, от марта 2025 года. То есть код, который я тестировал, v2.3.0, опережает то, что показывает страница Releases в репозитории. Это особенность того, как со временем расходятся Go modules и GitHub-теги, а не признак проблемы. Просто не удивляйтесь, если go get и страница релизов покажут разные числа.
Практика — цифры, которые стоят за словом «fast»
Я запускал Colly на самодостаточном тестовом сервере на базе httptest из Go, а также на двух публичных демо-сайтах, чтобы поведение можно было воспроизвести, а не принимать на веру. Вот что получилось.
| Тест | Цель | Результат |
|---|---|---|
| Статический каталог + пагинация | локальный тестовый сайт | 12/12 товаров, полнота 1.0 |
| Извлечение статьи | локальный тестовый сайт | заголовок + 3/3 абзаца |
| Динамический JSON API | локальный тестовый сайт | 8/8 элементов через OnResponse, полнота 1.0 |
| Обработка HTTP 500 | локальный тестовый сайт | перенаправлено в OnError, статус 500 |
Граф обхода (MaxDepth 2) | локальный тестовый сайт | 17 страниц |
| Books to Scrape | публичная демо-страница | 20 товаров |
| Динамическая страница (без JS) | локальный тестовый сайт | 0 карточек (ожидаемо) |
| Quotes JS (без рендера) | публичная демо-страница | 0 (ожидаемо) |
Если читать сверху вниз, картина складывается довольно цельно. Статическое извлечение сработало чисто: 12 из 12 товаров в каталоге, все 3 абзаца статьи, и все это через OnHTML селекторы. Тест с JSON API вообще не открывал HTML-парсер: OnResponse передал тело ответа, я распаковал JSON, и вернулись все 8 из 8 элементов. Тест на 500-й статус для меня самый важный, потому что именно он отделяет краулер, который можно оставить работать ночью, от того, которому доверять нельзя: Colly отправил сбой в OnError, корректно показал статус и не упал, ничего не потерял молча. На публичной демо-странице Books to Scrape он извлек 20 товаров без какой-либо специальной обработки.
Результат обхода — главный вывод, и тут важно сформулировать его аккуратно. Collector с MaxDepth(2), который переходил по ссылкам и приводил их к абсолютным URL, добрался до 17 страниц в моем тестовом графе. Вот вам и конкретное число вместо ощущения, за которым обычно прячется фраза «fast Go crawler». Но обратите внимание на формулировку: 17 страниц в рамках обхода с глубиной 2. Само число глубины — это счетчик моего тестового стенда, то есть способ, которым я настроил запуск; я не утверждаю, что Colly внутренне гарантирует контракт «строго глубина 2 и ни шагом дальше». Честное и проверяемое утверждение такое: при ограничении глубины до 2 обход прошел по графу и достиг 17 страниц.
Теперь о потолке возможностей — это та часть, где посты про «насколько это быстро» обычно замолкают. Colly не исполняет JavaScript. Я направил его на тестовую страницу, рендерящуюся JS, и получил 0 карточек; затем проверил публичную страницу Quotes to Scrape JS и снова получил 0. Это не баг и не недостаток. Colly — это HTTP-краулер: он скачивает и парсит HTML, но никогда не запускает браузер ради клиентских скриптов. Как и Scrapy и другие HTTP-first краулеры, если нужный контент появляется только после выполнения JavaScript, Colly каждый раз вернет пустой результат, и никакая скорость этот предел не сдвинет. Либо соединяйте его с рендерером, либо выбирайте инструмент, где браузер уже встроен.
Скажу прямо и о том, что я не тестировал, чтобы никто не пытался натянуть мои результаты на то, чего в них нет. Я не прогонял async collector, конфигурацию rate limiting и politeness, ротацию прокси, а также queue и storage backend’ы. Все это в Colly есть. Я проверял ядро извлечения и краулинга, а не инфраструктуру для масштабирования. В README заявлена пропускная способность выше тысячи запросов в секунду на одном ядре, но это уже цифра самого проекта — я измерял число страниц и полноту извлечения, а не throughput. Поэтому когда я говорю «быстрый», я имею в виду именно тот путь извлечения на скомпилированном Go, который реально прогнал, а не сравнение со Scrapy, которого я не делал.
Плюсы и минусы
Плюсы:
- Полное извлечение на статике — 12/12 товаров каталога и 3/3 абзаца статьи через
OnHTML. - Аккуратная работа с JSON через
OnResponse, без необходимости парсить DOM — 8/8 элементов API. - Корректная обработка ошибок — 500 ушел в
OnError, статус был виден, падения не было. - Обход с ограничением глубины достиг 17 страниц из одного collector’а.
- Один статический Go-бинарник, ноль runtime-зависимостей — очень удобный сценарий для деплоя и эксплуатации.
- Дружественная лицензия Apache-2.0.
Минусы:
- Не исполняет JavaScript — контент, рендерящийся на клиенте, дает 0 без вариантов.
- Нужен Go toolchain; команды, которые не работают в Go, сначала платят за настройку окружения.
- Самый свежий модуль (
v2.3.0) опережает последний тег релиза (v2.2.0), и это легко запутает тех, кто смотрит страницу Releases. - На выходе — ваш собственный код: Colly дает callback’и, но не встроенный набор данных и не экспорт feed’а, как Scrapy.
- Async, rate limiting, proxy и queue backend’ы существуют, но в этом тесте не проверялись; «fast» здесь — это измеренный путь извлечения, а не прямое сравнение throughput.
Для кого Colly подходит — а кому лучше пройти мимо
Colly хорошо подходит, если вы уже пишете на Go и краулите сайты, где контент приходит в HTML или JSON, причем в высоком темпе. Если для вас «чистый деплой» — это просто скопировать один бинарник на сервер и запустить его без интерпретатора, virtualenv и лотереи с зависимостями, этот инструмент сделан именно под такой сценарий. Модель callback’ов начинает приносить пользу в тот момент, когда извлечение перестает быть совсем тривиальным: OnHTML — для структуры, OnResponse — для сырых данных, OnError — для сбоев, которые иначе остались бы незамеченными. Для статических сайтов и API, которые вы обходите по расписанию из CI, это сильный и спокойный вариант.
Лучше пройти мимо или, как минимум, подключить второй инструмент, если ваши цели завязаны на JavaScript. В моих тестах Colly возвращал 0 на каждой клиентской странице, и это не настройка, которую можно переключить. Не стоит брать его и в том случае, если ваша команда не работает на Go и вы не хотите поднимать toolchain ради нескольких сайтов — языковая привязка здесь настоящая, и ее нужно поддерживать. А если вам нужна уже готовая структурированная выдача, а не код, который все это собирает сам, то Colly перекладывает эту работу на вас.
Альтернативы — где уместен managed AI scraping API
Colly — бесплатная open-source библиотека, которую вы собираете и запускаете сами. Вы владеете Go-кодом, callback’ами, логикой обхода и машиной, на которой все работает — и взамен не платите за каждый запрос, удерживая все внутри своей инфраструктуры. Для команды, которая живет в Go, это вполне оправданное решение, а сценарий с одним бинарником по-настоящему приятен.
Проблемные места у него ровно два, и именно их стоит сравнивать с альтернативами. Первое — JavaScript: Colly его не рендерит, поэтому любой клиентский контент для него недоступен, если не прикручивать браузер отдельно. Второе — структура: Colly дает callback’и и оставляет формирование чистого результата вашему коду. Managed AI scraping API решает оба вопроса иначе. Developer stack от Thunderbit берет на себя рендеринг JS и возвращает структурированные данные на стороне сервера. POST /distill превращает страницу в чистый Markdown, готовый для LLM, а динамический контент и anti-bot-ограничения обрабатываются за вас. POST /extract возвращает структурированный JSON по заданной вами JSON Schema, а renderMode можно поднять до полного браузерного рендера, если страница этого требует. Для AI-агентов и coding assistants у Thunderbit есть MCP-сервер — thunderbit_suggest_fields бесплатный, так что можно сначала посмотреть, какие поля вообще доступны на странице, прежде чем принимать решение. Есть и CLI, который можно запускать через npx @thunderbit/thunderbit-cli для терминала, CI и cron.
Попробовать Thunderbit для извлечения веб-данных
Разница не в том, что лучше, а в том, где выполняется работа. С Colly вы держите рендеринг (его нет), парсинг и сопровождение внутри собственного скомпилированного бинарника, не платите за вызовы и сами следите за ним, когда сайт меняется. С managed API вы отдаете на сторону рендеринг JS, anti-bot-защиту и структурированный вывод, а платите за каждый запрос за это удобство. Небольшие, Go-native цели на HTML или JSON, которые вы готовы поддерживать сами? Здесь контроль и скорость Colly выигрывают напрямую. Страницы с тяжелым JavaScript или просто желание получать JSON по схеме вместо написания еще одного callback’а? Это уже аргумент в пользу managed-решения. Если хотите посмотреть на более широкий ландшафт, подборки лучших инструментов для веб-скрейпинга и лучших GitHub-проектов для веб-скрейпинга показывают, где библиотека вроде Colly находится рядом с браузерными и управляемыми вариантами.
Итог
Стоит ли использовать Colly? Да — если вы пишете на Go и краулите HTML или JSON с высокой скоростью, он действительно делает то, за что его и любят как «быстрый краулер», и теперь за этой репутацией стоят конкретные цифры. Полная полнота на статике. Чистый JSON через OnResponse. Корректно обработанный 500-й статус через OnError, а не исчезнувший запрос. Обход с глубиной 2, добравшийся до 17 страниц. И все это собирается в один статический бинарник без runtime-зависимостей — пожалуй, самый удобный сценарий деплоя в этой категории.
Но важно честно ограничивать обещания. JavaScript он не рендерит — все клиентские страницы в моем прогоне вернули 0, и это не настройка, которую вы просто забыли включить. Для него нужен Go toolchain, так что командам без опыта в Go придется заплатить за подготовку окружения заранее. Версия модуля, которую вы устанавливаете (v2.3.0), опережает последний тег релиза (v2.2.0), так что не паникуйте, если страницы показывают разные числа. И «fast» здесь означает именно тот путь извлечения, который я измерил, а не throughput-бенчмарк, которого я не запускал. В этих рамках Colly — быстрый, надежный и по-настоящему пригодный к деплою Go-краулер, который оправдывает свою репутацию в тот момент, когда вы перестаете просить его запускать JavaScript.
Попробовать Thunderbit для извлечения веб-данных Get Started Free
Часто задаваемые вопросы
Colly действительно быстрый, и есть ли за этим какая-то цифра? Да, если говорить о том, что важно для ядра, которое я тестировал: скомпилированный Go, полное извлечение на статике (12/12 товаров каталога), корректная работа с JSON и обход с глубиной 2, который достиг 17 страниц — все это из одного статического бинарника. Но я не запускал throughput-бенчмарк против Scrapy, поэтому воспринимайте «fast» как измеренное поведение при извлечении, а не как прямой speed-замер в лоб.
Может ли Colly собирать страницы, где контент рендерится JavaScript’ом? Нет. Colly — это HTTP-краулер: он скачивает и парсит HTML, но не запускает браузер. Тестовая страница с JS-рендерингом вернула 0 карточек, и публичная страница Quotes JS тоже вернула 0. Для клиентского контента нужно либо соединять Colly с рендерером, либо брать инструмент, где браузерный рендеринг уже встроен.
Нужно ли знать Go, чтобы пользоваться Colly?
Да. Colly — это Go-библиотека, а не самостоятельная CLI-утилита: вы подключаете пакет, регистрируете callback’и (OnHTML, OnResponse, OnError) и компилируете проект. На машине, где я тестировал, Go не было вообще, так что настройка началась с установки toolchain (1.26.5). Если ваша команда еще не работает на Go, именно это окружение и есть настоящая цена входа.
Почему версия, которую я устанавливаю, не совпадает с последним релизом Colly на GitHub?
Потому что Go module и GitHub release tag со временем разошлись. Самая свежая версия модуля в Go proxy — v2.3.0 (декабрь 2025), а самый новый тег релиза на GitHub — v2.2.0 (март 2025). Я тестировал v2.3.0. Это особенность расхождения модулей и тегов, а не сломанная установка.
Можно ли использовать Colly в коммерческих проектах бесплатно? Да, лицензия Apache-2.0 — это разрешительный вариант, удобный для коммерческого использования. Как всегда, перед тем как строить на этом продукт, стоит перепроверить актуальную лицензию в репозитории.
