Caché de atrás/adelante (bfcache)

TL;DR — La caché de atrás/adelante (bfcache) es una función del navegador que congela una página entera en memoria al salir de ella, de modo que pulsar Atrás o Adelante puede devolverla al instante, sin recarga, siempre que el navegador no haya expulsado antes esa página congelada. Es algo propio del navegador, no un factor de posicionamiento de Google. Pero, como una página restaurada carga casi al instante, mejora discretamente tus cifras de Core Web Vitals en las navegaciones Atrás/Adelante que sí se restauran; por eso una auditoría de rendimiento puede recomendarte «corregir la aptitud para bfcache».

Qué es bfcache

Cuando haces clic en el botón Atrás del navegador ocurren una de dos cosas. El navegador reconstruye la página anterior desde cero —vuelve a descargar archivos, ejecuta de nuevo JavaScript y vuelve a distribuir todo el diseño— o la restaura instantáneamente, exactamente como la dejaste. Esa versión instantánea es la caché de atrás/adelante, o bfcache.

El truco es que, en lugar de desechar la página antigua al navegar fuera de ella, el navegador congela la página entera en memoria —todo, incluido el JavaScript en ejecución— y la mantiene en pausa. Si vuelves pronto y el navegador aún conserva esa página congelada, la descongela y te muestra exactamente la misma página: sin solicitudes de red y sin espera. Es una restauración posible, no una garantía: el navegador puede expulsar una página congelada de la memoria antes de que pulses Atrás (por poca memoria, un tiempo de espera o cierta actividad); en ese caso obtienes una recarga normal.

La descripción de una línea de Google lo dice claramente: “a browser optimization that enables instant back and forward navigation.” (traducción) «una optimización del navegador que permite una navegación instantánea hacia atrás y hacia adelante».

Por qué no es «la caché» que ya conoces

Esta es la parte que la gente mezcla. Cuando oyes «caché» probablemente piensas en la caché del navegador o la caché HTTP: los archivos (imágenes, scripts y hojas de estilo) que el navegador guarda para no volver a descargarlos. Bfcache no es eso. Esas cachés guardan archivos; bfcache guarda la página viva entera, con el estado de JavaScript incluido, como una instantánea. La documentación de Chrome lo explica: la bfcache “differs from browser cache and HTTP cache.” (traducción) «se diferencia de la caché del navegador y de la caché HTTP».

Tampoco es ninguna de las otras dos cosas que a veces se meten en el mismo saco: la caché de recursos en memoria del navegador (scripts compilados e imágenes decodificadas que conserva durante la sesión actual) y Cache Storage de un service worker (pares de solicitud/respuesta que el sitio administra explícitamente mediante caches.open()). Ambas pueden estar activas en la misma página que bfcache: son mecanismos separados, no la propia bfcache.

Tampoco es la antigua función de «página almacenada» o «instantánea almacenada» que Google y Bing ofrecían en los resultados de búsqueda (el pequeño menú que mostraba la versión de una página que tenían guardada). Aquello era una función de búsqueda y se retiró. Bfcache es una función activa del navegador que no tiene nada que ver con los resultados de búsqueda.

¿Ayuda bfcache a mi SEO?

No directamente. Bfcache no es un factor de posicionamiento de Google: la propia documentación de Google sobre el posicionamiento mediante Core Web Vitals nunca la menciona. Lo que hace es que las navegaciones Atrás/Adelante carguen casi al instante para las personas que realmente obtienen una restauración, y los navegadores lo miden como una «carga de página» excelente. Así que, si muchas personas navegan Atrás y Adelante (compran, recorren resultados de búsqueda o leen un artículo tras otro), bfcache puede mejorar las cifras de Core Web Vitals de campo de tu sitio, una de las muchas cosas que Google dice que encajan con lo que sus sistemas de posicionamiento premian. Está a dos pasos de «bfcache mejora las posiciones» y no garantiza tu tasa de restauración, tu valoración global de Core Web Vitals ni tus posiciones, pero es real y medible.

¿Quieres el panorama completo —qué bloquea exactamente bfcache, cómo probarla y cuál es la relación precisa (sin exagerarla) con Core Web Vitals? Cambia a la pestaña Advanced.

TL;DR — Bfcache es una instantánea de la página completa en memoria (DOM + heap de JS + estado en ejecución), no una respuesta HTTP que se pueda volver a solicitar, ni la caché de recursos en memoria del navegador, ni Cache Storage de un service worker: esa es la distinción conceptual número uno. Al navegar fuera, el navegador pausa JavaScript y congela la página; al pulsar Atrás/Adelante, si esa instantánea sigue disponible, la descongela y la vuelve a mostrar al instante, sin solicitudes de red, pero siempre es posible que la expulse, así que trata la restauración como probable, no garantizada. No es un factor de posicionamiento documentado por Google Search (la documentación de Core Web Vitals de Search Central no la menciona); su relevancia es indirecta y acotada, a través de la medición de CWV de campo (principalmente LCP y CLS) en las navegaciones que sí se restauran: no garantiza tu tasa de restauración, tu valoración global de CWV, tus posiciones ni la conversión. El mayor bloqueo de aptitud es el controlador unload (aproximadamente 18 puntos porcentuales de la tasa de restauración en Chrome); históricamente el mayor fue Cache-Control: no-store (bloqueaba aproximadamente el 17 % de las navegaciones históricas en móvil y el 7 % en escritorio), aunque Chrome permite ahora bfcache en muchas páginas no-store de forma condicional (las expulsa si cambian la autenticación o las cookies y las mismas API de conexiones abiertas siguen bloqueándolas) tras su despliegue de 2025. Las conexiones abiertas, los temporizadores y los observers deben cerrarse o pausarse en pagehide/freeze y restablecerse en pageshow/resume; window.opener, las políticas de permisos y los frames también pueden bloquearla: comprueba el motivo por frame en DevTools o notRestoredReasons en lugar de suponerlo. Prueba casos aislados con Chrome DevTools y diagnostica en campo con la API notRestoredReasons, exclusiva de Chrome (un resultado null no demuestra una restauración y el texto del motivo no es estable). Cada navegador tiene sus propias reglas de aptitud, y las navegaciones blandas de las SPA no reciben el mismo tratamiento.

