Busca “Colly” y siempre aparece el mismo adjetivo primero: rápido. Un crawler Go rápido, rápido porque compila, rápido porque no tiene un navegador estorbando. Casi nadie lo acompaña con una cifra.
Así que dejé de creer esa palabra por fe. Monté un pequeño sitio de pruebas, compilé Colly contra él y observé qué hacía realmente la librería: el recall en páginas reales, cómo resolvía una petición fallida, hasta dónde llegaba un rastreo con profundidad limitada. La versión corta, antes de entrar en números: la extracción estática devolvió un recall completo, un error 500 terminó exactamente donde debía, y un rastreo con límite de profundidad alcanzó 17 páginas desde un único binario estático, sin navegador conectado. La librería también devolvió un cero limpio en todo lo que dependía de JavaScript, que casualmente es justo la parte que el coro de “rápido” suele saltarse.
Qué es realmente Colly, y qué no es
Colly se presenta como un “elegant scraper and crawler framework for Golang”, y esa sola frase pesa más de lo que parece. Se trata de una librería de Go — alrededor de ~25.4k estrellas al 2026-07-09 en gocolly/colly, con licencia Apache-2.0. No es una herramienta de línea de comandos que descargas y apuntas a una URL. Escribes Go, importas el paquete, conectas unos cuantos callbacks y compilas el resultado en un ejecutable único.
El modelo mental es orientado a eventos, y eso descoloca a quien viene de la costumbre de hacer request y parsear. No recorres una respuesta sacando campos línea por línea. Asocias handlers a un Collector y dejas que la librería los dispare mientras avanza por las páginas. OnHTML ejecuta tu código de extracción cada vez que aparece un selector CSS que coincide. OnResponse te entrega el cuerpo bruto de la respuesta, algo clave cuando la carga útil es JSON y no HTML. OnError captura las peticiones que fallan. El rastreo funciona igual: dentro de un handler para enlaces, llamas a Visit() sobre las URLs que encuentras, Colly las pone en cola, y MaxDepth decide hasta dónde puede extenderse. Callbacks, cola de visitas, límite de profundidad, compilación estática. Sin intérprete, sin runtime, sin Chrome headless ocupando memoria.
El modelo de callbacks, y por qué cambia la sensación al extraer datos
Los callbacks son la personalidad completa de la herramienta, así que vale la pena detenerse un poco en ellos. Tres de ellos sostuvieron todas las pruebas que ejecuté.
OnHTML(selector, handler) es el que usarás más. Lo registras con .product o article p, y Colly llama a tu handler una vez por cada elemento coincidente mientras analiza el DOM. Ahí vive la extracción estructurada, y se lee muy bien: tú describes lo que quieres, no el bucle que lo obtiene.
OnResponse(handler) está un nivel más abajo y te da los bytes crudos que llegan por la red. Cuando un objetivo devuelve JSON en lugar de HTML, ni siquiera tocas el DOM: deserializas el cuerpo tú mismo. Ese único callback fue la razón por la que Colly manejó una API JSON en mi prueba sin tener que parsear ni una migaja de HTML.
OnError(handler) es el callback que todo el mundo olvida hasta que el scraper se cae a las 3 de la mañana. Se activa cuando falla una petición y te entrega la respuesta para que puedas leer el código de estado y decidir qué hacer después. Un crawler que traga silenciosamente los fallos es peor que uno que revienta con ruido; Colly no hace ni una cosa ni la otra, y eso importa mucho más de lo que parece cuando el trabajo corre sin supervisión.
Encima de esos callbacks hay dos funciones más que importan en operación. MaxDepth limita el rastreo, así que un colector que sigue enlaces se detiene a dos saltos en vez de pasearse por toda la web. Y el resultado de compilación es un binario Go estático único: compilas una vez, obtienes un solo archivo sin dependencias en runtime, lo dejas en un servidor o en un job de CI y lo ejecutas. Si alguna vez perdiste una tarde peleándote con un virtualenv de Python en una máquina recién montada, este perfil de despliegue se siente como una ventaja, no como una nota al pie.
Configuración — la parte de Go que nadie menciona
La historia de dependencias es corta, pero tiene un detalle importante, así que lo digo antes de que instales nada. La máquina donde hice la prueba no tenía Go instalado, y Colly es una librería de Go, así que el paso cero fue poner un toolchain en el sistema: instalé Go 1.26.5 con Homebrew. Si tu equipo no vive ya en Go, esa es la fricción real. No la librería. El entorno de lenguaje que necesita antes de compilar una sola línea.
Con Go listo, instalar Colly fue limpio. go get github.com/gocolly/colly/v2 resolvió a v2.3.0 sin complicaciones: sin navegador, sin nada headless, sin más dependencia que el binario compilado al final. Comparado con scrapers en Python que instalan un parser y luego se rompen en el primer fetch por una cadena de extras faltantes, esto fue agradablemente aburrido. Y aburrido aquí es un cumplido.
Un apunte de precisión, dicho sin rodeos, porque te va a confundir seguro si te pones a revisar. El módulo más reciente en el proxy de Go es v2.3.0, publicado en diciembre de 2025. El release con tag más nuevo en GitHub es v2.2.0, de marzo de 2025. Así que el código que probé — v2.3.0 — va por delante de lo que muestra la página de Releases del repositorio. Es una particularidad de cómo se van separando con el tiempo los módulos de Go y los tags de GitHub, no una señal de que algo vaya mal. Solo no te sorprendas cuando go get y la página de Releases te den números distintos.
Prueba práctica — las cifras detrás de “rápido”
Ejecuté Colly contra un servidor de pruebas autocontenido construido con httptest de Go, además de dos sitios demo públicos, para que el comportamiento sea reproducible y no solo una historia que te estoy contando. Esto fue lo que devolvió.
| Prueba | Destino | Resultado |
|---|---|---|
| Catálogo estático + paginación | entorno local de prueba | 12/12 productos, recall 1.0 |
| Extracción de artículo | entorno local de prueba | título + 3/3 párrafos |
| API JSON dinámica | entorno local de prueba | 8/8 elementos vía OnResponse, recall 1.0 |
| Manejo de HTTP 500 | entorno local de prueba | enviado a OnError, estado 500 |
Grafo de rastreo (MaxDepth 2) | entorno local de prueba | 17 páginas |
| Books to Scrape | demo público | 20 productos |
| Página dinámica (sin JS) | entorno local de prueba | 0 tarjetas (esperado) |
| Quotes JS (sin renderizado) | demo público | 0 (esperado) |
Si lees eso de arriba abajo, el cuadro encaja. La extracción estática salió limpia: 12 de 12 productos del catálogo, los 3 párrafos del artículo, todo impulsado por selectores OnHTML. La prueba de la API JSON nunca abrió un parser HTML: OnResponse entregó el cuerpo, yo lo deserialicé, y volvieron 8 de 8 elementos. La prueba del 500 es la que más me importa, porque marca la frontera entre un crawler que puedes dejar corriendo toda la noche y uno que no: Colly mandó la falla a OnError y expuso el estado con claridad, sin caída ni pérdida silenciosa. En la demo pública Books to Scrape extrajo 20 productos sin ningún tratamiento especial.
El resultado del rastreo es el titular, y quiero expresarlo con cuidado. Un colector con MaxDepth(2), siguiendo enlaces y resolviéndolos como URLs absolutas, alcanzó 17 páginas en mi grafo de pruebas. Esa es la frase del “crawler Go rápido” por fin respaldada por un número real de páginas, en lugar de una simple sensación. Pero fíjate bien en la redacción: 17 páginas dentro de un rastreo con profundidad 2. Ese número de profundidad es el contador de mi propio harness de pruebas, que describe cómo configuré la ejecución; no estoy afirmando que Colly garantice internamente “exactamente profundidad 2, sin pasar un enlace más” como contrato. La afirmación honesta y verificable es esta: con la profundidad limitada a 2, el rastreo recorrió el grafo y llegó a 17 páginas.
Ahora el techo, que es justo donde suelen callarse los posts de “es tan rápido”. Colly no ejecuta JavaScript. Lo apunté a un entorno de prueba renderizado con JavaScript y obtuve 0 tarjetas; luego lo apunté a la página pública Quotes to Scrape JS y volvió a dar 0. Eso no es un bug ni una crítica injusta. Colly es un crawler HTTP: descarga y analiza HTML, y nunca arranca un navegador para ejecutar scripts del lado del cliente. Igual que Scrapy y otros crawlers HTTP-first, si el contenido que buscas solo existe después de que JavaScript se ejecute, Colly te devuelve un resultado vacío siempre, y por mucha velocidad bruta que tenga eso no cambia. Tendrás que combinarlo con un renderer o elegir una herramienta que ya lo incluya.
También quiero ser igual de claro sobre lo que no probé, para que nadie estire mis resultados más allá de la evidencia. No llevé al límite el colector asíncrono, la configuración de rate limiting y politeness, la rotación de proxies, ni los backends de cola y almacenamiento. Eso existe en Colly. Yo probé el núcleo de extracción y rastreo, no la infraestructura para escalar. El README anuncia un rendimiento por encima de mil requests por segundo en un solo núcleo, pero esa es la cifra del proyecto; yo medí conteos de páginas y recall, no throughput, así que cuando digo “rápido” me refiero al camino de extracción compilado en Go que realmente cronometré, no a un benchmark contra Scrapy que no ejecuté.
Pros y contras
Pros:
- Recall completo en extracción estática: 12/12 productos del catálogo y 3/3 párrafos del artículo mediante
OnHTML. - Manejo limpio de JSON con
OnResponse, sin necesidad de parsear DOM: 8/8 elementos de la API. - Enrutamiento correcto de fallos: un 500 llegó a
OnErrorcon el estado expuesto, sin caída. - Un rastreo con profundidad limitada alcanzó 17 páginas desde un solo colector.
- Un único binario Go estático, sin dependencias en runtime: un perfil de despliegue y operación excelente.
- Licencia permisiva Apache-2.0.
Contras:
- No ejecuta JavaScript: el contenido renderizado por el cliente devuelve 0, sin matices.
- Requiere un toolchain de Go; los equipos que no usan Go pagan ese coste de configuración antes de escribir un scraper.
- El módulo más reciente (
v2.3.0) está por delante del último release con tag (v2.2.0), lo que confundirá a quien mire la página de Releases. - La salida depende de tu propio código: Colly te da callbacks, no un dataset listo ni un exportador de feeds integrado como Scrapy.
- Los backends asíncronos, de rate limiting, proxy y cola existen, pero no se probaron aquí; “rápido” es la ruta de extracción que medí, no una comparación directa de throughput.
Para quién es Colly — y quién debería saltárselo
Colly encaja si ya programas en Go y vas a rastrear sitios basados en HTML o JSON a buen ritmo. Si tu definición de un despliegue limpio es copiar un binario a una máquina y ejecutarlo — sin intérprete, sin virtualenv, sin lotería de dependencias — la herramienta está pensada exactamente para esa mentalidad. El modelo de callbacks gana valor en cuanto la extracción deja de ser trivial: OnHTML para estructura, OnResponse para cargas útiles crudas, OnError para los fallos que de otro modo nunca verías. Para un objetivo estático o basado en API que rastreas en horario desde CI, es una opción fuerte y sin drama.
Conviene saltárselo, o al menos añadirle una segunda herramienta, cuando tus objetivos dependen de JavaScript. Colly devolvió 0 en todas las páginas renderizadas por cliente que le puse delante, y eso es por diseño, no un ajuste que puedas activar. También deberías descartarlo si tu equipo no usa Go y no quieres montar un toolchain solo para raspar unos pocos sitios: el compromiso con el lenguaje es real y te toca mantenerlo a ti. Y si quieres que los datos estructurados te lleguen ya hechos en vez de tener que armarlos con código propio, los callbacks de Colly ponen ese trabajo claramente de tu lado de la mesa.
Alternativas — dónde encaja una API de scraping con IA gestionada
Colly es una librería gratuita y de código abierto que compilas y ejecutas por tu cuenta. Tú controlas el código Go, los callbacks, la lógica del rastreo y la máquina donde corre; a cambio no pagas nada por solicitud y mantienes toda la operación dentro de casa. Para un equipo Go, esa es una respuesta perfectamente defendible, y el despliegue en un solo binario es realmente cómodo.
Los dos puntos en que se queda corto son precisamente los dos que vale la pena comparar con otra cosa. Primero, JavaScript: Colly no lo renderiza, así que todo lo que dependa del cliente queda fuera a menos que le acoples un navegador. Segundo, la estructura: Colly te da callbacks y deja la construcción de una salida limpia en tu propio código. Una API de scraping con IA gestionada responde de otra forma a ambas cosas. El stack para desarrolladores de Thunderbit maneja el renderizado de JS y devuelve datos estructurados del lado del servidor. POST /distill convierte una página en Markdown limpio, listo para LLM, con contenido dinámico y anti-bot resueltos por ti. POST /extract devuelve JSON estructurado según un esquema JSON que tú defines, con un renderMode que puedes subir hasta renderizado completo del navegador cuando una página lo requiera. Thunderbit también tiene un servidor MCP para agentes de IA y asistentes de programación — thunderbit_suggest_fields es gratuito, así que puedes explorar qué expone una página antes de comprometerte — y una CLI que puedes ejecutar con npx @thunderbit/thunderbit-cli para terminal, CI y cron.
Prueba Thunderbit para extraer datos web
La diferencia no es mejor o peor. Es dónde vive el trabajo. Con Colly mantienes el renderizado (ninguno), el parsing y el mantenimiento dentro de tu propio binario compilado, sin coste por llamada, y eres tú quien lo cuida cuando un sitio cambia de forma. Con una API gestionada delegas el renderizado de JS, el anti-bot y la salida estructurada, y pagas por llamada a cambio. ¿Objetivos pequeños, nativos de Go, basados en HTML o JSON, que te resulte cómodo poseer y mantener? Ahí el control y la velocidad de Colly ganan sin discusión. ¿Páginas pesadas en JavaScript, o simplemente prefieres recibir JSON con forma de esquema en vez de escribir otro callback? Entonces el camino gestionado es el indicado. Si quieres una visión más amplia, los listados de best web scraping tools y best web scraping GitHub projects muestran dónde se sitúa una librería como Colly frente a las opciones basadas en navegador y las gestionadas.
Veredicto
¿Deberías usar Colly? Sí — si programas en Go y vas a rastrear HTML o JSON a buen ritmo, cumple lo que promete su fama de “crawler rápido”, y ahora además hay números que respaldan esa reputación. Recall completo en extracción estática. JSON limpio vía OnResponse. Un 500 enviado correctamente a OnError. Un rastreo con profundidad 2 que llegó a 17 páginas. Todo ello compilado en un solo binario estático sin dependencias en runtime, que es probablemente la historia de despliegue más amable de toda esta categoría.
Eso sí, hay que medir bien las afirmaciones. No renderiza JavaScript: cada página del lado del cliente en mi prueba devolvió 0, y eso es permanente, no una configuración que se te escapó. Necesita un toolchain de Go, así que los equipos que no usan Go pagan un impuesto de configuración desde el principio. El módulo que instalas (v2.3.0) va por delante del último release etiquetado (v2.2.0), así que no entres en pánico cuando las páginas no coincidan. Y “rápido” aquí significa la ruta de extracción que medí, no un benchmark de throughput que no ejecuté. Dentro de esos límites, Colly es un crawler Go rápido, fiable y realmente desplegable, y hace honor a su reputación en cuanto dejas de pedirle que ejecute JavaScript.
Prueba Thunderbit para extraer datos web Get Started Free
Preguntas frecuentes
¿Colly es realmente rápido, y hay una cifra detrás? Es rápido en el sentido que importa para la ruta principal que medí: Go compilado, recall completo en extracción estática (12/12 productos del catálogo), manejo limpio de JSON y un rastreo con profundidad 2 que llegó a 17 páginas, todo desde un único binario estático. Lo que no ejecuté fue un benchmark de throughput contra Scrapy, así que conviene entender “rápido” como el comportamiento medido de extracción, no como una comparación directa de velocidad.
¿Puede Colly extraer páginas renderizadas con JavaScript? No. Colly es un crawler HTTP: descarga y analiza HTML, pero nunca ejecuta un navegador. Un entorno de prueba renderizado con JavaScript devolvió 0 tarjetas, y la página pública Quotes JS también devolvió 0. Para contenido del lado del cliente tendrás que combinar Colly con un renderer o usar una herramienta que ya traiga renderizado de navegador integrado.
¿Necesito saber Go para usar Colly?
Sí. Colly es una librería de Go, no una CLI independiente: la importas, registras callbacks (OnHTML, OnResponse, OnError) y compilas. La máquina donde hice la prueba no tenía Go instalado, así que la configuración empezó instalando un toolchain (1.26.5). Si tu equipo no trabaja ya en Go, ese entorno es el verdadero coste de entrada.
¿Por qué la versión que instalo no coincide con el último release de Colly en GitHub?
Porque el módulo de Go y el tag de release de GitHub se han ido separando con el tiempo. El módulo más reciente en el proxy de Go es v2.3.0 (diciembre de 2025), mientras que el último release etiquetado en GitHub es v2.2.0 (marzo de 2025). Yo probé v2.3.0. Es una particularidad de módulos frente a tags, no una instalación rota.
¿Colly es gratis para uso comercial? Sí, tiene licencia Apache-2.0, que es permisiva y apta para uso comercial. Como siempre, confirma la licencia actual en el repo antes de construir algo encima.
