Las Core Web Vitals son las tres métricas que usa Google para medir la experiencia de carga, interactividad y estabilidad visual de una página: LCP, INP y CLS. En este artículo te muestro cómo las diagnostico y las corrijo en proyectos reales de WordPress, con las herramientas, los cambios técnicos y las cifras que uso en cada caso.
He optimizado Core Web Vitals en proyectos con WordPress, Webflow y Shopify, incluyendo mi propio sitio, andres.marketing. En Webflow he trabajado con diseños personalizados y en Shopify con algunas plantillas, pero en este artículo me voy a concentrar en WordPress, que es donde más veces he tenido que resolver este problema desde cero.
No voy a nombrar los sitios específicos en los que trabajé estos casos. Lo que sí te puedo dar son los patrones que se repiten una y otra vez, las cifras reales con las que trabajo y los errores que más me han costado entender, porque eso es lo que realmente sirve cuando tienes que resolver esto en tu propio proyecto. Si quieres el panorama completo de SEO técnico antes de entrar en Core Web Vitals, te dejo mi guía de SEO técnico.
Qué son las Core Web Vitals hoy
Son tres métricas y cada una mide algo distinto de la experiencia del usuario:
| Métrica | Qué mide | Umbral bueno |
|---|---|---|
| LCP (Largest Contentful Paint) | Cuánto tarda en aparecer el elemento más grande y visible de la página | Menos de 2.5 segundos |
| INP (Interaction to Next Paint) | Qué tan rápido responde la página cuando alguien hace clic, toca o escribe | Menos de 200 milisegundos |
| CLS (Cumulative Layout Shift) | Cuánto se mueven los elementos de la página mientras carga | Menos de 0.1 |
Un punto que vale la pena aclarar porque todavía hay páginas que lo tienen mal: la métrica de interactividad ya no es FID (First Input Delay), sino INP. Google hizo el reemplazo oficial en marzo de 2024, hace más de dos años, pero sigo encontrando guías, incluso páginas con bastante autoridad, que siguen enseñando FID como si fuera la métrica vigente. Si ves eso en algún lado, está desactualizado.
Por qué le importan a Google, y a tu negocio
Google incorporó las Core Web Vitals como parte de las señales de experiencia de página desde 2021. No son el factor de posicionamiento más determinante que existe, pero sí son parte de la ecuación. Y a diferencia de otros factores, son algo que puedes medir y arreglar directamente sin depender de autoridad de dominio ni de backlinks.
Cómo diagnostico: mis herramientas y qué suelo encontrar
Para diagnosticar siempre uso lo mismo: PageSpeed Insights de Google o Lighthouse directamente desde Chrome DevTools. En WordPress mi stack habitual es Neve como tema, Yoast para SEO, y Autoptimize junto con Flying Scripts para el manejo de recursos, una combinación que forma parte de los plugins de velocidad que suelo recomendar.
De las tres métricas, las que más veces he encontrado con mal rendimiento son LCP y CLS. INP suele estar mejor de entrada, aunque cuando falla es la más difícil de arreglar, y ya te cuento por qué más adelante.
Cómo corrijo el LCP
Esta es la métrica en la que más experiencia tengo, porque es la que más se repite como problema.
Lo primero que reviso siempre es el tamaño de las imágenes, con la misma estrategia de carga de imágenes que aplico en todos mis proyectos. Me he encontrado banners de más de 3000 píxeles de ancho o alto, cuando en realidad ese elemento se renderiza como máximo a 1200 píxeles en pantalla. Ahí ya hay una ganancia enorme solo con redimensionar.
Lo segundo es el formato: cambiar de PNG o JPG a WebP reduce muchísimo el peso del archivo. Uso el mismo proceso que explico en mi guía para comprimir imágenes sin perder calidad, y como regla general busco que la imagen final quede por debajo de 100kb.
Pero el caso que más me costó entender no fue una imagen. Fue un proyecto donde el elemento LCP era un título de texto. La fuente de ese proyecto se cargaba desde Google Fonts, y ese request externo era el que estaba disparando el tiempo de LCP. La solución fue descargar la fuente y alojarla directamente en el proyecto en vez de pedirla a un servidor externo, algo que detallo en mi guía de cómo optimizar fuentes tipográficas, y el indicador bajó enormemente. Después de eso también reduje la cantidad de variantes de fuente que se importaban, y usé async o defer según el proyecto para que la carga de la fuente no bloqueara el renderizado.
Cómo corrijo el INP
Acá tengo que ser honesto: no hay una técnica única que aplique siempre, como sí la hay con las imágenes en LCP. Lo que me ha funcionado es entender muy bien el proyecto, saber exactamente qué JavaScript o CSS carga cada funcionalidad o estilo.
Dos prácticas concretas que sí aplico siempre que puedo:
- Retraso unos milisegundos la carga de Google Tag Manager y de los píxeles de analítica que no afectan directamente la experiencia del usuario.
- Difiero el JavaScript que no es crítico para que el usuario pueda interactuar con la página lo antes posible.
Cómo corrijo el CLS
Acá los cambios suelen ser más puntuales. Añadir dimensiones explícitas, ancho y alto, a las imágenes evita que la página salte cuando terminan de cargar. Y el mismo self-hosting de fuentes que ayuda al LCP también reduce el CLS, porque evita ese salto visual que se produce cuando la fuente termina de cargar tarde y el navegador tiene que reajustar el texto.
¿Se mantiene en el tiempo?
Sí. Validando con el informe de Core Web Vitals de Search Console, las mejoras se mantienen después del periodo de 28 días que usa Google para confirmar el cambio, a menos que aparezcan otros problemas que no se habían detectado en la primera revisión.
El impacto real después de mejorar esto
El patrón más consistente que he visto: proyectos con un puntaje de Performance por debajo de 60 en PageSpeed o Lighthouse que se llevan a más de 85 muestran mejoras reales, tanto en posicionamiento como en tráfico. No es una promesa genérica, es lo que he visto repetirse en varios proyectos después de aplicar estos cambios.
Este es un ejemplo real y actual, no un caso de antes y después: es simplemente cómo está mi propio sitio hoy. De hecho el CLS de mobile está en 0.108, justo por encima del umbral bueno de 0.1, así que ni yo tengo esto perfecto todavía. En escritorio el resultado es distinto:
El error que más se repite, y el que más cuesta resolver
El error más común, y el que más he corregido, es LCP: casi siempre son imágenes grandes con formatos que no están optimizados para web.
El que más me ha costado resolver es INP, porque no depende de una checklist. Depende de conocer muy bien la estructura del proyecto y cómo interactúa el usuario con cada elemento para llegar a una solución que realmente funcione.
Si quieres revisar tu propio caso
Este es el orden en el que yo empezaría a buscar el problema si ya sabes que tu sitio está mal en alguna de las tres métricas:
- El peso y formato de las imágenes.
- De dónde vienen las fuentes que usa el sitio.
- Qué scripts de terceros están cargando sin necesidad.
Si tienes dudas sobre por dónde empezar con tu propio sitio en WordPress, con gusto lo revisamos juntos.
Preguntas frecuentes
¿INP reemplazó a FID como Core Web Vital?
Sí. Google reemplazó First Input Delay (FID) por Interaction to Next Paint (INP) como la métrica oficial de interactividad en marzo de 2024. Si ves contenido que sigue mencionando FID como vigente, está desactualizado.
¿Cuáles son los umbrales buenos de LCP, INP y CLS?
Google considera buena una página con LCP menor a 2.5 segundos, INP menor a 200 milisegundos y CLS menor a 0.1. Por encima de esos valores, la página necesita mejora o tiene un rendimiento deficiente.
¿Con qué herramienta puedo medir mis Core Web Vitals gratis?
PageSpeed Insights de Google y Lighthouse, disponible directamente en Chrome DevTools, son gratuitos y son las herramientas que uso por defecto para diagnosticar. También puedes revisar el informe de Core Web Vitals en Search Console.
¿Cuánto tarda Google en confirmar que una mejora de Core Web Vitals se mantuvo?
Search Console usa un periodo de validación de 28 días desde que corriges el problema. Si durante ese tiempo no vuelve a aparecer, se considera resuelto, aunque puede reaparecer si surge un problema distinto que no se había detectado.
Si quieres correr tu propia auditoría, empieza igual que yo: entra a PageSpeed Insights, y si tienes dudas sobre por dónde empezar, con gusto lo revisamos juntos.
