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 páginas que contienen datos sensibles (por ejemplo, para páginas en las que un usuario accedió), pero a menudo se usa la directiva no-store en páginas que no tienen 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 la especificación HTML no lo exige, los navegadores suelen tomar Cache-Control: no-store como indicador para evitar colocar la página en bfcache. Este es el motivo principal por el que no se usa bfcache, en aproximadamente el 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 está cambiando Chrome este comportamiento
Chrome anunció su intención de cambiar este comportamiento, pero toma un enfoque cauteloso para solucionarlo. Hemos estado ejecutando experimentos desde Chrome 116 y, hasta hace poco, se ejecutaban en el 5% de las cargas de página.
Aumentamos este porcentaje al 10% de las cargas de páginas el 2 de octubre y tenemos la intención de aumentarlo más al 20% de las cargas de páginas en noviembre, 50% a principios del próximo año. Lanzaremos esta cifra poco después, con algunas opciones de inhabilitación 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 se deben colocar en ella. 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 evitan el uso de bfcache, sino las APIs que bloquean la bfcache en páginas Cache-Control: no-store, incluso si no se usan al 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 en páginas de 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 esta marca y sin ella.
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. Te recomendamos que las 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 actualizaciones al restablecer la página
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 es posible que los usuarios prefieran "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
De manera similar al impacto de las estadísticas, los sitios pueden ver una reducción en las impresiones de anuncios si estos solo se cargan durante la carga de 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 completa sobre 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 incorporar el beneficio de la bfcache en muchas más páginas para mejorar la experiencia de página para 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 realizar las modificaciones necesarias para evitar problemas cuando esto ocurra.