Botasaurus Review: un driver de 4 MB, una instalación de 122 MB y el dato de 0,08 ms que no deberías citar

Botasaurus es un framework de scraping web en Python de Omkar Cloud que se presenta como un kit integral para crear scrapers. Escribes una función normal, la decoras con @browser, @request o @task, y el framework monta alrededor un driver de navegador, un cliente HTTP con apariencia de navegador, caché, paralelismo y exportación en varios formatos. Es un meta-paquete, y eso es lo importante: pip install botasaurus no coloca una sola librería en tu entorno, sino que ensambla una pequeña familia de wheels propias junto con un amplio árbol de dependencias transitivas. Ese detalle mecánico terminó siendo lo más interesante que pude medir con honestidad.

Botasaurus se promociona por su enfoque anti-detección, y justamente esa es la dimensión que esta reseña no evalúa. Hice un inventario del framework —qué instala, qué importa, qué métodos expone, cuánto pesa y bajo qué licencia se publica— en lugar de enfrentarlo a una defensa real en vivo. Todas las cifras de huella e importación que verás abajo provienen de pip, de python -c "import ..." y de la introspección de clases construidas pero nunca usadas para cargar una página; no lancé ningún navegador para obtenerlas. Más adelante sí lancé navegadores, pero solo contra páginas que yo mismo escribí y serví en 127.0.0.1, para ver qué declara el driver sobre sí mismo y si puede extraer contenido de una página que se construye con JavaScript. No intervino ningún sitio real, no se contactó ni midió ningún servicio anti-bot y no se tocó ningún CAPTCHA. La eficacia frente a webs reales queda fuera del alcance a propósito, y prefiero dejarlo claro desde el principio antes que insinuar un benchmark que no ejecuté.

Con ese límite trazado, el hallazgo principal es una historia de huella, y una bastante benigno. Una instalación limpia genera un directorio site-packages de 122,3 MB repartido en 44 paquetes, en una máquina donde el driver de navegador que está en el centro de todo ronda los 4 MB. El framework no pesa porque el driver pese mucho; pesa porque "todo en uno" significa traer numpy, lxml, gevent y una docena de piezas más para una tarea que consiste en obtener HTML. Y la otra mitad del hallazgo es un número que suele citarse como virtud y que no conviene creer al pie de la letra: import botasaurus tarda 0,08 ms, lo que suena a framework ultraligero cuando en realidad solo es una puerta de entrada vacía.

Qué es realmente Botasaurus

Botasaurus — omkarcloud/botasaurus en GitHub, con 5.561 estrellas, 486 forks y 58 issues abiertos cuando consulté los metadatos el 14 de julio de 2026— es un framework de Python, no una librería de un solo propósito. Las versiones que probé fueron botasaurus 4.0.97 para el meta-paquete y botasaurus-driver 4.0.92 para el motor interno. El meta-paquete declara requires-python >=3.7 (el driver, >=3.5), y los clasificadores de PyPI solo afirman compatibilidad hasta 3.11. Se instaló y superó una prueba básica de importación en Python 3.14.2 en mi equipo. Eso es evidencia sobre esta instalación, no una garantía de compatibilidad para cualquier función.

La etiqueta de categoría importa, porque define qué significa "bueno". Botasaurus está en el extremo de framework del espectro, en el mismo vecindario que Scrapy y Crawlee: adoptas su estructura, sus decoradores y sus convenciones, y a cambio él se encarga de la infraestructura. Es una propuesta distinta a la de un driver especializado como nodriver, que te da una conexión con Chrome DevTools Protocol y luego se aparta. Botasaurus incluye un driver (eso es botasaurus-driver), pero lo envuelve con un ejecutor de tareas, una capa de caché, serializadores de salida y un cliente de peticiones. No estás comprando solo un driver; estás comprando un flujo de trabajo con opinión incorporada.

