Reseña de Colly: HTML estático, JSON directo y el límite del navegador

Construí un sitio de prueba para evaluar la parte de Colly que ni el conteo de páginas ni la fama por velocidad responden: si sus callbacks extraen los registros esperados, enrutan un error HTTP, siguen un grafo acotado y exponen contenido entregado fuera del HTML renderizado. No fue una revisión de rendimiento, sino de corrección y límites.

En los fixtures controlados, extrajo todos los registros estáticos esperados, envió una respuesta 500 a OnError y recorrió 17 URLs en el grafo con profundidad limitada configurada. Devolvió cero elementos objetivo en dos páginas cuyos elementos solo aparecían después de ejecutar JavaScript. Un endpoint JSON accesible directamente siguió siendo utilizable sin navegador, una diferencia importante frente a renderizar la interfaz del cliente.

Qué es realmente Colly

Colly se presenta como un “elegant scraper and crawler framework for Golang”, y esa descripción dice más de lo que parece. Es una librería de Go —con alrededor de 25,300 estrellas en GitHub y 1,850 forks— bajo licencia Apache-2.0. No es una CLI que descargas y apuntas a una URL. Escribes Go, importas Colly, registras algunos callbacks y compilas todo en un solo ejecutable.

El modelo mental es orientado a eventos. Adjuntas handlers a un Collector: OnHTML ejecuta la lógica de extracción para los selectores CSS que coinciden, OnResponse entrega el cuerpo crudo de la respuesta y OnError maneja fallos de solicitud. Los handlers de enlaces llaman a Visit() sobre las URLs descubiertas, mientras que MaxDepth limita el recorrido. Para estas rutas solo HTTP, el host de destino no necesita un runtime de Go ni un navegador instalados por separado; si el ejecutable termina siendo totalmente estático depende de las banderas de compilación y del uso de CGO, algo que esta prueba no registró.

Funciones clave y cómo funcionan por dentro

El modelo de callbacks es lo principal que hay que entender, porque es lo que hace que Colly se sienta distinto de un script que simplemente hace requests y parsea. Tres callbacks cubrieron todas las pruebas que ejecuté.

OnHTML(selector, handler) es el caballo de batalla. Lo registras sobre .product o article p y Colly invoca tu handler una vez por cada elemento que coincida mientras parsea el DOM. Ahí vive la extracción estructurada, y se lee con claridad: describes qué quieres capturar, no escribes un bucle de parsing.

OnResponse(handler) trabaja un nivel más abajo y te entrega los bytes crudos. Cuando un destino devuelve JSON en lugar de HTML, puedes saltarte por completo el DOM y deserializar el cuerpo por tu cuenta. Ese único callback explica por qué Colly manejó una API JSON sin problemas en mis pruebas, sin hacer ningún parsing de HTML.

OnError(handler) se encarga de los fallos de solicitud y puede exponer el estado de la respuesta al código que llama. En esta prueba, un fixture con estado 500 llegó al callback registrado. No se probaron reintentos, timeouts, fallos DNS, resets de conexión, panics en callbacks, persistencia ni alertas.

Encima de los callbacks hay dos funciones operativas. MaxDepth limita el recorrido de enlaces según la semántica de profundidad de Colly. Un ejecutable compilado en Go también evita depender de un runtime del lenguaje instalado por separado en el host de destino. Esta ejecución no registró flags de compilación ni estado de CGO, así que no afirma que cada binario resultante sea completamente estático.

Configuración: la toolchain de Go requerida

La historia de dependencias es breve, pero real, así que la adelanto antes de que instales nada. La máquina donde probé no tenía Go instalado, y Colly es una librería de Go; por tanto, el paso cero fue poner una toolchain de Go en el equipo (instalé Go 1.26.5 con Homebrew). Si tu equipo no vive ya en Go, esa es la fricción: no Colly en sí, sino el entorno de lenguaje que necesita antes de compilar una sola línea.