Qué es realmente bfcache (la columna vertebral de precisión)

Lo más importante que hay que entender bien es esto: bfcache es una instantánea de la página completa en memoria, no una respuesta HTTP guardada. Cuando navegas fuera de una página, el navegador no la desmonta: pausa la ejecución de JavaScript y congela la página entera —el DOM, el heap de JS, los temporizadores en curso, todo— y la mantiene en memoria. Si pulsas Atrás o Adelante mientras esa instantánea congelada aún está disponible, la descongela y vuelve a mostrar exactamente la página que dejaste, con cero solicitudes de red y cero renderizado de nuevo. Es una restauración posible, no una garantía: el navegador puede expulsar la instantánea antes de que vuelvas (por presión de memoria, un tiempo de espera o ciertos eventos), o una regla del navegador puede forzar una carga nueva; en ese caso solo es una navegación histórica normal. El encuadre canónico de Google es que bfcache es “a browser optimization that enables instant back and forward navigation.” (traducción) «una optimización del navegador que permite una navegación instantánea hacia atrás y hacia adelante».

Por eso confundirla con la caché HTTP o del navegador es el error recurrente de la competencia. La caché HTTP guarda respuestas a solicitudes anteriores: archivos que puede volver a servir. Bfcache guarda la página viva y en ejecución. La documentación de Chrome DevTools marca explícitamente la diferencia: bfcache “differs from browser cache and HTTP cache.” (traducción) «se diferencia de la caché del navegador y de la caché HTTP». No «activas» bfcache con cabeceras de caché como configuras la caché HTTP; el único lugar donde entran las cabeceras es que Cache-Control: no-store solía descalificar una página (volveremos a ello).

La misma distinción se aplica frente a otras dos cachés que a veces se confunden con bfcache: la caché de recursos en memoria del navegador (scripts compilados e imágenes decodificadas conservados durante la sesión actual) y Cache Storage de un service worker (pares explícitos de solicitud/respuesta que el sitio administra mediante caches.open()). Ambas pueden estar activas en la misma página que bfcache al mismo tiempo; ninguna es bfcache, que es específicamente la instancia de página congelada, no assets guardados ni respuestas interceptadas.

Hay otra aclaración que conviene hacer porque sigue causando confusión: bfcache no tiene nada que ver con la antigua función de búsqueda de «página almacenada» que Google (y Bing) mostraba antes en los resultados. Era una instantánea guardada de una página en el índice de búsqueda y se retiró. Bfcache es una función del motor de renderizado del lado del cliente.

¿Son frecuentes de verdad las navegaciones Atrás/Adelante?

No es un caso extremo. Según web.dev, “1 in 10 navigations on desktop and 1 in 5 on mobile are either back or forward.” (traducción) «1 de cada 10 navegaciones en escritorio y 1 de cada 5 en móvil son hacia atrás o hacia adelante». En cualquier sitio con recorridos repetidos de Atrás/Adelante —categoría a producto y vuelta en comercio electrónico, resultados de búsqueda, contenido paginado o lectura de artículo a artículo— es una porción grande de navegaciones reales que puedes hacer casi instantáneas.

Compatibilidad de los navegadores

“All major browsers include a bfcache, including Chrome since version 96, Firefox and Safari.” (traducción) «Los principales navegadores incluyen bfcache, incluidos Chrome desde la versión 96, Firefox y Safari». Firefox y Safari tienen sus propias implementaciones de bfcache, más antiguas; todos los navegadores basados en Chromium (Edge, Brave, Opera y Arc) heredan la de Chrome. La documentación de políticas de Microsoft Edge describe la misma función: al navegar fuera de una página, su estado actual (árbol del documento, script y demás) puede conservarse en la caché de atrás/adelante y, si el navegador vuelve a ella, puede restaurarse desde allí y mostrarse en el estado que tenía antes de guardarse. Viene activada de forma predeterminada en Edge; el único interruptor de apagado es una política empresarial que controla el administrador de TI, no el propietario del sitio.

La salvedad importante es que cada navegador aplica sus propias reglas de aptitud para bfcache. Que una página supere la prueba «Test back/forward cache» de Chrome DevTools no garantiza que sea apta en Firefox o Safari. Trata un aprobado de Chrome como necesario, no suficiente.

Qué impide la aptitud para bfcache

El evento unload: el mayor bloqueo individual

Si solo te quedas con una cosa de este artículo, que sea esta: deja de usar el evento unload. web.dev lo expresa con un énfasis poco habitual para un documento de Google: “Never use the unload event. Ever!” (traducción) «No uses nunca el evento unload. ¡Nunca!». En Chrome, los controladores de unload cuestan aproximadamente una reducción de 18 puntos porcentuales en la tasa de restauración de bfcache, el mayor descalificador que puedes introducir tú mismo.

Hay dos motivos por los que Chrome lo está retirando activamente. Primero, es el mayor bloqueo de bfcache. Segundo, unload ya es extremadamente poco fiable: en móvil con frecuencia ni siquiera se ejecuta, porque las pestañas pasan a segundo plano, se eliminan y el navegador prioriza bfcache frente a disparar unload. Así que el evento del que dependes para la «limpieza» a menudo no se ejecuta y bloquea una mejora real de rendimiento.

Las correcciones:

• Sustituye unload por pagehide. El evento pagehide se dispara en todos los casos en que lo haría unload y además cuando una página entra en bfcache: es una mejora estricta. Usa visibilitychange para la limpieza fiable cuando la persona se va.
• Detecta una restauración de bfcache con pageshow. Escucha pageshow y comprueba event.persisted; si es true, la página se restauró desde bfcache, la señal para actualizar datos obsoletos o volver a contar una visita.
• Bloquea de forma preventiva los listeners de unload con la cabecera de respuesta Permissions-Policy: unload=(), que impide registrar cualquier controlador unload. Chrome está trasladando gradualmente la política predeterminada hacia la denegación (una Permissions-Policy para unload se lanzó desde Chrome 115).

