Chrome realizará 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 lo que esto significa para los desarrolladores.
Segundo plano
Configurar 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 en las que un usuario accedió), pero la directiva no-store
se suele usar en páginas sin datos sensibles.
Con bfcache, en lugar de destruir una página cuando el usuario sale de ella, posponemos la destrucción y pausamos la ejecución de JS. Si el usuario vuelve a la página pronto, volveremos a mostrar la página y reanudaremos la ejecución de JS. Esto genera una navegación por páginas casi instantánea para el usuario.
Si bien las especificaciones de HTML no lo requieren, los navegadores suelen tomar Cache-Control: no-store
como un indicador para evitar colocar la página en bfcache. Este es el motivo principal por el que no se usa bfcache, en el caso de alrededor del 17% de las navegaciones de historial en dispositivos móviles y el 7% de las navegaciones de historial en computadoras de escritorio. Esto significa que estas páginas no se benefician de los restablecimientos rápidos y deben volver a cargarse por completo, incluidas las llamadas de red, la ejecución de JavaScript y la renderización.
A menudo, Cache-Control: no-store
se configura para evitar problemas de almacenamiento en caché cuando cambia el sitio, pero esta razón es menos relevante cuando se usa bfcache, ya que la página completa se restablece casi como si se hubiera dejado abierta todo el tiempo.
Cómo Chrome cambiará este comportamiento
Chrome anunció su intención de cambiar este comportamiento, pero está adoptando un enfoque cauteloso. Hemos estado ejecutando experimentos desde Chrome 116 y, hasta hace poco, se ejecutaban en el 5% de las cargas de página.
El 2 de octubre, lo aumentamos al 10% de las cargas de página y tenemos la intención de aumentarlo al 20% en noviembre y al 50% a principios del próximo año. Luego, lanzaremos la función por completo poco después, con algunas inhabilitaciones que se analizarán a continuación.
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 deben colocarse en la bfcache. Por ejemplo, cuando se sale de una cuenta, no debería ser posible recuperar una página a 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 bfcache:
Ten en cuenta que esta no es una lista completa de las APIs que impiden el uso de bfcache, sino las APIs que bloquean bfcache en las páginas Cache-Control: no-store
, incluso si no se están usando en el momento de salir de la página.
El tiempo de espera de bfcache para las páginas Cache-Control: no-store
también se reduce a 3 minutos (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.
Inhabilitación de Enterprise
Las empresas suelen tener software y dispositivos compartidos difíciles de actualizar. Se puede inhabilitar la política AllowBackForwardCacheForCacheControlNoStorePageEnabled
para seguir evitando el uso de bfcache para 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, el cambio de cookies), se impedirá que la página use la bfcache con el mensaje "Las páginas cuyo recurso principal tiene Cache-Control: no-store
no pueden ingresar a la memoria caché atrás/adelante", que se muestra en el probador de bfcache de DevTools de Chrome.
Puedes usar esta página de prueba de bfcache para realizar pruebas con y sin esta marca.
Qué deben saber los desarrolladores
Si bien los desarrolladores no necesitarán realizar ningún cambio para que sus usuarios se beneficien de este mayor uso de bfcache, hay algunos aspectos que podrían tener que tener en cuenta como resultado de esto. Estas son consideraciones similares que otros sitios pueden haber experimentado en el lanzamiento inicial de bfcache en diciembre de 2021.
Impacto en el rendimiento
El motivo por el que realizamos este cambio es mejorar la experiencia de la página para los usuarios en la Web. Cuando lanzamos bfcache por primera vez, notamos mejoras significativas en las métricas web esenciales y ahora queremos llevar esas mismas mejoras a más sitios.
Es posible que los propietarios de sitios vean una mejora en sus Métricas web esenciales a medida que se implemente esta función y puedan medir el uso de bfcache en CrUX, incluido en el panel de CrUX.
Estadísticas de impacto
Las páginas que se restablecen desde la bfcache “restablecen” la página anterior (incluida la pila de JavaScript) en lugar de volver a cargarla. Muchos proveedores de estadísticas populares no miden los restablecimientos de 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 vean una reducción en las cargas de página en sus estadísticas cuando comiencen a usar bfcache por primera vez. Recomendamos considerarlas 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');
}
});
Controla las actualizaciones en el restablecimiento de páginas
Dado que los sitios ahora pueden ver el uso de bfcache cuando antes no lo veían y cuando la página se volvía a cargar por completo con datos actualizados, es posible que los desarrolladores deban considerar actualizar los datos en un restablecimiento de bfcache.
Las actualizaciones se pueden activar de manera similar al registro de vistas de página adicionales para las estadísticas con el evento pageshow
y la verificación de la propiedad persisted
.
Ten en cuenta que no es necesario actualizar todo el contenido 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 ve un artículo que iba 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. Para ello, se vuelve a usar el evento pageshow
y se verifica la propiedad persisted
, pero no siempre es lo correcto. Consulta la documentación de tu proveedor de anuncios para obtener información sobre cómo activar la recarga de anuncios.
Más información sobre bfcache
Para obtener más información sobre bfcache, consulta nuestra guía técnica integral de bfcache.
Comentarios
Nos gustaría conocer tus comentarios sobre este cambio, que puedes enviar en el seguimiento de problemas de Chrome con el componente bfcache.
Conclusión
Nos complace llevar los beneficios de bfcache a muchas más páginas para mejorar la experiencia 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 cambios necesarios para evitar problemas cuando esto suceda.