La memoria caché atrás/adelante (o bfcache) es una optimización del navegador que habilita navegación hacia atrás y hacia adelante. Mejora notablemente la experiencia de navegación, especialmente 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 manera que tus usuarios puedan aprovechar los beneficios.
Compatibilidad del navegador
Durante muchos años, bfcache es compatible con Firefox y Safari, en computadoras de escritorio y dispositivos móviles.
A partir de la versión 86, Chrome habilitó la bfcache para navegaciones entre sitios en Android para un pequeño porcentaje de usuarios. En versiones posteriores, se lanzó compatibilidad adicional de forma gradual. A partir de la versión 96, la bfcache está habilitada para todos los usuarios de Chrome en computadoras y dispositivos móviles.
Conceptos básicos de bfcache
bfcache es una caché en memoria que almacena una instantánea completa de una página (incluido el montón de JavaScript) cuando el usuario abandona la página. Con toda la página en la memoria, el navegador puede restablecerla rápidamente si el usuario decide regresar.
¿Cuántas veces has visitado un sitio web e hiciste clic en un vínculo para ir a otra página, solo para darte cuenta de que no es 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 de carga de la página anterior:
| Sin bfcache habilitada | Se inicia una solicitud nueva para cargar la página anterior y, según qué tan bien se haya optimizado esa página para visitas repetidas, es posible que el navegador tenga que volver a descargar, analizar y ejecutar algunos (o todos) los recursos que acaba de descargar. |
| Con la bfcache habilitada | La carga de la página anterior es fundamentalmente instantánea, porque toda la página se puede restablecer desde la memoria, sin tener que ir a la red en absoluto. |
Mira este video de bfcache en acción para comprender la velocidad de navegación que puede implicar:
En el video, el ejemplo con bfcache es bastante más rápido que el ejemplo sin él.
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 de escritorio y 1 de cada 5 en dispositivos móviles están hacia atrás o adelante. Con bfcache habilitada, los navegadores pueden eliminar la transferencia de datos y el tiempo dedicado a cargar miles de millones de páginas web todos los días.
La manera en que la caché funciona
La caché que usa bfcache es diferente de la caché HTTP, que cumple su propio rol en la aceleración de las navegaciones repetidas. bfcache es una instantánea de toda la página en la memoria, incluido el montón de JavaScript, mientras que la caché HTTP contiene solo las respuestas para solicitudes realizadas previamente. Dado que es muy poco frecuente que todas las solicitudes necesarias para cargar una página se completen desde la caché HTTP, las visitas repetidas con restablecimientos de bfcache son siempre más rápidas que incluso las navegaciones sin bfcache más optimizadas.
Sin embargo, crear una instantánea de una página en la memoria implica cierta complejidad en términos de la mejor manera de preservar el código en progreso. Por ejemplo, ¿cómo controlas las llamadas 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 los cronómetros pendientes o las promesas sin resolver para las páginas en la bfcache, incluidas casi todas las tareas pendientes en las listas de tareas en cola de JavaScript, y reanudan las tareas de procesamiento si la página se restablece desde la bfcache.
En algunos casos, como los tiempos de espera y las promesas, esto es un riesgo bastante bajo, pero en otros puede llevar a un comportamiento confuso o inesperado. Por ejemplo, si el navegador detiene una tarea que se requiere como parte de una IndexedDB transacción, esta podría afectar a otras pestañas abiertas del mismo origen, ya que varias pestañas pueden acceder a las mismas bases de datos de IndexedDB en simultáneo. Como resultado, los navegadores no suelen intentar almacenar páginas en caché en medio de una transacción de IndexedDB o mientras usan APIs que puedan afectar otras páginas.
Para obtener más detalles sobre cómo varios usos de la API afectan la elegibilidad de bfcache de una página, consulta Cómo optimizar tus páginas para la bfcache.
Los iframes y la bfcache
Si una página contiene iframes incorporados, estos no son aptos para la bfcache. Por ejemplo, si navegas a otra página dentro de un iframe, pero luego regresas, el navegador hará lo mismo. dentro del iframe en lugar de en el marco principal, pero la navegación hacia atrás dentro del iframe no usará la bfcache.
También se puede bloquear el marco principal para que no use la bfcache si un iframe incorporado usa APIs que lo bloqueen. Para evitar esto, puedes usar la Política de Permisos establecida en el marco principal o el uso de atributos sandbox.
La bfcache y las apps de una sola página (SPA)
Debido a que bfcache es compatible con las navegaciones administradas por el navegador, no funciona para las "navegaciones en segundo plano". dentro de una aplicación de una sola página (SPA). Sin embargo, la bfcache aún puede ser útil cuando se vuelve a una SPA, en lugar de volver a inicializar por completo esa app desde el principio.
APIs para observar bfcache
Si bien la bfcache es una optimización que los navegadores realizan automáticamente, es importante que los desarrolladores sepan cuándo sucede para poder optimizar sus páginas en función de 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 de 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, y en otras situaciones, por ejemplo, cuando una pestaña en segundo plano se inmoviliza 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 bfcache
Cuando la página se carga por primera vez 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 bfcache y false en caso contrario. Puedes usar la propiedad persisted para distinguir las cargas de página normales de 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 navegadores compatibles con 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 inmovilizada. Si quieres actualizar el estado de una página después de que se inmoviliza (lo que incluye las páginas de la bfcache), puedes usar el evento resume, pero si deseas medir la tasa de aciertos de bfcache de tu sitio, debes usar el evento pageshow. En algunos casos, es posible que debas usar ambos.
Para obtener detalles sobre las prácticas recomendadas de medición de bfcache, consulta Cómo afecta la bfcache a las estadísticas y la medición de rendimiento.
Observa cuando una página ingresa a 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 estar seguro de que esa página no está a punto de ingresar a la bfcache. Sin embargo, el hecho de que persisted sea true no garantiza que una página se almacene en caché. Significa que el navegador desea almacenar la página en caché, pero puede haber otros factores que la 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 desea almacenar la página en caché. Es posible que, de todos modos, deba descartarlo por varias razones que se explicarán más adelante.
Optimiza tus páginas para la bfcache
No todas las páginas se almacenan en la bfcache y, incluso si una página se almacena allí, no permanece allí indefinidamente. Es fundamental que los desarrolladores comprendan qué factores hacen que las páginas sean aptas (y no aptas) para la bfcache. De esta manera, se maximizarán 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 lo más probable posible.
Nunca usar 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 la bfcache, y muchas páginas de Internet funcionan bajo la suposición (razonable) de que una página no seguirá existiendo después de que se active el evento unload. Esto presenta un desafío, ya que muchas de esas páginas también se crearon con el supuesto de que el evento unload se activaría cada vez que un usuario salga de la página, lo cual ya no es cierto (y no hace mucho que no sucede).
Por lo tanto, los navegadores se enfrentan a un dilema: tienen que elegir entre algo que pueda mejorar la experiencia del usuario, pero que también pueda correr el riesgo de 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. Sin embargo, para reducir las posibles fallas, no ejecutará el evento unload cuando un usuario salga de ella, 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 fallas es menor debido a que el evento unload siempre ha sido muy poco confiable en dispositivos móviles. Firefox trata las páginas que usan unload como no aptas para la bfcache, excepto en iOS, que requiere que todos los navegadores usen el motor de renderización de WebKit y, por lo tanto, se comporta como Safari.
En lugar de usar el evento unload, utiliza 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 la poca confiabilidad y el impacto en el rendimiento de la bfcache, Chrome está intentando 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 utilizan controladores de eventos unload pueden asegurarse de que no se agreguen mediante una Política de Permisos.
Permission-Policy: unload=()
Esto también evita que terceros o extensiones ralenticen el sitio, ya que agregan controladores de descarga y hacen que el sitio no sea apto para la bfcache.
Solo agrega objetos de escucha beforeunload de forma condicional
El evento beforeunload no hará que tus páginas sean aptas para la bfcache de los navegadores modernos; sin embargo, antes sí lo hacía y, aun así, no es confiable, por lo que debes evitar su uso a menos que sea absolutamente necesario.
Sin embargo, a diferencia del evento unload, hay usos legítimos de
beforeunload Por ejemplo, cuando quieres advertir al usuario que tiene
los cambios no guardados que se perderán si salen de la página. En este caso, es
se recomendó que solo agregaras objetos de escucha beforeunload cuando un usuario no haya guardado
los cambios y, luego, quitarlos inmediatamente después de guardar los cambios no guardados.
window.addEventListener('beforeunload', (event) => {
if (pageHasUnsavedChanges()) {
event.preventDefault();
return event.returnValue = 'Are you sure you want to exit?';
}
});
Este código agrega un objeto de escucha beforeunload de forma incondicional.
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);
});
Este código solo agrega el objeto de escucha beforeunload cuando es necesario (y
y la quita cuando no lo está).
Minimizar el uso de Cache-Control: no-store
Cache-Control: no-store es un encabezado HTTP que los servidores web pueden configurar en respuestas que indican al navegador que no debe almacenar la respuesta en ninguna caché HTTP. Se usa para los recursos que contienen información sensible del usuario, como las páginas con acceso protegido.
Aunque la bfcache no es una caché HTTP, históricamente, cuando Cache-Control: no-store se configuraba en el recurso de página en sí (en lugar de cualquier subrecurso), los navegadores optan por no almacenar la página en la bfcache. Estamos trabajando para cambiar este comportamiento en Chrome de una manera que preserve la privacidad, pero, por el momento, las páginas que usen Cache-Control: no-store no serán aptas para la bfcache.
Dado que Cache-Control: no-store restringe la elegibilidad de una página para bfcache, solo se debe configurar en páginas que contengan información sensible en las que no sea apropiado almacenar en caché de ningún tipo.
En el caso de las páginas que deben mostrar siempre contenido actualizado y que no incluya información sensible, usa Cache-Control: no-cache o Cache-Control: max-age=0. Estas directivas le indican al navegador que revalide el contenido antes de entregarlo, y no afectan la elegibilidad de bfcache de una página.
Ten en cuenta que cuando una página se restablece desde la bfcache, se restablece desde la memoria, no desde la caché HTTP. Por lo tanto, no se tienen en cuenta 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 brinde una mejor experiencia del usuario, ya que los restablecimientos de bfcache son instantáneos y, como las páginas no permanecen en la bfcache por mucho tiempo, es poco probable que el contenido esté desactualizado. Sin embargo, si tu contenido cambia minuto a minuto, puedes recuperar cualquier actualización con el evento pageshow, como se describe en la siguiente sección.
Actualiza datos inactivos o sensibles después de restablecer la bfcache
Si tu sitio mantiene el estado del usuario (especialmente cualquier información sensible del usuario), esos datos se deben actualizar o borrar 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 compras 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 inactiva desde la bfcache.
Otro ejemplo más crítico es cuando un usuario sale de 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 los datos privados que el usuario asumió que se borraron cuando salió de su cuenta.
Para evitar situaciones como esta, te recomendamos que siempre actualices 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, idealmente, actualizarías el contenido, para algunos cambios, es posible que debas forzar una recarga completa. El siguiente código verifica la presencia de una cookie específica del sitio en el evento pageshow y se vuelve a cargar 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 seguirá preservando el historial (para permitir las navegaciones hacia adelante), pero un redireccionamiento puede ser más apropiado en algunos casos.
Restablecimiento de anuncios y bfcache
Puede ser tentador intentar evitar el uso de bfcache para publicar un nuevo conjunto de anuncios en cada navegación hacia atrás/adelante. Sin embargo, además de tener un impacto en el rendimiento, es cuestionable si ese comportamiento genera una mejor participación con el anuncio. Es posible que los usuarios hayan notado un anuncio que querían volver para hacer clic, pero no podrán hacerlo si lo vuelven a cargar en lugar de restablecerlo desde la bfcache. Probar esta situación, idealmente con una prueba A/B, es importante antes de hacer suposiciones.
En el caso de los sitios que sí desean actualizar los anuncios con el restablecimiento de 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í hay un ejemplo de cómo hacerlo con la etiqueta de Google Publishing.
Evita las referencias window.opener
En navegadores más antiguos, si una página se abre con window.open() desde un vínculo con target=_blank, sin especificar rel="noopener", la página que se abre 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 cualquier página que intente acceder a ella.
Por lo tanto, lo mejor es evitar crear referencias a window.opener. Puedes hacerlo con rel="noopener" siempre que sea posible (ten en cuenta que ahora es la opción predeterminada 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 window, ni la ventana abierta ni el abridor serán aptos para la bfcache.
Cierra las conexiones abiertas antes de que el usuario abandone la navegación.
Como se mencionó anteriormente, cuando se coloca una página en la bfcache, se pausan todas las tareas de JavaScript programadas y se reanudan cuando la página se quita de la caché.
Si estas tareas programadas de JavaScript solo acceden a las APIs del DOM (o a otras APIs aisladas solo de la página actual), detener estas tareas mientras la página no sea visible para el usuario no provocará 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, 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 que tienen una conexión IndexedDB abierta
- Páginas con fetch() o XMLHttpRequest en curso
- Páginas con una conexión abierta de WebSocket o WebRTC
Si tu página usa alguna de estas APIs, te recomendamos que cierres las conexiones y que quites o desconectes observadores durante el evento pagehide o freeze. De esta manera, el navegador puede almacenar la página en caché de forma segura sin el riesgo de afectar otras pestañas abiertas.
Luego, si se restablece la página desde la bfcache, puedes volver a abrir esas APIs o volver a conectarte a ellas durante el evento pageshow o resume.
En el siguiente ejemplo, se muestra cómo cerrar una conexión abierta en el objeto de escucha de eventos pagehide para garantizar que las páginas que usan IndexedDB sean aptas para la bfcache:
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());
Realiza pruebas para asegurarte de que tus páginas puedan almacenarse en caché
Las Herramientas para desarrolladores de Chrome pueden ayudarte a probar tus páginas para asegurarte de que estén optimizadas para la bfcache y detectar cualquier problema que podría impedir que sean aptas.
Para probar una página, haz lo siguiente:
- Navega a la página en Chrome.
- En Herramientas para desarrolladores, ve a Aplicación -> Memoria caché atrás/adelante
- Haz clic en el botón Ejecutar prueba. Herramientas para desarrolladores intenta navegar hacia atrás y hacia adelante para determinar si la página se puede restablecer desde la bfcache.
Si la prueba se realiza correctamente, el panel mostrará el mensaje "Se restableció de la memoria caché atrás/adelante".
Si no tiene éxito, el panel indica el motivo. Si puedes abordar el motivo como desarrollador, el panel lo marcará como Practicidad.
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 ese 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 los documentos 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 vistas de página informadas, ya que Chrome habilita la bfcache para más usuarios.
De hecho, es probable que ya no registres las vistas de página de otros navegadores que implementan bfcache, ya que muchas bibliotecas de estadísticas populares no miden los restablecimientos de bfcache como nuevas vistas de página.
Si quieres incluir restablecimientos de bfcache en tu 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');
}
});
Mide la tasa de aciertos de tu bfcache
También puedes medir si se usó la bfcache para identificar páginas que no la usan. Para ello, se puede medir el tipo de navegación para las cargas de página:
// 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 la tasa de aciertos de tu bfcache con los recuentos de navegaciones de back_forward y back_forward_cache.
Es importante tener en cuenta que existen varias situaciones, fuera del control de los propietarios del sitio, en las que la navegación hacia atrás/adelante no usa la bfcache. Por ejemplo:
- 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, es posible que algunos navegadores conserven el tipo de navegación original y, por lo tanto, es posible que se muestre un tipo de back_forward a pesar de que no sean navegaciones hacia atrás/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 una tasa de aciertos de bfcache del 100% 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 propia página impide que se use la bfcache para una gran 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 las 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 bfcache, incluso sin medirla por tu cuenta.
Medición del rendimiento
La bfcache también puede afectar negativamente las métricas de rendimiento recopiladas en el campo, específicamente las métricas que miden los tiempos de carga de la página.
Dado que las navegaciones mediante bfcache, restablecen una página existente en lugar de iniciar una nueva carga de página, por lo que la cantidad total de cargas de páginas recopiladas disminuirá cuando se habilite bfcache. Sin embargo, lo fundamental es que las cargas de la página que se reemplazan por restablecimientos de bfcache probablemente hayan sido algunas de las cargas de páginas más rápidas de tu conjunto de datos. Esto se debe a que las navegaciones hacia delante y hacia atrás, por definición, son visitas repetidas, y las cargas repetidas de páginas suelen ser más rápidas que las cargas de páginas de visitantes nuevos (debido al almacenamiento en caché de HTTP, como se mencionó anteriormente).
Como resultado, obtendrás menos cargas de páginas rápidas en tu conjunto de datos, lo que probablemente sesgará la distribución más lentamente, a pesar de que el rendimiento del usuario probablemente haya mejorado.
Existen varias formas de solucionar este problema. Una es anotar todas las métricas de carga de página con su tipo de navegación respectivo: 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 es negativa. Recomendamos este enfoque para métricas de carga de página no centradas en el usuario, como el tiempo hasta el primer byte (TTFB).
En el caso de las métricas centradas en los usuarios, como las Métricas web esenciales, una mejor opción es informar un valor que represente de forma más precisa lo que experimenta el usuario.
Impacto en las Métricas web esenciales
Las Métricas web esenciales miden la experiencia del usuario de una página web en una variedad de dimensiones (velocidad de carga, interactividad y estabilidad visual). Como los usuarios experimentan restablecimientos de la bfcache como navegaciones más rápidas que cuando se carga la página completa, es importante que las métricas de las Métricas web esenciales reflejen esta información. Después de todo, al usuario no le importa si se habilitó bfcache, solo le interesa que la navegación sea rápida.
Las herramientas que recopilan métricas web esenciales y también informan sobre ellas, como el Informe sobre la experiencia del usuario en Chrome, tratan los restablecimientos de la bfcache como visitas a páginas separadas en su conjunto de datos. Además, si bien no hay APIs de rendimiento web dedicadas para medir estas métricas después de restablecer la bfcache, puedes usar las APIs web existentes para aproximar sus valores:
- Para el Procesamiento de imagen con contenido más grande (LCP), usa el delta entre la marca de tiempo del evento
pageshowy la marca de tiempo del siguiente fotograma pintado, ya que todos los elementos del fotograma se pintarán al mismo tiempo. En el caso de un restablecimiento de bfcache, el LCP y el FCP son los mismos. - En Interaction to Next Paint (INP), sigue usando tu Performance Observer existente, pero restablece el valor de INP actual a 0.
- Para el Cambio de diseño acumulado (CLS), sigue usando el Performance Observer existente, pero restablece el valor de CLS actual a 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 las Métricas web esenciales. Para ver un ejemplo específico de cómo implementar versiones bfcache de estas métricas, consulta el artículo PR que las agrega a la biblioteca web-vitals JS.
La biblioteca JavaScript web-vitals admite restablecimientos de bfcache en las métricas que informa.
Recursos adicionales
- Almacenamiento en caché de Firefox (bfcache en Firefox)
- Caché de la página (bfcache en Safari)
- Memoria caché atrás/adelante: comportamiento expuesto en la Web (diferencias en la bfcache entre navegadores)
- Verificador de bfcache (prueba cómo las diferentes APIs y eventos afectan la bfcache en navegadores)
- Cambio de juego de rendimiento: Memoria caché atrás/adelante del navegador (un caso de éxito de Smashing Magazine en el que se muestran mejoras espectaculares en las Métricas web esenciales cuando se habilita bfcache)