Cache-Control: no-store: históricamente el mayor, ahora con matices

Este es el punto de frescura que más equivocadamente trata el contenido de la competencia. Históricamente, Cache-Control: no-store era el motivo individual más importante por el que se excluían páginas de bfcache: las cifras de Chrome lo situaban aproximadamente en el 17 % de las navegaciones históricas en móvil y el 7 % en escritorio. Muchos sitios configuran no-store de forma defensiva para evitar servir una página obsoleta, pero el argumento de Google es que esa razón pierde fuerza con bfcache: una restauración de bfcache no carga una respuesta guardada obsoleta, sino que vuelve a mostrar la página viva exacta casi como si la pestaña se hubiera quedado abierta.

Por eso Chrome cambió el comportamiento, pero de forma condicional, no universal. Los experimentos comenzaron en Chrome 116, con el despliegue final al 100 % de las personas durante marzo y abril de 2025: Chrome permite ahora bfcache en muchas páginas no-store, sujeto a condiciones de seguridad concretas en vez de una excepción general. Según la documentación de Chrome, existen límites reales: la página se expulsa de bfcache si cambia el estado de autenticación o las cookies mientras está congelada (para que una persona que ha cerrado sesión o borrado cookies no vea una instantánea antigua con sesión abierta), y una lista fija de API —las mismas API de conexiones abiertas que se tratan abajo (IndexedDB, WebSocket, WebRTC y demás)— sigue excluyendo de bfcache una página no-store igual que cualquier otra. Es un comportamiento específico de Chrome y de un intervalo concreto de versiones, no una regla que puedas suponer para otros navegadores o versiones antiguas de Chrome: consulta el informe actual de DevTools/notRestoredReasons para el navegador y la versión que realmente estés probando, en vez de confiar en una regla fija.

Conclusión práctica: cualquier guía (incluidas las versiones antiguas de esta) que enumere no-store como bloqueo incondicional y permanente de bfcache está obsoleta, pero también lo está tratarlo como un problema completamente resuelto. Si la frescura importa de verdad, la documentación de Chrome sugiere no-cache o un max-age breve (por ejemplo, max-age=60) en lugar de no-store.

Conexiones abiertas, observers y otros bloqueos

En el momento de navegar, ciertos recursos abiertos todavía pueden impedir la aptitud, y exactamente cuáles lo hacen —y si bloquean por completo o simplemente se cierran y se pueden reconectar— depende del navegador y de su versión. Trata la lista siguiente como ejemplos de un patrón, no como una lista fija y permanente:

• Solicitudes fetch() / XMLHttpRequest en curso.
• Transacciones abiertas de IndexedDB.
• Conexiones abiertas de WebSocket / WebRTC, temporizadores y observers (MutationObserver, IntersectionObserver y similares). Es un área que mejora activamente: las notas de lanzamiento recientes de Microsoft Edge muestran que un WebSocket abierto ahora se cierra cuando una página entra en bfcache (en vez de bloquear la caché por completo), con la reconexión recomendada mediante el evento pageshow y su comprobación event.persisted. Eso refleja la tendencia más amplia de Chrome a reducir bloqueos en lugar de excluir páginas sin más.

El patrón general que conviene implementar, en vez de memorizar una lista fija, es cerrar o pausar las conexiones abiertas, los temporizadores y los observers al gestionar pagehide/freeze, y restablecerlos al gestionar pageshow/resume cuando event.persisted sea true. Ese patrón resiste que un navegador cambie qué API bloquea la aptitud por completo y cuál simplemente suspende para que puedas reconectarla.

window.opener, políticas de permisos y frames. Una referencia window.opener, ciertas políticas de permisos y frames incrustados (del mismo origen o de otro) también pueden afectar a la aptitud; es algo que resumí en la guía de CLS de Ahrefs y en la documentación de Chrome. Pero no supongas la causa real a partir de una lista genérica: el panel de Chrome DevTools y la API notRestoredReasons informan de los motivos de bloqueo por frame —el frame superior y cada iframe por separado—, porque el frame responsable no siempre es la página de nivel superior. Obtén el motivo real del informe de ese frame para el navegador que estés probando, en lugar de adivinar a partir de una lista general.

Cómo acertar con la secuencia de eventos y estados del ciclo de vida

Confundir lo que cada evento del ciclo de vida realmente demuestra con lo que solo sugiere es el segundo error de corrección más común aquí, después de los errores de aptitud anteriores:

La regla práctica es tratar pagehide.persisted como intención, no como prueba: la página todavía puede ser expulsada antes de que veas una restauración. Solo pageshow.persisted === true demuestra que ocurrió. Haz la limpieza sin condiciones en pagehide/freeze (es barata y segura incluso en una navegación normal) y ejecuta el trabajo específico de restauración solo en pageshow/resume, condicionado a event.persisted, para no actualizar datos ni contar dos veces una visita en una carga nueva normal.

Cómo probar y diagnosticar bfcache

Laboratorio / caso aislado: Chrome DevTools

Abre DevTools → Application → Background services → Back/forward cache y haz clic en «Test back/forward cache». Chrome navega automáticamente a chrome://terms/ y vuelve, y después informa de éxito o de una lista concreta de motivos de bloqueo. Es útil para comprobar una URL cada vez.

Campo / producción: la API notRestoredReasons

Antes, la única forma de comprobar la aptitud era esa prueba manual de DevTools, una URL cada vez; no había forma de saber por qué se bloqueaban las navegaciones de personas reales. La propiedad notRestoredReasons de PerformanceNavigationTiming (disponible desde Chrome 123+) cierra esa brecha: informa de los motivos de bloqueo concretos del frame superior y de los iframes del mismo origen en datos de campo reales.

const nav = performance.getEntriesByType('navigation')[0];
console.log(nav.notRestoredReasons);

