FlyingPress 5.6 introduce una novedad importante para los sitios WordPress con mucho contenido dinámico: caché persistente de objetos con Redis integrada desde el propio panel del plugin. La mejora permite activar Redis Object Cache con un interruptor dentro de la pestaña de caché, ver el estado de conexión y monitorizar métricas como uso de memoria y cache hit ratio sin instalar un plugin adicional de object cache.
El movimiento es relevante porque FlyingPress ya era conocido por su enfoque en page caching, optimización de CSS y JavaScript, imágenes, fuentes, CDN y Core Web Vitals. Con Redis, entra en una capa distinta del rendimiento de WordPress: la reducción de consultas repetidas a la base de datos en páginas que no siempre pueden servirse como HTML estático.
La actualización llega con un matiz importante. FlyingPress 5.6.0 incorporó Object Caching with Redis el 24 de junio de 2026, pero ese mismo día apareció la versión 5.6.1 para corregir un error crítico que afectaba a algunos sitios tras activar la caché de objetos. Para administradores y agencias, la recomendación lógica es no quedarse en la 5.6.0 y actualizar directamente a la versión corregida antes de probar la función en producción.
La caché de página y la caché de objetos resuelven problemas distintos. La primera guarda una versión final del HTML de una página y la sirve sin tener que ejecutar todo WordPress, PHP y consultas MySQL en cada visita. Es especialmente útil para páginas públicas que no cambian para cada usuario, como posts, páginas corporativas, categorías o landing pages.
Redis Object Cache trabaja en otra capa. Guarda en memoria resultados de consultas y objetos internos de WordPress para que, cuando el sistema vuelva a necesitar los mismos datos, no tenga que pedirlos otra vez a MySQL. Esto afecta a opciones del sitio, menús, metadatos, consultas de posts, datos de usuarios, taxonomías y otros elementos que WordPress carga de forma constante.
| Capa de caché | Qué almacena | Dónde ayuda más |
|---|---|---|
| Page cache | HTML final de una página | Visitantes anónimos y páginas públicas |
| Object cache con Redis | Objetos y resultados de consultas | WooCommerce, wp-admin, usuarios logueados y zonas dinámicas |
| CDN cache | Archivos estáticos o HTML en red distribuida | Audiencias geográficas amplias |
| Browser cache | Recursos en el navegador del usuario | Visitas repetidas y activos estáticos |
La diferencia práctica se ve en los sitios que no pueden cachear todo como página estática. Un carrito de WooCommerce, un checkout, un panel de usuario, una zona de miembros o una página personalizada para usuarios logueados siguen necesitando construir contenido en tiempo real. Ahí Redis puede reducir trabajo de base de datos y mejorar respuesta del servidor.
WooCommerce es uno de los casos donde Redis puede tener más sentido. Una tienda online no vive solo de fichas de producto públicas. También tiene carrito, checkout, cuenta de cliente, filtros, stock, cupones, pedidos, sesiones y consultas que dependen del usuario. Muchas de esas rutas no deben servirse desde una caché de página convencional porque contienen información personalizada o sensible.
En el ejemplo mostrado por FlyingPress, una página de tienda pasaba de más de 300 consultas a solo 35 tras activar Redis y recargar una vez la página, con una reducción clara del tiempo dedicado a consultas. Es una prueba concreta de laboratorio o demo, no una promesa universal para cualquier instalación, pero ilustra bien el tipo de beneficio que puede aportar la caché persistente de objetos.
El primer acceso después de activar Redis puede no mejorar, e incluso parecer más lento, porque la caché está vacía y debe poblarse. La lectura correcta llega en peticiones posteriores, cuando WordPress empieza a reutilizar datos ya guardados en memoria.
| Tipo de sitio | Redis Object Cache puede aportar |
| Blog pequeño con páginas estáticas | Mejora limitada si la page cache ya funciona bien |
| Medio digital con mucho tráfico | Menos carga en base de datos y wp-admin más ágil |
| WooCommerce | Mejor rendimiento en carrito, checkout y cuenta |
| Membresías | Mejor respuesta en zonas logueadas y dashboards |
| LMS o comunidad | Menos consultas repetidas para usuarios activos |
| Multisite | Potencial alto, pero exige configuración cuidadosa de prefijos y bases |
Redis no arregla una tienda mal optimizada por sí solo. Si hay plugins pesados, consultas lentas, autoload inflado, temas con mala arquitectura o hosting insuficiente, la caché ayuda, pero no sustituye al diagnóstico.
La novedad de FlyingPress es la integración. Si el hosting ya ofrece Redis, el plugin intenta conectarse automáticamente. En FlyingHost, según la explicación de la compañía, Redis está preconfigurado y listo para usar, con una instancia dedicada por sitio. En otros proveedores puede ser necesario pedir los datos de conexión o añadir constantes en wp-config.php.
Los requisitos son claros: WordPress con FlyingPress, un servidor Redis accesible, la extensión PHP phpredis instalada y permiso para escribir el drop-in object-cache.php dentro de wp-content. Ese drop-in es importante porque WordPress solo puede usar una implementación activa de object cache a la vez. Por tanto, no se debe mantener otro plugin de Redis Object Cache activo en paralelo.
| Requisito | Por qué importa |
| Redis disponible en el servidor | Sin Redis no hay caché persistente de objetos |
Extensión PHP phpredis | Permite a PHP comunicarse con Redis de forma eficiente |
Permiso para escribir en wp-content | FlyingPress necesita instalar object-cache.php |
| No usar otro drop-in de object cache | Solo puede haber un object-cache.php activo |
| Configuración de host/puerto/socket | Algunos hostings no usan valores por defecto |
| Prefijo de claves | Evita colisiones entre sitios o entornos |
Las constantes habituales incluyen WP_REDIS_HOST, WP_REDIS_PORT, WP_REDIS_PASSWORD, WP_REDIS_DATABASE, WP_REDIS_SCHEME, WP_REDIS_PATH y WP_REDIS_PREFIX. En la mayoría de entornos gestionados el usuario no debería inventar estos valores: debe obtenerlos del proveedor de hosting.
Uno de los aciertos de FlyingPress es mostrar métricas dentro del dashboard. El cache hit ratio indica con qué frecuencia WordPress encuentra en Redis los datos que busca en lugar de reconstruirlos o consultarlos de nuevo en MySQL. Un ratio alto suele indicar que la caché está aprovechándose bien. Un ratio bajo puede significar que el sitio tiene consultas muy variables, poca reutilización, purgas demasiado frecuentes o una configuración que no encaja con el patrón de tráfico.
El uso de memoria de Redis también importa. Una caché sin control puede crecer, expulsar claves o competir con otros procesos si el servidor va justo de RAM. En servidores pequeños, activar Redis sin monitorizar puede desplazar el problema en vez de resolverlo. En tiendas, medios o intranets con tráfico serio, medir memoria, expiración de claves y comportamiento tras purgas es parte del trabajo.
| Métrica | Qué indica |
| Cache hit ratio | Porcentaje de lecturas resueltas desde Redis |
| Redis memory usage | Memoria consumida por objetos cacheados |
| Query count | Número de consultas MySQL por carga |
| Query time | Tiempo invertido en base de datos |
| TTFB | Tiempo hasta el primer byte desde el servidor |
| CPU load | Carga de proceso PHP/MySQL tras activar Redis |
Para una prueba seria, conviene medir antes y después con Query Monitor, logs del servidor, New Relic, Grafana, el panel del hosting o herramientas similares. Lo importante no es solo ver una mejora en una página concreta, sino comprobar que el sitio se comporta mejor bajo carga real.
Hasta ahora, muchos administradores instalaban plugins como Redis Object Cache para habilitar esta capa en WordPress. FlyingPress 5.6 reduce esa dependencia al integrarlo dentro de su propio flujo. Esto puede ser cómodo para usuarios que quieren mantener menos plugins y centralizar la optimización en una sola interfaz.
La ventaja es clara: menos piezas, menos pantallas y una experiencia más guiada. La posible desventaja es que los usuarios avanzados que necesitan configuraciones complejas de Redis, clustering, replicación, Sentinel, métricas más profundas o soporte empresarial pueden seguir prefiriendo soluciones especializadas como Object Cache Pro o configuraciones gestionadas por el hosting.
| Enfoque | Ventaja | Cuándo encaja |
| FlyingPress Redis Object Cache | Integración sencilla y menos plugins | Sitios que ya usan FlyingPress y Redis básico |
| Plugin Redis Object Cache dedicado | Más control específico de Redis | Administradores que quieren una herramienta separada |
| Object Cache Pro | Funciones avanzadas y soporte especializado | WooCommerce grande, multisite, entornos críticos |
| Redis gestionado por hosting | Menos carga operativa para el usuario | Empresas que delegan infraestructura |
La integración de FlyingPress no elimina el conocimiento técnico necesario. Hace más accesible una función que muchos sitios dinámicos deberían valorar, pero Redis sigue siendo infraestructura.
Antes de activar la función en producción, conviene revisar si el hosting soporta Redis y phpredis, desactivar cualquier plugin de object cache existente y hacer una copia de seguridad. También es prudente probar primero en staging, sobre todo si se trata de WooCommerce, membresías, LMS o sitios con usuarios logueados.
Después de activarlo, hay que comprobar que FlyingPress muestra conexión correcta, memoria en uso y métricas de hit ratio. A continuación conviene navegar por páginas dinámicas, wp-admin, carrito, cuenta de usuario y checkout. Si se detectan datos obsoletos o comportamientos extraños, puede purgarse la caché de objetos desde el panel y revisar exclusiones, sesiones, cookies y compatibilidad con plugins.
| Paso | Recomendación |
| 1 | Actualizar a FlyingPress 5.6.1 o superior |
| 2 | Confirmar soporte Redis con el hosting |
| 3 | Desactivar otros plugins de object cache |
| 4 | Probar en staging si el sitio es crítico |
| 5 | Activar Object Cache en FlyingPress → Caching |
| 6 | Revisar estado de conexión y métricas |
| 7 | Medir consultas, TTFB y comportamiento dinámico |
| 8 | Purgar object cache si hay datos obsoletos |
La versión 5.6.1 debería ser el punto de partida mínimo, porque corrige el error crítico detectado tras la introducción de la función. En sitios de clientes, activar una capa persistente de caché sin probar puede provocar incidencias difíciles de detectar al principio.
FlyingPress 5.6 refuerza una idea que cada vez se ve más en WordPress: la optimización ya no puede quedarse solo en minificar archivos y generar HTML estático. Los sitios modernos tienen ecommerce, usuarios logueados, contenido personalizado, paneles, buscadores, filtros, automatizaciones y zonas que no encajan en una caché de página tradicional.
Redis Object Cache ayuda justo en esa frontera. Reduce consultas repetidas, aligera MySQL y puede hacer más fluido wp-admin, WooCommerce y las zonas dinámicas. Pero su efecto depende del sitio, del hosting, de la calidad de plugins y temas, del tamaño de la base de datos y del tráfico real.
Para blogs sencillos, FlyingPress con page cache bien configurada puede ser suficiente. Para tiendas, membresías y proyectos con carga dinámica, Redis merece una prueba seria. La clave está en medir, no en activarlo por moda.
FlyingPress ha dado un paso lógico al integrar Redis en su panel. Hace más fácil activar una capa de rendimiento que antes solía requerir otro plugin o configuración manual. Ahora el reto está en usarla con criterio: versión corregida, Redis bien configurado, métricas observadas y pruebas en las páginas donde WordPress realmente trabaja.
¿Redis Object Cache sustituye a la caché de página de FlyingPress?
No. La caché de página guarda HTML final. Redis Object Cache guarda objetos y resultados de consultas para reducir trabajo de base de datos, sobre todo en páginas dinámicas.
¿Qué versión de FlyingPress conviene usar?
La función llegó en FlyingPress 5.6.0, pero la 5.6.1 corrigió un error crítico relacionado con object caching. Lo recomendable es usar 5.6.1 o superior.
¿Redis ayuda en WooCommerce?
Sí, puede ayudar especialmente en carrito, checkout, cuenta de usuario, páginas de usuarios logueados y otras zonas que no se sirven como HTML estático.
¿Puedo usar otro plugin de Redis al mismo tiempo?
No es recomendable. WordPress solo puede tener un drop-in object-cache.php activo. Mantener varios sistemas de object cache puede generar conflictos.
