Core Web Vitals en WordPress: cómo medir y arreglar LCP, INP y CLS

Existe la idea, muy extendida entre quien vende mantenimiento por 30 € al mes, de que los Core Web Vitals se arreglan instalando un plugin de caché, activando cuatro casillas y esperando a que PageSpeed se ponga verde. Se hace en diez minutos, no requiere tocar el tema y el informe que le mandas al cliente queda precioso.

Error monumental.

Las tres métricas miden cosas distintas y solo una de ellas mejora con caché.

Aquí tienes el orden de intervención: qué mide cada una, cómo diagnosticarla en tu WordPress y qué tocar primero. Antes de operar hace falta un triaje, y la mayoría de webs entran en quirófano por la herida equivocada.

Qué mide cada métrica y con qué umbral

Google evalúa el percentil 75 de tus usuarios reales durante 28 días.

No la última medición de tu portátil con fibra.

• LCP (Largest Contentful Paint): cuánto tarda en pintarse el elemento visible más grande, casi siempre tu imagen de cabecera. Bueno por debajo de 2,5 segundos.
• INP (Interaction to Next Paint): cuánto tarda la página en responder visualmente cuando el usuario toca algo. Bueno por debajo de 200 milisegundos.
• CLS (Cumulative Layout Shift): cuánto se mueve el contenido mientras carga. Bueno por debajo de 0,1.

Ese percentil 75 importa más de lo que parece. Significa que tres de cada cuatro visitas deben quedar por debajo del umbral.

Tu media puede ser excelente y el conjunto seguir suspendiendo por culpa del cuarto peor: usuarios en 4G, con móviles de tres años, en una zona con mala cobertura.

Optimizar para tu propio equipo es optimizar para el percentil equivocado.

Hay una cuarta cifra que no es una Core Web Vital pero condiciona a las tres: el TTFB, o Time to First Byte, el tiempo que tarda tu servidor en soltar el primer byte. Por encima de 800 milisegundos, ninguna optimización de frontend te va a salvar.

El error de diagnóstico más común

Los datos de laboratorio y los de campo no dicen lo mismo.

Confundirlos es lo que hace que un sitio «verde» siga fallando.

Cuando abres PageSpeed Insights ves dos bloques. Arriba, si tu web tiene tráfico suficiente, están los datos de usuarios reales de los últimos 28 días: eso es lo que Google usa para evaluarte.

Abajo está la simulación de Lighthouse, que sirve para encontrar causas y nunca para dar el problema por resuelto. El INP, además, no se puede medir ahí: necesita a alguien tocando la pantalla.

Tu fuente para decidir es Search Console, informe «Métricas web principales». Tu fuente para investigar es Lighthouse y el panel de rendimiento del navegador.

Si tu web tiene poco tráfico, el bloque de campo aparecerá vacío. No es un fallo: es que no hay muestra suficiente.

En ese caso trabaja con laboratorio, pero mide siempre en modo móvil y con la CPU limitada. El escritorio te dará números que ningún cliente tuyo verá jamás.

Antes de seguir, tres preguntas. ¿Sabes cuál es el elemento que marca tu LCP? ¿Cuántos plugins cargan JavaScript en todas tus páginas, incluidas las que no lo usan? ¿Has abierto tu web en un móvil de gama media con datos, y no en el tuyo con fibra?

El protocolo: cuatro pruebas por orden de sangrado

Se interviene por gravedad, no por comodidad. Este es el orden.

La prueba del servidor

Mide el TTFB antes de tocar una sola imagen. En PageSpeed lo tienes como «Tiempo de respuesta inicial del servidor».

Por encima de 800 ms tu problema está debajo de WordPress: hosting compartido saturado, PHP desactualizado, sin caché de página o una base de datos con miles de revisiones y transitorios.

Un plugin de caché resuelve este punto en muchos casos. Es el único de los cuatro donde ese plugin es la respuesta correcta.

Si tu TTFB sigue alto con la caché activa, el hosting es la explicación.

Compruébalo con una prueba barata: pide una cuenta de prueba en otro proveedor, clona el sitio y mide lo mismo. Si la diferencia es de cientos de milisegundos, ya sabes dónde estaba el cuello de botella y cuánto cuesta arreglarlo.

La prueba del elemento grande

Lighthouse te señala cuál es tu elemento LCP.

Ábrelo y comprueba tres cosas.

• Formato y peso: una cabecera en JPG de 900 KB pesa entre un 30% y un 50% menos en WebP o AVIF. Es la mejora más barata que existe.
• Lazy load mal aplicado: si tu imagen de cabecera lleva loading="lazy", la estás retrasando a propósito. La primera imagen visible nunca se difiere.
• Cadena de dependencias: si el LCP es un texto y llega tarde, el culpable suele ser una fuente web que bloquea el renderizado o un CSS del maquetador de 400 KB.

En WordPress el sospechoso habitual es el slider de tu portada: tres imágenes a pantalla completa, una librería de JavaScript y un texto animado. Arruina el LCP y casi nunca aporta nada medible.