Al usarla, hay algunos puntos importantes que vienen directamente de la guía de la API de Chrome:

• Solo funciona en Chrome (123+). Firefox y Safari no exponen un campo equivalente, así que necesitarás comprobaciones manuales en esos navegadores para conocer allí tu tasa de restauración.
• Un resultado null es ambiguo, no una luz verde. Puede significar que la página se restauró o que el navegador simplemente no recopiló un motivo; la propia documentación de Chrome dice que no se debe tratar null como prueba de una restauración correcta.
• El texto del motivo no es un contrato estable. No codifiques coincidencias contra sus cadenas; agrupa y sigue la tendencia por motivo porque las palabras exactas pueden cambiar entre versiones de Chrome.

En la práctica, extrae notRestoredReasons junto con las tasas de restauración de pageshow.persisted antes y después de publicar una corrección, compara la tendencia en vez de una instantánea y acompáñala de una prueba manual de laboratorio en Firefox y Safari, los navegadores a los que no llega la API. Es la herramienta adecuada para diagnosticar bfcache a escala en RUM/producción, en vez de comprobar URL por URL; solo no la trates como el panorama completo.

Bfcache y Core Web Vitals: la relación precisa

Este es el matiz que más difumina el contenido de la competencia y el ángulo que merece la pena explicar con precisión.

Cómo se mide una restauración de bfcache. Los navegadores (y, por tanto, los datos de campo de CrUX) cuentan una navegación restaurada desde bfcache como una «carga de página» extremadamente rápida: un LCP casi instantáneo y, cuando la página está implementada correctamente (no tiene que redistribuir el diseño), un CLS adicional prácticamente igual a cero, porque no hay un renderizado de nuevo. En la comparación del mundo real de DebugBear, una página restaurada desde bfcache obtuvo un LCP de alrededor de 100 ms frente a unos 427 ms en una carga sin caché. Por eso bfcache aparece como palanca para CLS y LCP en mi propia lista de comprobación de CLS de Ahrefs, donde lo resumo así: “Make sure your pages are eligible for bfcache. The back/forward cache keeps pages in the browser cache. It allows for instant loading of a page that was already loaded, meaning no layout shifts will happen.” (traducción) «Comprueba que tus páginas pueden entrar en bfcache. El mecanismo conserva en la caché del navegador una página ya cargada. Hace posible mostrarla al instante, así que no se producen cambios de diseño».

Hay dos salvedades de alcance que conviene expresar con precisión porque aquí el contenido de la competencia suele exagerar. Primero, esto solo afecta a las navegaciones que CrUX clasifica como atrás/adelante (su dimensión navigation-type): no dice nada de las navegaciones de primera visita o de recarga, que son la mayoría del tráfico en la mayoría de los sitios. Segundo, que una restauración mejore la experiencia medida de quienes la reciben no equivale a una garantía: quien haya sido expulsado de bfcache (consulta la tabla del ciclo de vida) obtiene una carga normal, sin mejora; por tanto, el trabajo de aptitud para bfcache mueve tu tasa de restauración entre las navegaciones Atrás/Adelante, no un porcentaje fijo de todo tu tráfico, y no garantiza tu valoración global de Core Web Vitals de campo, tus posiciones ni tu tasa de conversión. Es una palanca real y medible con un alcance concreto, no una solución general de rendimiento o SEO.

¿Es bfcache un factor de posicionamiento? No. Esta es la afirmación defendible y diferenciadora. La propia documentación de Google sobre el posicionamiento mediante Core Web Vitals no menciona bfcache. La cadena de influencia honesta es: aptitud para bfcache → mejores cifras de CWV de campo (principalmente LCP/CLS) en navegaciones Atrás/Adelante → Core Web Vitals es una señal entre muchas de «experiencia de página» que Google dice que encajan con lo que ya premian sus sistemas de posicionamiento. Es una afirmación materialmente más débil y precisa que «bfcache mejora las posiciones», y es la que el contenido de la competencia debería hacer pero normalmente no formula con cuidado. Bfcache es también, correctamente, una función del motor de renderizado, no del crawler: no tiene nada que ver con cómo Googlebot o Bingbot rastrean tus páginas, por eso no existe un «punto de vista de Bing sobre bfcache para SEO» como sí lo hay para robots.txt o sitemaps.

SPA y navegaciones blandas. Bfcache funciona con navegaciones y eventos de historial reales del navegador. El cambio de ruta «blando» de una aplicación de una sola página (un intercambio de vista dirigido por JS que no activa una navegación real del navegador) no es un evento de bfcache ni recibe el mismo tratamiento. Los intentos de algunas herramientas RUM de atribuir Core Web Vitals a navegaciones blandas pueden crear diferencias de medición entre CrUX y RUM; conviene señalarlo al auditar un sitio basado en un framework JS.

¿Qué frecuencia tienen los bloqueos de bfcache en la práctica?

El Web Almanac de HTTP Archive lo registra, y es un área viva y cambiante, no una noticia antigua ya cerrada. En la edición de 2022, al menos alrededor del 22 % de las páginas móviles no eran aptas para bfcache solo por los criterios de unload y no-store. Desde entonces, el uso de controladores unload ha disminuido entre niveles de sitios y dispositivos, pero el uso de Cache-Control: no-store ha aumentado (el capítulo de 2025 lo sitúa alrededor del 23 % de los sitios, frente a aproximadamente el 21 % en 2024, en parte por el aumento de experiencias autenticadas o personalizadas y requisitos de cumplimiento más estrictos).

El hallazgo contraintuitivo que merece citarse es que los sitios grandes y con más tráfico tienen desproporcionadamente más probabilidades de bloquear su propia bfcache. Entre los 1 000 sitios principales, aproximadamente el 28 % de las páginas de escritorio y el 20 % de las móviles siguen usando controladores unload, frente a solo alrededor del 11 % en escritorio y el 10 % en móvil de todos los sitios, a menudo porque los sitios grandes arrastran más analítica heredada y código dependiente de unload. Los sitios que tienen más tráfico de Atrás/Adelante que perder suelen ser los que más se estorban a sí mismos.

