Playwright: automatización de navegador confiable para scraping y agentes

Tarde o temprano, un agente que necesita datos web en vivo se topa con una página que un «fetch» HTTP simple no puede leer: el markup llega casi vacío y JavaScript pinta el contenido después de cargar. El instinto es recurrir a un navegador headless, y es la decisión correcta; pero ese mismo navegador que resuelve el problema de renderizado va a filtrar memoria sin avisar y, en un solo VPS, terminar tumbando el host con él. Playwright es la base confiable para manejar un navegador real desde TypeScript; lo que sigue es cuándo usarlo, cuándo evitarlo a propósito, y cómo manejarlo con un pool y ponerle límites para que un scraper corra días en lugar de caerse al mediodía.

01 · Qué es en realidad

Playwright es una librería de automatización de navegador que controla Chromium, Firefox y WebKit desde una sola API, en TypeScript o Python. Maneja un motor de navegador real, así que ve la página tal como la vería una persona: después de que corre JavaScript, después de que cargan las fuentes, después de que aparece el contenido lazy.

La característica que lo define es la auto-espera. Un locator no toma una foto del DOM y cruza los dedos; reintenta hasta que el elemento objetivo está adjunto, visible, estable y listo para usarse, y solo entonces ejecuta la acción. Ese único comportamiento elimina la mayoría de las fallas intermitentes de «elemento no encontrado» y de "le hice clic antes de tiempo" que vuelven un suplicio mantener un scraper hecho a mano.

import { chromium } from "playwright"

const browser = await chromium.launch()
const page = await browser.newPage()
await page.goto("https://example.com")

// Auto-espera hasta que <main> exista y esté renderizado: sin sleep manual.
const text = await page.locator("main").innerText()

await browser.close()

02 · Por qué se gana un lugar en el stack

Dos cosas hacen que Playwright valga su peso para scraping y para herramientas que maneja un agente.

La primera es que lee páginas que ninguna otra cosa puede. Single-page apps, scrolls infinitos, contenido detrás de un render del lado del cliente: un «fetch» crudo devuelve un cascarón, pero Playwright devuelve el resultado ya pintado. Si tu objetivo entrega sus datos vía JavaScript, el navegador no es opcional.

La segunda importa especialmente para los agentes: el snapshot del árbol de accesibilidad. En lugar de pasarle al modelo decenas de miles de tokens de HTML anidado y lleno de anuncios, Playwright puede producir un snapshot estructurado del árbol de accesibilidad de la página, roles, nombres y los elementos interactivos que importan, que es una superficie mucho más limpia, barata y estable para que el modelo razone y actúe.

• Es más pequeño, así que cuesta menos tokens y cabe más página en el contexto.
• Es semántico, así que el modelo apunta al "botón Buscar", no a una ruta CSS frágil.
• Es estable, así que un rediseño cosmético que reordena las clases de los «div» no rompe al agente.

03 · Inicio rápido: instalar y una extracción real

Instala el paquete y después instala los binarios del navegador: son una descarga aparte, y olvidar el segundo paso es el error más común en la primera corrida.

npm install playwright
npx playwright install chromium

Aquí va una extracción pequeña pero realista: abrir una página de listado, esperar a que se rendericen los ítems, y sacar los datos estructurados en una sola pasada de «evaluate» en lugar de ir y volver por cada campo.

import { chromium } from "playwright"

const browser = await chromium.launch()
try {
  const page = await browser.newPage()
  await page.goto("https://news.ycombinator.com", { waitUntil: "domcontentloaded" })
  await page.locator(".athing").first().waitFor()

  const items = await page.locator(".athing").evaluateAll((rows) =>
    rows.map((row) => ({
      title: row.querySelector(".titleline a")?.textContent ?? "",
      href: row.querySelector(".titleline a")?.getAttribute("href") ?? "",
    })),
  )

  console.log(items.length, "ítems")
} finally {
  await browser.close()
}

04 · Iniciar sesión y actuar como usuario

Los casos donde un navegador es realmente obligatorio suelen ser los que tienen login, muro de cookies o un flujo de varios pasos. Playwright los maneja bien, y puede conservar el estado autenticado para que no tengas que iniciar sesión en cada corrida.

El patrón: inicias sesión una vez, guardas el storage state (cookies más local storage) en un archivo y luego cargas ese estado en contexts nuevos. Un context de navegador es una sesión aislada, con sus propias cookies y cache, y es barato comparado con lanzar un navegador entero, así que un solo proceso de navegador puede alojar muchos contexts.

// Una sola vez: captura una sesión autenticada.
const context = await browser.newContext()
const page = await context.newPage()
await page.goto("https://app.example.com/login")
await page.getByLabel("Email").fill(process.env.SCRAPE_USER)
await page.getByLabel("Password").fill(process.env.SCRAPE_PASS)
await page.getByRole("button", { name: "Sign in" }).click()
await page.waitForURL("**/dashboard")
await context.storageState({ path: ".auth/state.json" })

// Corridas posteriores: reutiliza la sesión guardada, sin re-login.
const authed = await browser.newContext({ storageState: ".auth/state.json" })

05 · El detalle que tumba hosts

Los navegadores headless son pesados y propensos a filtrar memoria. Cada uno es un proceso de navegador completo con su propia memoria; cada página y context que abres pero no cierras retiene RAM hasta que el proceso muere. La falla clásica es un scraper que lanza un navegador por URL, nunca cierra sus páginas y corre sin límite: en un solo VPS la memoria sube sin parar hasta que el OOM killer lo mata (o peor, mata otra cosa).

