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, especialmente para los usuarios con redes o dispositivos más lentos.
Como desarrollador web, es fundamental comprender cómo optimizar tus páginas para la bfcache, de modo que tus usuarios puedan cosechar los beneficios.
Compatibilidad del navegador
Durante muchos años, bfcache es compatible con Firefox y Safari, tanto en computadoras de escritorio como en dispositivos móviles.
A partir de la versión 86, Chrome habilitó la bfcache para la navegación entre sitios en Android de un pequeño porcentaje de usuarios. En las versiones posteriores, se lanzó gradualmente compatibilidad adicional. A partir de la versión 96, bfcache está habilitado para todos los usuarios de Chrome en computadoras de escritorio y dispositivos móviles.
Conceptos básicos de bfcache
bfcache es una memoria caché en la que se almacena una instantánea completa de una página (incluido el montón de JavaScript) a medida que el usuario se va. Con toda la página en la memoria, el navegador puede restablecerla rápidamente si el usuario decide regresar.
¿Cuántas veces visitaste un sitio web e hiciste clic en un vínculo para ir a otra página, pero te diste cuenta de que no era lo que querías y hiciste clic en el botón Atrás? En ese momento, bfcache puede marcar una gran diferencia en la velocidad de carga de la página anterior:
| Sin bfcache habilitado | Se inicia una solicitud nueva para cargar la página anterior y, según qué tan bien se haya optimizado esa página para las visitas repetidas, es posible que el navegador deba volver a descargar, analizar y volver a ejecutar algunos (o todos) los recursos que acaba de descargar. |
| Con bfcache habilitado | La carga de la página anterior es básicamente instantánea, ya que se puede restablecer toda la página desde la memoria, sin tener que ir a la red. |
Mira este video de bfcache en acción para comprender la velocidad que puede brindar a las navegaciones:
En el video, el ejemplo con bfcache es bastante más rápido que el que no lo tiene.
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 hacia adelante. Con la bfcache habilitada, los navegadores podían eliminar la transferencia de datos y el tiempo dedicado a cargar miles de millones de páginas web todos los días.
Cómo funciona la "caché"
La "caché" que usa la bfcache es diferente de la caché HTTP, que desempeña su propia función a la hora de acelerar 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 solo contiene las respuestas para solicitudes realizadas anteriormente. Dado que es muy raro 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 que no son de 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 curso. Por ejemplo, ¿cómo manejas las llamadas de 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 no resueltas 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 se restablece la página desde la bfcache.
En algunos casos, como los tiempos de espera y las promesas, esto tiene un riesgo bastante bajo, pero en otros puede generar un comportamiento confuso o inesperado. Por ejemplo, si el navegador pausa una tarea que es necesaria como parte de una transacción de IndexedDB, esto puede afectar otras pestañas abiertas en el mismo origen, ya que múltiples pestañas pueden acceder a las mismas bases de datos de IndexedDB simultáneamente. 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 a otras páginas.
Para obtener más información sobre cómo los distintos usos de la API afectan la elegibilidad de la bfcache de una página, consulta Optimiza tus páginas para la bfcache.
iframes y 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 "atrás" dentro del iframe en lugar del marco principal, pero la navegación hacia atrás dentro del iframe no usará la bfcache.
También es posible que el marco principal no pueda usar la bfcache si un iframe incorporado usa APIs que lo bloquean. Para evitar esto, puedes usar la Política de Permisos establecida en el marco principal o el uso de atributos sandbox.
bfcache y apps de una sola página (SPA)
Debido a que bfcache funciona con navegaciones administradas por el navegador, no funciona para "navegaciones de software" dentro de una app de una sola página (SPA). Sin embargo, la bfcache aún puede ser útil cuando se regresa a una SPA, en lugar de volver a inicializar por completo esa app 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 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 Page Lifecycle (freeze y resume) también se envían cuando las páginas ingresan a la bfcache o salen de ella, y 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 bfcache
Cuando la página se carga inicialmente y cada vez que se restablece la página desde bfcache, se activa el evento pageshow inmediatamente 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áginas 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, se activa el evento resume 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 congelada. Si quieres actualizar el estado de una página después de que se haya inmovilizado (lo que incluye las páginas de la bfcache), puedes usar el evento resume. Sin embargo, si deseas medir la tasa de aciertos de la bfcache de tu sitio, debes usar el evento pageshow. En algunos casos, es posible que debas usar ambos.
Si deseas obtener más información sobre las prácticas recomendadas para la medición de bfcache, consulta Cómo la bfcache afecta las estadísticas y la medición del rendimiento.
Cómo observar cuando una página ingresa a 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 estar seguro de que esa página no está a punto de ingresar a la bfcache. Sin embargo, que persisted sea true, no garantiza que una página se almacenará en caché. Significa que el navegador intends almacenar la página en caché, pero puede haber otros factores que imposibiliten esta operación.
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.');
}
});
De manera similar, el evento freeze se activa inmediatamente después del evento pagehide si persisted es true, pero eso solo significa que el navegador intends almacenar la página en caché. Es posible que aún debas descartarlo por varias razones que se explican más adelante.
Optimiza tus páginas para la bfcache
No todas las páginas se almacenan en la bfcache. Incluso si una página se almacena allí, no permanecerá allí de forma indefinida. Es fundamental que los desarrolladores entiendan qué hace que las páginas sean aptas (y no aptas) para la bfcache y maximizar sus tasas de aciertos de caché.
En las siguientes secciones, se describen las prácticas recomendadas para que sea lo más probable que el navegador pueda almacenar tus páginas en caché.
Nunca usar el evento unload
La forma más importante de optimizar para la bfcache en todos los navegadores es nunca usar el evento unload. ¡Nunca!
El evento unload resulta problemático para los navegadores porque es anterior a la bfcache y muchas páginas de Internet operan bajo la suposición (razonable) de que una página dejará de existir después de que se active el evento unload. Esto presenta un desafío porque muchas de esas páginas también se compilaron con el supuesto de que el evento unload se activaría cada vez que un usuario salga de la página, lo que ya no es así (y no se aplica desde hace mucho tiempo).
Por lo tanto, los navegadores se enfrentan a un dilema: deben elegir entre algo que pueda mejorar la experiencia del usuario, pero también pueden correr el riesgo de dañar 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 fallas, no se 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é 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 fue muy poco confiable en dispositivos móviles. Firefox considera que las páginas que usan unload no son aptas para la bfcache, excepto en iOS, que requiere que todos los navegadores usen el motor de renderización de 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 advierte 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 el impacto en el rendimiento de la bfcache, Chrome planea dar de baja el evento unload.
Utiliza la política de permisos para evitar que se utilicen controladores de descarga en una página
Los sitios que no usan controladores de eventos unload pueden asegurarse de que no se agreguen mediante una Política de Permisos de Chrome 115.
Permission-Policy: unload()
Esto también evita que terceros o extensiones reduzcan la velocidad del sitio agregando controladores de descarga y haciendo que el sitio no sea apto para la bfcache.
Solo agregar objetos de escucha de beforeunload de manera condicional
El evento beforeunload no hará que tus páginas no sean aptas para la bfcache en la bfcache de los navegadores modernos, aunque antes sí lo hacía y sigue siendo poco confiable, por lo que debes evitar usarla a menos que sea absolutamente necesario.
Sin embargo, a diferencia del evento unload, beforeunload existen usos legítimos. Por ejemplo, si deseas advertir al usuario que tiene cambios sin guardar, los perderás si abandona la página. En este caso, se
recomienda que solo agregues objetos de escucha beforeunload cuando un usuario tenga cambios sin guardar
y que los quites inmediatamente después de que se guarden esos cambios.
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 lo quita cuando no lo es).
Minimizar el uso de Cache-Control: no-store
Cache-Control: no-store es un encabezado HTTP que los servidores web pueden configurar en las respuestas para indicarle al navegador que no almacene la respuesta en ninguna caché HTTP. Se usa para recursos que contienen información sensible del usuario, como páginas que requieren acceso.
Aunque la bfcache no es una caché HTTP, históricamente, cuando Cache-Control: no-store se configura en el recurso de la página (a diferencia de cualquier subrecurso), los navegadores eligieron no almacenar la página en bfcache. Se está trabajando para cambiar este comportamiento en Chrome de una manera que preserve la privacidad. Sin embargo, por el momento, las páginas que usan 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 la bfcache, solo se debe configurar en páginas que contienen información sensible en las que nunca es apropiado almacenar en caché de cualquier tipo.
En el caso de las páginas que necesitan mostrar siempre contenido actualizado y que no incluye información sensible, usa Cache-Control: no-cache o Cache-Control: max-age=0. Estas directivas indican al navegador que vuelva a validar el contenido antes de publicarlo y no afectan la elegibilidad de la bfcache de una página.
Ten en cuenta que, cuando se restablece una página desde la bfcache, se hace desde la memoria y no desde la caché HTTP. Como resultado, no se tienen en cuenta directivas como Cache-Control: no-cache o Cache-Control: max-age=0 y no se produce ninguna revalidación antes de que se muestre el contenido al usuario.
Es probable que esto ofrezca una mejor experiencia del usuario. Sin embargo, ya que los restablecimientos de bfcache son instantáneos 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 cualquier actualización con el evento pageshow, como se describe en la siguiente sección.
Actualiza los datos inactivos o sensibles después del restablecimiento de la bfcache
Si tu sitio mantiene el estado del usuario (especialmente si se trata de información sensible del usuario), esos datos deberán actualizarse o borrarse después de que una página se restablezca 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, una navegación hacia atrás podría mostrar 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 su cuenta en 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 supuso que se borraron cuando salió de la cuenta.
Para evitar situaciones como esta, es bueno 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 el lugar, para algunos cambios, es posible que desees 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 conservará el historial (para permitir las navegaciones futuras), pero un redireccionamiento puede ser más adecuado 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 dicho comportamiento conduce a una mejor participación del anuncio. Es posible que los usuarios hayan notado un anuncio que querían volver para hacer clic, pero que no puedan volver a cargarlo 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 desean actualizar anuncios en la 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 este es un ejemplo de cómo hacerlo con Google Publishing Tag.
Evita las referencias window.opener
En navegadores anteriores, 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 cualquier página que intente acceder a ella.
Por lo tanto, te recomendamos que evites crear referencias window.opener. Para hacerlo, usa 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 con window.postMessage() o hacer referencia directamente al objeto de la ventana, ni la ventana abierta ni el dispositivo de apertura serán aptos para la bfcache.
Cerrar las conexiones abiertas antes de que el usuario salga
Como se mencionó anteriormente, cuando una página se coloca en la bfcache, se pausan todas las tareas programadas de JavaScript y se reanudan cuando se quita la página de la caché.
Si estas tareas de JavaScript programadas solo acceden a APIs de DOM, u otras APIs aisladas solo de la página actual, pausar estas tareas mientras la página no sea 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 en el 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 los siguientes casos:
- Páginas con una conexión IndexedDB abierta
- Páginas con fetch() o XMLHttpRequest en progreso
- Páginas con una conexión WebSocket o WebRTC abierta
Si tu página usa alguna de estas APIs, te recomendamos cerrar las conexiones y quitar o desconectar observadores durante el evento pagehide o freeze. Esto permite que el navegador almacene la página en caché 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 volver a conectar a esas APIs 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 asegurarte de 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 se puedan almacenar 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 a identificar cualquier problema que pueda 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 Run Test. Herramientas para desarrolladores intenta navegar a la página anterior y viceversa para determinar si se puede restablecer la página desde la bfcache.
Si la prueba se realiza correctamente, el panel mostrará el mensaje "Se restableció de 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 Práctico.
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. Si deseas obtener más información, consulta los documentos de la auditoría de bfcache.
Cómo la bfcache afecta las estadísticas y la medición del rendimiento
Si utilizas 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 registradas, ya que Chrome habilita la bfcache para más usuarios.
De hecho, es probable que ya no informes las vistas de página desde otros navegadores que implementan la bfcache, ya que muchas bibliotecas de estadísticas populares no miden los restablecimientos de bfcache como nuevas vistas de página.
Para incluir restablecimientos de bfcache en el recuento de páginas vistas, 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 utilicen 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 la bfcache
Es posible que también quieras medir si se usó la bfcache para identificar las páginas que no usan la bfcache. Para ello, se debe medir el tipo de navegación de 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 la tasa de aciertos de la bfcache con los recuentos de navegaciones de back_forward y de back_forward_cache.
Es importante tener en cuenta que hay varias situaciones, fuera del control de los propietarios del sitio, en las que una 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, puede mostrar un tipo de back_forward a pesar de que no sean navegaciones hacia atrás y 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 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 páginas en las que la página en sí impide el uso de 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 bfcache. Los desarrolladores pueden mejorar sus tasas de aciertos de bfcache. El equipo de Chrome también agregó tipos de navegación a CrUX, lo que permite ver la cantidad de navegaciones en bfcache, incluso sin medirla por su cuenta.
Medición del rendimiento
La bfcache también puede afectar de forma negativa las métricas de rendimiento que se recopilan en el campo, específicamente, a las métricas que miden los tiempos de carga de las páginas.
Dado que las navegaciones con bfcache restablecen una página existente en lugar de iniciar una carga de página nueva, la cantidad total de cargas de páginas recopiladas disminuirá cuando se habilite la bfcache. Lo fundamental es que, probablemente, las cargas de páginas que se reemplazan por restablecimientos de bfcache hayan sido algunas de las cargas de páginas más rápidas de tu conjunto de datos. Esto se debe a que, por definición, las navegaciones hacia atrás y hacia adelante 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, se reducirán las cargas de páginas más rápidas en tu conjunto de datos, lo que probablemente sesgará la distribución más lenta, a pesar de que el rendimiento que experimentó el usuario probablemente haya mejorado.
Hay varias formas de abordar este problema. Uno 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 se inclina hacia un valor negativo. 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).
En el caso de 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 varias dimensiones (velocidad de carga, interactividad y estabilidad visual). Dado que los usuarios experimentan los restablecimientos de la bfcache como navegaciones más rápidas que las cargas de página completa, es importante que las métricas de las Métricas web esenciales reflejen esto. Después de todo, al usuario no le importa si se habilitó o no bfcache, solo le importa que la navegación sea rápida.
Las herramientas que recopilan y generan informes sobre las métricas web esenciales, como el Informe sobre la experiencia del usuario en Chrome, tratan los restablecimientos de la bfcache como visitas a la página independientes en su conjunto de datos. Si bien no hay APIs de rendimiento web dedicadas para medir estas métricas después de los restablecimientos de bfcache, puedes aproximar sus valores con las APIs web existentes:
- En el caso del 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, LCP y FCP son iguales. - En Interaction to Next Paint (INP), sigue usando el observador de rendimiento existente, pero restablece el valor actual de INP a 0.
- Para el Cambio de diseño acumulado (CLS), sigue usando tu 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 individuales de las guías de métricas de las Métricas web esenciales. Si quieres ver un ejemplo específico de cómo implementar versiones de bfcache de estas métricas, consulta el documento de RR.PP. para agregarlas a la biblioteca JS de web-vitals.
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 de bfcache entre navegadores)
- bfcache (prueba cómo diferentes APIs y eventos afectan a bfcache en navegadores)
- Cambio en el rendimiento: caché atrás/adelante del navegador (un caso de éxito de Smashing Magazine que muestra mejoras drásticas en las Métricas web esenciales mediante la habilitación de la bfcache)