Caso real de optimización WordPress: El Vigía de Cuba pasa de 7,5 a 2,4 segundos de LCP

Cuando una web tiene buen contenido, pero tarda demasiado en mostrarlo

El Vigía de Cuba es un medio digital con noticias, análisis y actualidad para cubanos dentro y fuera de la isla. En la portada se publican artículos con frecuencia y trabajan varios editores. Eso significa muchas imágenes, actualizaciones y elementos que deben funcionar sin que cada persona tenga que convertirse en especialista en rendimiento web.

La optimización de WordPress y la velocidad web no consisten únicamente en conseguir una buena puntuación. Consisten en que la página responda bien mientras el equipo publica y los lectores llegan desde distintos dispositivos.

El problema se resumía en una experiencia frustrante: había buen contenido, pero la web tardaba demasiado en mostrarlo. En la primera prueba, el elemento principal de la portada podía tardar alrededor de 7,5 segundos en aparecer.

Y seamos honestos: si el rendimiento depende de que los redactores recuerden comprimir imágenes, revisar formatos y pensar qué script puede cargar, el sistema está mal planteado. Un editor tiene que publicar y continuar con su trabajo. El servidor y WordPress tienen que encargarse de lo demás.

Por eso no buscamos una solución aislada. Revisamos qué estaba ocurriendo y organizamos la intervención en varias capas.

La hoja de ruta de la optimización WordPress

En lugar de una única solución, organizamos el trabajo en cuatro capas:

  • Servidor: migración a un VPS exclusivo, Plesk Performance Booster, PHP optimizado, OPcache y 2 GB de swap.
  • Imágenes: EWWW Image Optimizer, cwebp, pngquant, optipng y PHP-GD para convertir miles de imágenes a WebP y optimizar automáticamente las nuevas.
  • Portada: Asset CleanUp para descargar recursos innecesarios, retirada de recursos del mapa y priorización de la imagen principal como LCP.
  • Scripts y caché: Flying Scripts, desactivación de Google Sign-In de Site Kit, Cache Enabler, minificación prudente y revisión de los encabezados de caché en Nginx y Plesk.

El objetivo era sencillo: que el equipo pudiera seguir publicando con normalidad y que la web hiciera automáticamente el trabajo pesado. En Ibero Studio trabajamos la velocidad, el SEO técnico y el mantenimiento de WordPress como partes de un mismo sistema.

El primer problema estaba en el alojamiento

El Vigía de Cuba comenzó en un hosting compartido. Durante un tiempo funcionó, pero en junio la cuenta se quedó sin inodos, es decir, sin capacidad para gestionar más archivos y elementos.

En un medio digital los archivos se acumulan rápido: imágenes originales, miniaturas, versiones optimizadas, cachés y archivos de trabajo. Puedes tener espacio libre en gigabytes y, aun así, haber alcanzado el límite de archivos.

La solución fue trasladar el sitio a un VPS exclusivo para El Vigía de Cuba. La memoria, la capacidad de procesamiento y el almacenamiento quedaron destinados al proyecto, sin compartirlos con otras webs. El VPS no hace rápida una web automáticamente, pero sí proporciona una base adecuada para configurar el servidor y dejar de depender del consumo de otras cuentas. El sitio ganó así un entorno más controlable y margen para seguir creciendo.

Las imágenes no podían depender de cada editor

El Vigía publica con frecuencia y cuenta con varios editores. Pedirle al equipo editorial que comprobara el peso, eligiera el formato, generara una versión WebP y revisara la compatibilidad de cada fotografía era una batalla perdida. Tarde o temprano, una imagen pesada acabaría publicada y, multiplicada por cientos o miles, influiría en la velocidad de toda la web.

Instalamos y configuramos EWWW Image Optimizer y dejamos preparados cwebp, pngquant, optipng y PHP-GD. Convertimos miles de imágenes a WebP, incluidos archivos PNG.

También configuramos la optimización automática para las nuevas imágenes. Los originales se conservaron y la entrega optimizada se realiza mediante etiquetas <picture>, para que cada navegador reciba un formato compatible.

Desde entonces, el equipo editorial puede subir una imagen como parte normal de su trabajo. El sistema se ocupa de optimizarla y preparar su entrega. Así la velocidad deja de depender de que alguien recuerde hacer una tarea técnica cada vez que publica.

La portada estaba cargando cosas que no necesitaba

Algunos recursos se cargaban en la portada aunque solo fueran útiles en otras partes de la web. Entre ellos estaban recursos de Post Views Counter y elementos de un mapa que ya no se utilizaba.

Cada recurso adicional implica descargas, interpretación y ejecución. Puede parecer poco cuando se mira un archivo aislado, pero el navegador nota la suma.

Instalamos Asset CleanUp y descargamos de la portada los recursos innecesarios. También desactivamos los recursos relacionados con el mapa que ya no tenía función. La portada dejó de cargar trabajo que no necesitaba para mostrar sus contenidos y el navegador pudo llegar antes a lo importante.

