Memoria caché atrás/adelante

Philip Walton

Barry Pollard

La memoria caché atrás/adelante (o bfcache) es una optimización del navegador que permite la navegación instantánea hacia atrás y hacia adelante. Mejora significativamente la experiencia de navegación, en especial para los usuarios con redes o dispositivos más lentos.

Como desarrolladores web, es fundamental comprender cómo optimizar tus páginas para la bfcache, de modo que los usuarios puedan aprovechar sus beneficios.

Compatibilidad del navegador

Todos los navegadores principales incluyen una bfcache, como Chrome desde la versión 96, Firefox y Safari.

Conceptos básicos de bfcache

Con la memoria caché atrás/adelante (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.

¿Cuántas veces visitaste un sitio web y hiciste clic en un vínculo para ir a otra página, solo para darte cuenta de que no era lo que querías y hacer clic en el botón Atrás? En ese momento, la bfcache puede marcar una gran diferencia en la velocidad con la que se carga la página anterior:

Mira este video de la bfcache en acción para comprender la aceleración que puede aportar a las navegaciones:

En el video, el ejemplo con bfcache es bastante más rápido que el ejemplo sin él.

La bfcache no solo acelera la navegación, sino que también reduce el uso de datos, ya que no es necesario volver a descargar los recursos.

Los datos de uso de Chrome muestran que 1 de cada 10 navegaciones en computadoras y 1 de cada 5 en dispositivos móviles son hacia atrás o hacia adelante. Con bfcache habilitada, los navegadores podrían eliminar la transferencia de datos y el tiempo de carga de miles de millones de páginas web todos los días.

Cómo funciona la "caché"

La "caché" que usa bfcache es diferente de la caché HTTP, que cumple su propia función para acelerar las navegaciones repetidas. La bfcache es una instantánea de toda la página en la memoria, incluido el montón de JavaScript, mientras que la caché HTTP solo contiene las respuestas a las solicitudes realizadas anteriormente. Dado que es muy raro que todas las solicitudes necesarias para cargar una página se cumplan desde la caché HTTP, las visitas repetidas que usan la caché de atrás y adelante siempre son más rápidas que incluso las navegaciones sin caché de atrás y adelante mejor optimizadas.

Congelar una página para volver a habilitarla más adelante implica cierta complejidad en cuanto a la mejor manera de conservar el código en curso. Por ejemplo, ¿cómo controlas las llamadas a setTimeout() en las que se alcanza el tiempo de espera mientras la página está en la bfcache?

La respuesta es que los navegadores pausan cualquier temporizador pendiente o promesa no resuelta para las páginas en la bfcache, incluidas casi todas las tareas pendientes en las colas de tareas de JavaScript, y reanudan el procesamiento de tareas si la página se restablece desde la bfcache.

En algunos casos, como los tiempos de espera y las promesas, el riesgo es bastante bajo, pero en otros casos puede generar un comportamiento confuso o inesperado. Por ejemplo, si el navegador pausa una tarea que se requiere como parte de una transacción de IndexedDB, puede afectar a otras pestañas abiertas en el mismo origen, ya que se puede acceder a las mismas bases de datos de IndexedDB desde varias pestañas de forma simultánea. Como resultado, los navegadores generalmente no intentarán almacenar en caché las páginas en medio de una transacción de IndexedDB o mientras se usan APIs que podrían afectar otras páginas.

Para obtener más detalles sobre cómo el uso de varias APIs afecta la elegibilidad de una página para la bfcache, consulta Cómo optimizar tus páginas para la bfcache.

La bfcache y los iframes

Si una página contiene iframes incorporados, estos no son aptos para la bfcache por separado. Por ejemplo, si navegas a otra URL dentro de un iframe, el contenido anterior no ingresa en la bfcache y, si vuelves atrás, el navegador volverá atrás dentro del iframe en lugar de en el marco principal, pero la navegación hacia atrás dentro del iframe no usará la bfcache.

Sin embargo, cuando el marco principal se restablece desde la bfcache, los iframe incorporados se restablecerán tal como estaban cuando la página ingresó en la bfcache.

También se puede bloquear el uso de la bfcache en el marco principal si un iframe incorporado usa APIs que bloquean esta función. Para evitar esto, se puede usar la Política de permisos establecida en el marco principal o el uso de atributos sandbox.

La bfcache y las aplicaciones de una sola página (SPA)

Debido a que bfcache funciona con navegaciones administradas por el navegador, no funciona para las "navegaciones suaves" dentro de una aplicación de una sola página (SPA). Sin embargo, la bfcache aún puede ayudar cuando vuelves a una SPA en lugar de volver a inicializar esa app por completo desde el principio.

APIs para observar la bfcache

Aunque la bfcache es una optimización que los navegadores realizan automáticamente, sigue siendo importante que los desarrolladores sepan cuándo se produce para que puedan optimizar sus páginas para ella y ajustar las métricas o la medición del rendimiento según corresponda.

Los eventos principales que se usan para observar la bfcache son los eventos de transición de página pageshow y pagehide, que son compatibles con la mayoría de los navegadores.

Los eventos más recientes del ciclo de vida de la página (freeze y resume) también se envían cuando las páginas entran o salen de la bfcache, así como en otras situaciones, por ejemplo, cuando se inmoviliza una pestaña en segundo plano para minimizar el uso de CPU. Estos eventos solo son compatibles con los navegadores basados en Chromium.

Observa cuándo se restablece una página desde la bfcache

Cuando la página se carga inicialmente y cada vez que se restablece la página desde bfcache, se activa inmediatamente el evento pageshow después del evento load. El evento pageshow tiene una propiedad persisted, que es true si la página se restableció desde la bfcache y false en caso contrario. Puedes usar la propiedad persisted para distinguir entre las cargas de página normales y los restablecimientos de bfcache. Por ejemplo:

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    console.log('This page was restored from the bfcache.');
  } else {
    console.log('This page was loaded normally.');
  }
});