Dónde encaja

Bfcache es una palanca de rendimiento entre varias de este clúster. Su beneficio aparece en los datos de campo de Core Web Vitals, específicamente en Cumulative Layout Shift y Largest Contentful Paint, porque una página restaurada vuelve a mostrarse al instante sin redistribuir el diseño. Es distinta de la caché, que guarda archivos y no una instantánea de página viva, aunque ambas comparten la cabecera Cache-Control como punto de contacto. No existe un vínculo directo con Interaction to Next Paint, así que no voy a forzarlo.

Resumen de IA

Una síntesis de la versión Advanced:

• Bfcache = una instantánea de la página completa en memoria (DOM + heap de JS + estado en ejecución), no una respuesta HTTP que se pueda volver a pedir, ni la caché de recursos en memoria del navegador, ni Cache Storage de un service worker. Al navegar fuera, el navegador pausa JS y congela la página; al pulsar Atrás/Adelante, si la instantánea sigue disponible, la descongela y la vuelve a mostrar al instante, sin solicitudes de red: la expulsión siempre es posible, así que una restauración es probable, no garantizada. La documentación de Chrome dice que “differs from browser cache and HTTP cache.” (traducción) «se diferencia de la caché del navegador y de la caché HTTP». Tampoco es la antigua función retirada de búsqueda de «página almacenada».
• No es un factor de posicionamiento y tiene un alcance acotado. La documentación de Google sobre el posicionamiento mediante Core Web Vitals nunca menciona bfcache. La cadena real es indirecta: aptitud para bfcache → mejores cifras de CWV de campo (principalmente LCP/CLS) en las navegaciones Atrás/Adelante que se restauran → CWV es una señal de experiencia de página que Google dice que encaja con sus sistemas de posicionamiento. No garantiza la tasa de restauración, los CWV agregados, las posiciones ni la conversión, y solo afecta a las navegaciones que CrUX clasifica como atrás/adelante.
• Escala: «1 de cada 10 navegaciones de escritorio y 1 de cada 5 en móvil son hacia atrás o hacia adelante». Es compatible con Chrome desde la versión 96, Firefox y Safari, pero cada navegador tiene sus propias reglas de aptitud.
• Mayor bloqueo: el evento unload («No uses nunca el evento unload. ¡Nunca!»): aproximadamente 18 puntos porcentuales de la tasa de restauración en Chrome. Sustitúyelo por pagehide + visibilitychange, detecta restauraciones con pageshow / event.persisted y bloquea unload mediante Permissions-Policy: unload=().
• Cache-Control: no-store fue históricamente el mayor bloqueo (aproximadamente el 17 % de las navegaciones históricas en móvil y el 7 % en escritorio). Chrome permite ahora bfcache en muchas páginas no-store de forma condicional tras su despliegue de marzo-abril de 2025: las expulsa si cambian autenticación o cookies, y las mismas API de conexiones abiertas siguen bloqueándolas. Solo aplica a Chrome; las guías antiguas que llaman a no-store bloqueo absoluto están obsoletas, pero también lo está tratarlo como un asunto completamente resuelto.
• Otros bloqueos: fetch/XHR en curso, temporizadores, observers, IndexedDB abierto, WebSocket/WebRTC, window.opener, políticas de permisos y frames. Cierra o pausa en pagehide/freeze, reconecta en pageshow/resume y consulta el motivo por frame en DevTools/notRestoredReasons en vez de suponerlo.
• Corrección del ciclo de vida: pagehide.persisted es intención, no prueba; solo pageshow.persisted === true confirma una restauración. Limpia siempre en pagehide/freeze y actualiza estado sensible, reconecta y cuenta una visita en pageshow/resume únicamente cuando event.persisted sea verdadero.
• Pruebas: Chrome DevTools «Test back/forward cache» para un caso aislado; la API notRestoredReasons, exclusiva de Chrome (123+), para datos de campo. null no es prueba de restauración, el texto del motivo no es estable y Firefox/Safari necesitan comprobaciones manuales. Compara notRestoredReasons y las tasas de pageshow.persisted antes y después de una corrección.
• SPA: las navegaciones blandas del cliente no son eventos de bfcache ni reciben el mismo tratamiento, una posible fuente de diferencias entre CrUX y RUM.
• Adopción (Web Almanac): el uso de no-store aumenta (aproximadamente del 21 % al 23 %) y el uso de unload es mayor en los sitios más grandes (aproximadamente el 28 % en escritorio entre los 1 000 principales); los sitios grandes suelen bloquear su propia bfcache.

Documentación oficial

Documentación de fuentes primarias sobre bfcache. Observa la división: bfcache vive en la documentación de Chrome / del motor de renderizado (la voz institucional de Google sobre ella), no en Google Search Central; esa separación es precisamente el punto.

Google / Chrome

• Caché de atrás/adelante — el documento canónico: definición, mecanismo, la estadística de 1 de cada 10 / 1 de cada 5 y la recomendación sobre unload.
• Probar la caché de atrás/adelante — pasos de prueba de DevTools, bloqueos principales y la frase explícita de que se «diferencia de la caché del navegador y de la caché HTTP».
• Activar bfcache para Cache-Control: no-store — el cambio de política de 2025, las cifras del 17 % / 7 % y el calendario de despliegue.
• Retirada del evento unload — por qué se está eliminando unload y la migración de Permissions-Policy.
• API de motivos por los que bfcache no restauró — diagnóstico de campo mediante PerformanceNavigationTiming (Chrome 123+).
• Entender Core Web Vitals y los resultados de Google Search — documentación de posicionamiento de Google Search Central; se cita aquí como prueba de que nunca menciona bfcache.

Microsoft / Edge

• Política de Microsoft Edge: BackForwardCacheEnabled — definición de Edge, la misma salvedad de unload y el interruptor de apagado mediante política empresarial.

MDN / estándares web

