Cuando hablamos de mejorar el rendimiento de WordPress, casi siempre pensamos en las mismas acciones: instalar un plugin de caché, comprimir imágenes, reducir archivos CSS y JavaScript, utilizar una CDN o contratar un alojamiento más rápido.
Todo eso sigue siendo importante. Sin embargo, existe una optimización menos conocida que puede conseguir que una web parezca mucho más rápida durante la navegación: BFCache, también llamada Back/Forward Cache o caché de avance y retroceso.
En mi opinión, BFCache es una de esas tecnologías que pasan desapercibidas precisamente porque trabajan desde el navegador. El usuario no ve un aviso, no pulsa un botón y tampoco tiene que activar una opción. Simplemente nota que, al volver a una página anterior, esta aparece casi al instante.
El navegador puede conservar temporalmente el estado completo de una página que acabamos de visitar. Si después utilizamos los botones de atrás o adelante, puede restaurar ese estado sin repetir todo el proceso normal de carga.
Esto puede mejorar mucho la sensación de fluidez en un blog, una web corporativa, una tienda WooCommerce o un medio con muchos contenidos. Sin embargo, no todas las páginas de WordPress pueden utilizar BFCache. Algunos encabezados HTTP, scripts, plugins y comportamientos dinámicos pueden impedirlo.
Además, no siempre conviene eliminar esos bloqueos sin analizar sus consecuencias. En páginas privadas, carritos de compra o zonas para usuarios conectados, restaurar un estado anterior puede mostrar información desactualizada.
Por eso, en esta guía no me limitaré a explicar cómo “activar BFCache en WordPress”. Veremos qué es realmente, cómo se diferencia de otros sistemas de caché, cómo comprobar si funciona y qué debemos revisar antes de modificar una web en producción.
Qué es BFCache y por qué puede hacer que WordPress parezca más rápido
BFCache es una función del navegador diseñada para acelerar las navegaciones realizadas con los botones de atrás y adelante.
Cuando abandonamos una página para visitar otra, el navegador puede conservar la página anterior en memoria. No guarda únicamente algunos archivos, como ocurre con la caché tradicional del navegador. Puede mantener una representación mucho más completa de su estado.
Una forma sencilla de entenderlo es imaginar que el navegador hace una especie de fotografía funcional de la página antes de abandonarla. Esa fotografía puede incluir el contenido visible, la posición del desplazamiento, el estado de determinados formularios y parte del comportamiento de JavaScript.
Si después regresamos a esa página, el navegador puede recuperar la versión que ya tenía preparada.
El visitante no necesita saber que BFCache existe. Desde su punto de vista, únicamente pulsa el botón de volver y la página aparece inmediatamente.
Cómo funciona la caché de avance y retroceso
En una navegación convencional, volver a una página puede obligar al navegador a realizar varios pasos:
- Solicitar nuevamente el documento.
- Esperar la respuesta del servidor.
- Permitir que WordPress ejecute PHP.
- Consultar la base de datos cuando sea necesario.
- descargar o recuperar los recursos de la página;
- procesar el HTML, el CSS y JavaScript;
- reconstruir la interfaz.
Los sistemas de caché tradicionales pueden reducir buena parte de ese trabajo. Por ejemplo, un plugin puede servir una versión estática de la página y el navegador puede reutilizar imágenes o estilos que ya tiene almacenados.
BFCache va un paso diferente. En lugar de acelerar la reconstrucción, intenta evitarla.
Cuando la restauración es posible, el navegador recupera el estado que había conservado. Esto permite que la navegación hacia atrás o hacia delante se sienta prácticamente instantánea.
No significa que WordPress haya generado la página más rápido. En muchos casos, significa que el navegador no ha necesitado volver a pedírsela.
BFCache puede conservar más información que una caché de recursos:
- el contenido de la página;
- la posición exacta del scroll;
- el estado visual de determinados componentes;
- valores introducidos en algunos formularios;
- parte del estado de JavaScript;
- la situación de menús, pestañas o elementos desplegables;
- la posición desde la que el usuario abandonó la página.
Este comportamiento es especialmente útil en páginas largas. Si una persona ha avanzado hasta la mitad de un listado, abre un elemento y después regresa, puede recuperar el punto exacto en el que estaba.
El resultado se parece menos a una nueva carga y más a volver a mostrar una aplicación que ya se encontraba abierta.
Un ejemplo sencillo en un blog de WordPress
Imaginemos la portada de un blog con diez artículos.
Un lector desplaza la página, encuentra un contenido interesante y entra en él. Después de leerlo, pulsa el botón de volver para seguir buscando otros artículos.
Sin BFCache, la portada puede reconstruirse y aparecer inicialmente en una posición distinta. Aunque la carga sea relativamente rápida, el lector percibe una interrupción.
Con BFCache, la página puede reaparecer inmediatamente en el mismo punto del listado.
En mi caso, esta es una de las situaciones en las que mejor se entiende su utilidad. No se trata únicamente de ahorrar unas décimas de segundo. Se trata de conservar el contexto del usuario.
Esa continuidad hace que la web parezca más estable, rápida y agradable.
BFCache no es lo mismo que la caché tradicional de WordPress
Uno de los errores más habituales consiste en pensar que BFCache es otro tipo de plugin de caché.
No lo es.
Los plugins de caché de WordPress, la caché del navegador, la caché del servidor y BFCache pueden mejorar el rendimiento, pero actúan en momentos y capas diferentes.
Una caché de página guarda o genera una versión preparada del HTML. Su objetivo es evitar que WordPress tenga que ejecutar todas las operaciones habituales cada vez que recibe una visita.
La caché del navegador suele conservar recursos descargados, como:
- imágenes;
- hojas de estilo;
- fuentes;
- archivos JavaScript;
- otros recursos estáticos.
Cuando el usuario vuelve a cargar una página, el navegador puede reutilizar esos archivos en lugar de descargarlos nuevamente.
BFCache no se limita a reutilizar recursos. Puede conservar el estado completo de una página que ya se encontraba abierta.
| Tecnología | Qué conserva o acelera | Cuándo actúa |
|---|---|---|
| Caché de página | HTML preparado o estático | Al solicitar una página |
| Caché del navegador | Imágenes, CSS, fuentes y scripts | Durante nuevas cargas |
| Caché de objetos | Resultados de consultas y datos internos | Durante la ejecución de WordPress |
| CDN | Recursos distribuidos desde servidores cercanos | Durante la descarga |
| BFCache | Estado completo de una página visitada | Al usar atrás o adelante |
Esta distinción es importante porque una web puede utilizar perfectamente un plugin de caché y, aun así, no ser compatible con BFCache.
También puede ocurrir lo contrario: una página sencilla puede restaurarse desde BFCache aunque su optimización general sea mejorable.
¿Sustituye BFCache a un plugin de caché?
No.
BFCache no sustituye:
- una buena configuración del servidor;
- la caché de página;
- la optimización de imágenes;
- la reducción del peso de JavaScript;
- la optimización de la base de datos;
- una CDN;
- un tema eficiente;
- un alojamiento adecuado.
Su beneficio aparece principalmente en un tipo concreto de navegación: volver a una página ya visitada o avanzar de nuevo hacia ella.
Si la primera carga tarda cinco segundos, BFCache no corrige ese problema. El usuario seguirá sufriendo una espera inicial demasiado larga.
En mi opinión, conviene entender BFCache como una capa adicional. Primero debemos conseguir que WordPress responda correctamente y que las páginas sean ligeras. Después podemos revisar si el navegador tiene libertad para restaurarlas cuando el usuario navega por el historial.
BFCache frente a Speculation Rules, prefetch y prerender
BFCache también suele confundirse con tecnologías de carga anticipada.
La diferencia principal es bastante sencilla:
- BFCache recupera una página que ya ha sido visitada.
- Prefetch o prerender intentan preparar una página que todavía no se ha abierto.
Las Speculation Rules permiten indicar al navegador qué enlaces podría interesarle anticipar. Dependiendo de la configuración y de la compatibilidad, el navegador puede descargar recursos o preparar páginas antes de que el usuario haga clic.
BFCache funciona después de una visita previa. Su objetivo es conservar o restaurar la página cuando utilizamos el historial.
Ambas tecnologías pueden conseguir que una navegación parezca instantánea, pero lo hacen en direcciones opuestas:
- una anticipa el futuro;
- la otra recupera el pasado.
Qué ventajas aporta BFCache a una web de WordPress
La principal ventaja de BFCache es la mejora de la velocidad percibida.
Una web no se siente rápida únicamente porque su servidor responda bien. También influye lo que ocurre al abrir menús, desplazarse por listados, volver a una categoría o recuperar el estado de una página.
BFCache puede aportar fluidez sin cambiar el diseño ni eliminar funcionalidades visibles.
Los botones de atrás y adelante siguen siendo una parte fundamental de la navegación web.
Muchas personas los utilizan constantemente para:
- comparar productos;
- consultar varios artículos;
- revisar resultados de búsqueda;
- volver a una categoría;
- alternar entre páginas informativas;
- recuperar una pantalla anterior.
Si cada regreso provoca una carga completa, la experiencia puede sentirse más lenta de lo necesario.
Cuando el navegador restaura la página desde BFCache, la respuesta puede ser inmediata. No tiene que volver a solicitar el documento, esperar al servidor y reconstruir toda la interfaz.
Esta mejora resulta especialmente perceptible en webs con páginas largas o listados amplios.
Recuperación de la posición del scroll y del estado de la página
La velocidad no es el único beneficio.
Recuperar el mismo punto de desplazamiento evita que el usuario tenga que buscar dónde estaba. Esto es importante en:
- categorías de productos;
- páginas de archivo;
- listados de noticias;
- directorios;
- comparativas;
- documentación extensa;
- resultados de búsqueda internos.
En una tienda WooCommerce, por ejemplo, una persona puede bajar hasta la mitad de una categoría, abrir un producto y después regresar al listado.
Si la categoría se carga desde cero y pierde su posición, la experiencia resulta frustrante. El usuario tiene que volver a desplazarse y localizar el producto por el que iba.
Con BFCache, puede recuperar exactamente el mismo contexto.
Por qué su efecto puede notarse más en dispositivos móviles
Considero que BFCache puede aportar todavía más valor en teléfonos móviles.
En una conexión rápida, una nueva carga puede tardar poco. En una red lenta, saturada o inestable, esa misma navegación puede implicar varios segundos de espera.
Si el navegador recupera la página desde memoria, evita depender nuevamente de la conexión y del tiempo de respuesta del servidor.
Además, en móviles es frecuente navegar de forma secuencial:
- Abrir un listado.
- Entrar en un resultado.
- Volver atrás.
- Abrir otro resultado.
- Repetir el proceso.
Cada interrupción se acumula. Una restauración rápida puede conseguir que el usuario siga explorando en lugar de abandonar la web.
Esto no significa que BFCache reduzca mágicamente el consumo de recursos en todos los casos ni que funcione siempre. Sin embargo, cuando es compatible, puede mejorar notablemente la sensación de continuidad.
Cómo saber si BFCache funciona en WordPress
Antes de instalar un plugin, modificar una cabecera o añadir código, debemos comprobar si realmente existe un problema.
No todas las páginas necesitan una intervención. Los navegadores modernos pueden utilizar BFCache automáticamente cuando consideran que la página es apta.
Nuestra tarea consiste en comprobar el comportamiento y revisar los motivos de exclusión cuando la restauración no se produce.
Comprobar BFCache con Chrome DevTools
Chrome incluye herramientas para analizar la compatibilidad de una página con BFCache.
El procedimiento puede variar ligeramente entre versiones, pero normalmente podemos hacer lo siguiente:
- Abrir la página que queremos analizar.
- Acceder a las herramientas para desarrolladores.
- Entrar en el panel Application.
- Buscar la sección relacionada con Back/Forward Cache.
- Ejecutar la prueba.
- Revisar si la página puede restaurarse.
- Consultar los motivos indicados cuando la prueba falla.
La utilidad de esta herramienta no consiste únicamente en mostrar un resultado positivo o negativo. También puede señalar qué condición está impidiendo la restauración.
Podríamos encontrar referencias a:
- encabezados incompatibles;
- eventos JavaScript;
- conexiones abiertas;
- comportamientos introducidos por scripts;
- restricciones de seguridad;
- características de la propia página.
No debemos asumir que el primer motivo detectado es el único. Al corregir un bloqueo, puede aparecer otro que antes permanecía oculto.
También podemos hacer una comprobación básica sin herramientas avanzadas:
- Abrir una página de WordPress.
- Desplazarnos hasta una zona concreta.
- Entrar en otra página.
- Pulsar el botón de volver.
- Observar la velocidad y la posición del scroll.
Esta prueba no es suficiente para confirmar técnicamente BFCache, pero puede revelar cambios evidentes.
Para obtener resultados más fiables, conviene repetirla en distintos escenarios:
- usuario desconectado;
- usuario conectado;
- página pública;
- formulario;
- categoría de WooCommerce;
- producto;
- carrito;
- página privada;
- móvil;
- escritorio.
También debemos probar más de un navegador. Una página puede comportarse de manera diferente según la implementación y las políticas de cada uno.
Interpretar los motivos de exclusión
Cuando una herramienta muestra que la página no es apta para BFCache, el siguiente paso es clasificar el bloqueo.
Podemos dividir las causas en cuatro grupos:
- Cabeceras HTTP, como determinadas directivas de caché.
- JavaScript, eventos o librerías incompatibles.
- Funcionalidades dinámicas, conexiones o estados activos.
- Decisiones del navegador, que no siempre dependen directamente de WordPress.
Esta clasificación evita aplicar soluciones a ciegas.
Por ejemplo, si el problema procede de un script de chat, modificar una cabecera de WordPress no servirá. Si el bloqueo está relacionado con información privada, eliminarlo sin medidas adicionales podría ser peligroso.
Por qué BFCache puede no funcionar en WordPress
Aunque BFCache es una función del navegador, WordPress y sus extensiones pueden crear condiciones que impidan utilizarla.
No existe una única causa universal. El resultado depende del tipo de página, del estado del usuario, de los plugins activos, del tema, del servidor y del código JavaScript.
La cabecera Cache-Control: no-store
Una de las causas más comentadas es la directiva:
Cache-Control: no-storeEsta instrucción indica que la respuesta no debe almacenarse. Históricamente, se ha utilizado en páginas sensibles o asociadas a sesiones para evitar que determinada información quede disponible después.
En WordPress puede aparecer en contextos relacionados con usuarios conectados y páginas que no deberían conservarse de forma convencional.
El problema es que no-store también puede impedir que algunos navegadores utilicen BFCache.
Esto ha provocado que muchos tutoriales propongan eliminar la directiva para “activar” BFCache. Sin embargo, hacerlo de forma indiscriminada no es una buena idea.
La cabecera puede estar protegiendo información que no debería reaparecer después de cerrar sesión. Antes de modificarla, debemos comprender por qué existe y qué páginas se verán afectadas.
Eventos JavaScript que impiden conservar la página
Algunos comportamientos de JavaScript pueden bloquear BFCache.
Los eventos utilizados para detectar que el usuario abandona una página han sido históricamente problemáticos. Determinados scripts pueden asumir que, al salir, la página será destruida completamente.
BFCache rompe esa suposición, porque la página puede quedar congelada y restaurarse después.
Los plugins o temas pueden añadir lógica relacionada con:
unload;beforeunload;- conexiones persistentes;
- reproductores;
- chats;
- seguimiento;
- validación de formularios;
- herramientas de terceros.
No todos estos elementos bloquean siempre BFCache, pero forman parte del diagnóstico.
Plugins, temas y scripts de terceros incompatibles
Una instalación de WordPress no está compuesta únicamente por el núcleo.
Cada plugin puede cargar archivos, añadir cabeceras, iniciar conexiones o modificar el comportamiento de la página. Lo mismo ocurre con el tema, el sistema de analítica, los anuncios, los chats y las integraciones externas.
Por eso, dos webs aparentemente similares pueden obtener resultados distintos.
Una estrategia útil para localizar conflictos consiste en realizar pruebas controladas en un entorno de desarrollo:
- Comprobar el estado inicial.
- Desactivar temporalmente plugins no esenciales.
- Repetir la prueba.
- Activarlos uno a uno.
- Identificar cuándo reaparece el bloqueo.
Esta metodología requiere tiempo, pero es más fiable que copiar código encontrado en un tutorial.
Formularios, conexiones activas y contenido dinámico
BFCache puede resultar más delicado en páginas que cambian constantemente.
Debemos prestar atención a:
- formularios enviados;
- chats en tiempo real;
- reproductores multimedia;
- paneles de usuario;
- carritos;
- precios;
- existencias;
- notificaciones;
- estados de reserva;
- resultados personalizados;
- conexiones abiertas.
Al restaurar una página, el estado visible puede corresponder al momento en que el usuario la abandonó.
Esto no es necesariamente un error. Es parte de la naturaleza de BFCache. Sin embargo, algunos componentes deben reaccionar a la restauración y actualizarse.
Por qué eliminar un solo bloqueo puede no ser suficiente
Una página puede presentar varios motivos de exclusión al mismo tiempo.
Supongamos que encontramos no-store y lo eliminamos. La prueba posterior podría seguir fallando porque también existe un evento incompatible o una conexión activa.
Esto explica por qué algunas soluciones parecen funcionar en una web y no en otra.
BFCache no se activa mediante un interruptor único. El navegador evalúa un conjunto de condiciones y decide si puede conservar la página de forma segura.
Cómo habilitar la compatibilidad con BFCache en WordPress
La expresión “activar BFCache” es útil desde el punto de vista de búsqueda, pero no describe exactamente el proceso.
No instalamos BFCache dentro de WordPress. La función ya pertenece al navegador.
Lo que podemos hacer es eliminar bloqueos innecesarios, adaptar determinados comportamientos y comprobar que la restauración es segura.
Antes de cambiar nada: copia de seguridad y entorno de pruebas
No recomiendo modificar cabeceras o sesiones directamente en producción.
Antes de hacer cambios:
- Crea una copia de seguridad completa.
- Utiliza un entorno de pruebas.
- Registra el comportamiento actual.
- Comprueba usuarios conectados y desconectados.
- Identifica qué páginas muestran información sensible.
- Revisa WooCommerce, formularios y áreas privadas.
- Prepara una forma rápida de revertir los cambios.
También conviene anotar los resultados iniciales. Sin una referencia anterior, será difícil saber si la intervención ha mejorado algo o ha creado una incompatibilidad.
Utilizar el plugin Instant Back/Forward
Una opción es utilizar un plugin desarrollado específicamente para mejorar la compatibilidad con BFCache.
La principal ventaja de un plugin dedicado es que puede aplicar una estrategia más completa que un fragmento aislado. Por ejemplo, puede modificar determinadas cabeceras y añadir mecanismos para gestionar sesiones o cierres de sesión.
Esto no elimina la necesidad de realizar pruebas.
Después de instalarlo debemos revisar:
- páginas públicas;
- usuarios conectados;
- inicio y cierre de sesión;
- administración;
- formularios;
- WooCommerce;
- contenido privado;
- navegadores diferentes.
El plugin tampoco puede solucionar automáticamente todos los bloqueos. Un script del tema, una herramienta de terceros o una configuración del servidor pueden seguir impidiendo BFCache.
Habilitar BFCache sin plugin
También es posible trabajar mediante código personalizado, pero esta vía requiere más conocimientos.
Crea un nuevo snippet y pega este código sin añadir <?php:
/**
* Mejora la compatibilidad de WordPress con bfcache.
*
* Evita que los scripts puedan utilizar el evento "unload",
* uno de los motivos habituales por los que el navegador
* descarta la caché atrás/adelante.
*/
function hostingtg_compatibilidad_bfcache( $headers ) {
// No aplicar en administración, AJAX, REST ni a usuarios conectados.
if (
is_admin() ||
wp_doing_ajax() ||
is_user_logged_in() ||
( function_exists( 'wp_is_json_request' ) && wp_is_json_request() )
) {
return $headers;
}
$permissions_policy = isset( $headers['Permissions-Policy'] )
? trim( $headers['Permissions-Policy'] )
: '';
// Añadir la directiva sin eliminar otras políticas existentes.
if ( stripos( $permissions_policy, 'unload=' ) === false ) {
$headers['Permissions-Policy'] = $permissions_policy
? $permissions_policy . ', unload=()'
: 'unload=()';
}
return $headers;
}
add_filter( 'wp_headers', 'hostingtg_compatibilidad_bfcache', 20 );Configuración en Code Snippets
Ponle, por ejemplo, este nombre:
Compatibilidad bfcache WordPressSelecciona:
Ejecutar el fragmento en todas partesDespués, guarda y activa el snippet.
Vacía la caché
Tras activarlo, vacía:
- La caché del plugin de WordPress.
- La caché de Cloudflare, si lo utilizas.
- La caché de Nginx, Varnish o del servidor.
- La caché del navegador.
Por qué no conviene copiar cualquier fragmento de código
Los tutoriales sobre rendimiento suelen ofrecer soluciones breves porque son fáciles de aplicar. El problema es que las cabeceras de caché tienen implicaciones que no siempre son visibles.
Un fragmento puede:
- afectar a usuarios conectados;
- permitir restaurar contenido privado;
- interferir con un plugin de seguridad;
- modificar páginas que deberían quedar excluidas;
- quedar obsoleto tras una actualización;
- utilizar un hook inadecuado;
- entrar en conflicto con el servidor o la CDN.
Además, algunas soluciones eliminan la protección, pero no añaden un mecanismo alternativo para invalidar la página después de cerrar sesión.
Una mejora de rendimiento deja de ser una mejora si introduce un problema de privacidad.
Cómo comprobar el resultado después de aplicar los cambios
Después de cualquier modificación debemos repetir exactamente las mismas pruebas iniciales.
La comprobación debería incluir:
- Chrome DevTools;
- navegación manual;
- usuario conectado;
- usuario desconectado;
- cierre de sesión;
- páginas privadas;
- formularios;
- WooCommerce;
- móvil;
- varios navegadores.
También debemos revisar el comportamiento después de actualizar plugins o WordPress. La compatibilidad puede cambiar con nuevas versiones, scripts o configuraciones.
BFCache en WooCommerce: ventajas y riesgos
WooCommerce es uno de los escenarios donde BFCache puede resultar más atractivo y, al mismo tiempo, más delicado.
Una tienda contiene numerosos recorridos de ida y vuelta:
- categoría y producto;
- buscador y ficha;
- carrito y catálogo;
- comparador y resultados;
- productos relacionados;
- filtros y listados.
La posibilidad de regresar inmediatamente al punto anterior puede mejorar mucho la experiencia de compra.
Volver al mismo punto de una categoría de productos
Imaginemos una categoría con cuarenta productos.
El visitante baja por el listado, abre una ficha y revisa sus características. Después decide regresar para comparar otra opción.
Sin una buena restauración, la categoría puede volver a cargar desde el principio. El usuario pierde la posición y tiene que buscar nuevamente dónde estaba.
Con BFCache, el navegador puede recuperar el listado en el mismo punto.
En mi opinión, este ejemplo muestra mejor que ningún otro el valor real de la tecnología. El beneficio no es únicamente técnico. Reduce fricción durante una acción directamente relacionada con la compra.
Carritos, precios y disponibilidad desactualizados
El riesgo aparece cuando la página restaurada contiene información que puede haber cambiado.
Por ejemplo:
- el número de productos del carrito;
- un precio actualizado;
- una promoción finalizada;
- la disponibilidad;
- una variación seleccionada;
- un mensaje de stock;
- los gastos de envío;
- el estado de una sesión.
La página recuperada puede mostrar inicialmente el estado que tenía cuando se abandonó.
Por eso, una implementación compatible con BFCache puede necesitar actualizar determinados componentes al producirse la restauración.
No todas las páginas requieren el mismo tratamiento. Una categoría pública puede ser menos sensible que el carrito o la cuenta del cliente.
Qué probar con usuarios conectados y sesiones activas
En WooCommerce debemos realizar pruebas con varios perfiles:
- visitante sin sesión;
- cliente conectado;
- administrador;
- usuario que acaba de iniciar sesión;
- usuario que acaba de cerrar sesión;
- cliente con productos en el carrito;
- cliente que modifica cantidades;
- usuario que completa una compra.
Después de cada acción, conviene navegar hacia otra página y volver atrás.
Debemos comprobar que:
- el carrito muestra la cantidad correcta;
- el estado de la sesión es coherente;
- no aparece contenido privado tras cerrar sesión;
- los avisos no se repiten;
- los formularios no se reenvían;
- los precios son correctos;
- la cuenta corresponde al usuario actual.
Páginas que conviene excluir o tratar con más cuidado
No es necesario conseguir que todas las URLs utilicen BFCache a cualquier precio.
Las páginas más delicadas suelen ser:
- carrito;
- finalizar compra;
- mi cuenta;
- pedidos;
- datos personales;
- formularios con información sensible;
- páginas con estados que cambian rápidamente.
En algunas situaciones puede ser preferible mantener restricciones. En otras, se puede permitir BFCache y actualizar los componentes necesarios al restaurar la página.
La decisión debe basarse en pruebas, no en una regla universal.
Seguridad y privacidad al utilizar BFCache
El rendimiento no puede analizarse de forma independiente a la privacidad.
Una página que se restaura rápidamente puede resultar problemática si muestra información que debería haber desaparecido.
Este riesgo es especialmente importante en equipos compartidos o después de cerrar sesión.
Qué puede ocurrir después de cerrar sesión
Supongamos que un usuario entra en una zona privada, consulta sus datos y después cierra sesión.
Si el navegador conserva la página anterior y permite restaurarla sin ninguna medida adicional, al pulsar atrás podría mostrar temporalmente el contenido privado.
Aunque la sesión del servidor ya haya terminado, la representación almacenada puede seguir existiendo en memoria.
Por eso, las estrategias de compatibilidad con BFCache deben tener en cuenta el cierre de sesión y la invalidación de páginas sensibles.
No basta con comprobar que el servidor rechaza nuevas solicitudes. BFCache puede restaurar una página sin hacer una nueva petición en ese momento.
Restauración de páginas privadas desde el historial
Las zonas privadas incluyen muchos escenarios:
- cuentas de clientes;
- cursos;
- membresías;
- intranets;
- paneles;
- historiales de pedidos;
- datos personales;
- documentos;
- administración de WordPress.
Cada proyecto necesita una política propia.
En una web pública, permitir la restauración de artículos puede ser sencillo. En una plataforma sanitaria, financiera o empresarial, las restricciones deben ser mucho más estrictas.
La seguridad y la privacidad deben tener prioridad sobre una mejora perceptible de velocidad.
Cómo evitar mostrar información antigua o sensible
Las soluciones pueden combinar varias medidas:
- mantener restricciones en páginas sensibles;
- invalidar estados al cerrar sesión;
- detectar restauraciones;
- actualizar componentes dinámicos;
- verificar la sesión;
- recargar cuando la información ya no sea válida;
- diferenciar páginas públicas y privadas;
- limitar los cambios a contextos seguros.
La implementación exacta dependerá de la arquitectura de la web.
Mi recomendación es no pensar en BFCache como una optimización global que deba imponerse a todas las páginas. Resulta más útil trabajar con una estrategia selectiva.
Errores frecuentes al optimizar BFCache en WordPress
BFCache parece sencillo cuando se resume en una frase: quitar un bloqueo y conseguir que el botón atrás sea más rápido.
En la práctica, los errores suelen aparecer por simplificar demasiado el problema.
Intentar activar BFCache como una función de WordPress
BFCache no es una característica que WordPress encienda o apague directamente.
El navegador decide si conserva una página. WordPress, el servidor, los plugins y los scripts pueden crear condiciones que influyan en esa decisión.
Por eso, instalar un plugin o modificar una cabecera no garantiza que el resultado sea positivo.
La pregunta correcta no es únicamente “¿cómo activo BFCache?”, sino:
¿Qué está impidiendo que el navegador conserve esta página y es seguro eliminar ese bloqueo?
Eliminar no-store de forma indiscriminada
La directiva no-store puede impedir BFCache, pero también puede cumplir una función relacionada con la privacidad.
Eliminarla en toda la web sin distinguir usuarios, páginas o estados puede provocar comportamientos inesperados.
Antes de hacerlo debemos identificar:
- dónde aparece;
- por qué se genera;
- qué contenido protege;
- qué mecanismo alternativo se utilizará;
- cómo se comporta el cierre de sesión.
Probar únicamente como usuario desconectado
Una página pública puede funcionar perfectamente con BFCache mientras que la versión para usuarios conectados presenta problemas.
Las pruebas deben incluir:
- sesiones activas;
- cierres de sesión;
- carritos;
- zonas privadas;
- formularios;
- cambios de permisos.
También conviene probar en una ventana normal y no limitarse al modo incógnito, porque algunas condiciones pueden ser diferentes.
BFCache puede hacer que volver atrás sea instantáneo, pero eso no significa que la web tenga un buen rendimiento general.
Debemos seguir analizando:
- la primera carga;
- el tiempo de respuesta del servidor;
- las imágenes;
- JavaScript;
- CSS;
- fuentes;
- consultas;
- plugins;
- Core Web Vitals;
- estabilidad visual;
- capacidad de respuesta.
BFCache complementa esas mejoras. No las reemplaza.
Aplicar cambios directamente en producción
Este es uno de los errores más arriesgados.
Una modificación aparentemente sencilla puede afectar a sesiones, contenido privado o procesos de compra.
La secuencia correcta es:
- Crear un entorno de pruebas.
- Registrar el comportamiento inicial.
- Aplicar el cambio.
- Repetir las pruebas.
- Revisar privacidad y datos dinámicos.
- Implementar en producción.
- Monitorizar.
¿Merece la pena optimizar BFCache en WordPress?
En muchos proyectos, sí.
BFCache puede mejorar una acción que los usuarios realizan constantemente: entrar en una página y volver a la anterior.
Su valor es especialmente claro en:
- blogs;
- tiendas;
- directorios;
- medios;
- páginas de resultados;
- catálogos;
- documentación;
- móviles;
- conexiones inestables.
Sin embargo, no todas las webs necesitan la misma intervención.
En una página pública y sencilla, el navegador puede utilizar BFCache sin que tengamos que hacer nada. En una tienda o una zona privada, quizá sea necesario adaptar componentes y gestionar la sesión con más cuidado.
Personalmente, no intentaría forzar BFCache de manera indiscriminada. Primero comprobaría qué páginas ya son compatibles. Después analizaría los bloqueos y decidiría cuáles pueden eliminarse sin comprometer la precisión de los datos o la privacidad.
El objetivo no debería ser obtener un resultado positivo en todas las pruebas. El objetivo debe ser mejorar la navegación sin introducir errores.
Sobre BFCache
BFCache es una función del navegador capaz de conservar temporalmente el estado completo de una página y restaurarlo cuando el usuario utiliza los botones de atrás o adelante.
En WordPress, esta tecnología puede conseguir que la navegación parezca mucho más rápida. Un lector puede volver a la portada de un blog sin perder su posición. Un cliente puede regresar a una categoría de WooCommerce y continuar comparando productos desde el mismo punto.
El visitante no necesita saber qué está ocurriendo. Simplemente siente que la web responde mejor.
Sin embargo, BFCache no sustituye a la caché de página, a un buen alojamiento ni a una optimización completa. Tampoco debe activarse a ciegas.
Las cabeceras HTTP, los eventos JavaScript, los plugins, las sesiones y el contenido dinámico pueden impedir la restauración o hacer que resulte inadecuada.
Por eso, el mejor enfoque consiste en:
- Comprobar si BFCache funciona.
- Identificar los motivos de exclusión.
- Diferenciar páginas públicas y sensibles.
- Aplicar cambios en un entorno de pruebas.
- Revisar usuarios conectados, formularios y WooCommerce.
- Confirmar que no aparece información antigua o privada.
- Repetir las pruebas en varios navegadores.
En mi caso, considero que BFCache merece más atención dentro de las estrategias de rendimiento de WordPress. No porque sea una solución milagrosa, sino porque puede mejorar de forma muy perceptible una parte cotidiana de la experiencia de usuario.
Cuando se combina con una web ligera, un servidor bien configurado y un sistema de caché eficiente, puede convertir una navegación normal en una experiencia mucho más fluida.
Dudas de la comunidad
¿Qué es BFCache en WordPress?
BFCache o Back/Forward Cache es una función del navegador que puede conservar el estado completo de una página visitada. Cuando el usuario pulsa los botones de atrás o adelante, el navegador puede restaurarla sin realizar una nueva carga completa.
WordPress no incorpora BFCache como un sistema propio. Su configuración, cabeceras, plugins y scripts pueden facilitar o impedir que el navegador lo utilice.
¿BFCache sustituye a la caché de página?
No. La caché de página acelera la generación y entrega del HTML. BFCache intenta evitar una nueva carga cuando el usuario regresa a una página que ya había visitado.
Ambas tecnologías son complementarias.
¿Cómo puedo comprobar si BFCache está funcionando?
Puedes utilizar el panel Back/Forward Cache de Chrome DevTools y realizar pruebas manuales navegando entre varias páginas.
También conviene comprobar la posición del scroll y revisar si el navegador indica algún motivo de exclusión.
¿Por qué WordPress puede enviar la directiva no-store?
WordPress puede utilizar cabeceras restrictivas en contextos relacionados con usuarios conectados o contenido que no debería almacenarse.
La finalidad puede estar vinculada con la privacidad y la seguridad. Por eso no conviene eliminar no-store sin analizar las consecuencias.
¿Es seguro eliminar Cache-Control: no-store?
No siempre.
Depende de la página, del tipo de contenido, del estado del usuario y de las medidas utilizadas para gestionar el cierre de sesión y la información privada.
La modificación debe probarse en un entorno seguro y no debería aplicarse globalmente sin conocer sus efectos.
¿BFCache funciona con WooCommerce?
Puede funcionar y mejorar mucho la navegación entre categorías y productos.
Sin embargo, es necesario comprobar carritos, precios, disponibilidad, sesiones, cuentas de cliente y páginas de compra. Algunos componentes pueden necesitar actualizarse cuando la página se restaura.
¿Puede BFCache mostrar información desactualizada?
Sí. La página restaurada puede reflejar el estado que tenía cuando el usuario la abandonó.
Por eso deben revisarse los elementos dinámicos, como carritos, notificaciones, precios, estados de sesión y formularios.
¿BFCache mejora los Core Web Vitals?
BFCache puede mejorar la experiencia al navegar hacia atrás y hacia delante, pero no sustituye la optimización de las métricas de la primera carga.
Una restauración desde BFCache puede sentirse instantánea, aunque la página siga teniendo problemas de rendimiento al abrirse por primera vez.
No necesariamente. Los navegadores pueden aplicar criterios y restricciones diferentes. Además, su comportamiento puede cambiar con nuevas versiones.
Conviene probar la web en los navegadores utilizados por la audiencia del proyecto.
¿Conviene habilitar BFCache en todas las páginas?
No como regla general.
Las páginas públicas suelen ser las candidatas más sencillas. Los carritos, áreas privadas, administraciones, formularios y páginas con datos sensibles requieren más precauciones.
La compatibilidad debe decidirse según el funcionamiento real de cada sección.
Opinión Personal
BFCache merece mucha más atención dentro de la optimización de WordPress. No es una solución milagrosa ni sustituye a un buen alojamiento, una caché correctamente configurada o una web ligera, pero puede mejorar de forma muy perceptible la navegación entre páginas ya visitadas.
Lo que más valoro de BFCache es que el usuario no necesita saber que existe. Simplemente pulsa el botón de volver y encuentra la página prácticamente al instante, en la misma posición y con el contexto que había dejado. En blogs, catálogos y tiendas WooCommerce, esa sensación de continuidad puede marcar una gran diferencia.
Eso sí, no recomiendo eliminar bloqueos o modificar cabeceras sin analizar cada proyecto. En páginas privadas, carritos, formularios o zonas con usuarios conectados, es fundamental comprobar que la información se restaura correctamente y que no aparecen datos antiguos o sensibles.
En definitiva, considero que BFCache es una optimización muy interesante cuando se implementa con criterio, pruebas y sentido común.
¿Has comprobado si BFCache funciona en tu WordPress? Cuéntame en los comentarios qué resultado has obtenido, qué problemas encontraste o qué solución utilizaste. Tu experiencia puede ayudar a otros usuarios.