Una vez instalado Go, go get github.com/gocolly/colly/v2 resolvió a v2.3.0. Las rutas probadas no requirieron navegador ni Chrome headless.

Hay un punto de versiones que puede confundir. El módulo de Go resolvió a v2.3.0 (publicado en diciembre de 2025), mientras que la entrada más reciente visible en la interfaz de Releases de GitHub era v2.2.0 (marzo de 2025) en el momento de la comprobación. La diferencia es entre versión del módulo/repositorio y entrada de GitHub Release, no entre módulo y tag de Git. Yo probé v2.3.0.

Prueba práctica: extracción y límites operativos

Ejecuté Colly contra un servidor de fixtures autocontenido (httptest de Go) y dos sitios demo públicos. El directorio de benchmark actual y results/colly-test-summary.json exponen artefactos, pero ambos enlaces siguen una rama en movimiento. El artículo no proporciona un commit probado, el comando exacto, los flags de compilación ni la semilla de fixtures, así que todavía no es una receta de reproducción inmutable.

En los fixtures estáticos controlados, los selectores configurados devolvieron 12 de los 12 registros de producto esperados y los tres párrafos esperados del artículo. La respuesta JSON directa nunca tocó un parser HTML: OnResponse entregó el cuerpo y el harness decodificó los ocho elementos esperados. El único fixture 500 llegó a OnError con su estado expuesto y no rompió esa ejecución; eso no demuestra fiabilidad sin supervisión. En la página pública Books to Scrape, el selector devolvió 20 productos como prueba rápida sobre un sitio real.

Para el recorrido, el collector se configuró con MaxDepth(2) usando la convención de profundidad de la semilla del harness y visitó 17 URLs en el grafo de fixtures. El resultado habla de cobertura de rastreo, no de velocidad. El rastro observado —no una afirmación general sobre grafos arbitrarios— está en results/local_crawl_graph.json.

Colly no ejecuta JavaScript. El fixture renderizado con JavaScript produjo 0 tarjetas objetivo, y la página pública Quotes to Scrape JS produjo 0 citas objetivo. Si los elementos solo existen después de la ejecución en el navegador y no hay un endpoint de respaldo accesible que los entregue, la ruta HTTP únicamente no puede ver esos elementos como DOM renderizado. Combínalo con un renderer, o llama directamente al endpoint de respaldo cuando exista, como muestra el fixture JSON.

No sometí a prueba el collector asíncrono, la limitación de tasa ni la configuración de cortesía, la rotación de proxies, los reintentos, ni los backends de cola y almacenamiento. No medí tiempo transcurrido, throughput, concurrencia, CPU, memoria, latencia del destino ni una línea base de comparación. Por tanto, este artículo no hace ninguna afirmación de velocidad ni de fiabilidad sin supervisión.

Cómo interpretar los resultados de los fixtures

Las tres rutas de contenido exitosas ejercitan contratos distintos. Los casos de catálogo y artículo prueban la selección CSS sobre HTML devuelto por el servidor. Sus denominadores son expectativas de fixture escritas antes de extraer: doce registros de producto y tres párrafos de artículo. Presentarlos como “registros esperados extraídos” es deliberado. La ejecución no define matching difuso, manejo de duplicados, tolerancia a campos parciales ni una métrica de recall sobre un corpus completo, así que el resultado no debe inflarse hasta convertirlo en precisión general de extracción.

El caso JSON evita la selección del DOM. Colly recibe los bytes de la respuesta a través de OnResponse, y el harness realiza la decodificación JSON. Por eso “Colly no renderiza JavaScript” no significa que todos los sitios respaldados por cliente sean inalcanzables. Si la fuente de datos que usa el cliente es un endpoint llamable directamente y la solicitud puede reproducirse fuera del navegador, el crawler HTTP puede ser suficiente. La autenticación, las firmas generadas, el estado exclusivo del navegador y los controles anti-bot pueden cambiar esa respuesta; aquí no se ejercitó ninguno de ellos.