Los tres decoradores son el diseño completo en miniatura, y las tres entradas existen de verdad: confirmé que botasaurus.browser.browser, botasaurus.request.request y botasaurus.task.task están presentes e importan. @browser ejecuta tu función sobre el driver de navegador humanizado. @request la ejecuta sobre un cliente HTTP ligero diseñado para parecerse a un navegador. @task es el envoltorio genérico para todo lo que no encaja claramente en los dos anteriores. Decoras, y Botasaurus aporta el resto: ejecución paralela, reutilización del driver, caché de resultados y exportación a JSON, CSV, Excel y HTML. La idea es coherente. La cuestión real es si quieres tanto framework alrededor de un scraper, y eso es una decisión de gusto, no un defecto.

Mi conclusión, y el límite de esa conclusión

Botasaurus es competente, está bien planteado y hace lo que se espera de un framework: acorta el caso común. El modelo de decoradores es limpio. La licencia MIT es realmente generosa. La instalación funciona sin drama. Si estuviera evaluando la ergonomía de su API, saldría bien parada.

Lo que sigo teniendo presente es que la propia propuesta principal del framework —anti-detección— es precisamente lo único que una reseña responsable no puede juzgar sin apuntarla a defensas de producción de alguien. El driver sí expone una superficie de API claramente asociada a anti-detección: métodos cuya existencia confirmé, pero cuyo comportamiento no ejercité contra ningún objetivo. Eso es todo lo que voy a afirmar al respecto. No lo apunté a un sitio protegido, no medí tasa de éxito, no invertí ningún mecanismo y no voy a sugerir ninguna de esas cosas por la forma de redactarlo. Los métodos están en la clase. Lo que hacen en el mundo real es otra reseña distinta, y esta no es.

Lo que sigue es un inventario de capacidades, instalación, recursos y licencia, además de lo que el driver hace en una página que controlo; una afirmación más estrecha que la de la mayoría de reseñas de esta herramienta, y la estrechez es precisamente el punto.

Qué declara sobre sí mismo

Hay una pregunta que puedes responder sin acercarte a una defensa real: cuando Botasaurus conduce un navegador, ¿qué le confiesa ese navegador a la página que está viendo? Escribí una página que lee las cosas obvias —navigator.webdriver, el user-agent, la plataforma, los idiomas, los conteos de plugins y hardware, la forma de window.chrome, lo que dice la Permissions API y la geometría de ventana y pantalla—, la serví en 127.0.0.1 y apunté cuatro stacks hacia ella: Botasaurus, nodriver y, como controles, Playwright y Puppeteer stock. Los cuatro condujeron la misma versión de Chrome (Chrome for Testing 151.0.7922.10), así que cualquier diferencia viene de la librería y no del navegador. Se probaron modos headless y headed, tres veces cada uno. Todos los valores de abajo se mantuvieron igual en las tres repeticiones.

Las diferencias dependen del control que uses. Frente a Puppeteer stock, Botasaurus cambió navigator.webdriver; la lista de idiomas y la geometría de ventana de tamaño cero coincidieron, mientras que el user-agent solo difirió en el formato de la versión. Frente a Playwright stock, las diferencias observadas también incluyeron la lista de idiomas y la geometría de ventana. Frente a nodriver, el booleano y los idiomas coincidieron, y solo cambió el formato del user-agent en los campos mostrados aquí. Estas son observaciones sobre lo que se declara por defecto, no una puntuación de anti-detección.

Hay dos detalles que lo vuelven más interesante que el simple false. El primero es cómo llega ese valor. En los cuatro stacks, la propiedad sigue siendo el getter nativo del navegador en Navigator.prototype —function get webdriver() { [native code] }— y no una propiedad propia añadida a la instancia ni una función reemplazada. Botasaurus no está reescribiendo la propiedad después de cargar la página; el valor se decide al arrancar el navegador, y la propiedad en sí queda intacta.

El segundo detalle es el que matiza el marketing. En modo headless, el user-agent de Botasaurus sigue anunciando HeadlessChrome/151.0.0.0, idéntico a Puppeteer stock e idéntico a Playwright stock. En modo headed pasa a Chrome/151.0.0.0, de nuevo de forma idéntica. El constructor Driver acepta un parámetro user_agent, así que fijarlo está a un argumento nombrado de distancia, pero nada en la configuración por defecto oculta la cadena de autoidentificación más famosa de la automatización de navegadores.

Casi todo lo demás fue igual en los cuatro stacks, y conviene decirlo sin rodeos porque acota la historia —cada propiedad de abajo dio el mismo valor en Botasaurus, nodriver, Playwright y Puppeteer:

