Cómo optimizar los Core Web Vitals en tu web WordPress

Si tu web WordPress tarda más de tres segundos en mostrar el contenido principal, ya has perdido a parte de tus visitantes antes de que lean la primera línea. Los Core Web Vitals —LCP, INP y CLS— siguen siendo en 2026 factor de posicionamiento en Google y, sobre todo, el termómetro real de si tu web se siente rápida o lenta para quien la usa.

Esta guía está pensada para sitios WordPress «normales»: blogs, webs corporativas, páginas de servicios. Si tu proyecto trabaja con contenido dinámico, personalización en tiempo real o widgets que cambian según el usuario que navega, la casuística es distinta y la tratamos con detalle en Core Web Vitals en sitios con contenido dinámico y personalización.

1. LCP: que el contenido principal aparezca antes de 2,5 segundos

El LCP (Largest Contentful Paint) mide cuánto tarda en pintarse el elemento más grande de la pantalla, casi siempre una imagen destacada, un titular grande o un bloque de cabecera. Por debajo de 2,5 segundos se considera bueno.

• Comprime las imágenes antes de subirlas: convertirlas a WebP o AVIF reduce el peso a la mitad sin que se note en calidad. Si prefieres no depender de un plugin en el servidor, puedes hacerlo tú mismo antes de publicar, como explicamos en comprimir imágenes en local.
• Precarga el elemento crítico: añadir <link rel="preload"> a la imagen o fuente principal, desde el tema o con un plugin como Perfmatters, adelanta su descarga y mejora la percepción de velocidad.
• Evita sliders en la cabecera: un carrusel pesado en la parte superior de la página suele ser el principal culpable de un LCP alto. Una imagen estática optimizada casi siempre rinde mejor.
• Elige un tema ligero: GeneratePress, Blocksy o Astra cargan poco CSS y JavaScript de serie, frente a temas todo-en-uno que arrastran librerías que no vas a usar.
• Baja el TTFB: un hosting con LiteSpeed, HTTP/3 y caché a nivel de servidor, más una CDN por delante, recorta el tiempo de respuesta antes de que el navegador empiece siquiera a pintar. Si no tienes claro qué hace una CDN en la práctica, lo explicamos en qué es una CDN y cómo acelera tu web.

2. INP: que la web responda en menos de 200 ms

El INP (Interaction to Next Paint) sustituyó a FID en marzo de 2024 y mide la latencia de cualquier interacción: un clic, una pulsación, un campo de formulario. El objetivo son 200 ms o menos.

• Retrasa el JavaScript que no es crítico: widgets de redes sociales, chats o vídeos incrustados pueden esperar a que el usuario interactúe. Flying Scripts, Asset CleanUp o Perfmatters hacen ese trabajo sin tocar código.
• Revisa qué bloquea el hilo principal: abre Chrome DevTools y busca scripts que tarden más de 50 ms en ejecutarse. Los constructores visuales pesados, tipo Elementor cargado en páginas que no lo necesitan, suelen aparecer en esa lista. Si sospechas que un plugin o un builder está detrás de la lentitud, tenemos una guía específica para aislar cuellos de botella causados por plugins y builders.
• No cargues JS globalmente si solo lo usas en una página: es habitual encontrar plugins que meten su script en todo el sitio aunque solo trabajen en el formulario de contacto. Desactivarlo por ruta con Perfmatters o Plugin Organizer libera bastante hilo principal.
• Valora Web Workers para lógica pesada: si tu sitio ejecuta mucho cálculo en el navegador (filtros, calculadoras, buscadores en tiempo real), mover esa carga a un Web Worker mantiene el hilo principal libre para responder al usuario. Es una solución avanzada, pero merece la pena en proyectos con mucha interactividad.

3. CLS: que nada se mueva mientras carga la página

El CLS (Cumulative Layout Shift) mide la estabilidad visual. Si un botón se desplaza justo cuando ibas a pulsarlo, el usuario acaba haciendo clic donde no quería, y eso se paga en confianza y en conversión. Un buen CLS está por debajo de 0,1.

• Define ancho y alto en imágenes e iframes: WordPress los añade por defecto al subir una imagen, pero algunos temas o constructores los eliminan. Revísalo en el HTML final, no solo en el editor.
• Reserva espacio para anuncios y widgets externos: un contenedor con altura fija o un min-height evita el salto brusco cuando AdSense u otro script tarda en cargar.
• Usa font-display: swap: así el texto se ve desde el primer momento con una fuente de sistema, en vez de quedar invisible mientras se descarga la tipografía personalizada. Plugins como OMGF alojan las fuentes de Google en tu propio servidor y aplican esta propiedad sin tocar código.
• Cuidado con banners de cookies y popups: deben cargar después del contenido principal o tener un espacio reservado. Un banner que empuja el texto hacia abajo nada más entrar es una de las causas más comunes de CLS alto.

Herramientas para medir, no para adivinar

Antes de tocar nada, mide. Y después de cada cambio, vuelve a medir para comprobar que realmente ha servido de algo.

• PageSpeed Insights: combina datos reales de usuarios (CrUX) con un análisis simulado y sugerencias concretas por URL.
• Lighthouse, integrado en Chrome DevTools, para revisar en local antes de publicar.
• Web Vitals Extension, que muestra las métricas en tiempo real mientras navegas por tu propia web.
• Query Monitor, para detectar consultas lentas y plugins que consumen recursos de más.
• WebPageTest.org, útil para comparar el antes y el después de un cambio concreto con datos objetivos.

Mantén el núcleo, el tema y los plugins actualizados: buena parte de las mejoras de rendimiento llegan silenciosamente en esas versiones, sin que tengas que cambiar nada más.

Preguntas frecuentes

¿Cuánto tiempo se tarda en mejorar los Core Web Vitals de una web?

Los cambios básicos (comprimir imágenes, retrasar scripts, definir dimensiones) suelen notarse en el propio PageSpeed Insights a los pocos minutos. Que Google actualice el dato de campo (CrUX) que ve en Search Console tarda entre dos y cuatro semanas, porque se calcula sobre datos reales de los últimos 28 días.

¿Es mejor cambiar de hosting o de tema para mejorar el LCP?

Depende de dónde esté el cuello de botella. Si el TTFB ya es bajo (por debajo de 200-300 ms) el problema suele estar en el tema o en los plugins, no en el servidor. Mide primero con Query Monitor antes de gastar en un hosting más caro.

¿Los constructores visuales como Elementor siempre penalizan el rendimiento?

No siempre, pero cargan más CSS y JavaScript que un tema minimalista. Si lo usas, activa la carga optimizada de assets (solo en las páginas donde se usa) y evita widgets innecesarios en secciones que no lo requieren.

¿Qué pasa si mi web tiene contenido personalizado por usuario?

Ahí entran en juego factores adicionales, como el renderizado del lado del cliente o la caché por segmento de usuario. Lo tratamos con detalle en nuestra guía sobre Core Web Vitals en sitios con contenido dinámico.

Optimizar los Core Web Vitals no exige rehacer la web desde cero, sino saber qué recursos usas, cómo se cargan y qué impacto tienen en quien la visita. Con las técnicas de esta guía y algo de medición constante, la mayoría de sitios WordPress puede acercarse a «bueno» en las tres métricas sin depender de un rediseño completo.