En los navegadores que admiten la API de Page Lifecycle, el evento resume se activa cuando se restablecen las páginas desde la bfcache (inmediatamente antes del evento pageshow) y cuando un usuario vuelve a visitar una pestaña en segundo plano inactiva. Si deseas actualizar el estado de una página después de que se inmoviliza (lo que incluye las páginas en la bfcache), puedes usar el evento resume, pero si deseas medir la tasa de aciertos de la bfcache de tu sitio, deberás usar el evento pageshow. En algunos casos, es posible que debas usar ambos.

Para obtener detalles sobre las prácticas recomendadas de medición del bfcache, consulta Cómo afecta el bfcache a las estadísticas y la medición del rendimiento.

Observa cuándo una página ingresa en la bfcache

El evento pagehide se activa cuando se descarga una página o cuando el navegador intenta colocarla en la bfcache.

El evento pagehide también tiene una propiedad persisted. Si es false, puedes tener la certeza de que la página no está a punto de ingresar en la bfcache. Sin embargo, que persisted sea true no garantiza que se almacenará una página en caché. Esto significa que el navegador intenta almacenar en caché la página, pero puede haber otros factores que lo impidan.

window.addEventListener('pagehide', (event) => {
  if (event.persisted) {
    console.log('This page *might* be entering the bfcache.');
  } else {
    console.log('This page will unload normally and be discarded.');
  }
});

Del mismo modo, el evento freeze se activa inmediatamente después del evento pagehide si persisted es true, pero eso solo significa que el navegador pretende almacenar en caché la página. Es posible que, de todas formas, deba descartarlo por varios motivos que se explican más adelante.

Optimiza tus páginas para la bfcache

No todas las páginas se almacenan en la bfcache y, aunque se almacenen, no permanecerán allí de forma indefinida. Es fundamental que los desarrolladores comprendan qué hace que las páginas sean aptas (o no aptas) para la bfcache, de modo que puedan maximizar sus tasas de aciertos de caché.

En las siguientes secciones, se describen las prácticas recomendadas para que el navegador pueda almacenar en caché tus páginas con la mayor probabilidad posible.