La ruta 500 prueba despacho, no recuperación. Muestra que el callback OnError registrado recibió ese fixture y su estado. Un crawler de producción sigue necesitando una política explícita para códigos reintentables, backoff, fallos terminales, persistencia y alertas. La prueba no aporta evidencia para esas decisiones, y “el callback se activó” no debe leerse como “el trabajo se puede confiar sin supervisión”.

El grafo de 17 URLs es igual de acotado. Confirma el conjunto de visitados producido por este fixture, esta convención de semilla y MaxDepth(2). No establece páginas por segundo, equidad entre hosts, crecimiento de memoria ni comportamiento ante ciclos y formas duplicadas de URL. Eso requiere pruebas separadas de carga y de cola.

Lista de selección basada en esta ejecución

Empieza mirando la respuesta que Colly recibe realmente. Si los campos requeridos están presentes en el HTML devuelto por el servidor, usa OnHTML y valida el número de campos o las claves obligatorias antes de aceptar un registro. Si la respuesta es JSON, procesa el cuerpo mediante OnResponse y valida su esquema. Si el HTML es solo un shell de aplicación, comprueba si una solicitud de respaldo accesible contiene los datos antes de añadir un navegador.

Cuando la ejecución del navegador es necesaria, trátala como otro componente, no como algo que se activa con una bandera de Colly. El navegador debe establecer la disponibilidad, exponer el contenido renderizado o las respuestas de respaldo, y pasar los datos al resto del pipeline. Esta revisión no probó esa integración.

Para despliegue, registra la versión de Go, la versión del módulo, los flags de compilación, el estado de CGO, el comando exacto, la semilla de fixtures y el commit del repositorio. Esos detalles faltan en los enlaces de publicación actuales y marcan la diferencia entre artefactos inspeccionables y una reproducción duradera. En operaciones, añade una matriz de fallos y mide la carga que realmente te importa antes de llamar al sistema rápido o fiable.

Ventajas y desventajas

Ventajas:

• Extrajo 12/12 productos esperados del catálogo y 3/3 párrafos esperados del artículo mediante OnHTML.
• Manejo limpio de JSON a través de OnResponse, sin necesidad de parsing del DOM: 8/8 elementos de la API.
• La respuesta 500 probada llegó a OnError con el estado expuesto.
• Un crawl con profundidad limitada recorrió 17 páginas desde un solo collector.
• Compila en un ejecutable de Go; el destino no necesita un runtime de Go instalado por separado para las rutas probadas.
• Licencia Apache-2.0 permisiva.

Desventajas:

• No ejecuta JavaScript: el contenido renderizado por el cliente devuelve 0, sin matices.
• Requiere una toolchain de Go; los equipos que no usan Go pagan ese coste de preparación antes de escribir un scraper.
• El módulo probado (v2.3.0) está por delante de la última entrada de GitHub Release observada (v2.2.0).
• El output depende de tu propio código: Colly te da callbacks, no un dataset integrado ni un exportador de feeds como Scrapy.
• Los backends asíncronos, de limitación de tasa, de proxy y de cola existen, pero no se probaron aquí; el throughput y la escala siguen sin medirse.

Para quién sirve y quién debería descartarlo

Colly encaja si ya programas en Go y apuntas a HTML renderizado por el servidor o a JSON accesible directamente. El modelo de callbacks separa coincidencias estructuradas, payloads crudos y fallos de solicitud. Un ejecutable compilado también evita depender de un entorno de lenguaje instalado por separado en la máquina de destino, aunque aquí no se verificó el enlazado totalmente estático.

Añade un renderer cuando los elementos objetivo solo aparezcan después de ejecutar el navegador y no exista un endpoint de respaldo útil. Un endpoint JSON directo puede seguir solicitándose sin renderizado. Colly también es menos adecuado para equipos que no quieren una toolchain de Go o que prefieren que un servicio de extracción se encargue de la forma del esquema y del mantenimiento de selectores.