La corrección tiene un orden claro. Primero, quitar lo que no debería estar. Después, servir en el formato correcto y al tamaño real en que se muestra, que casi nunca es el tamaño en que se subió.

Solo al final, precargar la imagen de cabecera. Precargar una imagen de 900 KB que no debería existir es acelerar el error.

La prueba de la respuesta

El INP es la métrica que más ha empeorado desde que sustituyó al FID.

En WordPress el motivo es casi siempre el mismo: demasiado JavaScript ejecutándose en el hilo principal.

Abre el panel de rendimiento, graba mientras pulsas tu menú y busca las tareas largas, las que pasan de 50 ms. Verás nombres reconocibles: el chat de soporte, el gestor de consentimiento, el buscador con autocompletado, tu maquetador cargando su motor de animaciones.

Escribe document.querySelectorAll('*').length en la consola. Un DOM de 3.000 nodos donde bastarían 800 castiga tu INP en cualquier móvil de gama media.

Ninguna caché lo arregla: el trabajo no está en descargar, está en ejecutar.

Lo que sí lo arregla es cargar cada script solo donde hace falta. El formulario de contacto no necesita su JavaScript en las fichas de producto, ni el buscador con autocompletado en el aviso legal.

En una instalación media, esa sola decisión quita entre un tercio y la mitad del JavaScript de las páginas interiores. Y no obliga a renunciar a ninguna función.

La prueba del salto

El CLS se ve mejor de lo que se mide. Carga tu portada en un móvil real, con datos y sin Wi-Fi, y mira si algo se mueve mientras aparece.

Cuatro causas cubren casi todos los casos:

• Imágenes sin width y height declarados.
• Banners de cookies inyectados después del primer pintado.
• Fuentes que cambian la altura de línea al sustituir a la de respaldo.
• Bloques que un plugin monta encima del contenido ya visible.

Todas se resuelven reservando el espacio antes de que llegue el elemento. Ninguna se resuelve con caché.

Es la métrica más barata de corregir y la que más irrita cuando falla: provoca el clic equivocado justo en el momento de decidir.

Un botón que se desplaza medio segundo después de aparecer manda a tu cliente a la página que no quería. Eso ya no es una cifra de laboratorio: es una venta menos.

Qué no los arregla (y cada cuánto hay que mirarlos)

Nada de botones mágicos.

Un plugin de optimización todo en uno hace tres cosas útiles (caché de página, minificación y diferido de scripts) y una peligrosa: te deja creer que tu problema está resuelto porque el semáforo cambió de color en una medición de laboratorio. Sigue habiendo 70 peticiones. Sigue habiendo un maquetador cargando su motor completo en cada página. Y tu usuario sigue esperando.

La optimización real no va de activar casillas: va de eliminar trabajo que tu página no necesita hacer.

Hay además un efecto secundario que casi nadie menciona.

Diferir scripts a ciegas rompe cosas, y lo hace en silencio: el formulario que deja de enviar, el filtro del catálogo que no responde, el vídeo que no arranca.

Si activas esas opciones, prueba después el recorrido completo de compra o de contacto en un móvil real. No solo la portada.

Con la frecuencia pasa algo parecido. Mira tu informe de campo una vez al mes y usa el laboratorio solo después de cada cambio grande.

Los datos de campo tardan hasta 28 días en reflejar una mejora. Si corriges tu LCP hoy y el lunes sigues en rojo, no ha fallado la corrección: falta ventana.

Por eso se mide antes de tocar nada. Y se guarda la captura con la fecha.

Esto forma parte de mantener el sitio después del lanzamiento, no de una intervención puntual. Un sitio optimizado que suma cuatro plugins en seis meses vuelve al punto de partida.

Dónde encaja esto en el resto del sitio

Las tres métricas no explican si tu web vende. Explican si tu web deja competir a tu contenido. El impacto en negocio, con conversión y coste por clic, lo tienes en el efecto de la carga sobre tus ventas.

Hay una parte que ninguna métrica captura: la fricción real que vive alguien intentando comprarte. Eso se detecta mirando sesiones, no gráficas, y lo desarrollé en las fricciones que sufre tu usuario. Si necesitas el mapa completo de tu sitio, con SEO técnico y contenido en el mismo informe, eso es una auditoría web.

Y hay un techo que no se rompe desde el panel de administración.

Cuando el rendimiento lo limita el tema o el maquetador, ninguna de las cuatro pruebas te saca del rojo: el problema es de qué está hecha tu web, no de cómo está configurada.

Ahí la decisión ya no es técnica sino de presupuesto, y la tienes con cifras en cuánto cuesta rehacerlo bien y en lo que se recorta cuando el precio baja.

Cuando el rendimiento entra desde el principio, este artículo sobra. Por eso empiezo cada proyecto por la estructura y no por el diseño de la portada.

Yo no entrego capturas verdes. Entrego tu informe de campo antes y después, con la fecha de cada medición, y digo qué parte de la mejora es estructural y qué parte es maquillaje. Cuando el techo lo pone tu tema o tu maquetador, lo digo también, aunque signifique que el trabajo es más grande de lo que esperabas.