Fecha de publicación: 21 de octubre de 2024; última actualización: 9 de septiembre de 2025
Chrome está realizando un cambio para permitir el uso de la memoria caché atrás/adelante (bfcache) para las páginas que usan Cache-Control: no-store cuando sea seguro hacerlo. Descubre qué significa esto para los desarrolladores.
Fondo
Establecer Cache-Control: no-store como encabezado HTTP es un indicador de que la página no debe almacenarse en la caché HTTP. Se debe usar para las páginas que contienen datos sensibles (por ejemplo, para las páginas cuando un usuario accede), pero la directiva no-store se suele usar en páginas sin datos sensibles.
Con la bfcache, en lugar de destruir una página cuando el usuario navega fuera de ella, posponemos la destrucción y pausamos la ejecución de JS. Si el usuario vuelve a navegar hacia atrás pronto, volveremos a hacer visible la página y reanudaremos la ejecución de JS. Esto permite que el usuario navegue por las páginas casi al instante.
Si bien no es un requisito de la especificación de HTML, los navegadores suelen tomar Cache-Control: no-store como un indicador para evitar colocar la página en la bfcache. Este es el motivo principal por el que no se usa la bfcache, en aproximadamente el 17% de las navegaciones por el historial en dispositivos móviles y el 7% en computadoras de escritorio. Esto significa que estas páginas no se benefician de las restauraciones rápidas y deben volver a cargar la página por completo, incluidas las llamadas de red, la ejecución de JavaScript y la renderización.
A menudo, se establece Cache-Control: no-store para evitar problemas de almacenamiento en caché cuando cambia el sitio, pero este motivo es menos relevante cuando se usa la bfcache, ya que se restablece la página completa casi como si hubiera permanecido abierta todo el tiempo.
Cómo Chrome cambia este comportamiento
Chrome anunció su intención de cambiar este comportamiento, pero está adoptando un enfoque cauteloso para este cambio. Desde Chrome 116, hemos estado realizando experimentos para aumentar gradualmente el porcentaje de cargas de páginas, y se espera que este alcance el 100% en marzo y abril de 2025.
Datos sensibles
Si bien nuestro análisis muestra que la mayoría de las navegaciones hacia atrás o hacia adelante no incluyen datos sensibles y, por lo tanto, deberían ser aptas para la bfcache, hay casos en los que las páginas no deberían colocarse en la bfcache. Por ejemplo, al cerrar la sesión, no debería ser posible recuperar una página en la que se accedió navegando hacia atrás o hacia adelante.
Para evitar esto, Chrome expulsará una página de la bfcache cuando se realicen cambios en las cookies o en otros métodos de autorización.
Además, el uso de las siguientes APIs para las páginas que usan Cache-Control: no-store seguirá haciendo que esas páginas no sean aptas para el almacenamiento en caché atrás/adelante:
Ten en cuenta que esta no es una lista exhaustiva de las APIs que impiden el uso de la bfcache, sino las APIs que bloquean la bfcache en las páginas Cache-Control: no-store, incluso si no se usan en el momento de salir de la página.
El tiempo de espera de la bfcache para las páginas Cache-Control: no-store también se reduce a 3 minutos (en lugar de los 10 minutos que se usan para las páginas que no usan Cache-Control: no-store) para reducir aún más el riesgo.
Exclusión de la versión para empresas
Las empresas suelen tener software difícil de actualizar y dispositivos compartidos. La política AllowBackForwardCacheForCacheControlNoStorePageEnabled se puede inhabilitar para seguir impidiendo el uso de bfcache en las páginas Cache-Control: no-store.
Prueba el cambio
Los desarrolladores pueden probar este cambio con la siguiente marca:
--enable-features=CacheControlNoStoreEnterBackForwardCache:level/restore-unless-cookie-change
Si se aplica alguna de las excepciones anteriores (por ejemplo, si cambian las cookies), se impedirá que la página use la bfcache, y se mostrará el motivo "Las páginas cuyo recurso principal tiene Cache-Control: no-store no pueden ingresar en la memoria caché atrás/adelante" en el probador de bfcache de Chrome DevTools.
Puedes usar esta página de prueba de bfcache para realizar pruebas con y sin esta marca.
Lo que deben saber los desarrolladores
Si bien los desarrolladores no deberán realizar ningún cambio para que sus usuarios se beneficien de este mayor uso de la bfcache, hay algunas cosas que deberán tener en cuenta como resultado de esto. Estas fueron consideraciones similares a las que otros sitios pueden haber experimentado en el lanzamiento inicial de bfcache en diciembre de 2021.
¿Los desarrolladores aún deberían intentar reducir el uso de Cache-Control: no-store?
La bfcache está habilitada para Cache-Control: no-store en las circunstancias limitadas mencionadas anteriormente y solo para Chrome. Es posible que otros navegadores sigan bloqueando el uso de la bfcache cuando se use Cache-Control: no-store.
La práctica recomendada sigue siendo minimizar el uso de Cache-Control: no-store en lugar de depender de estas heurísticas.
Impacto en el rendimiento
El motivo por el que realizamos este cambio es para mejorar la experiencia de página de los usuarios en la Web. Observamos mejoras notables en las Métricas web esenciales cuando lanzamos la bfcache por primera vez, y ahora queremos llevar esas mismas mejoras a más sitios.
Los propietarios de sitios pueden observar una mejora en sus Métricas web esenciales a medida que se lanza esta función y pueden medir el uso de la bfcache en CrUX, incluso en CrUX Vis.
Estadísticas de impacto
Las páginas restablecidas desde la bfcache "restablecen" la página anterior (incluido el heap de JavaScript) en lugar de volver a cargar la página. Muchos proveedores de estadísticas populares no miden los restablecimientos de la bfcache como vistas de página nuevas, ya que solo activan las vistas de página cuando se cargan inicialmente.
Por lo tanto, es posible que los sitios observen una reducción en las cargas de página en sus estadísticas cuando comiencen a usar la bfcache por primera vez. Recomendamos que los consideres como vistas de página. Para ello, configura objetos de escucha para el evento pageshow y verifica la propiedad persisted:
// Send a pageview when the page is first loaded.
gtag('event', 'page_view');
// Send another pageview if the page is restored from bfcache.
window.addEventListener('pageshow', (event) => {
if (event.persisted) {
// Page was restored from bfcache, sent another page view.
gtag('event', 'page_view');
}
});
Cómo controlar las actualizaciones en el restablecimiento de la página
Dado que es posible que los sitios ahora vean el uso de la bfcache cuando antes no lo veían y cuando la página se volvería a cargar por completo con datos nuevos, es posible que los desarrolladores deseen considerar la actualización de los datos en una restauración de la bfcache.
Las actualizaciones se pueden activar de manera similar al registro de vistas de página adicionales para Analytics con el evento pageshow y la verificación de la propiedad persisted.
Ten en cuenta que no todo el contenido debe actualizarse y que los usuarios pueden preferir "volver" al contenido que vieron anteriormente. Por ejemplo, actualizar una lista de artículos puede significar que el usuario ya no vea un artículo que quería volver a ver.
Impacto en los anuncios
Al igual que con el impacto en las estadísticas, es posible que los sitios vean una reducción en las impresiones de anuncios si estos solo se cargan cuando se carga la página. Los anuncios se pueden actualizar de forma programática en el restablecimiento de bfcache para garantizar la paridad con las cargas de página completas, nuevamente con el evento pageshow y verificando la propiedad persisted, pero es posible que no siempre sea lo correcto. Consulta la documentación de tu proveedor de anuncios para saber cómo activar las recargas de anuncios.
Más información sobre la bfcache
Para obtener más información sobre la bfcache, consulta nuestra guía técnica completa sobre la bfcache.
Comentarios
Nos interesa conocer tu opinión sobre este cambio, que puedes proporcionar en el seguimiento de problemas de Chrome con el componente bfcache.
Conclusión
Nos complace ofrecer los beneficios de la bfcache en muchas más páginas para mejorar la experiencia de página de los usuarios. Consideramos cuidadosamente este cambio y nuestro enfoque busca implementarlo de la manera más segura posible. Esperamos que la información que se proporciona aquí ayude a los desarrolladores a comprender este cambio y a realizar los ajustes necesarios para evitar problemas cuando se produzca.