• bfcache — glosario de MDN — definición general independiente del motor y distinción respecto de la caché HTTP.
• Supervisar los motivos de bloqueo de bfcache — MDN — uso práctico de notRestoredReasons.

Citas de la fuente

Declaraciones públicas de la documentación fuente. Cada enlace es un enlace profundo que salta al pasaje citado de la página de origen.

Google / Chrome: qué es bfcache y por qué importa

• “Back/forward cache (or bfcache) is a browser optimization that enables instant back and forward navigation.” (traducción) «La caché de atrás/adelante (o bfcache) es una optimización del navegador que permite una navegación instantánea hacia atrás y hacia adelante». — web.dev. Saltar a la cita
• “1 in 10 navigations on desktop and 1 in 5 on mobile are either back or forward. With bfcache enabled, browsers could eliminate the data transfer and time spent loading for billions of web pages every single day!” (traducción) «1 de cada 10 navegaciones en escritorio y 1 de cada 5 en móvil son hacia atrás o hacia adelante. Con bfcache activada, los navegadores podrían eliminar la transferencia de datos y el tiempo de carga de miles de millones de páginas web cada día». Saltar a la cita
• “All major browsers include a bfcache, including Chrome since version 96, Firefox and Safari.” (traducción) «Los principales navegadores incluyen bfcache, incluidos Chrome desde la versión 96, Firefox y Safari». Saltar a la cita

Google / Chrome: la regla de optimización número uno

• “Never use the unload event. Ever!” (traducción) «No uses nunca el evento unload. ¡Nunca!». — web.dev. Saltar a la cita

Chrome DevTools: bfcache no es la caché HTTP

• “Back/forward cache differs from browser cache and HTTP cache.” (traducción) «La caché de atrás/adelante se diferencia de la caché del navegador y de la caché HTTP». — documentación de Chrome DevTools. Saltar a la cita

Microsoft Edge: la misma función, la misma salvedad

• “When navigating away from a page, its current state (document tree, script, and so on) may be preserved in the back-forward cache. If the browser navigates back to the page, the page may be restored from the back-forward cache and displayed in the state it was in before being cached.” (traducción) «Al navegar fuera de una página, su estado actual (árbol del documento, script y demás) puede conservarse en la caché de atrás/adelante. Si el navegador vuelve a la página, puede restaurarla desde la caché de atrás/adelante y mostrarla en el estado que tenía antes de guardarse». — documentación de políticas de Microsoft Edge. Saltar a la cita

Patrick Stox (yo): bfcache como palanca de CLS

• “Make sure your pages are eligible for bfcache. The back/forward cache keeps pages in the browser cache. It allows for instant loading of a page that was already loaded, meaning no layout shifts will happen.” (traducción) «Asegúrate de que tus páginas son aptas para bfcache. La caché de atrás/adelante conserva las páginas en la caché del navegador. Permite cargar al instante una página que ya se había cargado, por lo que no habrá cambios de diseño». — mi guía de CLS de Ahrefs. Leerla

Lista de comprobación de aptitud para bfcache

Una pasada para confirmar que tus páginas pueden entrar en la caché de atrás/adelante:

• Ningún listener del evento unload en ninguna parte de la página (tuyo o de scripts de terceros). Es el mayor bloqueo individual.
• Mueve el código de limpieza y analítica de unload a pagehide y visibilitychange.
• Un listener de pageshow comprueba event.persisted para actualizar datos obsoletos y volver a contar correctamente las visitas después de una restauración.
• Considera la cabecera de respuesta Permissions-Policy: unload=() para impedir que se registren listeners unload.
• Revisa Cache-Control: no-store: si la estableces de forma defensiva, confirma que todavía la necesitas (Chrome 2025+ permite bfcache en muchas páginas no-store condicionalmente; se expulsan si cambia la autenticación o las cookies y las mismas API de conexiones abiertas siguen bloqueándolas; no supongas que otros navegadores o versiones se comportan igual). Si importa la frescura, prefiere no-cache o un max-age breve.
• No dejes conexiones abiertas, temporizadores u observers pendientes al navegar: fetch/XHR en curso, transacciones abiertas de IndexedDB, WebSocket/WebRTC, MutationObserver/IntersectionObserver (cierra o pausa en pagehide/freeze, y restablece en pageshow/resume cuando event.persisted sea true).
• No uses referencias window.opener, políticas de permisos restrictivas ni frames bloqueados que vuelvan inelegible la página; consulta el motivo por frame en DevTools/notRestoredReasons en lugar de suponer cuál se aplica.
• Haz una prueba de laboratorio en Chrome DevTools → Application → Back/forward cache → «Test back/forward cache».
• Diagnostica en campo a escala con notRestoredReasons en tu RUM (solo Chrome; un resultado null no prueba una restauración y el texto del motivo no es un contrato estable: sigue la tendencia por motivo y no codifiques cadenas).
• No supongas que aprobar en Chrome significa ser apto en todas partes: comprueba Firefox y Safari, que aplican sus propias reglas.

Hoja rápida de bfcache

Qué la bloquea y cuál es la solución

Eventos que conviene conocer

Pruébala

Datos rápidos

• Bfcache = página viva completa en memoria, no archivos, no la caché de recursos y no Cache Storage de un service worker. Chrome dice que se «diferencia de la caché del navegador y de la caché HTTP».
• No es un factor de posicionamiento de Google: la documentación de CWV de Search Central no la menciona. Una restauración mejora el LCP/CLS medido para quienes la reciben; no garantiza la tasa de restauración, los CWV agregados, las posiciones ni la conversión.
• Compatibilidad: Chrome 96+, Firefox y Safari; cada uno con sus propias reglas.
• 1 de cada 10 en escritorio / 1 de cada 5 en móvil son navegaciones Atrás/Adelante.

Antipatrones de bfcache (y los mitos que esconden)

«Bfcache es solo mi caché HTTP/del navegador: la configuro con Cache-Control.» No. Bfcache es una instantánea distinta de la página completa en memoria; la documentación de Chrome dice que se «diferencia de la caché del navegador y de la caché HTTP». Las cabeceras de caché solo importan porque no-store solía descalificar una página. No «activas bfcache» con cabeceras de caché.