Nunca uses el evento unload

La forma más importante de optimizar la bfcache en todos los navegadores es no usar nunca el evento unload. ¡Nunca!

El evento unload es problemático para los navegadores porque es anterior a bfcache y muchas páginas de Internet operan bajo la suposición (razonable) de que una página no seguirá existiendo después de que se active el evento unload. Esto representa un desafío, ya que muchas de esas páginas también se crearon con la suposición de que el evento unload se activaría cada vez que un usuario navegara fuera de la página, lo que ya no es cierto (y no lo ha sido durante mucho tiempo).

Por lo tanto, los navegadores se enfrentan a un dilema: deben elegir entre algo que puede mejorar la experiencia del usuario, pero que también podría romper la página.

En computadoras, Chrome y Firefox decidieron que las páginas no sean aptas para la bfcache si agregan un objeto de escucha unload, lo que es menos riesgoso, pero también descalifica muchas páginas. Safari intentará almacenar en caché algunas páginas con un objeto de escucha de eventos unload, pero, para reducir posibles interrupciones, no ejecutará el evento unload cuando un usuario salga de la página, lo que hace que el evento sea muy poco confiable.

En dispositivos móviles, Chrome y Safari intentarán almacenar en caché las páginas con un objeto de escucha de eventos unload, ya que el riesgo de interrupción es menor debido a que el evento unload siempre fue extremadamente poco confiable en dispositivos móviles. Firefox considera que las páginas que usan unload no son aptas para el almacenamiento en caché atrás/adelante, excepto en iOS, que requiere que todos los navegadores usen el motor de renderización WebKit, por lo que se comporta como Safari.

En lugar de usar el evento unload, usa el evento pagehide. El evento pagehide se activa en todos los casos en los que se activa el evento unload y también se activa cuando una página se coloca en la bfcache.

De hecho, Lighthouse tiene una auditoría de no-unload-listeners que advertirá a los desarrolladores si algún código JavaScript en sus páginas (incluido el de bibliotecas de terceros) agrega un objeto de escucha de eventos unload.

Debido a su falta de confiabilidad y al impacto en el rendimiento de la bfcache, Chrome busca dar de baja el evento unload.

Usa la política de permisos para evitar que se usen controladores de descarga en una página

Los sitios que no usan controladores de eventos de unload pueden asegurarse de que no se agreguen con una política de permisos.

Permissions-Policy: unload=()

Esto también evita que terceros o extensiones ralenticen el sitio agregando controladores de descarga y haciendo que el sitio no sea apto para la bfcache.

Solo agrega objetos de escucha de beforeunload de forma condicional

El evento beforeunload no hará que tus páginas no sean aptas para la bfcache en la bfcache de los navegadores modernos, pero antes sí lo hacía y sigue siendo poco confiable, por lo que debes evitar usarlo a menos que sea absolutamente necesario.

Sin embargo, a diferencia del evento unload, existen usos legítimos para beforeunload. Por ejemplo, cuando quieras advertirle al usuario que tiene cambios no guardados que perderá si abandona la página. En este caso, se recomienda que solo agregues objetos de escucha beforeunload cuando un usuario tenga cambios no guardados y, luego, los quites inmediatamente después de que se guarden los cambios no guardados.

window.addEventListener('beforeunload', (event) => {
  if (pageHasUnsavedChanges()) {
    event.preventDefault();
    return event.returnValue = 'Are you sure you want to exit?';
  }
});

function beforeUnloadListener(event) {
  event.preventDefault();
  return event.returnValue = 'Are you sure you want to exit?';
};

// A function that invokes a callback when the page has unsaved changes.
onPageHasUnsavedChanges(() => {
  window.addEventListener('beforeunload', beforeUnloadListener);
});

// A function that invokes a callback when the page's unsaved changes are resolved.
onAllChangesSaved(() => {
  window.removeEventListener('beforeunload', beforeUnloadListener);
});

Minimiza el uso de Cache-Control: no-store

