Si usas Playwright CLI para automatización, pronto aparece una pregunta práctica: ¿puedes abrir varias sesiones de navegador al mismo tiempo sin que interfieran entre sí? La respuesta es sí, y Playwright CLI ya hace que este mecanismo sea bastante directo.
Siguiendo la referencia oficial session-management, este artículo se centra en sus piezas más prácticas: sesiones nombradas, aislamiento de sesiones, perfiles persistentes, patrones concurrentes y comandos comunes de limpieza. Se conservan las líneas de comando y las explicaciones de bloques de comandos de la referencia.
01 Sesiones de navegador nombradas
La recomendación oficial es usar el parámetro -s para aislar diferentes contextos de navegador:
|
|
El punto clave es que distintos nombres de session se asignan a distintos contextos de navegador. Puedes usar auth para el flujo de login y public para navegación anónima, y no compartirán cookies ni estado local.
02 Qué separa el aislamiento de sesiones
Cada sesión de navegador mantiene de forma independiente:
- Cookies
- LocalStorage / SessionStorage
- IndexedDB
- Caché
- Historial de navegación
- Pestañas abiertas
Eso significa que si inicias sesión en un sitio dentro de la sesión auth, no afectará automáticamente a la sesión public. Esto es especialmente importante para pruebas multi-cuenta, verificación de estado de login y comparaciones entre navegación anónima y autenticada.
03 Comandos relacionados con sesiones de navegador
La documentación oficial agrupa los comandos de gestión de sesiones más usados:
|
|
Puedes pensarlos como tres tipos de operaciones:
list: ver qué sesiones existen actualmenteclose/close-all/kill-all: detener sesiones o limpiar procesos de navegador atascadosdelete-data: eliminar el directorio de datos de usuario de una sesión concreta
Si solo quieres cerrar un navegador, close suele ser la primera opción. Si ya quedaron procesos residuales, kill-all encaja mejor.
04 Definir una sesión predeterminada con variable de entorno
Si no quieres repetir -s=mysession en cada comando, la documentación oficial también ofrece un enfoque con variable de entorno:
|
|
Después de eso, cuando no especifiques -s, el comando usará mysession como sesión de navegador predeterminada.
05 Patrón común: scraping concurrente
La referencia da un ejemplo muy típico de scraping concurrente:
|
|
Este patrón funciona bien cuando quieres abrir varios sitios a la vez, capturar el estado de cada página y luego limpiarlo todo junto. Como cada sitio corre en una sesión independiente, no contaminan el estado local de los demás.
06 Patrón común: sesiones de A/B testing
Otro escenario común es comparar distintas variantes de experimento al mismo tiempo:
|
|
Este estilo es muy útil para comparaciones A/B de páginas porque las dos variantes se ejecutan en sesiones separadas, haciendo más fácil gestionar capturas y comprobaciones de estado de forma independiente.
07 Persistencia de perfiles de navegador
La documentación oficial señala específicamente que, por defecto, los perfiles de navegador se almacenan solo en memoria.
Si quieres persistir un perfil en disco, añade --persistent al ejecutar open:
|
|
Esta capacidad es útil cuando necesitas reutilizar estado de login, caché local o un entorno de depuración con extensiones durante más tiempo. Al depurar repetidamente el mismo sitio, un perfil persistente suele ser mucho más eficiente que empezar desde cero cada vez.
08 La sesión de navegador predeterminada
Si no se proporciona -s explícitamente, el comando usa la sesión de navegador predeterminada:
|
|
En otras palabras, los comandos sin -s se ejecutan de forma continua dentro de la misma sesión predeterminada.
09 Configuración de arranque relacionada con sesiones
Además del nombre de sesión, la documentación oficial muestra varios patrones comunes de configuración de arranque:
|
|
Estos parámetros pueden combinarse con la gestión de sesiones. Por ejemplo, puedes hacer que una sesión nombrada siempre use firefox, o que una sesión concreta arranque siempre en modo headed para inspección manual más cómoda.
10 Buenas prácticas de la documentación oficial
La referencia enumera tres buenas prácticas.
1. Usar nombres de sesión significativos
|
|
Los nombres de sesión deberían comunicar directamente su propósito. Nombres como github-auth y docs-scrape hacen mucho más claro el mantenimiento posterior de scripts.
2. Limpiar puntualmente después de usar
|
|
Si no cierras el navegador al terminar una tarea, la sesión y los procesos en segundo plano permanecen. Puede no parecer grave al principio, pero cuando las tareas se acumulan, el entorno se vuelve desordenado rápidamente.
3. Eliminar datos de navegador obsoletos
|
|
Cuando algunas sesiones antiguas ya no hacen falta, borrar sus directorios de datos ahorra espacio y también ayuda a evitar reutilizar accidentalmente estado obsoleto.
11 Resumen rápido
Si solo quieres lo esencial, recuerda estos puntos:
-s=<name>crea y usa una sesión de navegador independiente- Distintas sesiones aíslan cookies, distintos tipos de storage, caché, historial y pestañas
close-allsirve para cierre unificado, mientraskill-allayuda a limpiar procesos anormales--persistentescribe el perfil en disco y es útil para reutilizar estado a largo plazo- Los nombres de sesión deberían ser significativos, y los datos antiguos deberían limpiarse regularmente
Si tu flujo ya incluye reutilización de estados de login, trabajo paralelo multi-cuenta, comparaciones A/B o scraping por lotes, entonces session management es una de las partes de Playwright CLI que más vale la pena aprender primero.
Referencias
- Referencia session-management de Playwright CLI: https://github.com/microsoft/playwright-cli/blob/main/skills/playwright-cli/references/session-management.md
- Página principal de Playwright CLI: https://github.com/microsoft/playwright-cli