Cuatro hábitos lo mantienen sano:

1. Reutiliza un solo navegador. Lanzar un navegador es caro; abrir un context es barato. Lanza una vez, crea un context por trabajo y cierra el context, no el navegador, cuando el trabajo termina.
2. Cierra siempre en el «finally». Páginas, contexts y el navegador tienen que cerrarse incluso cuando un paso lanza error, o una sola falla te filtra la sesión entera. Envuelve el trabajo en try/finally.
3. Limita la concurrencia. No corras cincuenta páginas a la vez solo porque la lista tenga cincuenta filas. Elige un tamaño de pool pequeño que tu RAM aguante y pon el resto en cola.
4. Pon timeouts en todos lados. Un «goto» colgado en una página muerta te deja un slot bloqueado para siempre. Pon límites a la navegación y a las acciones para que un trabajo trabado falle rápido y libere su slot.

import { chromium, type Browser } from "playwright"

const POOL_SIZE = 3
let browser: Browser | undefined

async function scrape(url: string) {
  browser ??= await chromium.launch()
  const context = await browser.newContext()
  try {
    const page = await context.newPage()
    page.setDefaultTimeout(15_000) // falla rápido, no bloquees un slot
    await page.goto(url, { timeout: 20_000 })
    return await page.locator("main").innerText()
  } finally {
    await context.close() // reutiliza el navegador, libera el context
  }
}

// Concurrencia acotada: nunca más de POOL_SIZE contexts a la vez.
async function run(urls: string[]) {
  const queue = [...urls]
  const workers = Array.from({ length: POOL_SIZE }, async () => {
    let url: string | undefined
    while ((url = queue.shift())) await scrape(url)
  })
  await Promise.all(workers)
  await browser?.close()
}

Para un servicio de larga duración, bloquea además los recursos que no necesitas, imágenes, fuentes, media, analytics, con interceptación de requests. En la mayoría de los objetivos de scraping eso recorta el ancho de banda y la memoria de golpe sin perder ni un dato de los que viniste a buscar.

06 · Cuándo usarlo frente a las alternativas

Playwright es el peso pesado, y la disciplina está en no recurrir a él cuando algo más liviano hace el trabajo.

Usa Playwright cuando

• El contenido lo renderiza JavaScript: un «fetch» crudo devuelve un cascarón vacío.
• Necesitas actuar como usuario: iniciar sesión, recorrer un flujo a clics, llenar un formulario, cerrar un modal, hacer scroll para cargar más.
• Estás construyendo una herramienta de navegación que maneja un agente y quieres el snapshot del árbol de accesibilidad como la vista del modelo.

Usa algo más liviano cuando

• La página es HTML estático o tiene una API. Un «fetch» más un parser (o pegarle al endpoint JSON que la propia página llama) es un orden de magnitud más barato. Abre primero la pestaña de red: muchas veces el dato está a un solo request limpio de distancia.
• Solo necesitas un sitemap, un feed o un archivo. No arranques un motor de navegador para leer XML.
• Estás a escala masiva y el costo de un navegador por página es prohibitivo; ahí un enfoque híbrido, fetch barato por defecto, navegador solo para las páginas que lo necesitan, casi siempre gana.

Playwright frente a Puppeteer / Selenium

Puppeteer está enfocado en Chromium y es excelente, pero el soporte multinavegador de Playwright, su auto-espera de primera clase y su API de locators lo vuelven la mejor opción por defecto para trabajo nuevo. Selenium es el veterano maduro y políglota, pero su modelo de espera es más viejo y más propenso a fallas intermitentes de fábrica. Para un scraper o una herramienta de agente nuevos en TypeScript, Playwright es donde empiezo.

07 · Las concesiones honestas

• Es pesado. Un navegador son cientos de megabytes de binario y bastante RAM por instancia. Si mides scrapers en miles de páginas por minuto, el costo por página es real y vas a tener que diseñar la arquitectura en torno a eso.
• Necesita cuidado para mantenerse estable. La auto-espera te salva en el camino feliz, pero la disciplina de memoria, cerrar, usar pools, poner límites y timeouts, corre por tu cuenta. Un script ingenuo funciona en un demo y se cae en producción.
• Los sitios cambian y se defienden. Los selectores quedan obsoletos con los rediseños (el snapshot del árbol de accesibilidad ayuda), y algunos objetivos detectan y bloquean la automatización de forma activa. Esa es una carrera armamentista en la que quizá no quieras meterte.
• El modo headless se puede detectar y difiere sutilmente de un navegador real. Cuando un sitio se comporta distinto bajo automatización, correr en modo no-headless o con un context persistente a veces cierra la brecha; pero toma eso como una señal para revisar si deberías estar haciendo scraping de ese sitio.

Playwright es la base correcta para la automatización de navegador en un stack de TypeScript, y solo su auto-espera ya justifica adoptarlo: elimina la mayor fuente individual de intermitencia en los scrapers. Todo el juego está en usarlo a propósito: lanza un solo navegador, maneja los contexts con un pool, cierra todo en el «finally», limita la concurrencia y los timeouts, y recurre a un «fetch» simple siempre que el dato no necesite de verdad un navegador. Haz eso y un scraper sobrevive en un solo VPS; sáltatelo y el navegador que resolvió tu problema de renderizado se vuelve el que te tumba el host.