Cache-Control: no-store es un encabezado HTTP que los servidores web pueden establecer en las respuestas para indicarle al navegador que no almacene la respuesta en ninguna caché HTTP. Se usa para los recursos que contienen información sensible del usuario, como las páginas que requieren acceso.

Si bien la bfcache no es una caché de HTTP, históricamente, cuando se establece Cache-Control: no-store en el recurso de la página en sí (a diferencia de cualquier subrecurso), los navegadores optaron por no almacenar la página en la bfcache, por lo que es posible que las páginas que usan Cache-Control: no-store no sean aptas para la bfcache. Se está trabajando para cambiar este comportamiento en Chrome de una manera que preserve la privacidad.

Dado que Cache-Control: no-store restringe la elegibilidad de una página para la bfcache, solo se debe configurar en las páginas que contienen información sensible en las que el almacenamiento en caché de cualquier tipo nunca es adecuado.

Para las páginas que siempre deben mostrar contenido actualizado y que no contienen información sensible, usa Cache-Control: no-cache o Cache-Control: max-age=0. Estas directivas le indican al navegador que vuelva a validar el contenido antes de publicarlo y no afectan la elegibilidad de una página para la bfcache.

Ten en cuenta que, cuando se restablece una página desde la bfcache, se restablece desde la memoria, no desde la caché HTTP. Como resultado, no se tienen en cuenta las directivas como Cache-Control: no-cache o Cache-Control: max-age=0, y no se realiza ninguna revalidación antes de que se muestre el contenido al usuario.

Sin embargo, es probable que esto siga siendo una mejor experiencia del usuario, ya que las restauraciones de la bfcache son instantáneas y, como las páginas no permanecen en la bfcache durante mucho tiempo, es poco probable que el contenido esté desactualizado. Sin embargo, si tu contenido cambia minuto a minuto, puedes recuperar las actualizaciones con el evento pageshow, como se describe en la siguiente sección.

Actualiza los datos inactivos o sensibles después de la restauración de la bfcache

Si tu sitio mantiene el estado del usuario, en especial cualquier información sensible del usuario, esos datos deben actualizarse o borrarse después de que se restablece una página desde la bfcache.

Por ejemplo, si un usuario navega a una página de confirmación de compra y, luego, actualiza su carrito de compras, la navegación hacia atrás podría exponer información desactualizada si se restablece una página obsoleta desde la bfcache.

Otro ejemplo más crítico es si un usuario cierra la sesión de un sitio en una computadora pública y el siguiente usuario hace clic en el botón Atrás. Esto podría exponer datos privados que el usuario suponía que se habían borrado cuando cerró la sesión.

Para evitar situaciones como esta, es recomendable actualizar siempre la página después de un evento pageshow si event.persisted es true:

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    // Do any checks and updates to the page
  }
});

Si bien lo ideal sería actualizar el contenido en su lugar, es posible que, para algunos cambios, desees forzar una recarga completa. El siguiente código verifica la presencia de una cookie específica del sitio en el evento pageshow y vuelve a cargar la página si no se encuentra la cookie:

window.addEventListener('pageshow', (event) => {
  if (event.persisted && !document.cookie.match(/my-cookie)) {
    // Force a reload if the user has logged out.
    location.reload();
  }
});

Una recarga tiene la ventaja de que conservará el historial (para permitir la navegación hacia adelante), pero un redireccionamiento puede ser más adecuado en algunos casos.

Anuncios y restablecimiento de la bfcache

Puede ser tentador intentar evitar el uso de bfcache para publicar un nuevo conjunto de anuncios en cada navegación hacia atrás o hacia adelante. Sin embargo, además de tener un impacto en el rendimiento, es cuestionable si este comportamiento genera una mejor participación en los anuncios. Es posible que los usuarios hayan visto un anuncio en el que querían hacer clic más tarde, pero, si lo recargan en lugar de restablecerlo desde la bfcache, no podrán hacerlo. Es importante probar esta situación, idealmente con una prueba A/B, antes de hacer suposiciones.