Los scripts secundarios estaban compitiendo con el contenido

No todos los scripts tienen la misma urgencia. Algunos son necesarios para una interacción concreta, pero no tienen por qué ejecutarse antes de que el lector pueda ver la noticia o la imagen principal.

Configuramos Flying Scripts para retrasar scripts secundarios. También desactivamos Google Sign-In de Site Kit porque no era necesario para el funcionamiento principal de la web.

La configuración fue conservadora. Retrasar todo sin comprobarlo puede romper menús, formularios o elementos interactivos.

El navegador pudo concentrarse primero en mostrar el contenido principal y dejar para después tareas menos urgentes. El lector ve antes la página y las funciones secundarias siguen disponibles cuando realmente hacen falta.

Infografía con las mejoras de velocidad de El Vigía de Cuba: VPS, imágenes WebP, caché y scripts; LCP de 7,5 a 2,4 segundos

La imagen principal necesitaba prioridad

La portada tenía una imagen principal dinámica, pero no estaba tratada como el elemento visual prioritario. Eso influía en el LCP, la métrica que indica cuándo aparece el contenido visual principal. web.dev explica con más detalle cómo se mide esta métrica.

Ajustamos esa imagen para que el navegador pudiera priorizarla y excluimos el logotipo de la optimización LCP, porque no era el elemento que debía marcar la carga principal. La imagen que el lector ve al entrar comenzó a recibir atención antes que elementos menos importantes. Una miniatura al final de la página puede esperar; la imagen principal de la portada, no tanto.

El servidor también necesitaba una configuración más afinada

Después de la migración confirmamos que el VPS utilizaba Nginx junto con Apache y PHP-FPM, no LiteSpeed. También había que aprovechar mejor los recursos disponibles en el nuevo entorno.

Configuramos Plesk Performance Booster, optimizamos PHP y activamos OPcache, que permite reutilizar código PHP ya compilado. La documentación oficial de PHP sobre OPcache explica su funcionamiento. Añadimos además 2 GB de memoria swap para disponer de un margen adicional en momentos de mayor consumo.

Instalamos Cache Enabler, configuramos la limpieza automática de caché al publicar o actualizar y aplicamos una minificación prudente de CSS y JavaScript. Por último, revisamos los encabezados de caché de las imágenes en Nginx y Plesk.

El servidor quedó preparado para reutilizar mejor los recursos y servir los archivos estáticos durante más tiempo cuando correspondía. La caché se actualiza al cambiar contenido y la minificación no se aplicó de forma agresiva para evitar romper funciones.

El resultado: de 7,5 a 2,4 segundos de LCP

Después de los ajustes, la prueba mostró:

  • Rendimiento: 95
  • Accesibilidad: 91
  • Prácticas recomendadas: 96
  • SEO: 100
  • Navegación agéntica: 3/3
  • FCP: 2,0 s
  • LCP: 2,4 s
  • TBT: 0 ms
  • CLS: 0,019

El cambio más visible fue el LCP: bajó aproximadamente de 7,5 a 2,4 segundos.

No hubo una configuración milagrosa. Primero cambiamos la base, pasando de un hosting compartido sin inodos a un VPS exclusivo. Después hicimos que las imágenes se optimizaran solas, quitamos recursos innecesarios, retrasamos scripts secundarios, priorizamos la portada y ajustamos PHP y la caché.

optimización WordPress y velocidad web del Vigía de Cuba: captura de pantalla del pagespeed dia 8 de agosto del 2026

La idea importante: que el sistema trabaje por el equipo

La mejor optimización de WordPress y velocidad web es la que trabaja en segundo plano mientras el equipo hace lo que mejor sabe hacer: crear y publicar contenido.

En El Vigía de Cuba, el objetivo no era solo conseguir una mejor puntuación en una prueba. Era que el medio pudiera seguir publicando noticias e imágenes con normalidad, mientras el servidor se encargaba de comprimir, convertir, priorizar y servir los recursos de forma más eficiente.

¿Tu WordPress tarda demasiado en cargar? En Ibero Studio puedes solicitar un análisis SEO y de velocidad para saber qué está ocurriendo y qué merece la pena corregir primero.

Preguntas frecuentes

¿WebP sustituye a las imágenes originales?

No. En este caso se conservaron los originales para mantener la compatibilidad con navegadores que no soporten WebP.

¿Un VPS hace rápida cualquier web?

No. Aporta recursos dedicados y un entorno más controlable, pero también hay que configurar WordPress, las imágenes, los scripts y la caché.

¿Los editores tienen que convertir las imágenes manualmente?

No. La optimización automática permite que suban la imagen y que el sistema genere y entregue las versiones optimizadas.

¿Qué significa un LCP de 2,4 segundos?

Es el tiempo aproximado que tardó en aparecer el elemento principal de contenido visual en la prueba realizada.

¿La optimización termina después de la primera intervención?

No. Conviene vigilar nuevas imágenes, actualizaciones, scripts añadidos, caché y datos reales de navegación.

Comparte tu aprecio