Playwright vs Selenium vs Scrapy: cuál usar para tu scraper en 2026

Si estás eligiendo herramienta de scraping en 2026, la respuesta rápida: Scrapy para volúmenes grandes en HTML estático, Playwright para todo lo demás. Selenium ya casi no tiene casos de uso justificables.

Pero como siempre, los detalles importan. En este artículo comparamos las tres herramientas en velocidad, complejidad, mantenimiento y casos donde una gana clara sobre las otras. Datos basados en nuestros 47 pipelines en producción durante los últimos 5 años.

Resumen ejecutivo

Scrapy: el rey de volumen en HTML estático

Scrapy es un framework completo en Python pensado desde el día 1 para scraping a escala. Es asíncrono nativamente (sobre Twisted), tiene scheduler, pipelines de procesamiento, manejo de cookies y mucho más.

Cuándo elegir Scrapy:

• Necesitas procesar 100,000+ páginas/día
• El sitio devuelve HTML completo (renderiza server-side)
• Tienes equipo Python con experiencia
• Quieres seguir un patrón de framework establecido
• Necesitas pipelines de procesamiento estructurados

Cuándo Scrapy es mala idea:

• El sitio carga datos vía JavaScript después del HTML inicial
• El proyecto es one-off de menos de 1,000 páginas
• Tu equipo no conoce el paradigma de spiders/items/pipelines
• Necesitas interactuar (login con formulario complejo, clicks, scroll)

Pros: velocidad imbatible. En benchmarks típicos, Scrapy procesa 100-500 páginas/segundo en una sola máquina vs 3-10 páginas/segundo de Playwright. Para scraping de directorios, e-commerce con API expuesta o sitios noticieros, no hay competencia.

Cons: curva de aprendizaje más empinada. El paradigma de spiders no es intuitivo si vienes de scripts simples. Para JavaScript necesitas plugin externo (Splash o Scrapy-Playwright) que duplica la complejidad.

Playwright: el navegador para todo lo moderno

Playwright es la herramienta de automatización de navegadores que Microsoft lanzó como sucesor espiritual de Puppeteer. Soporta Chromium, Firefox y WebKit con la misma API. En Python tiene la mejor experiencia developer del mercado.

Cuándo elegir Playwright:

• El sitio usa JavaScript pesado (React, Vue, Angular, SPA)
• Necesitas interactuar: clicks, scroll, formularios complejos, login
• El sitio tiene sistemas anti-bot que detectan requests puros
• Quieres una API moderna y bien documentada
• Necesitas screenshots o PDFs como parte del flujo
• Tu equipo prefiere síntaxis async/await moderna

Cuándo Playwright es overkill:

• El sitio devuelve HTML completo en el primer request (un simple httpx + BeautifulSoup es 50x más rápido)
• El sitio tiene una API REST documentada (úsala directo)
• Volúmenes muy altos donde 5 segundos/página no es aceptable

Pros:

• Auto-waiting inteligente: no necesitas time.sleep(2) en cada paso
• Selectores potentes: CSS, XPath, texto visible, role ARIA
• Network interception: puedes ver y modificar requests del navegador
• Mejor manejo de iframes y popups
• Configuración stealth nativa para anti-detection
• Documentación excelente y comunidad activa

Cons: es un navegador real, consume memoria (200-400 MB por instancia). Para volúmenes altos hay que paralelizar con cuidado.

Selenium: legacy maduro pero superado

Selenium fue el estándar durante 15 años. Sigue siendo válido pero raramente es la mejor opción en 2026.

Únicos casos donde Selenium gana:

• Tu equipo ya tiene 5+ años de código Selenium y migrar es caro
• Necesitas soportar navegadores muy específicos o muy viejos
• Estás trabajando con QA testing donde la mayoría de frameworks asume Selenium

Por qué Playwright lo destruye en casi todo:

• Selenium requiere drivers separados (ChromeDriver, GeckoDriver). Playwright gestiona internamente.
• Selenium no tiene auto-wait. Necesitas WebDriverWait explícito en cada paso.
• Selenium tiene problemas conocidos con shadow DOM, iframes y elementos asíncronos.
• La API de Selenium se siente vieja (Selenium 4 mejoró, pero el código existente arrastra patrones de Selenium 2).
• Anti-detection es mucho más débil; los sitios detectan Selenium con más facilidad.

Alternativas que vale la pena conocer

httpx + BeautifulSoup (o lxml)

Para sitios HTML estáticos pequeños o medianos, la combinación httpx (cliente HTTP moderno con async) + BeautifulSoup o lxml sigue siendo imbatible en simplicidad y velocidad. No es un framework, son librerías. Para un proyecto de menos de 5,000 páginas/día contra HTML estático, es la elección correcta.

Camoufox + Playwright

Para sitios con sistemas anti-bot modernos (Cloudflare Bot Management, DataDome, PerimeterX), Playwright solo no alcanza. Camoufox es un fork de Firefox con fingerprinting realista que combinado con Playwright pasa la mayoría de las detecciones. Es la herramienta de elección para sitios donde el HTML cambia según si te detectan o no.

Scrapy + Playwright

Para casos híbridos donde necesitas la velocidad de Scrapy y la capacidad JavaScript de Playwright, existe el plugin scrapy-playwright. Funciona pero la curva de aprendizaje es la suma de ambos frameworks.

API directa cuando existe

Antes de elegir herramienta, abre DevTools del navegador → tab Network y revisa qué endpoints llama el frontend. Si el sitio carga datos vía API REST (90% de los SPAs modernos lo hacen), llamar a la API directamente es 50-100x más rápido que cualquier scraper. Esto NO es scraping; es consumir una API expuesta. Y es lo que recomendamos siempre que es viable.

Decisión por tipo de proyecto

Scraping de directorio de empresas (HTML estático): Scrapy o httpx + BeautifulSoup.

Scraping de e-commerce moderno (React/Vue): Playwright en modo headless con paralelización.

Scraping de marketplace con sistemas anti-bot: Playwright + Camoufox + IPs residenciales rotativas.

Scraping de redes sociales (perfiles públicos): Playwright con cuenta autenticada, manejo cuidadoso de rate limits.

Scraping de portales gubernamentales (gacetas, BOE): Scrapy. Son HTML clásico, alto volumen, sin protección.

Monitoreo de precios en tiempo real: Si el sitio tiene API, consumirla. Si no, Playwright con scheduler y diff inteligente.

Extracción de datos detrás de login complejo: Playwright con storage state persistente (guardas la sesión y la reutilizas).

Lo que en realidad importa para producción

La herramienta es solo el 15% del éxito de un scraper de producción. El otro 85% es arquitectura:

• Selectores defensivos con fallbacks (ver nuestro artículo sobre errores en scraping producción)
• Monitoreo de calidad de datos, no solo errores técnicos
• Rate limiting respetando al sitio objetivo
• Manejo de fallos con reintentos exponenciales
• Normalización inmediata después de extracción
• Storage con índices y deduplicación
• Plan de respuesta cuando el sitio cambia

Un scraper bien arquitectado con Selenium funciona mejor que uno mal arquitectado con Playwright. Pero un scraper bien arquitectado con Playwright es lo ideal hoy.

Quieres construir o que te lo construyamos

Si tu equipo tiene experiencia en Python y volumen suficiente para justificar el aprendizaje, construir internamente con Playwright es razonable. Para proyectos one-off, casos complejos con anti-bot o cuando los datos son críticos para tu negocio, contratar el pipeline tiene mejor ROI.

En DevActivo construimos pipelines de extracción de datos en producción con la herramienta correcta según el caso. Scrapy para volumen, Playwright para complejidad, APIs directas cuando existen. Cotización con plan técnico detallado en 48 horas.

Servicios relacionados:

• Web Scraping y Extracción de Datos
• Automatización n8n con IA
• Generación de Leads B2B con datos enriquecidos