En el caso de los sitios que desean actualizar los anuncios cuando se restablece bfcache, actualizar solo los anuncios en el evento pageshow cuando event.persisted es true permite que esto suceda sin afectar el rendimiento de la página. Consulta con tu proveedor de anuncios, pero aquí tienes un ejemplo de cómo hacerlo con la etiqueta Google Publisher Tag.

Evita las referencias de window.opener

En navegadores más antiguos, si una página se abría con window.open() desde un vínculo con target=_blank, sin especificar rel="noopener", la página de apertura tendría una referencia al objeto de ventana de la página abierta.

Además de ser un riesgo de seguridad, una página con una referencia window.opener no nula no se puede colocar de forma segura en la bfcache, ya que eso podría dañar las páginas que intenten acceder a ella.

Por lo tanto, es mejor evitar la creación de referencias window.opener. Puedes hacerlo usando rel="noopener" siempre que sea posible (ten en cuenta que ahora es el valor predeterminado en todos los navegadores modernos). Si tu sitio requiere abrir una ventana y controlarla a través de window.postMessage() o hacer referencia directamente al objeto de la ventana, ni la ventana abierta ni el elemento que la abrió serán aptos para la bfcache.

Cierra las conexiones abiertas antes de que el usuario navegue a otra página

Como se mencionó anteriormente, cuando una página se mantiene en la bfcache, se pausan todas las tareas de JavaScript programadas y se reanudan cuando se quita la página de la caché.

Si estas tareas de JavaScript programadas solo acceden a las APIs del DOM (o a otras APIs aisladas solo para la página actual), pausar estas tareas mientras la página no está visible para el usuario no causará ningún problema.

Sin embargo, si estas tareas están conectadas a APIs a las que también se puede acceder desde otras páginas del mismo origen (por ejemplo, IndexedDB, Web Locks y WebSockets), esto puede ser problemático, ya que pausar estas tareas puede impedir que se ejecute el código en otras pestañas.

Como resultado, algunos navegadores no intentarán colocar una página en la bfcache en las siguientes situaciones:

• Páginas con una conexión IndexedDB abierta
• Páginas con fetch() o XMLHttpRequest en curso
• Páginas con una conexión WebSocket o WebRTC abierta

Si tu página usa alguna de estas APIs, te recomendamos que cierres las conexiones y quites o desconectes los observadores durante el evento pagehide o freeze. Esto permite que el navegador almacene en caché la página de forma segura sin el riesgo de afectar otras pestañas abiertas.

Luego, si la página se restablece desde la bfcache, puedes volver a abrir o reconectarte a esas APIs durante el evento pageshow o resume.

En el siguiente ejemplo, se muestra cómo garantizar que las páginas que usan IndexedDB sean aptas para la bfcache cerrando una conexión abierta en el objeto de escucha de eventos pagehide:

let dbPromise;
function openDB() {
  if (!dbPromise) {
    dbPromise = new Promise((resolve, reject) => {
      const req = indexedDB.open('my-db', 1);
      req.onupgradeneeded = () => req.result.createObjectStore('keyval');
      req.onerror = () => reject(req.error);
      req.onsuccess = () => resolve(req.result);
    });
  }
  return dbPromise;
}

// Close the connection to the database when the user leaves.
window.addEventListener('pagehide', () => {
  if (dbPromise) {
    dbPromise.then(db => db.close());
    dbPromise = null;
  }
});

// Open the connection when the page is loaded or restored from bfcache.
window.addEventListener('pageshow', () => openDB());

Prueba para asegurarte de que tus páginas se puedan almacenar en caché

Las Herramientas para desarrolladores de Chrome pueden ayudarte a probar tus páginas para garantizar que estén optimizadas para la bfcache y detectar cualquier problema que pueda impedir que sean aptas.

Para probar una página, haz lo siguiente:

1. Navega a la página en Chrome.
2. En Herramientas para desarrolladores, ve a Aplicación -> Caché atrás-adelante.
3. Haz clic en el botón Ejecutar prueba. Luego, las Herramientas para desarrolladores intentan salir de la página y regresar para determinar si esta se puede restablecer desde la bfcache.

