El botón Atrás también es una prueba de rendimiento en páginas con video

Una página con video no está terminada cuando su LCP mejora. También debe volver al instante cuando alguien toca Atrás. Para eso, el reproductor, sus listeners y las llamadas de red tienen que permitir que el navegador restaure la página desde bfcache en lugar de reconstruirla.

En auditorías de rendimiento solemos mirar el primer render, el peso de la portada y la interacción inicial. Es correcto, pero incompleto. La gente no navega una web como un script de Lighthouse: abre un caso de estudio, entra a una página de detalle, vuelve a la lista y compara otra opción. Si esa vuelta repite loaders, analytics, inicialización del reproductor y peticiones que ya no aportan nada, el sitio se siente pesado aunque la primera carga haya sido muy buena.

El back/forward cache, o bfcache, guarda una instantánea en memoria de una página cuando el usuario sale de ella. Si la página cumple las condiciones del navegador, Atrás o Adelante puede restaurarla sin reconstruir el documento desde cero.[1] No es una técnica de caché de CDN ni un truco de framework. Es una propiedad de la navegación real.

Las páginas con video son donde esto suele romperse. Tienen SDKs de terceros, listeners globales, observadores de visibilidad, conexiones a analítica y lógica que intenta “limpiar todo” al abandonar la ruta. Cada una de esas piezas puede convertir una vuelta inmediata en otra carga completa.

La diferencia entre una página rápida y una navegación rápida

Una estrategia de medios sensata ya reduce el costo de la primera visita. En Mintec hemos documentado por qué conviene cargar video y audio de forma diferida, por qué una hero con video debe proteger el LCP y cómo medir la presión de CPU de un reproductor en una experiencia multimedia. Pero esas prácticas responden a una sola pregunta: “¿cuánto cuesta llegar aquí?”.

bfcache plantea otra: “¿cuánto cuesta regresar?”.

El error común es arreglar el cuarto punto a golpes: “cuando la persona se va, desmontemos todo”. Es una reacción comprensible, especialmente después de depurar una fuga de memoria. Pero el objetivo no es dejar una habitación vacía para el navegador. Es dejar una página que pueda congelar y retomar sin mentir sobre su estado.

El marco de cuatro contratos para video y bfcache

Usamos cuatro contratos durante una revisión de arquitectura. No reemplazan las pruebas, pero evitan que el equipo discuta solo de framework o de proveedor de video.

1. Contrato de ciclo de vida

El código debe asumir que la página puede volver sin recargar. pageshow permite detectar una restauración con event.persisted; MDN documenta ese indicador precisamente para este caso.[3]

No hace falta reiniciar toda la aplicación. Lo útil es reconciliar lo que el visitante puede ver: controles, poster, estado de mute y tiempo mostrado. Si un módulo se inicializa cada vez que corre pageshow, el supuesto beneficio desaparece y aparecen duplicados difíciles de detectar.

window.addEventListener('pageshow', (event) => {
  if (!event.persisted) return;

  refreshVideoControls();
  syncPosterAndPlaybackState();
});

En un sitio Astro, este código vive cerca de la isla que posee el reproductor, no en un listener global que intenta adivinar qué ruta está activa. La misma regla aplica si usas un proveedor externo: una integración debe exponer una forma de sincronizar estado, no obligarte a crear otra instancia.

2. Contrato de estado

Un reproductor tiene dos tipos de estado. El primero es visible y vale la pena preservar: posición, volumen, subtítulos elegidos, si el video estaba pausado. El segundo es efímero y no debería decidir la interfaz al volver: un spinner viejo, un error de red ya resuelto o una promesa que pertenecía a la visita anterior.

Antes de añadir persistencia, define qué debe ocurrir al volver. Nuestra posición es deliberada: no reanudar video con sonido automáticamente tras Atrás. Restablece la posición y deja una señal clara de que el usuario puede continuar. Es más respetuoso y evita que una restauración inesperada dispare audio en una reunión.

Esta decisión no depende de bfcache. Es diseño de producto. bfcache solo hace visible cuando el equipo no la tomó.