El viejo clásico en el que la Permissions API y Notification.permission se contradicen no apareció en ningún caso: los cuatro devolvieron default y prompt en concordancia. También revisé document y window buscando restos del estilo cdc_ que eran habituales en versiones antiguas de WebDriver: no había ninguno en los cuatro.

Un último dato útil antes de desplegar: pese a sus 122 MB, Botasaurus no incluye ni descarga un navegador. find_chrome_executable() resuelve el Chrome ya instalado en tu máquina —en la mía, /Applications/Google Chrome.app, versión 150.0.7871.187—, y esa es la versión que luego revela el user-agent. Tu flota anuncia el Chrome que tenga instalado, lo cual, para un framework tan opinado, es un valor por defecto sorprendentemente poco opinado.

Llamemos a esto por su nombre y también a lo que no es. Es un registro de lo que revela un stack automatizado cuando nadie le pide que oculte nada: útil si estás del lado defensor, útil si quieres saber qué emite tu propia herramienta. No es una medida de si todo eso importa para un servicio concreto. No lo probé, y ninguna fila de arriba debe leerse como una inferencia de resultado.

Una lectura más indulgente de esta prueba

Declararse es una cosa; devolver el HTML correcto es el trabajo. Ejecuté Botasaurus contra la misma fixture de tres clases de contenido que usa el resto de este repositorio de benchmarks, así que las cifras encajan con las de las demás herramientas medidas aquí. La página contiene tres cosas: A, un enlace estático cuyo marcador es un literal dentro de los bytes servidos; B, un nodo construido por un script inline durante el parseo, con su marcador y su URL ensamblados a partir de fragmentos, de modo que solo ejecutando el JavaScript aparecen; y C, un nodo inyectado 800 ms después del evento load, construido del mismo modo. La clase C es la adversaria: una lectura tomada en el evento load no puede verla.

Botasaurus cae donde caen los pesos pesados. driver.get() seguido directamente de driver.page_html es una captura al momento de carga: renderiza JavaScript correctamente —la clase B lo demuestra, porque B no existe en los bytes servidos—, pero si esperamos 800 ms se pierde la clase C. Añades driver.wait_for_element("#delayed-injected") y obtienes las tres. Fue estable en tres repeticiones y en tres ejecuciones completas del conjunto, sin fallos intermitentes.

Lo interesante aparece cuando recorres el retardo de inyección para ver a partir de qué momento la lectura por defecto de cada stack deja de captar la clase C:

Todos los demás stacks pierden la clase C en cuanto la inyección ocurre 100 ms o más después del load. Botasaurus aún la detecta a 300 ms, y solo abandona a partir de 400. Esto es el framework haciendo de framework, y la causa está a la vista en el constructor: wait_for_complete_page_load=True es el valor por defecto, así que get() devuelve algo significativamente más tarde que un simple evento load. En términos concretos, su lectura por defecto cuesta entre 401 y 431 ms de reloj frente a 119–129 ms para nodriver y 125–171 ms para Puppeteer.

En esta fixture local de inyección diferida, la contrapartida fue de unos 250 ms por navegación a cambio de una captura por defecto más tardía. Eso permitió capturar contenido inyectado hasta 300 ms después del load en estas ejecuciones; no demuestra que Botasaurus sea más correcto en sitios arbitrarios. Si escribes scrapers rápidos sin condiciones de espera explícitas, ese margen puede evitar perder un nodo tardío. A alto volumen de navegación, o si ya esperas una condición precisa, simplemente es sobrecoste.

Dos cifras más para ponerlo en contexto. Arrancar el navegador puso a Botasaurus prácticamente al nivel de nodriver y Puppeteer, y muy por detrás de Playwright:

Y wait_for_element() no añade coste extra hasta un retardo de 300 ms —get() ya había quedado más allá de la inyección—, y luego pasa a unos 1,42 s en retardos de 400–800 ms y a 2,43 s en 1500 ms.

La pregunta de los 122 MB: qué instala realmente un meta-paquete