Si la prueba se realiza correctamente, el panel mostrará el mensaje "Se restableció desde la Memoria caché atrás/adelante".

De lo contrario, el panel indicará el motivo. Si el motivo es algo que puedes abordar como desarrollador, el panel lo marcará como Actionable.

En este ejemplo, el uso de un objeto de escucha de eventos unload hace que la página no sea apta para la bfcache. Para solucionar este problema, cambia de unload a pagehide:

window.addEventListener('pagehide', ...);

window.addEventListener('unload', ...);

Lighthouse 10.0 también agregó una auditoría de bfcache, que realiza una prueba similar. Para obtener más información, consulta la documentación de la auditoría de bfcache.

Cómo afecta la bfcache a las estadísticas y la medición del rendimiento

Si usas una herramienta de estadísticas para medir las visitas a tu sitio, es posible que notes una disminución en la cantidad total de páginas vistas registradas a medida que Chrome habilite la bfcache para más usuarios.

De hecho, es probable que ya estés subestimando las vistas de página de otros navegadores que implementan la bfcache, ya que muchas bibliotecas de estadísticas populares no miden los restablecimientos de la bfcache como vistas de página nuevas.

Para incluir los restablecimientos de bfcache en el recuento de vistas de página, configura objetos de escucha para el evento pageshow y verifica la propiedad persisted.

En el siguiente ejemplo, se muestra cómo hacerlo con Google Analytics. Es probable que otras herramientas de análisis usen una lógica similar:

// Send a pageview when the page is first loaded.
gtag('event', 'page_view');

window.addEventListener('pageshow', (event) => {
  // Send another pageview if the page is restored from bfcache.
  if (event.persisted) {
    gtag('event', 'page_view');
  }
});

Cómo medir la tasa de aciertos de la bfcache

También puedes medir si se usó la bfcache para identificar las páginas que no la utilizan. Para ello, mide el tipo de navegación para las cargas de páginas:

// Send a navigation_type when the page is first loaded.
gtag('event', 'page_view', {
   'navigation_type': performance.getEntriesByType('navigation')[0].type;
});

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    // Send another pageview if the page is restored from bfcache.
    gtag('event', 'page_view', {
      'navigation_type': 'back_forward_cache';
    });
  }
});

Calcula tu proporción de aciertos de la caché de bfcache con los recuentos de las navegaciones back_forward y back_forward_cache.

Es importante tener en cuenta que hay varios casos, fuera del control de los propietarios del sitio, en los que la navegación hacia atrás o hacia adelante no usará la bfcache, incluidos los siguientes:

• Cuando el usuario cierra el navegador y lo vuelve a iniciar
• Cuando el usuario duplica una pestaña
• Cuando el usuario cierra una pestaña y la vuelve a abrir

En algunos de estos casos, algunos navegadores pueden conservar el tipo de navegación original y, por lo tanto, mostrar un tipo de back_forward a pesar de que no se trate de navegaciones hacia atrás o hacia adelante.

Incluso sin esas exclusiones, la bfcache se descartará después de un período para conservar la memoria.

Por lo tanto, los propietarios de sitios web no deberían esperar un porcentaje de aciertos del 100% en la bfcache para todas las navegaciones de back_forward. Sin embargo, medir su proporción puede ser útil para identificar las páginas en las que la página en sí impide el uso de la bfcache para una alta proporción de navegaciones hacia atrás y hacia adelante.

El equipo de Chrome agregó la API de NotRestoredReasons para ayudar a exponer los motivos por los que las páginas no usan la bfcache, de modo que los desarrolladores puedan mejorar sus tasas de aciertos de la bfcache. El equipo de Chrome también agregó tipos de navegación a CrUX, lo que permite ver la cantidad de navegaciones de la caché de bf incluso sin medirlas por tu cuenta.

Medición del rendimiento

La bfcache también puede afectar de forma negativa las métricas de rendimiento recopiladas en el campo, en especial las métricas que miden los tiempos de carga de la página.