3. Contrato de red

Una vuelta con Atrás no debe llamar al CMS, al endpoint de recomendaciones y al proveedor de analítica como si fuera una visita nueva. Eso no significa bloquear medición. Significa clasificarla.

Mantén las métricas de navegación separadas de las impresiones de contenido. Si la plataforma de analítica necesita registrar una restauración, envía un evento específico como page_restored_from_bfcache; no reutilices el evento de pageview que activa personalización, fetches o reproducción automática. La arquitectura de contenido de Astro con fuentes múltiples ayuda aquí: el frontend puede recibir contenido estable sin que cada interacción obligue a consultar un backend.

También conviene revisar sockets, polling y refrescos en segundo plano. Un player que sigue preguntando por el estado de una transmisión cuando la página ya no está visible no es “más vivo”; solo deja más trabajo para recuperar.

4. Contrato de control

El visitante debe recuperar una interfaz que coincida con la realidad. Si el navegador restauró una página pausada, el botón tiene que decir reproducir. Si los subtítulos estaban activos, no pueden quedar visualmente apagados. Si el video es una demostración de producto, el foco no debe saltar a un control oculto ni perderse después de Atrás.

Este contrato une rendimiento, accesibilidad y UX. Lo tratamos como una prueba de aceptación: volver a una página debe conservar contexto, pero nunca secuestrar atención ni reiniciar sonido.

Qué revisar antes de culpar a Astro o al proveedor de video

Astro no elimina automáticamente una causa de bloqueo de bfcache, igual que Next.js o un CMS headless tampoco la crean por sí solos. El problema suele estar en el JavaScript que montamos encima: SDK de ads, chat, player, medición o código de transición.

Chrome ofrece diagnósticos de bfcache y razones de no restauración; úsalos para investigar, no como una lista universal de reglas, porque el soporte y los motivos cambian entre navegadores.[2] La secuencia de revisión es simple:

1. Abre una página real con video, deja que el reproductor llegue a un estado reconocible y navega a otra ruta interna.
2. Vuelve con Atrás. Comprueba visualmente posición, controles, foco y silencio.
3. Repite con herramientas de desarrollo abiertas para revisar si hubo una restauración o una carga completa.
4. Si no hubo restauración, identifica primero el listener o integración responsable. No añadas un unload nuevo como “solución”.
5. Prueba en el navegador que usa tu audiencia. Un arreglo que solo funciona en el equipo de desarrollo no es una decisión de arquitectura.

Chrome recomienda evitar unload porque puede impedir bfcache.[2] Esa recomendación es una buena alarma, no una invitación a sustituirlo por lógica agresiva de pagehide. Evalúa qué recurso necesita realmente liberarse. Muchas veces basta con pausar, detener polling y preparar una reconciliación de UI al volver.

El criterio que cambia una decisión de arquitectura

Al elegir plataforma de video, solemos comparar costo, analítica, DRM, streaming adaptativo y facilidad de embed. Añade una pregunta operativa: “¿podemos controlar el ciclo de vida del player sin parchar el documento completo?”. Si la respuesta es no, ese proveedor puede tener un buen dashboard y aun así ser una mala pieza para una web que depende de exploración.

Lo mismo vale para un CMS headless. WordPress, Sanity o archivos locales no determinan bfcache. Lo determinan el runtime, las integraciones y las decisiones de estado que tomas al renderizar cada página. Un frontend estático con un reproductor mal aislado puede dar una experiencia peor que un sitio dinámico bien instrumentado.

El botón Atrás parece un detalle. En realidad expone si la web entiende una sesión como una cadena de pantallas conectadas o como páginas desechables. Para sitios con video, esa diferencia se siente cada vez que alguien compara una pieza con otra.

Sources

[1] https://developer.mozilla.org/en-US/docs/Glossary/bfcache — MDN: bfcache [2] https://developer.chrome.com/docs/web-platform/bfcache — Chrome for Developers: bfcache [3] https://developer.mozilla.org/en-US/docs/Web/API/Window/pageshow_event — MDN: pageshow event