Alternativas, y dónde encaja Thunderbit

Colly es software de código abierto que ejecutas tú mismo. No tiene tarifa de uso del proveedor, pero el cómputo, el ancho de banda, los proxies, el almacenamiento, la observabilidad y la ingeniería siguen siendo tus costes. Tú te ocupas del comportamiento de las solicitudes, de los callbacks de parsing, de la lógica de rastreo y de la integración con navegador si un destino necesita renderizado.

Un servicio de extracción gestionado traslada parte de esas responsabilidades a un proveedor. Nosotros construimos Thunderbit, pero no lo probamos contra estos fixtures, así que este artículo no hace comparación de renderizado, anti-bot, calidad, latencia ni coste. La diferencia que sí está cubierta es la propiedad: Colly expone respuestas HTTP y callbacks dentro de tu proceso Go; un servicio gestionado puede encargarse de la adquisición y de la forma del esquema por una tarifa por llamada.

Revisiones relacionadas del benchmark: la comparación completa de scrapers open source, la revisión del crawler Python de Scrapy y la revisión del selector adaptativo de Scrapling.

Prueba Thunderbit para extraer datos web

Veredicto

Colly es un candidato sólido para equipos de Go que apuntan a HTML renderizado por el servidor o JSON directo y están dispuestos a hacerse cargo de su código de extracción. Los fixtures respaldan la extracción de registros esperados, un trace de crawl acotado y una respuesta 500 observada, pero no velocidad, escala ni fiabilidad sin supervisión. El DOM renderizado por navegador requiere otra vía, salvo que el endpoint de datos subyacente pueda llamarse directamente.

Prueba Thunderbit para extraer datos web Get Started Free

Preguntas frecuentes

¿Esta revisión midió la velocidad de Colly? No. Midió extracción de registros esperados, manejo directo de JSON, un callback de error y cobertura de un grafo de crawl de fixtures. No midió tiempo transcurrido, throughput, concurrencia, CPU, memoria ni una línea base de comparación.

¿Colly puede extraer páginas renderizadas con JavaScript? Colly no ejecuta el JavaScript de la página. Por eso la ruta HTTP probada no encontró elementos objetivo que solo existían en el DOM renderizado. Aun así, puede solicitar directamente un endpoint JSON de respaldo accesible, como muestra el fixture JSON. Usa un renderer cuando la ejecución sea obligatoria y no exista una solicitud de respaldo reproducible que entregue los datos.

¿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 probé no tenía Go, así que la configuración empezó instalando una toolchain de Go (1.26.5). Si tu equipo no trabaja ya con Go, ese entorno es el coste real de puesta en marcha.

¿Por qué la versión que instalo no coincide con la última release de GitHub de Colly? El módulo de Go resolvió a v2.3.0 (diciembre de 2025), mientras que la entrada más reciente de GitHub Release observada era v2.2.0 (marzo de 2025). Yo probé v2.3.0; es una diferencia entre superficies de versión, no evidencia de una instalación rota.

¿Colly es gratis para uso comercial? Sí, está bajo Apache-2.0, una licencia permisiva y apta para uso comercial. Como siempre, conviene confirmar la licencia actual en el repo antes de construir sobre ella.

Antes de adoptarlo en producción, añade pruebas que reflejen el riesgo operativo en lugar de extrapolar el resultado de los fixtures por analogía. Cronometra rastreos repetidos sobre destinos representativos, registra CPU y memoria pico, prueba fallos reintentables y terminales, y verifica la cortesía bajo concurrencia. Si la persistencia importa, detén y reanuda un crawl mientras inspeccionas el manejo de duplicados y el estado de la cola. Si la simplicidad de despliegue importa, registra la configuración exacta del compilador y del enlazador e inspecciona las dependencias en tiempo de ejecución del ejecutable generado. Ninguna de esas comprobaciones cambia lo que estableció el fixture actual; solo determinan si esa misma configuración de biblioteca encaja en un trabajo de producción concreto.