Dado que las navegaciones de bfcache restablecen una página existente en lugar de iniciar una carga de página nueva, la cantidad total de cargas de página recopiladas disminuirá cuando se habilite la bfcache. Sin embargo, lo fundamental es que las cargas de página que se reemplazan por restablecimientos de la bfcache probablemente habrían sido algunas de las cargas de página más rápidas de tu conjunto de datos. Esto se debe a que las navegaciones hacia atrás y hacia adelante, por definición, son visitas repetidas, y las cargas de páginas repetidas suelen ser más rápidas que las cargas de páginas de los visitantes por primera vez (debido al almacenamiento en caché de HTTP, como se mencionó anteriormente).

El resultado es que habrá menos cargas rápidas de páginas en tu conjunto de datos, lo que probablemente sesgará la distribución hacia una velocidad más lenta, a pesar de que es probable que el rendimiento que experimenta el usuario haya mejorado.

Existen algunas formas de solucionar este problema. Una es anotar todas las métricas de carga de la página con su respectivo tipo de navegación: navigate, reload, back_forward o prerender. Esto te permite seguir supervisando tu rendimiento en estos tipos de navegación, incluso si la distribución general se sesga de forma negativa. Recomendamos este enfoque para las métricas de carga de la página que no se centran en el usuario, como el tiempo hasta el primer byte (TTFB).

Para las métricas centradas en el usuario, como las métricas web esenciales, una mejor opción es informar un valor que represente con mayor precisión lo que experimenta el usuario.

Impacto en las Métricas web esenciales

Las Métricas web esenciales miden la experiencia del usuario en una página web en diversas dimensiones (velocidad de carga, interactividad, estabilidad visual), y, dado que los usuarios experimentan las restauraciones de la bfcache como navegaciones más rápidas que las cargas de página completas, es importante que las métricas de Core Web Vitals reflejen esto. Después de todo, a los usuarios no les importa si se habilitó o no la bfcache, solo les importa que la navegación haya sido rápida.

Las herramientas que recopilan y registran las métricas de Core Web Vitals, como el Informe sobre la experiencia del usuario en Chrome, tratan las restauraciones de la bfcache como visitas a páginas separadas en su conjunto de datos. Si bien no hay APIs de rendimiento web dedicadas para medir estas métricas después de que se restablece la bfcache, puedes aproximar sus valores con las APIs web existentes:

• Para el Procesamiento de imagen con contenido más grande (LCP), usa el delta entre la marca de tiempo del evento pageshow y la marca de tiempo del siguiente fotograma renderizado, ya que todos los elementos del fotograma se renderizarán al mismo tiempo. En el caso de un restablecimiento de bfcache, el LCP y el FCP son iguales.
• En el caso de Interaction to Next Paint (INP), sigue usando tu Performance Observer existente, pero restablece el valor actual del INP a 0.
• En el caso del Cambio de diseño acumulado (CLS), sigue usando tu Performance Observer existente, pero restablece el valor actual del CLS en 0.

Para obtener más detalles sobre cómo la bfcache afecta cada métrica, consulta las páginas de guías de métricas individuales de Core Web Vitals. Para ver un ejemplo específico de cómo implementar versiones de bfcache de estas métricas, consulta la solicitud de extracción que las agrega a la biblioteca de JS de web-vitals.

La biblioteca de JavaScript web-vitals admite la restauración de la caché de atrás y adelante en las métricas que informa.

Recursos adicionales

• Almacenamiento en caché de Firefox (bfcache en Firefox)
• Caché de páginas (bfcache en Safari)
• Memoria caché atrás/adelante: Comportamiento expuesto en la Web (Diferencias de la bfcache en los distintos navegadores)
• Probador de bfcache (prueba cómo diferentes APIs y eventos afectan la bfcache en los navegadores)
• Performance Game Changer: Browser Back/Forward Cache (un caso de estudio de Smashing Magazine que muestra mejoras drásticas en las Métricas web principales al habilitar la bfcache)