«Bfcache es un factor de posicionamiento de Google, así que arreglarla mejora las posiciones.» No lo establece ninguna fuente oficial de Google Search. Su documentación de posicionamiento de Core Web Vitals no menciona bfcache. La relación real es indirecta (mejor LCP/CLS de campo en navegaciones Atrás/Adelante), una afirmación más débil y precisa.

«Cache-Control: no-store siempre bloquea bfcache, de forma permanente.» Fue cierto históricamente y sigue siendo la mayor causa histórica, pero ya no es cierto de forma categórica después del despliegue completo de Chrome de 2025 para una bfcache segura con no-store. Las guías anteriores al cambio están obsoletas en este punto exacto, pero también lo está tratarlo como completamente resuelto: la excepción de Chrome es condicional (expulsión si cambian autenticación o cookies, y bloqueo por las mismas API de conexiones abiertas) y específica de Chrome, no una luz verde universal.

«Una página que dispara pagehide con persisted: true quedó definitivamente en caché.» No: eso es intención, no prueba. El navegador todavía puede expulsar la página antes de que veas una restauración. Solo pageshow.persisted === true confirma que realmente ocurrió.

«Si supera la prueba de bfcache de Chrome DevTools, es apta en todas partes.» Falso. Chrome, Firefox y Safari aplican restricciones propias; aprobar en uno no garantiza la aptitud en otro.

«unload es una forma válida de ejecutar la limpieza de salida, así que lo mantengo.» No: Chrome lo considera extremadamente poco fiable (en móvil a menudo no se dispara) y lo está retirando mediante una Permissions-Policy, precisamente porque es el mayor bloqueo de bfcache. Usa pagehide + visibilitychange.

«Bfcache ayuda a mi SPA igual que a un sitio multipágina.» No sin matices. Bfcache está vinculada a navegaciones reales del navegador; un cambio de ruta «blando» del cliente no es el mismo evento y no recibe el mismo tratamiento, lo que también provoca diferencias entre CrUX y RUM en sitios muy basados en SPA.

«Bfcache está resuelto o es una noticia vieja, no merece una auditoría.» Los propios datos del Web Almanac lo contradicen: el uso de no-store aumenta y el uso de unload sigue siendo mucho mayor en los sitios grandes y con más tráfico, precisamente los que tienen más navegaciones Atrás/Adelante que perder.

Herramientas para probar y diagnosticar bfcache

• Panel de bfcache de Chrome DevTools. Application → Background services → Back/forward cache → «Test back/forward cache». Navega automáticamente a chrome://terms/ y vuelve, e informa de éxito o de los motivos de bloqueo exactos. Es lo mejor para una comprobación aislada de una URL en laboratorio.
• API notRestoredReasons (Chrome 123+). Lee performance.getEntriesByType('navigation')[0].notRestoredReasons en tu RUM para ver a escala los motivos de bloqueo de personas reales, incluidos los iframes del mismo origen, no solo en una prueba manual de laboratorio.
• PageSpeed Insights / Lighthouse / CrUX. Es donde suele aparecer primero una recomendación o señal de «caché de atrás/adelante» en una auditoría y donde se ve el beneficio de campo en CWV de un sitio apto para bfcache.
• Cabecera Permissions-Policy: unload=(). No es una herramienta de prueba, sino la palanca de aplicación: impide activamente que se registren listeners unload, incluidos los de terceros.
• Capítulo Performance de Web Almanac (HTTP Archive). Sirve para comparar la frecuencia de los bloqueos de bfcache en la web por dispositivo y nivel de tráfico.

DevTools dice que un controlador unload bloqueó la restauración

Síntoma: la prueba de bfcache de Atrás/Adelante menciona unload. Causa probable: código propio o de terceros registró un listener unload. Solución: sustituye la limpieza por pagehide/visibilitychange, añade Permissions-Policy: unload=() cuando corresponda y repite la prueba después de cada cambio en los scripts afectados.

Una página restaurada muestra datos obsoletos de la persona usuaria

Síntoma: Atrás vuelve al instante, pero el estado de la cuenta, el inventario u otro valor dinámico está obsoleto. Causa probable: la página reanudó el estado congelado sin actualizar datos sensibles al tiempo. Solución: escucha pageshow, comprueba event.persisted y actualiza solo los datos necesarios. Confirma que funcionan tanto las cargas normales como las restauraciones.

La analítica pierde o duplica las visitas Atrás/Adelante

Síntoma: las visitas de página no coinciden con las navegaciones históricas reales. Causa probable: la analítica solo se ejecuta en la carga original o se ejecuta dos veces sin distinguir una restauración. Solución: gestiona pageshow explícitamente y usa event.persisted para contar una sola vez la navegación restaurada.

El laboratorio aprueba, pero la restauración de campo sigue siendo baja

Síntoma: una URL de muestra supera DevTools, mientras que el RUM registra muchas no restauraciones. Causa probable: otras plantillas, navegadores, estados reales de usuario o conexiones abiertas intermitentes añaden bloqueos. Solución: recopila notRestoredReasons, agrupa por motivo y plantilla, y reproduce el caso de campo dominante en vez de extrapolar una sola prueba aprobada.

Demuestra que una corrección de bfcache llegó

Prueba de aptitud

Prueba: DevTools → Application → Back/forward cache → Test back/forward cache. Resultado esperado: la página se restaura correctamente sin motivo de bloqueo. Interpretación de fallo: queda al menos un bloqueo de aptitud. Ventana de supervisión: inmediata para Chrome en el estado probado. Disparador de reversión: la corrección rompe la limpieza, la seguridad o el comportamiento necesario de la aplicación.

Prueba de comportamiento de restauración

