Core Web Vitals en WordPress: Mejorar LCP, INP y CLS

Google lleva anos usando la velocidad como factor de ranking, pero con los Core Web Vitals la cosa cambio de nivel. No es cuestion de segundos de carga en abstracto: son tres metricas concretas que miden como el usuario percibe tu sitio mientras interactua con el. Y si tu sitio corre sobre WordPress, hay acciones muy especificas que puedes tomar hoy mismo para mejorar cada una.

En Weboption llevamos mas de 15 anos auditando sitios WordPress. El patron que vemos semana a semana con los core web vitals wordpress es siempre el mismo: el sitio parece rapido visualmente, pero PageSpeed Insights cuenta una historia diferente. Esta guia es el resultado de haber pasado por ese proceso con mas de 200 instalaciones de WordPress.

Que miden LCP, INP y CLS (y por que importan juntos)

LCP, Largest Contentful Paint, mide cuanto tarda en aparecer el elemento mas grande visible en pantalla. Generalmente es una imagen hero, un banner o un bloque de texto grande. Google considera aceptable un LCP por debajo de 2.5 segundos. Por encima de 4 segundos, tu pagina esta en zona roja y Google lo nota.

INP, Interaction to Next Paint, reemplazo a FID en marzo de 2024. Mide el tiempo entre que el usuario hace algo (click, tap, tecla) y el momento en que la pagina responde visualmente. Menos de 200ms es bueno. Mas de 500ms es un problema serio, especialmente en movil.

CLS, Cumulative Layout Shift, cuantifica cuanto se mueve el contenido de forma inesperada mientras la pagina carga. Ese anuncio que aparece de repente y empuja todo hacia abajo, o la fuente que cambia de tamano al cargar. Un CLS por debajo de 0.1 es el objetivo.

La trampa clasica es optimizar solo uno. Un sitio con LCP excelente pero CLS alto sigue frustrando al usuario. Google evalua los tres en conjunto para determinar la clasificacion de experiencia de pagina, y ninguno puede ignorarse.

Como mejorar el LCP en WordPress

El 80% de los problemas de LCP en WordPress vienen de las imagenes. Especificamente, de la imagen hero que no tiene fetchpriority="high" y no esta precargada. WordPress 6.3 introdujo soporte nativo para este atributo, pero muchos temas no lo aplican correctamente y eso cuesta puntos en PageSpeed.

Lo primero es identificar cual es tu elemento LCP. Abre Chrome DevTools, ve a la pestana Performance, graba una carga y busca el marcador LCP en la linea de tiempo. Una vez identificado el elemento, verifica que:

• La imagen este en formato WebP o AVIF. Imagify (desde 4.99 USD/mes) o ShortPixel (desde 3.99 USD/mes para 5.000 creditos) convierten automaticamente.
• El atributo loading="lazy" NO este en la imagen LCP. Es el error mas comun que vemos. Lazy load en la imagen principal retrasa todo el render.
• El servidor tenga un tiempo de respuesta (TTFB) por debajo de 600ms. Si no, el problema esta antes de que la imagen descargue.

Para el TTFB, el hosting marca la diferencia. Kinsta, WP Engine o Cloudways con un servidor en la region correcta dan TTFB entre 100 y 300ms. Hosting compartido barato muchas veces supera los 800ms, y eso no lo arregla ningun plugin.

El caching de paginas completas con WP Rocket (49 USD/ano para un sitio) o W3 Total Cache puede reducir el TTFB al servir HTML estatico en lugar de ejecutar PHP y MySQL en cada visita.

Reducir el INP: el problema que nadie ve venir

INP es la metrica mas nueva y la mas dificil de diagnosticar. Un LCP malo se ve. Un INP malo se siente: clicas un boton y la pagina tarda en responder. En movil es especialmente evidente.

Los principales culpables en WordPress son los scripts de terceros que bloquean el hilo principal. Google Tag Manager mal configurado puede agregar 200 a 400ms de INP por si solo. Lo mismo ocurre con plugins de chat en vivo como Intercom o Drift si se cargan de forma sincrona.

La solucion tecnica es diferir estos scripts. WP Rocket tiene una opcion llamada “Delay JavaScript Execution” que retrasa la ejecucion de scripts hasta que el usuario interactua con la pagina. En sitios con muchos scripts de terceros, hemos visto mejoras de INP de 600ms a 150ms solo con ese cambio.

Si construyes bloques Gutenberg personalizados, revisa que los event listeners no hagan trabajo pesado en el hilo principal. Mover logica costosa a requestIdleCallback o a un Web Worker es la solucion correcta para componentes interactivos complejos.

Para diagnosticar: Chrome DevTools, pestana Performance, con “Throttling” en 4x slowdown simula un dispositivo movil de gama media. Ahi es donde los problemas de INP se vuelven obvios.

Estabilizar el CLS en temas y plugins de WordPress

El CLS es el mas facil de diagnosticar y, paradojicamente, el que mas se ignora. Los tres origenes mas comunes en WordPress son imagenes sin dimensiones, fuentes tardias y anuncios sin espacio reservado.

Imagenes sin dimensiones definidas: si tu tema o el plugin de construccion de paginas no define width y height en las etiquetas img, el navegador no puede reservar espacio antes de descargar. Elementor hasta la version 3.5 tenia este problema. Lo corrigio en la 3.6, pero solo si usas las imagenes a traves del widget nativo.

