Playwright vs Puppeteer: cuatro decisiones antes de migrar

Playwright vs Puppeteer exige elegir un contrato de automatización. La pregunta útil es qué biblioteca, conexión, compilación del navegador y evidencia de depuración necesita el trabajo. Ambas bibliotecas crean contextos aislados; ninguna vuelve compatible automáticamente un ejecutable personalizado. BotBrowser proporciona rutas documentadas de lanzamiento para ambas y controles del navegador basados en perfiles, pero no garantiza equivalencia entre protocolos, no implementa sus ejecutores de pruebas ni garantiza que un sitio acepte la sesión.

TL;DR

• Elige primero el navegador y la operación necesarios. Puppeteer admite Chrome y Firefox mediante CDP y WebDriver BiDi; no se limita a envolver CDP para Chrome.
• Distingue la conexión propia de Playwright de connectOverCDP(). Su contrato oficial describe explícitamente una menor fidelidad al adjuntarse por CDP.
• Ambas bibliotecas separan el almacenamiento de los contextos, pero un contexto no crea por sí solo otra máquina ni otra salida de red.
• Una traza de contexto de Playwright y una línea temporal de navegador de Puppeteer son productos diferentes. Sus nombres y tamaños no deciden qué biblioteca es mejor.
• Fija juntos paquete, binario y conexión. Conserva una acción fallida aunque pase un sondeo DOM más pequeño.

Contenido

• Elegir con cuatro requisitos
• Ajustar la conexión a la operación necesaria
• Comparar el estado y el alcance del aislamiento
• Elegir la evidencia de depuración necesaria
• Fijar juntos el paquete y el navegador
• Decidir dentro de los límites de la observación local
• Conclusión práctica

Elegir con cuatro requisitos

Un equipo que parte de Selenium puede revisar qué cambia en la práctica al elegir una alternativa antes de comparar estas dos bibliotecas.

Empieza por una operación necesaria. Un equipo que mantiene salida PDF exclusiva de Chromium tiene condiciones de aceptación distintas de quien ejecuta aserciones de aplicación en Chromium, Firefox y WebKit. Una conexión remota añade otro contrato. La documentación de navegadores de Playwright y el mapa de soporte de Puppeteer definen sus combinaciones compatibles; encontrar la palabra navegador en un servicio no demuestra qué combinación ofrece.

Requisito	Decisión con Playwright	Decisión con Puppeteer	Evidencia previa a la elección
Conexión y operación	Elegir lanzamiento/conexión normal o conexión CDP a Chromium	Elegir Chrome o Firefox y la ruta CDP/BiDi aplicable	El método necesario funciona por la conexión real
Estado del contexto	Asignar creación, reutilización y cierre de cada BrowserContext	Asignar createBrowserContext() y distinguir el contexto predeterminado	El estado compartido e independiente coincide con el trabajo
Depuración	Decidir si deben conservarse operaciones o aserciones de Playwright Test	Decidir si una línea temporal de Chrome explica el fallo	El archivo contiene el evento que explica el incidente
Versiones del navegador	Registrar los requisitos del paquete o validar el ejecutable propio	Registrar la versión descargada o asumir la pareja personalizada	Paquete, binario, protocolo y host son reproducibles

Una fila desconocida queda pendiente. Abrir una página remota no basta si la operación requerida es tracing de contexto o un comando CDP concreto. Un page.goto() satisfactorio establece que esa navegación funcionó, sin acreditar el resto de la API. Una captura tampoco demuestra que se registrara una aserción de prueba o una operación del servidor.

La selección precede a la integración. El diagnóstico de lanzamiento de Puppeteer cubre errores del ejecutable personalizado y de la sesión del navegador después de elegir Puppeteer. El análisis del orden de scripts iniciales de Playwright trata escritores que compiten antes del documento. Ninguno sustituye la comprobación del trabajo y del contrato de conexión al elegir biblioteca.

Escribe una condición capaz de rechazar la elección: un método requerido ausente del protocolo, un binario no compatible o un archivo que omite la aserción decisiva. Preferir un ecosistema mayor puede influir en mantenimiento, pero no constituye una condición ejecutable de aceptación. Vincula esa preferencia con la operación y la evidencia que el equipo necesita mantener.

Ajustar la conexión a la operación necesaria