Aquí está la aritmética, porque es lo más útil que puedo darte. Un pip install botasaurus limpio en un entorno virtual nuevo produjo un árbol de site-packages de 122,3 MB distribuido en 44 paquetes dist-info. Si sacas pip de la cuenta (10,9 MB, que es sobrecarga del entorno virtual y no algo que Botasaurus haya pedido), te quedan unos 111 MB entre framework y dependencias. El driver de navegador —el componente que realiza la automatización real del navegador— ocupa solo unos 4 MB de eso. Es decir, alrededor de 107 MB corresponden a todo lo demás que el meta-paquete decidió que necesitabas.

¿A dónde se va? Las cinco dependencias transitivas más pesadas explican ya la mayor parte (cada fila corresponde a una entrada de install_footprint.heaviest_deps_mb en artifacts/raw/runs/resource_baseline.run1.json; el total es una suma mía, no un campo del archivo):

Que numpy sea el elemento más grande es lo que me hizo alzar una ceja: una librería de álgebra lineal dentro de una herramienta cuya tarea es obtener y analizar páginas web. No es incorrecto, exactamente; los frameworks acumulan dependencias utilitarias, y evidentemente algo en el árbol quiere operar con arrays. Simplemente es mucho músculo para ese encargo.

Para comparar, el driver centrado nodriver pesa unos 17,2 MB repartidos en 6 paquetes en la misma máquina —algo así como 7x menos. (Esa cifra no sale de este paquete: es install_footprint.site_packages_total_mb en artifacts/raw/runs/resource_baseline.run1.json de nodriver, medido en una ejecución separada y escalonada en el mismo host, y 122,3 ÷ 17,2 = 7,1.) Ninguno de los dos números es un defecto, y esto no es una clasificación de capacidades; es la diferencia mecánica entre un framework con todo incluido y un driver enfocado. En un contenedor, la huella medida de site-packages forma parte de la capa de la aplicación. No es el tamaño total de la imagen, y esta prueba no midió tiempo de build ni de despliegue en frío.

Un matiz más sobre la huella: durante la introspección, el primer uso de from botasaurus.request import request desencadenó una descarga puntual de unos 12,8 MB. La ejecución capturada no identificó suficientemente bien el artefacto ni el destino como para tratar esa cifra como un incremento estable de la huella instalada. Sí demuestra que esa ruta de código puede requerir acceso a red en el primer uso, algo que conviene reproducir en tu propia imagen antes de un despliegue aislado.

El número de importación que engaña

El tiempo de importación en frío es donde una lectura superficial de las cifras se equivoca. Medido en siete subprocesos nuevos de importación, import botasaurus en el nivel superior dio una mediana de 0,08 ms. Citar eso en aislamiento hace pensar en el framework más ligero de la categoría.

No lo es. Es rápido porque casi no hay nada ahí. El paquete de nivel superior botasaurus no expone ningún __version__ y tiene un espacio público casi vacío: importarlo apenas hace trabajo porque apenas contiene nada. El número que de verdad importa para una herramienta CLI o un arranque frío en serverless es el import del motor: from botasaurus_driver import Driver ronda los 135 ms, estable a pocos milisegundos de diferencia entre ejecuciones. Ese es el coste fijo real que pagas antes de obtener una sola página. Y una vez importado el módulo del driver, la memoria residente se sitúa en torno a 29–30 MB —de nuevo, antes de que exista cualquier proceso Chrome. Cuando lanzas un navegador real, eso crece bastante; no medí la memoria con uno en ejecución, así que no voy a ponerle cifra.

La lección es pequeña pero clara: que import botasaurus sea instantáneo es una propiedad del paquete superior vacío, no de que el framework sea barato. Si estás dimensionando un cold start, mide el import del que realmente dependes.

Forma de la API: 99 métodos detrás de una puerta casi vacía

La clase Driver del motor expone 99 métodos públicos: una superficie amplia que cubre navegación, consultas de elementos, cookies y almacenamiento local, acciones de ratón y teclado, capturas de pantalla, gestión de pestañas, passthrough de CDP y subida de archivos. El constructor acepta 18 parámetros, que dibujan bastante bien el área configurable: headless, proxy, profile, tiny_profile, block_images, block_images_and_css, wait_for_complete_page_load, chrome_executable_path, extensions, arguments, user_agent, window_size, lang y algunos más. Como API de construcción, cubre los controles habituales de un wrapper de navegador.