Fuentes web que cargan tarde y desplazan el texto: font-display: swap evita el flash de texto invisible, pero puede causar un pequeno CLS cuando la fuente definitiva carga con dimensiones diferentes a la de respaldo. La solucion es precargar las fuentes criticas con <link rel="preload"> o, mejor aun, usar fuentes del sistema para reducir dependencias externas.

Anuncios y embeds sin espacio reservado: si tienes banners de AdSense o videos de YouTube embebidos, necesitas un contenedor con dimensiones fijas antes de que carguen. Para YouTube, el plugin WP YouTube Lyte hace esto correctamente ademas de reducir el peso de la pagina.

El error mas comun: creer que un plugin lo resuelve todo

Aqui viene la parte que muchos no quieren escuchar. Hay una creencia muy extendida de que instalar WP Rocket o LiteSpeed Cache resuelve los core web vitals wordpress de forma automatica. No funciona asi.

Despues de auditar mas de 200 instalaciones de WordPress, el patron es claro: un sitio con hosting lento, imagenes de 3MB sin comprimir y veinte plugins de terceros cargando scripts en el header no va a pasar a “Bueno” solo por activar el caching. Los plugins de optimizacion son herramientas, no soluciones magicas.

Lo que realmente funciona es un proceso de auditoria sistematica: medir con PageSpeed Insights y con el informe de Experiencia de Pagina en Google Search Console (que usa datos reales de usuarios, no solo de laboratorio), identificar los cuellos de botella especificos, y atacarlos en orden de impacto.

Los datos de campo de Search Console tardan 28 dias en actualizarse. Los cambios que hagas hoy no apareceran como mejoras hasta el mes que viene. Esto genera mucha confusion y lleva a la gente a deshacer cambios correctos antes de que surtan efecto. Usa PageSpeed Insights para validacion rapida y Search Console para confirmar mejoras reales en usuarios reales.

Monitoreo continuo: el trabajo no termina con la optimizacion

Optimizar los Core Web Vitals en WordPress no es una tarea de una vez. Cada actualizacion de tema, cada nuevo plugin, cada cambio en el builder puede revertir semanas de trabajo. Lo hemos visto demasiadas veces.

Lo minimo recomendable es revisar PageSpeed Insights una vez al mes y tener alertas configuradas en Search Console para caidas en la experiencia de pagina. Para sitios con trafico alto, SpeedCurve (desde 20 USD/mes) o Calibre permiten monitoreo automatico con alertas cuando las metricas caen por debajo de umbrales definidos.

En nuestra experiencia trabajando con sitios WordPress de mediano y alto trafico, los problemas de Core Web Vitals mas persistentes no vienen del codigo sino de las decisiones de infraestructura: hosting inadecuado para el nivel de trafico, sin CDN, sin caching agresivo. Eso es lo que mas cuesta arreglar porque implica migraciones, pero tambien es donde esta el mayor impacto real.

Si tu sitio sigue sin pasar los umbrales de Core Web Vitals despues de optimizar imagenes y scripts, el proximo paso es una auditoria de infraestructura. En weboption.com.br/contato hacemos un diagnostico completo e identificamos exactamente donde esta el problema.

Preguntas frecuentes

¿Cuanto tiempo tarda en mejorar el puntaje de Core Web Vitals despues de optimizar?

Los cambios en PageSpeed Insights se reflejan de forma inmediata porque usa datos de laboratorio. Sin embargo, los datos de campo en Google Search Console tardan entre 25 y 28 dias en actualizarse, ya que usan datos reales de usuarios acumulados en ese periodo. No deshagas cambios correctos antes de que ese plazo se cumpla.

¿WP Rocket mejora los Core Web Vitals automaticamente?

WP Rocket mejora varias metricas relacionadas con el tiempo de carga, pero no resuelve los Core Web Vitals por si solo. Un hosting lento, imagenes sin optimizar o scripts de terceros mal configurados siguen siendo problemas que ningun plugin de caching puede solucionar sin una auditoria previa.

¿Que herramienta uso para medir los Core Web Vitals reales de mi sitio?

Para datos de usuarios reales, usa el informe de Experiencia de Pagina en Google Search Console o el Chrome User Experience Report (CrUX). PageSpeed Insights tambien muestra datos de campo cuando hay suficiente trafico. Las herramientas de laboratorio como Lighthouse son utiles para diagnostico pero no representan el comportamiento real de los usuarios.

¿El LCP malo siempre es culpa de las imagenes?

No siempre, pero en WordPress lo es en la mayoria de los casos. Si el elemento LCP es un bloque de texto grande, el problema puede estar en el tiempo de respuesta del servidor (TTFB) o en el CSS que bloquea el render. Identifica primero cual es el elemento LCP usando Chrome DevTools antes de asumir que la causa son las imagenes.

¿Que es INP y como afecta al posicionamiento en Google?

INP, Interaction to Next Paint, reemplazo a FID como metrica oficial de Core Web Vitals en marzo de 2024. Mide la capacidad de respuesta de la pagina ante interacciones del usuario. Google lo usa como senal de experiencia de pagina dentro de su algoritmo de ranking, especialmente en busquedas donde la experiencia del usuario en movil es relevante.