La referencia de WebDriver BiDi de Puppeteer describe automatización de Chrome y Firefox. Firefox usa BiDi por defecto; Chrome usa CDP porque BiDi todavía no cubre todas sus funciones. También enumera operaciones no compatibles. Por eso, admitir Firefox no demuestra que un método exclusivo de Chrome funcione allí. Un proyecto que utiliza una operación de bajo nivel de Chromium debe verificar su frontera de protocolo real.

Playwright introduce otra distinción. La referencia de BrowserType describe connect() para un servidor Playwright y connectOverCDP() para un Chromium existente. La segunda conexión tiene explícitamente menor fidelidad. Una dirección WebSocket genérica no es automáticamente un servidor Playwright; identifica el protocolo del destino antes de conectar el cliente.

Esa misma referencia exige versiones mayor y menor coincidentes entre el Playwright que conecta y el que lanza el servidor. No traslades esa condición a la conexión CDP, cuyo contrato es distinto. Registra si el navegador procede de launch(), de un servidor Playwright o de un Chromium iniciado por separado. Esa procedencia importa más que compartir un esquema de URL.

El nombre importado no acredita la integridad del protocolo. Puppeteer con BiDi, Puppeteer con Chrome CDP y Playwright conectado a Chromium CDP pueden ofrecer operaciones diferentes. Si un proveedor remoto controla argumentos y actualizaciones, su contrato de cliente también es una dependencia. Solicita tipos de conexión y versiones compatibles documentados, sin suponer que todas las bibliotecas intercambian el mismo destino.

Concreta las operaciones necesarias. Si el trabajo requiere interacción, traza, comando de navegador y limpieza de contextos, valida las cuatro por la conexión prevista. Una navegación mínima sigue siendo útil como preparación, pero debe registrarse junto con lo no probado. No convierte una integración parcial en soporte completo. Conserva el protocolo y la versión exacta del paquete junto a cualquier operación no admitida.

Comparar el estado y el alcance del aislamiento

La documentación de contextos de Playwright describe sesiones independientes con almacenamiento aislado. La referencia BrowserContext de Puppeteer también describe cookies y almacenamiento local separados y explica el contexto predeterminado. Las dos ofrecen una frontera de estado para escenarios independientes; esa frontera no crea un host, un sistema operativo ni una cuota separados.

La comparación útil es quién controla esa frontera. Una página creada en el contexto A comparte su estado pertinente; el contexto B tiene otro ámbito de almacenamiento. Abrir una pestaña no equivale a crear otro contexto. Cerrar A tampoco equivale a cerrar el navegador completo, y dejar el contexto predeterminado en un trabajo puede producir una duración distinta de la de los contextos explícitos.

Estas comprobaciones de página son adecuadas para un fixture propio en localhost. Ejecútalas mediante page.evaluate() después de navegar al mismo origen con cada biblioteca. Inspeccionan estado sintético, sin copiar una sesión de cuenta ni medir todos los mecanismos de almacenamiento.

await pageA.evaluate(() => {
  localStorage.setItem('fixtureMarker', 'context-A');
  document.cookie = 'fixtureMarker=context-A; Path=/; SameSite=Lax';
});

const readState = () => ({
  cookie: document.cookie,
  local: localStorage.getItem('fixtureMarker'),
});

const a = await pageA.evaluate(readState);
const sibling = await siblingInA.evaluate(readState);
const b = await pageB.evaluate(readState);

El fixture observado creó ambos contextos, abrió una página hermana de A y cerró A antes de recargar B. Los estados compartidos y separados aparecen más abajo. Eso no determina IndexedDB, persistencia de permisos, service workers, perfiles en disco ni modelo de procesos sin pruebas adicionales. Un resultado de localStorage no certifica todo el almacenamiento; una cookie vacía tampoco demuestra salidas de red diferentes.

Incluye la limpieza en la elección. Una biblioteca puede exponer la API correcta mientras el programa de prueba reutiliza por error una página global o cierra el navegador que otra tarea necesita. Asigna un responsable a cada contexto y una duración del navegador superior a la de sus tareas compartidas. El análisis del ciclo de vida de contextos Playwright desarrolla ese problema; aquí solo se establece que ambas candidatas ofrecen un modelo de contextos que conviene validar.

Elegir la evidencia de depuración necesaria

La referencia Tracing de Playwright distingue las trazas de contexto de las de Playwright Test. La API de contexto captura operaciones del navegador y actividad de red, pero no aserciones como expect(). Cuando esas aserciones deben conservarse, recomienda tracing del ejecutor de pruebas. Llamar a context.tracing.start() no incorpora automáticamente el ejecutor a un script independiente.