Prueba: navega fuera y pulsa Atrás; después verifica que pageshow recibe event.persisted === true y que los datos sensibles al tiempo se actualizan. Resultado esperado: una restauración instantánea, datos correctos y una visita analítica. Interpretación de fallo: la página no se guardó o la gestión de la restauración está incompleta. Ventana de supervisión: inmediata en estados representativos con y sin sesión. Disparador de reversión: datos sensibles obsoletos o acciones duplicadas después de restaurar.

Prueba de motivos de campo

Prueba: supervisa PerformanceNavigationTiming.notRestoredReasons en el RUM. Resultado esperado: el bloqueo objetivo disminuye en las plantillas afectadas sin que otro bloqueo dominante lo sustituya. Interpretación de fallo: la muestra de laboratorio no representaba producción o la dependencia problemática pertenece a otro equipo. Ventana de supervisión: suficiente tráfico real de Atrás/Adelante para comparar la misma mezcla de plantillas. Disparador de reversión: una regresión material de la aplicación o de la integridad de los datos vinculada al cambio.

Métricas de bfcache que merece la pena conservar

Tasa de restauración

Métrica: navegaciones Atrás/Adelante aptas que se restauran desde bfcache. Qué te dice: con qué frecuencia las personas reciben el beneficio de una navegación instantánea. Cómo extraerla: entradas de navegación de RUM y pageshow.persisted, segmentadas por navegador y plantilla. Referencia / rango realista: establece tu propia línea base porque las reglas del navegador, el estado de la página y la mezcla de navegaciones varían. Cadencia: semanal y después de cambios en el ciclo de vida.

Motivos de no restauración

Métrica: navegaciones históricas agrupadas por notRestoredReasons. Qué te dice: qué bloqueos cuestan más restauraciones reales. Cómo extraerla: la API PerformanceNavigationTiming en navegadores compatibles. Referencia / rango realista: apunta a cero en los bloqueos que controla tu propio código y etiqueta la cobertura de navegador/API. Cadencia: triaje semanal.

Corrección de las navegaciones restauradas

Métrica: errores, incidentes de datos obsoletos y analítica o acciones duplicadas después de una restauración. Qué te dice: si una mayor aptitud conserva la corrección de la aplicación. Cómo extraerla: eventos de error de RUM, monitorización de la aplicación y QA de analítica asociados a pageshow.persisted. Referencia / rango realista: cero fallos conocidos de corrección o privacidad. Cadencia: alertas continuas y QA de cada lanzamiento.

Recursos que merecen tu tiempo

Mis artículos relacionados

• Qué es Cumulative Layout Shift (CLS) y cómo mejorarlo — donde enumero la aptitud para bfcache como táctica para mejorar CLS, con una lista breve de bloqueos.
• Qué son Core Web Vitals (CWV) y cómo mejorarlos — las métricas principales, con bfcache como una palanca de CLS entre muchas.
• Guía para principiantes de SEO técnico — dónde encaja el rendimiento web en el panorama general.

Mis presentaciones

• Cómo funciona la búsqueda (SlideShare) — mi recorrido por rastreo, renderizado, indexación y posicionamiento, para entender por qué una función del motor de renderizado como bfcache queda fuera de las señales de posicionamiento de Search. (Se aplica mi descargo habitual: «Esta es mi comprensión de los sistemas… no será 100 % completa ni exacta»).

Oficial

• Caché de atrás/adelante (web.dev) — el documento canónico.
• Activar bfcache para Cache-Control: no-store y Retirada del evento unload (Chrome para desarrolladores) — los dos cambios que vuelven obsoletas las guías antiguas.
• Entender Core Web Vitals y los resultados de Google Search (Google Search Central) — la documentación de posicionamiento que, de forma reveladora, nunca menciona bfcache.

De la industria

• bfcache — glosario de MDN — definición precisa e independiente del motor y distinción respecto de la caché HTTP.
• Qué significa la caché de atrás/adelante para la velocidad del sitio (DebugBear) — el artículo más basado en datos de este ámbito, con registros de un sitio real y una comparación concreta de LCP (aproximadamente 100 ms restaurado frente a unos 427 ms sin caché).
• Explicación de Back Forward Cache (SpeedVitals) — mecánica, aptitud, pruebas e impacto en CWV.
• Back/Forward Cache: qué es y cómo implementarla (NitroPack) — orientado a implementación para público de CMS y hosting.
• Cambio radical de rendimiento: la caché Atrás/Adelante del navegador (Smashing Magazine) — análisis técnico sólido, aunque anterior al cambio de no-store de 2025.
• Web Almanac — capítulo Performance (2025) (HTTP Archive) — datos de adopción reales sobre la prevalencia de unload y no-store por dispositivo y nivel del sitio.

Estadísticas que merece la pena citar

• Las navegaciones Atrás/Adelante son frecuentes: «1 de cada 10 navegaciones en escritorio y 1 de cada 5 en móvil son hacia atrás o hacia adelante»; es la escala de la oportunidad, no un caso marginal. Fuente
• unload cuesta aproximadamente 18 puntos porcentuales de la tasa de restauración de bfcache en Chrome, por eso es el bloqueo número uno y se está retirando. Fuente
• Cache-Control: no-store fue el mayor bloqueo histórico: aproximadamente el 17 % de las navegaciones históricas en móvil y el 7 % en escritorio, antes de que el despliegue de Chrome de marzo-abril de 2025 permitiera bfcache en muchas páginas no-store. Fuente
• Una restauración de bfcache es casi instantánea: DebugBear midió un LCP de unos 100ms en una página restaurada frente a unos 427ms en una carga sin caché. Fuente
• Los sitios grandes se bloquean más: entre los 1 000 sitios principales, alrededor del 28 % de las páginas de escritorio y el 20 % de las móviles aún usan controladores unload, frente a aproximadamente el 11 % / 10 % de todos los sitios; además, el uso de no-store aumenta (aproximadamente del 21 % al 23 %). Fuente

Ponte a prueba: caché de atrás/adelante (bfcache)

Cinco preguntas rápidas sobre qué es bfcache, qué la bloquea y cómo se relaciona con el SEO. Elige una respuesta para cada pregunta y comprueba después.

Registro de cambios