El detalle engañoso está arriba del todo, y es benigno pero real. import botasaurus te da un espacio de nombres casi vacío: no hay __version__, prácticamente no hay nombres públicos de nivel superior. Todo lo que realmente usas vive en submódulos: from botasaurus.browser import browser, Driver, from botasaurus.request import request, from botasaurus.task import task. Si buscas botasaurus.__version__ para registrar qué build estás usando, no lo encontrarás; tendrás que acudir a importlib.metadata. Nada de esto rompe nada. Simplemente no es la distribución que la mayoría de desarrolladores de Python espera de forma intuitiva, y saberlo te ahorra cinco minutos de confusión el primer día.

Una observación documental sobre los métodos que señalé antes sí entra dentro de este análisis: de los métodos con nombre asociado a anti-detección que existen, solo 2 incluyen docstring dentro del código. El resto se autodescribe solo por el nombre, y la documentación detallada vive en la web externa del proyecto, no en el código instalado. Eso es un comentario de ubicación, no una crítica de calidad: muchas buenas librerías mantienen su prosa fuera del código; pero si tu flujo de trabajo consiste en "leer el código para entender el método", la mayor parte de esa superficie te dirá su nombre y poco más.

Licencia: MIT, hasta el fondo del driver

Tanto el meta-paquete como botasaurus-driver declaran MIT, con el clasificador estándar License :: OSI Approved :: MIT License. MIT es permisiva: sin obligación de copyleft, sin requisito de abrir tu propio código, con fricción mínima para adopción comercial. Esa es una diferencia real y nada trivial frente a nodriver, el driver anti-detect adyacente, que se publica bajo AGPL-3.0 —una licencia de copyleft cuya cláusula de uso en red pone nerviosos a muchos departamentos legales. Si la licencia es un factor decisivo para ti, la postura MIT de Botasaurus es un punto fuerte de verdad.

La salvedad vuelve a ser la forma de meta-paquete. Esa MIT permisiva aplica a los wheels propios que publica Omkar Cloud. No cubre automáticamente a los cerca de 40 paquetes transitivos que trae la instalación, cada uno con su propia licencia. Confirmé la MIT de nivel superior en los paquetes publicados por Omkar Cloud; no audité la licencia de cada dependencia del árbol. Para un proyecto personal, esa distinción rara vez importa. Para una adopción de todo el árbol dentro de una empresa preocupada por su SBOM, esos 40 paquetes conviene pasarlos por tu propio escáner de licencias antes de comprometerte: no porque encontrara un problema, sino porque no lo revisé, y un meta-paquete es exactamente el lugar donde puede esconderse una licencia inesperada.

Pros y contras

Pros:

• Diseño limpio con tres decoradores (@browser / @request / @task), con las tres entradas confirmadas presentes; hace corto el caso común.
• Licencia MIT tanto para el meta-paquete como para el driver, una diferencia real frente a la AGPL-3.0 de un driver comparable. Permisiva, apta para uso comercial, sin copyleft.
• Superficie amplia del driver: 99 métodos públicos y un constructor con 18 parámetros que cubren las necesidades habituales de automatización de navegador.
• Se instaló y pasó pruebas básicas de importación en Python 3.14.2 y 3.12.13, más allá de su lista de clasificadores (que se queda en 3.11); no se estableció compatibilidad completa en ejecución.
• La ventana de lectura por defecto más indulgente de todos los stacks que medí: sigue capturando contenido inyectado 300 ms después del load, cuando nodriver, Playwright y Puppeteer lo pierden a los 100 ms. wait_for_complete_page_load=True realmente trabaja.
• Reporta navigator.webdriver como false por defecto, donde los controles stock devuelven true, sin parchear la propiedad —el descriptor sigue siendo el getter nativo del navegador.
• Incluye baterías por diseño: caché, paralelismo, reutilización del driver y salida a JSON/CSV/Excel/HTML vienen integrados, no como añadidos.

Contras:

• Pesado en disco: 122,3 MB repartidos en 44 paquetes, unas 7 veces más que un driver centrado, impulsado por dependencias como numpy (30,9 MB) y lxml (19,2 MB) más que por el propio driver de ~4 MB.
• El tranquilizador import de 0,08 ms en el nivel superior es engañoso; el import del motor del que realmente dependes ronda los 135 ms, y la memoria tras importarlo está en 29–30 MB antes de abrir ningún navegador.
• Esa ventana de lectura por defecto más amplia no es gratis: 401–431 ms por navegación y lectura frente a 119–129 ms de un driver ligero en la misma página y con el mismo Chrome.
• En modo headless, el user-agent sigue anunciando HeadlessChrome por defecto, exactamente igual que los controles stock; el parámetro user_agent existe, pero no viene configurado por defecto.
• Para ocupar 122 MB, sigue sin incluir navegador: controla el Chrome ya instalado en el host, así que la versión divulgada es la que tenga tu flota.
• El primer uso de @request desencadenó en esta ejecución una descarga puntual de unos 12,8 MB; el artefacto y su destino no quedaron suficientemente capturados como para considerarlo un incremento estable de la huella.
• El paquete de nivel superior está casi vacío y no expone __version__; la API real y la versión viven en otro sitio menos obvio.
• La mayoría de los métodos con nombre asociado a anti-detección no tienen docstring en el código, así que leer el fuente te dice nombres, no comportamiento.

Fuera de lo que cubren estas cifras, y por tanto sin probar aquí: todo lo relativo a la eficacia anti-bot en el mundo real (fuera de alcance a propósito), memoria por página, manejo de proxy y perfiles, throughput a escala y cualquier plataforma distinta de macOS arm64. Las cifras de huella e importación se obtuvieron sin lanzar ningún navegador; las cifras de recuperación y divulgación provienen de navegadores que solo hablaron con una fixture en 127.0.0.1.

Para quién sirve, y quién debería saltárselo

Botasaurus encaja si quieres un framework, no una pieza suelta. Si empiezas un proyecto de scraping desde un archivo vacío y prefieres adoptar una estructura antes que montarla tú mismo —decoradores para las entradas, caché y paralelismo gestionados, exportación integrada—, esta es una opción coherente y con licencia MIT. MIT es permisiva, pero tu modelo de uso y distribución sigue mereciendo su revisión de cumplimiento habitual. Los equipos que ya piensan en términos de Scrapy o Crawlee encontrarán el enfoque familiar.

Sáltatelo, o al menos piénsalo dos veces, si tu destino de despliegue es sensible al tamaño. Una instalación de 122 MB con numpy y gevent en el árbol es mucho para meter en un contenedor minimalista cuando lo único que necesitas es "conducir un navegador y extraer algunos campos". Un driver centrado te da la automatización a una fracción del peso, a cambio de escribir tú mismo la infraestructura alrededor. Y sáltatelo por completo si lo que buscas es una decisión sobre eficacia anti-detección, porque eso es precisamente lo que yo decidí no probar; estarías confiando en una promesa de marketing que ni confirmé ni refuté.

Alternativas y dónde encaja Thunderbit

Primero, el encuadre honesto: Botasaurus es gratis, con licencia MIT y autoalojado. Tú operas la infraestructura, gestionas las actualizaciones y eres dueño de todo el árbol de dependencias —los 44 paquetes—, incluidos parches, cumplimiento de licencias y lo que decida hacer numpy en una futura versión. Para muchos equipos, esa propiedad es exactamente lo que quieren, y ningún servicio gestionado supera a "un framework que ya tienes" en coste bruto.

Dentro del open source, las comparaciones útiles se hacen por forma. Si estás en el extremo de framework con Botasaurus, Scrapy y Crawlee son los pares obvios con los que comparar: maduros, con opinión propia y con sus propias convenciones. Si quieres Markdown listo para LLM a partir de una página en lugar de un framework para estructurar un crawler, Crawl4AI y el orientado a contenido Trafilatura apuntan justo a ese trabajo. Si te gusta el ángulo Python + anti-detect pero quieres algo más ligero que un meta-paquete, Scrapling merece una mirada; y si el lenguaje compilado entra en la conversación, la librería Go Colly intercambia renderizado de JavaScript por velocidad y una huella mínima. Cualquier opción que conduzca un navegador, incluido Botasaurus, hereda el perfil de coste que describe nuestra comparación Playwright vs Puppeteer: los navegadores reales no son baratos de ejecutar, y por eso el framework que los rodea pesa lo que pesa.