La referencia Tracing de Puppeteer describe un archivo que se abre en Chrome DevTools o en un visor de líneas temporales. Además, solo puede haber una traza activa por navegador. El producto y su ámbito de concurrencia difieren de una línea de depuración independiente para cada contexto. Los workers que comparten navegador necesitan un responsable de la traza, no solo nombres distintos de archivo.

Elige según la pregunta que debe contestar la evidencia. Ante una aserción fallida pueden importar la acción, la instantánea documental y el estado esperado; para rendimiento pueden importar eventos temporales. Un JSON con muchos eventos no es automáticamente un registro de fallo más completo que un ZIP pequeño. Tampoco un ZIP garantiza un diagnóstico de rendimiento útil.

El sondeo comprobó entradas de traza dentro del ZIP de Playwright y JSON temporal con eventos en las salidas de Puppeteer. Esas aserciones solo acreditan estructura. No demuestran que alguien abriera los visores, encontrara un fallo concreto o reconstruyera una transacción distribuida. El flujo de trazas Playwright cubre captura y revisión; elegir extensión de archivo no sustituye esa tarea.

Las restricciones de protocolo siguen siendo relevantes. La documentación actual de Puppeteer enumera Tracing entre las carencias genéricas de BiDi. Sin embargo, el paquete más antiguo instalado produjo una línea temporal de Chrome al conectarse a Chrome por BiDi. Esa observación no demuestra tracing en Firefox ni en cualquier conexión BiDi. A la inversa, una lista genérica no elimina un archivo realmente producido. Conserva juntos paquete, navegador y conexión al estudiar esas diferencias.

Fijar juntos el paquete y el navegador

El contrato de instalación de Playwright relaciona sus versiones con binarios concretos y describe canales de navegadores de marca. La referencia de configuración de Puppeteer indica que el paquete completo descarga una versión específica de Chrome; su tabla de soporte relaciona versiones del paquete y navegador. El archivo de dependencias y la ruta ejecutable son registros complementarios.

La distinción entre puppeteer y puppeteer-core afecta a la operación. La referencia indica explícitamente que core ignora los archivos de configuración y variables de entorno allí descritos. Un proyecto core debe seleccionar su navegador mediante la API correspondiente. Copiar un archivo del paquete completo no demuestra que el binario elegido haya cambiado.

Un ejecutable propio desplaza la responsabilidad. Las integraciones Playwright y Puppeteer de BotBrowser documentan sus rutas de lanzamiento, pero una ruta existente no es un resultado de compatibilidad. Registra versión y hash del binario, paquete, conexión, opciones de lanzamiento y host. Si falla la acción requerida, conserva el fallo aunque otra operación de la página funcione.

La ejecución local utilizó Playwright 1.58.0, puppeteer-core 24.29.1 y Chrome original 157.0.8103.79 en macOS arm64. Era una combinación elegida explícitamente, distinta de la pareja predeterminada documentada del paquete Puppeteer antiguo. Las páginas públicas actuales se recuperaron por separado e identificaban 25.17.0. Son fuente del contrato actual, no evidencia de que el paquete antiguo implemente todos esos comportamientos.

Define cuándo repetir la aceptación. Una actualización automática del navegador, un cambio de paquete, de servidor remoto o de modo de lanzamiento puede invalidar la combinación aceptada. Reutiliza el fixture propio, revisa la operación que falla y conserva el resultado anterior. Navegar después de actualizar no demuestra que entrada, trazas y limpieza sigan siendo compatibles. Cada requisito necesita observación en su frontera.

Decidir dentro de los límites de la observación local

Tres tareas se ejecutaron simultáneamente en la misma máquina: lanzamiento Playwright, Puppeteer Chrome CDP y Puppeteer Chrome BiDi. El pool solicitado era 20; el efectivo fue 3 porque había tres tareas. La comprobación registró 16 CPU y unos 19.8 GB disponibles sumando páginas libres, inactivas y especulativas de macOS, sin duplicar páginas purgables. No fue una prueba de rendimiento ni de servicios remotos.

