BeautifulSoup vs Scrapy vs Playwright no es una pelea entre tres opciones para el mismo problema. BeautifulSoup lee HTML, Scrapy recorre sitios enteros y Playwright maneja un navegador real. Si la página es estática y son pocas URLs, usá requests + BeautifulSoup. Si son miles de páginas, Scrapy. Si el contenido aparece recién cuando carga el JavaScript, Playwright. Y muchas veces la respuesta es combinarlas.
El problema: elegir mal te cuesta semanas
Alguien busca "web scraping python", encuentra un tutorial de BeautifulSoup y arranca. Funciona. Tres semanas después tiene que scrapear 20.000 páginas, el script tarda 9 horas y se corta a la mitad. Reescribe todo.
O al revés: alguien arranca con Playwright porque "sirve para todo", abre un navegador por cada URL y para monitorear 500 productos necesita una máquina que cuesta más que el dato que busca.
Las tres herramientas aparecen juntas en cada comparativa, pero resuelven capas distintas del mismo trabajo. Entender eso ahorra más tiempo que cualquier benchmark.
Qué es cada una (y por qué no compiten entre sí)
Un scraper hace tres cosas: pide una página, lee el HTML y guarda los datos. Cada herramienta cubre una parte diferente.
BeautifulSoup: el parser
BeautifulSoup no descarga nada. Recibe un HTML y te deja buscar adentro: "dame todos los
h3titlerequests- Se aprende en una tarde.
- Perfecta para scripts chicos y páginas estáticas (el HTML ya trae los datos).
- Es sincrónica: pide una página, espera, pide la siguiente. Con cientos de URLs se nota.
- No soporta XPath (solo CSS selectors y sus propios métodos
yfind
).find_all
Scrapy: el framework
Scrapy es un proyecto completo: hace las peticiones, sigue links, parsea con su propio motor (
parselrobots.txt- Pensado para rastrear sitios enteros, no una página suelta.
- Tiene pipelines, middlewares y throttling automático incorporados.
- La curva de aprendizaje es más alta: hay que entender su estructura de proyecto y sus callbacks.
- Tampoco ejecuta JavaScript por sí solo.
Playwright: el navegador
Playwright abre un Chromium, Firefox o WebKit real, carga la página como lo haría un usuario y te deja interactuar: hacer click, scrollear, esperar que aparezca un elemento. Lo mantiene Microsoft y nació para testing, pero se volvió el estándar para scrapear sitios que cargan el contenido con JavaScript.
- Si los datos aparecen recién después de que corre el JS, es la única de las tres que los ve.
- Puede interceptar las llamadas a la API interna del sitio, que muchas veces es la forma más limpia de obtener los datos.
- Es la más pesada: cada navegador consume CPU y memoria. Scrapear 10.000 páginas con Playwright es un problema de infraestructura, no de código.
El mismo scraper hecho tres veces
Usamos books.toscrape.com, un sitio creado para practicar scraping. Objetivo: título y precio de los libros de la primera página.
Con requests + BeautifulSoup
import requests from bs4 import BeautifulSoup url = "https://books.toscrape.com/" html = requests.get(url, timeout=10).content soup = BeautifulSoup(html, "html.parser") for libro in soup.select("article.product_pod"): titulo = libro.h3.a["title"] precio = libro.select_one("p.price_color").text print(titulo, precio)
Once líneas. Si solo necesitás esta página una vez por semana, acá terminó el proyecto.
Con Scrapy
import scrapy class LibrosSpider(scrapy.Spider): name = "libros" start_urls = ["https://books.toscrape.com/"] def parse(self, response): for libro in response.css("article.product_pod"): yield { "titulo": libro.css("h3 a::attr(title)").get(), "precio": libro.css("p.price_color::text").get(), } siguiente = response.css("li.next a::attr(href)").get() if siguiente: yield response.follow(siguiente, self.parse)
Se corre con
scrapy runspider libros.py -o libros.csvCon Playwright
from playwright.sync_api import sync_playwright with sync_playwright() as p: browser = p.chromium.launch() page = browser.new_page() page.goto("https://books.toscrape.com/") page.wait_for_selector("article.product_pod") for libro in page.query_selector_all("article.product_pod"): titulo = libro.query_selector("h3 a").get_attribute("title") precio = libro.query_selector("p.price_color").inner_text() print(titulo, precio) browser.close()
Para este sitio es matar una mosca con un cañón: el HTML ya viene con los datos. Pero cambiá la URL por una tienda que carga precios con React y los otros dos scripts devuelven una lista vacía. Este sigue funcionando.
BeautifulSoup vs Scrapy vs Playwright: tabla comparativa
| BeautifulSoup (+ requests) | Scrapy | Playwright | |
|---|---|---|---|
| Qué es | Parser de HTML | Framework de crawling | Automatización de navegador |
| Ejecuta JavaScript | No | No | Sí |
| Velocidad en muchas páginas | Baja (sincrónica) | Alta (asíncrona) | Baja (un navegador por página) |
| Curva de aprendizaje | Una tarde | Unos días | Un par de días, más tiempo en infraestructura |
| Consumo de recursos | Mínimo | Bajo | Alto |
| Selectores | CSS, | CSS y XPath | CSS, XPath, texto, roles |
| Reintentos, throttling, pipelines | Los programás vos | Incluidos | Los programás vos |
| Ideal para | Scripts puntuales, aprender, páginas estáticas | Catálogos, sitios enteros, crawls recurrentes | SPAs, scroll infinito, logins propios, contenido dinámico |
| Mantenimiento cuando cambia el sitio | Bajo | Medio | Alto |
Las 3 preguntas para decidir
**1. ¿Los datos están en el HTML o aparecen después?**Abrí la página, click derecho, "Ver código fuente". Si encontrás el precio ahí, es estática: BeautifulSoup o Scrapy alcanzan. Si no está, se carga con JavaScript: Playwright, o mejor todavía, buscá en la pestaña Network la API interna que trae ese dato en JSON.
**2. ¿Cuántas páginas y con qué frecuencia?**Menos de 100 páginas y de vez en cuando: BeautifulSoup. Miles de páginas, varias veces por semana, siguiendo links: Scrapy. Scrapy fue hecho para eso y te va a ahorrar escribir colas, reintentos y paralelismo.
**3. ¿Hay que interactuar con la página?**Scroll infinito, botones "cargar más", filtros que cambian la URL sin recargar: Playwright. Si no hay interacción, no pagues el costo de un navegador.
La combinación que más usamos en producción: Scrapy como motor del crawl y Playwright solo para las páginas que lo necesitan (existe
scrapy-playwrightErrores comunes al elegir
- Empezar con Playwright "por las dudas". Diez veces más lento y más caro, y en la mayoría de los sitios no hace falta.
- Hacer un crawl de 50.000 URLs con un
y requests. Sin paralelismo ni reintentos, se corta en la URL 3.000 y perdés todo.for - Ignorar la API interna del sitio. Muchos sitios dinámicos cargan los datos desde un endpoint JSON. Una petición a esa URL reemplaza al navegador entero.
- Creer que la herramienta evita los bloqueos. Ninguna de las tres lo hace sola. Los bloqueos se manejan con ritmo de peticiones, proxies y headers coherentes, y eso es otro artículo.
- No mirar
ni los términos del sitio. La herramienta no te protege legalmente. Si hay datos personales, aplica GDPR o la ley local, elijas lo que elijas.robots.txt
Recurso: el cheat sheet del stack de scraping
Armamos un PDF de una página con las herramientas que usamos en 2026 (parsers, frameworks, navegadores, proxies y APIs), qué cuesta cada una y cuándo conviene. Comentá STACK en el reel o el carrusel de esta nota y te lo mandamos por mensaje.
¿Y a escala?
Elegir bien la librería resuelve el primer scraper. Lo que nadie cuenta es el segundo mes: el sitio cambia el HTML, aparece un captcha, el crawl de 200.000 productos necesita proxies rotativos y alguien tiene que mirar los logs un domingo.
En AUTOScraping ese "segundo mes" es nuestro trabajo diario. Con DataFactory no te entregamos un scraper: te entregamos los datos, limpios y a la frecuencia que necesites, en CSV, base de datos o API. El stack, los bloqueos y el mantenimiento quedan de nuestro lado. Somos Bright Data Solution Partner y operamos dentro del marco legal (robots.txt, términos de uso, GDPR y CCPA).
Si tu equipo ya tiene el script andando con 100 URLs y la pregunta es qué pasa con un millón, esa conversación es la que más nos gusta tener.
Preguntas frecuentes
¿Scrapy puede reemplazar a BeautifulSoup? Sí para el parsing: Scrapy trae su propio motor con CSS y XPath. Pero si solo necesitás leer un HTML que ya tenés, BeautifulSoup es más simple y no requiere armar un proyecto.
¿Playwright es mejor que Selenium? Para scraping nuevo, en general sí: API más moderna, esperas automáticas, intercepción de red y menos fallos intermitentes. Selenium sigue siendo válido si ya lo tenés en producción.
¿Puedo usar BeautifulSoup para páginas con JavaScript? Solo si antes obtenés el HTML renderizado con Playwright (o encontrás la API interna). BeautifulSoup no ejecuta JavaScript.
¿Cuál es la más rápida? Scrapy, por ser asíncrona y liviana. Playwright es la más lenta porque renderiza la página completa, incluidos CSS e imágenes, salvo que los bloquees.
¿Cuál conviene para aprender web scraping? requests + BeautifulSoup. Entendés el flujo completo en un script de diez líneas. Después, Scrapy y Playwright se aprenden sobre esa base.