Cuando entra una API gestionada, ya estás en otro punto de la misma tubería. Botasaurus es la pila para desarrolladores autoalojada; Thunderbit vende la gestionada, orientada también a desarrolladores. La Open API son dos endpoints. POST /distill (1 crédito) devuelve una página como Markdown limpio, listo para LLM, con renderizado y anti-bot resueltos del lado del servidor, así que no tienes que aprovisionar ni navegador ni árbol de dependencias. POST /extract (20 créditos) devuelve JSON estructurado a partir de un esquema JSON que tú defines, con renderMode en none, basic o full según cuánto navegador necesite realmente la página. Ambos tienen versiones batch para hasta cien URLs a la vez. Hay un servidor MCP para agentes y asistentes de programación —thunderbit_suggest_fields es gratis y te dice qué expone una página antes de gastar nada— y una CLI con npx @thunderbit/thunderbit-cli para cron y CI. Para quienes no son desarrolladores y prefieren no tocar nada de eso, la extensión de Chrome usa el mismo motor como herramienta sin código, y los tutoriales del canal de YouTube de Thunderbit cubren los flujos de trabajo más comunes.

La diferencia está en dónde vive el trabajo, no en qué herramienta es "mejor". Botasaurus deja el framework, la flota de navegadores, las dependencias, la infraestructura y el mantenimiento de tu lado de la línea, sin una tarifa por solicitud al proveedor; el cómputo, el ancho de banda, los proxies y la operación siguen costando dinero. Una API gestionada te quita de encima el renderizado y la salida estructurada, y cobra por llamada; puedes comparar eso con una instalación autoalojada en la página de precios.

Prueba Thunderbit para extracción de datos web

Veredicto

Botasaurus es un candidato razonable si quieres un framework Python todo en uno y aceptas su huella de dependencias. El diseño con tres decoradores es limpio, la superficie del driver es amplia y pasó pruebas básicas de instalación e importación en versiones de Python más nuevas de las que sus clasificadores declaran. En mi fixture local, su captura por defecto también detectó contenido inyectado 300 ms después del load, donde los otros stacks probados lo perdieron a los 100 ms; eso es un resultado de fixture, no una clasificación general.

Pero hay que dimensionar bien las afirmaciones. Es una instalación de 122 MB y 44 paquetes, donde el driver ocupa unos 4 MB y el resto es numpy, lxml, gevent y compañía —unas 7x más que un driver centrado, y ese peso se te va al docker build y al despliegue en frío. El import de nivel superior de 0,08 ms es una puerta vacía, no un framework ligero; el import del motor de unos 135 ms es la cifra que realmente pagas. Esa lectura por defecto tan indulgente cuesta unos 250 ms extra en cada navegación. Y sobre la pregunta de divulgación por defecto que sí pude responder, la imagen es más estrecha que lo que sugiere el marketing: un booleano difiere respecto a Puppeteer stock, el user-agent en headless sigue diciendo HeadlessChrome, y el resto de propiedades que medí fueron idénticas en los cuatro stacks. La promesa anti-detección que vende la herramienta es precisamente lo que esta reseña no califica: confirmé que esos métodos existen, hice correr el driver contra una página en mi propia máquina y me detuve ahí, a propósito. Conoce la huella, ignora el número de importación halagador y trata el marketing de stealth como una cuestión abierta, y Botasaurus es un framework honesto que hace exactamente lo que un framework debe hacer. Espera un driver ultraligero y te sorprenderá el tiempo de docker build.

Prueba Thunderbit para extracción de datos web Get Started Free

Preguntas frecuentes

¿Botasaurus es gratis y bajo qué licencia está? Es gratis y tiene licencia MIT: tanto el meta-paquete botasaurus como el motor botasaurus-driver llevan el clasificador MIT aprobado por la OSI. MIT es permisiva, así que no hay obligación de copyleft y es amigable para uso comercial, una diferencia importante frente a drivers anti-detect comparables que se publican bajo AGPL-3.0. Un matiz: MIT cubre los paquetes propios de Omkar Cloud, pero no garantiza automáticamente las licencias de las aproximadamente 40 dependencias transitivas que arrastra la instalación; por tanto, conviene ejecutar tu propio escaneo de licencias antes de una adopción corporativa de todo el árbol.