Comprobación observada	Playwright	Puppeteer Chrome CDP	Puppeteer Chrome BiDi
A y su página hermana leen el marcador	context-A	context-A	context-A
B empieza sin marcador	null, cookie vacía	null, cookie vacía	null, cookie vacía
Acción DOM en el mundo principal	applied	applied	applied
Estructura de traza	ZIP con entradas .trace	JSON temporal, 7289 eventos	JSON temporal, 7063 eventos
B recarga tras cerrar A	Completado, sin marcador	Completado, sin marcador	Completado, sin marcador
Limpieza del navegador en esta ejecución	Cerrado	Cerrado	Cerrado

La acción DOM invocó el botón del fixture desde page.evaluate() y leyó la salida en la misma llamada. Su alcance era menor que una prueba de entrada: no validó hit testing, entrada confiable, accionabilidad ni espera automática de la biblioteca. Describir esa fila como soporte de clics aprobado omitiendo la restricción exageraría el resultado. Se observó una acción controlada de script y su marcador de aplicación.

La ejecución original de acciones sobre elementos sigue fallida. Tras pasar las aserciones de almacenamiento, CDP produjo Runtime.callFunctionOn timed out y BiDi produjo script.callFunction timed out, con un plazo de protocolo de 15 segundos. Playwright completó esa ejecución. El sondeo posterior del mundo principal pasó sin reparar ni revalidar esas rutas. Acota la diferencia observada, pero no establece la causa, arregla la combinación ni justifica comparar fiabilidad.

La preparación inicial también calculó incorrectamente el pool usando solo memoria inmediatamente libre, por lo que asignó un worker. Esa ejecución se interrumpió y se conservó aparte; no es la comparación concurrente. El cálculo posterior incluyó los componentes pertinentes de memoria disponible en macOS y registró un máximo de tres navegadores, sin residuos. Corregir ese cálculo arregló la planificación experimental, no las bibliotecas.

Usa el resultado para definir la siguiente aceptación. Si el trabajo necesita acciones sobre elementos, valida esa ruta exacta en una pareja oficialmente compatible antes de migrar. Si solo necesita evaluación de página con estados separados y captura temporal, el sondeo menor resulta pertinente dentro de su entorno declarado. No se ejercitaron Firefox, WebKit, PDF, servidores Playwright remotos ni aserciones Playwright Test.

En la decisión registra trabajo, familia de navegador, conexión, pareja paquete/binario, responsable del contexto y de la evidencia. Adjunta casos aprobados, fallidos y no probados. Elige quien cumpla los requisitos bajo un contrato mantenible, o deja la elección pendiente hasta probar la operación ausente. Una decisión condicional con un fallo reproducible es más útil que una recomendación universal basada en evidencia incompatible.

Preguntas frecuentes

¿Puppeteer se limita a Chrome y CDP?

No. Su documentación oficial describe Chrome y Firefox con CDP y WebDriver BiDi. La disponibilidad de cada método sigue dependiendo del protocolo, navegador y paquete elegidos.

¿Conectar Playwright por CDP ofrece el contrato completo?

No. BrowserType describe explícitamente una menor fidelidad que la conexión por protocolo Playwright. Valida las operaciones necesarias sin deducir equivalencia de una navegación exitosa.

¿Contextos separados significan identidades separadas?

Por sí solos, no. El almacenamiento aislado no demuestra máquinas, salidas de red, cuotas ni permisos diferentes. Ambas bibliotecas necesitan un contrato explícito de trabajo y ciclo de vida.

¿Qué biblioteca es más rápida para scraping o PDF?

Este fixture no responde a eso. No contiene trabajo de scraping representativo, comparación PDF ni medición temporal controlada. Selecciona operación y navegador; después mide ese trabajo por separado.

Fuentes

• Playwright: binarios y canales
• Playwright: contratos de conexión BrowserType
• Playwright: aislamiento de contextos
• Playwright: trazas y límite de aserciones
• Puppeteer: configuración y ejecutables propios
• Puppeteer: soporte WebDriver BiDi
• Puppeteer: correspondencia paquete/navegador
• Puppeteer: BrowserContext
• Puppeteer: trazas temporales
• BotBrowser: integración Playwright
• BotBrowser: integración Puppeteer

Conclusión práctica

Elige Playwright o Puppeteer según conexión, operación, estado bajo responsabilidad del trabajo, evidencia de depuración y pareja navegador/paquete que el equipo pueda mantener. Conserva por separado las rutas de entrada fallidas y los sondeos DOM aprobados, y distingue documentación actual de paquetes antiguos instalados. BotBrowser proporciona una integración documentada; el contrato de automatización aún necesita su propia evidencia de aceptación.