En el ecosistema WordPress, donde la velocidad ya no es un “extra” sino un requisito —por SEO, conversión y experiencia de usuario—, la optimización de imágenes sigue siendo uno de los frentes más determinantes… y, paradójicamente, de los más fragmentados. Muchos sitios han terminado acumulando plugins: uno para caché, otro para optimización de CSS/JS, otro para imágenes y, a veces, un cuarto para analítica de Core Web Vitals. FlyingPress, un plugin que se había posicionado como solución integral de rendimiento, ha decidido atacar precisamente ese punto débil con su versión 5.3: la optimización de imágenes pasa a estar integrada de forma nativa.
La novedad es relevante no tanto por “hacer lo mismo que otros”, sino por el enfoque: FlyingPress plantea la optimización de imágenes como un proceso centralizado, controlable y descargado del hosting, con procesamiento en la nube de la propia plataforma. En un contexto donde muchos administradores evitan recomprimir bibliotecas completas por miedo a picos de CPU, bloqueos o degradación visual, el movimiento busca reducir fricción operativa.
El mensaje de producto es claro: todo el procesamiento ocurre en servidores cloud de FlyingPress, no en el servidor WordPress. Esto tiene implicaciones directas para entornos compartidos o VPS ajustados de recursos: se reduce el riesgo de saturación de CPU durante tareas masivas, y se evita que el proceso de optimización compita con PHP, la base de datos o el tráfico real del sitio.
FlyingPress 5.3 permite definir:
La propia comunicación del producto insiste en un punto que conviene tomarse en serio: realizar copia de seguridad antes de optimizar en bloque. En la práctica, es la “red” que permite experimentar con AVIF/lossy sin convertir la biblioteca multimedia en un punto de no retorno.
En optimización de imágenes, la mayoría de problemas no vienen del algoritmo, sino del proceso: convertir toda la librería de golpe, romper compatibilidades, perder originales, o forzar un formato sin fallback. FlyingPress intenta resolver esto aportando un flujo de trabajo más conservador:
El ejemplo del vídeo de la función (mostrando una reducción de 8,2 MB a 1,5 MB en un caso concreto) sirve para ilustrar el objetivo, aunque en rendimiento real las ganancias dependen mucho del tipo de imagen, su resolución y el punto de compresión elegido.
La posibilidad de elegir formato es, probablemente, la parte más estratégica del cambio. WebP sigue siendo una apuesta “segura” por soporte, mientras que AVIF suele destacar cuando el objetivo es exprimir peso al máximo sin degradar demasiado. La compatibilidad en navegadores es alta en ambos casos, aunque WebP mantiene ventaja histórica y aún se percibe como opción de mínimo riesgo.
Tabla 1 — Comparativa rápida de formatos (en clave WordPress)
| Formato | Ventaja principal | Riesgo típico | Cuándo suele encajar mejor |
|---|---|---|---|
| AVIF | Muy buen ratio calidad/tamaño | Compatibilidad y pipeline de generación más exigente según entorno | Sitios con muchas imágenes “hero”, catálogo y móvil como prioridad |
| WebP | Gran compatibilidad y buen tamaño | Menos eficiente que AVIF en ciertos casos | Migraciones “sin sorpresas”, medios y corporativas con bibliotecas grandes |
| Original | Cero cambios y máxima previsibilidad | Peso y CWV peor si no se optimiza | Sitios con pocas imágenes o donde prima fidelidad absoluta sin conversión |
Además, para que AVIF sea realmente viable en WordPress, no basta con “quererlo”: el stack debe soportarlo. WordPress incorporó soporte para AVIF en su núcleo y ha ido mejorando el rendimiento del proceso de generación, pero la disponibilidad final depende del servidor (librerías de imagen y configuración). En otras palabras: FlyingPress puede facilitar el flujo, pero la realidad del entorno de hosting sigue mandando.
A nivel de versión, el despliegue se articula en dos hitos:
Antes de activar la optimización automática de subidas, en un medio o ecommerce conviene revisar tres puntos:
Tabla 2 — Ajustes clave en FlyingPress 5.3 y su implicación práctica
| Ajuste | Opciones | Impacto esperado | Nota operativa |
|---|---|---|---|
| Formato de salida | AVIF / WebP / Original | Reducción de peso y mejora de tiempos de carga | Elegir por compatibilidad y objetivos de calidad |
| Compresión | Lossless / Lossy | Más ahorro con Lossy | Lossy exige revisión visual por tipología de imagen |
| Auto-optimizar subidas | Sí / No | Ahorro continuo sin tareas manuales | Mejor activar tras validación inicial |
| Restaurar originales | Sí | Mitiga riesgo | Útil en incidencias o cambios de política |
| Borrar originales | Sí (irreversible) | Ahorro de almacenamiento | Recomendable solo tras auditoría y backup verificado |
En la práctica, esta actualización también compite en un terreno menos visible: la complejidad operativa. Cada plugin adicional implica compatibilidades, actualizaciones, licencias y posibles conflictos con cachés y CDNs. La propuesta de FlyingPress 5.3 es convertirse en un “núcleo de optimización” más completo: caché, optimización de página, analítica de Core Web Vitals basada en usuarios reales y, ahora, imágenes.
Eso no elimina la necesidad de criterio técnico —y, en sitios grandes, de un pipeline serio—, pero sí puede reducir el “patchwork” típico de muchos WordPress con problemas de rendimiento.
Puede sustituirlos en escenarios donde se busca un flujo integrado y control básico-avanzado (formato, compresión, automatización, restauración). En proyectos con necesidades muy específicas (CDN de imágenes dedicado, reglas por directorio, optimización por tipo de imagen o integraciones concretas), habrá que evaluar si la cobertura funcional es equivalente.
Para un despliegue conservador, WebP suele ser el punto de partida por compatibilidad y estabilidad. AVIF puede aportar más ahorro en peso, pero conviene introducirlo tras una fase de pruebas y verificación en el tráfico real del sitio.
Puede mejorar, pero depende de qué estaba limitando el rendimiento. Si el LCP está dominado por imágenes grandes sin compresión o sin formatos modernos, la mejora suele ser tangible. Si el cuello de botella es TTFB, JS o fuentes, optimizar imágenes ayuda, pero no resuelve el problema principal.
Solo cuando se cumplan tres condiciones: backup verificado, revisión visual satisfactoria y estabilidad medida (sin regresiones en plantillas, galerías o productos). Es un paso útil para ahorrar disco, pero irreversible.