¿Cuánto ocupa una instalación de Botasaurus y por qué import botasaurus parece instantáneo? Un pip install botasaurus limpio produjo en mi máquina un árbol site-packages de 122,3 MB repartido en 44 paquetes. El propio driver de navegador ocupa solo unos 4 MB: el peso viene de que el meta-paquete arrastra un árbol de dependencias amplio, encabezado por numpy (30,9 MB), lxml (19,2 MB), botasaurus_requests (12,6 MB), gevent (11,3 MB) y pygments (8,4 MB). Es aproximadamente 7 veces la huella de un driver centrado como nodriver en la misma máquina. Nada de eso es un defecto; es el precio de "todo incluido" y lo que más afecta es el tamaño de la imagen del contenedor. El tiempo de importación es donde se esconde esa huella: import botasaurus mide unos 0,08 ms, pero solo porque el paquete de nivel superior está casi vacío —sin __version__ y con casi ningún nombre público—, de modo que importar hace casi nada. El import que sí cuesta es el del motor, from botasaurus_driver import Driver, con unos 135 ms, y después de ese import la memoria residente ronda los 29–30 MB antes de arrancar ningún navegador. ¿Estás dimensionando un cold start de serverless? Mide el import del motor, no el del nivel superior vacío.

¿Qué expone Botasaurus sobre sí mismo y se probó contra sistemas anti-bot reales? La primera mitad se midió; la segunda se decidió no medirla. En una página que serví desde 127.0.0.1, usando la misma versión de Chrome que los controles: navigator.webdriver devuelve false, mientras que Playwright stock y Puppeteer stock devuelven true. Ese valor se fija al arrancar el navegador, no parcheando la propiedad: el descriptor sigue siendo el getter nativo de Chrome. Más allá de ese booleano, casi todo coincidió exactamente con los controles: misma cadena de plataforma, cinco plugins, doce núcleos, 16 GB de memoria de dispositivo reportada, la misma forma de window.chrome, sin contradicción en la Permissions API y sin restos del tipo cdc_ en document o window. En modo headless, el user-agent sigue anunciando HeadlessChrome/151.0.0.0, igual que en ambos controles; el constructor Driver acepta un parámetro user_agent, pero no lo configura por ti. En cuanto a la eficacia: nunca apunté el driver a un sitio real, nunca contacté un servicio anti-bot y nunca toqué un CAPTCHA. El driver sí incluye un conjunto de métodos con nombre asociado a anti-detección, cuya existencia confirmé, pero no los llamé, no probé su comportamiento contra ningún objetivo, no medí tasa de éxito ni describí mecanismo alguno. La tabla de divulgación de arriba te dice qué anuncia el stack, y nada sobre quién lo escucha ni qué hace con ello.

¿Botasaurus maneja correctamente contenido renderizado por JavaScript? Sí, y su comportamiento por defecto es más indulgente que el de la mayoría. En una fixture con tres clases de contenido, driver.get() + driver.page_html devolvió 2 de 3 con un retardo de inyección de 800 ms: ejecuta JavaScript correctamente, pero lee antes de que llegue el contenido muy tardío. driver.wait_for_element() devolvió 3 de 3. La diferencia distintiva está en dónde abandona la lectura por defecto: Botasaurus sigue capturando contenido inyectado 300 ms después del load, mientras que nodriver, Playwright y Puppeteer lo pierden a los 100 ms. Eso se debe a wait_for_complete_page_load=True en el constructor, y cuesta unos 250 ms por navegación.

¿Cómo importo y uso Botasaurus después de instalarlo? No como probablemente imaginas. El espacio de nombres de nivel superior botasaurus está casi vacío, así que la API real vive en submódulos: from botasaurus.browser import browser, Driver, from botasaurus.request import request y from botasaurus.task import task. Decoras una función normal con @browser, @request o @task y el framework se encarga del driver, la caché y la salida. Como no existe botasaurus.__version__, usa importlib.metadata si necesitas registrar qué build estás ejecutando.