¿Qué es el bfcache?

El bfcache es una optimización que forma parte del navegador, no de tu servidor ni de tu código. Cuando alguien sale de una página pulsando un enlace o escribiendo una nueva URL, el navegador no destruye necesariamente esa pestaña: puede pausar la ejecución de JavaScript y guardar el estado completo del documento en memoria RAM. Si esa persona vuelve después con el botón atrás o adelante, el navegador restaura la página exactamente como estaba, sin descargar ni un solo recurso de nuevo.

Google calcula que una de cada diez navegaciones en escritorio y una de cada cinco en móvil son de este tipo, avanzar o retroceder. Es una proporción que rara vez se mide, porque las herramientas de auditoría suelen fijarse solo en la primera carga de una página, la que alimenta la mayoría de los informes de Core Web Vitals.

Conviene no confundir el bfcache con otras formas de caché. La caché HTTP guarda archivos sueltos, como imágenes, hojas de estilo o scripts, para no descargarlos de nuevo. El bfcache guarda la página entera, con su estado de JavaScript incluido, lista para reaparecer sin ejecutar nada desde cero. Por eso una página con bfcache activo se percibe como instantánea al volver atrás, mientras que una recarga completa, aunque esté bien optimizada, siempre implica al menos una petición de red.

El navegador decide si una página es apta para el bfcache en el momento en que el usuario la abandona, según una lista de condiciones técnicas. Si la página las cumple, el proceso de renderizado queda congelado en memoria en vez de destruirse. La ejecución de JavaScript se detiene, los temporizadores dejan de correr y la página espera ahí, intacta, hasta que el usuario regresa o hasta que el navegador necesita liberar esa memoria para otra cosa.

Hay factores que impiden esta congelación, y web.dev los documenta con precisión. El más determinante es un manejador del evento unload: cualquier página que todavía use ese evento para ejecutar código queda excluida del bfcache en Chrome y en Firefox, sin excepción. La cabecera Cache-Control: no-store en la respuesta del servidor produce el mismo efecto, porque le indica explícitamente al navegador que no debe conservar nada de esa página. También bloquean el bfcache las conexiones que quedan abiertas al salir, como una transacción de IndexedDB en curso, una petición fetch o XMLHttpRequest sin resolver, un WebSocket activo o una conexión WebRTC, así como cualquier referencia a window.opener que deje la pestaña original vinculada a la nueva.

Para saber si una página concreta entra o no en el bfcache, Chrome DevTools incluye una prueba dedicada en la pestaña Application, bajo Back-forward cache, que ejecuta la comprobación real y devuelve el motivo exacto del bloqueo cuando lo hay. Otra vía de medición es programática: la Navigation Timing API expone el tipo de navegación en performance.getEntriesByType('navigation')[0].type, con el valor back_forward cuando la página vino del bfcache, lo que permite registrar esta proporción en cualquier sistema de analítica propio.

El bfcache no cambia una sola línea del contenido de la página, pero cambia por completo cómo se percibe su velocidad en una parte nada pequeña de las visitas: entre una de cada diez y una de cada cinco navegaciones, según los datos citados en el apartado anterior. Cuando una página se restaura desde el bfcache, sus valores de LCP y FCP prácticamente coinciden con el instante de la restauración, porque no hay descarga ni renderizado desde cero.

Esto explica un patrón que desconcierta a quien audita rendimiento sin conocer el bfcache: una web que aparentemente no ha cambiado nada mejora sus métricas de velocidad de un día para otro, o las empeora tras un despliegue que introdujo, sin que nadie se diera cuenta, un manejador de unload o una cabecera no-store. La causa no está en el código visible, está en si esa página sigue siendo apta para el bfcache o ha dejado de serlo.

Para un equipo que depende del rendimiento percibido, como una tienda con navegación de catálogo a producto y vuelta, o un medio con listado de artículos, el bfcache no es un detalle técnico menor. Es la diferencia entre que volver atrás se sienta instantáneo o se sienta como una carga más, y esa diferencia se nota en cada sesión que incluye al menos una navegación hacia atrás.

• Elimina cualquier manejador del evento unload y sustitúyelo por pagehide o visibilitychange, que sí son compatibles con el bfcache.
• Revisa que ninguna respuesta HTML lleve Cache-Control: no-store salvo que la página contenga de verdad datos sensibles que no deban persistir en memoria.
• Cierra las conexiones abiertas, como WebSocket, WebRTC o peticiones fetch pendientes, en el evento pagehide, en vez de dejarlas activas al salir de la página.
• Comprueba cada plantilla importante con la prueba Back-forward cache de Chrome DevTools, no solo la portada.
• Evita dejar window.opener accesible al abrir enlaces en una pestaña nueva; añade rel="noopener" a esos enlaces.
• Mide la proporción real de navegaciones back_forward en tu sitio con la Navigation Timing API antes de asumir que el problema es marginal.

• Dar por hecho que la lentitud percibida al volver atrás es un problema del servidor, cuando el bloqueo está en el propio código del cliente.
• Añadir Cache-Control: no-store a páginas normales por prudencia, sin medir si de verdad contienen datos que no deban guardarse.
• Dejar un manejador de unload heredado de un script antiguo de analítica que nadie ha revisado desde su instalación.
• Confundir la caché HTTP de archivos sueltos con el bfcache de la página completa, y pensar que optimizar una ya cubre la otra.