Core Web Vitals: guía técnica para mejorar LCP, INP y CLS

Las Core Web Vitals miden cómo se comporta una página para usuarios reales: cuánto tarda en mostrar su contenido principal, cómo responde a una interacción y si los elementos se desplazan mientras carga. No son una puntuación estética ni una garantía de posicionamiento. Son señales técnicas que permiten detectar fricción, especialmente en dispositivos móviles.

Una optimización seria no consiste en “subir el puntaje” de una prueba aislada. Consiste en identificar qué plantillas fallan, separar datos reales de mediciones de laboratorio y corregir el cuello de botella que afecta a más URLs y usuarios.

Respuesta rápida: ¿cuáles son las Core Web Vitals actuales?

• LCP (Largest Contentful Paint): mide la carga del contenido principal. El objetivo es 2,5 segundos o menos.
• INP (Interaction to Next Paint): mide la capacidad de respuesta durante la visita. El objetivo es 200 milisegundos o menos.
• CLS (Cumulative Layout Shift): mide la estabilidad visual. El objetivo es 0,1 o menos.

Google evalúa estas métricas con datos de uso reales y toma como referencia el percentil 75. Para que una página se considere en estado “bueno”, las tres métricas deben cumplir sus umbrales en la mayor parte de las visitas.

Qué cambió: FID fue sustituida por INP

Muchas guías todavía hablan de First Input Delay (FID). Esa información está desactualizada. INP sustituyó a FID porque no observa solamente la primera interacción: evalúa la capacidad de respuesta a lo largo de la visita. Esto permite descubrir bloqueos causados por JavaScript, tareas largas del hilo principal y componentes que reaccionan tarde después de hacer clic, tocar la pantalla o escribir.

Si un informe técnico sigue presentando FID como métrica principal, conviene revisar la fecha y la metodología utilizada.

LCP: cuándo aparece el contenido principal

El LCP suele corresponder a la imagen principal, un encabezado grande o el bloque de texto más relevante dentro de la pantalla inicial. Un LCP lento no siempre significa que “toda la web” sea lenta: puede existir un recurso específico que retrasa la pintura del elemento principal.

Causas frecuentes de un LCP deficiente

• respuesta lenta del servidor o ausencia de caché efectiva;
• imagen hero demasiado pesada o servida en dimensiones incorrectas;
• recurso LCP descubierto demasiado tarde por el navegador;
• CSS o fuentes que bloquean el renderizado;
• contenido principal insertado mediante JavaScript después de la carga inicial;
• uso indiscriminado de plugins y constructores visuales.

Cómo mejorarlo

• identificar el elemento LCP real en cada plantilla;
• comprimir y dimensionar correctamente la imagen principal;
• servir formatos modernos cuando exista compatibilidad;
• priorizar el recurso crítico y evitar aplicarle carga diferida;
• reducir el tiempo de respuesta inicial del servidor;
• eliminar CSS bloqueante y dependencias innecesarias.

La prioridad no es instalar otro plugin de optimización. Primero hay que determinar si el problema está en el servidor, la plantilla, la imagen, las fuentes o la secuencia de carga.

INP: cuánto tarda la página en responder

INP mide el tiempo transcurrido entre una interacción y la siguiente actualización visual. Una página puede cargar rápido y, aun así, sentirse torpe cuando un menú tarda en abrir, un filtro se congela o un botón no ofrece respuesta inmediata.

Causas frecuentes de un INP deficiente

• tareas largas de JavaScript que bloquean el hilo principal;
• scripts de analítica, chat, publicidad o personalización ejecutados sin control;
• listeners de eventos costosos;
• renderizados grandes después de una interacción;
• árbol DOM excesivo generado por plantillas y widgets;
• procesamiento que debería diferirse o dividirse.

Cómo mejorarlo

• localizar las interacciones lentas, no solo el archivo más pesado;
• dividir tareas largas y reducir trabajo síncrono;
• cargar scripts de terceros según necesidad y consentimiento;
• simplificar componentes y reducir nodos innecesarios;
• mostrar retroalimentación visual inmediata cuando una operación requiera tiempo;
• medir el comportamiento en móviles reales y no únicamente en un computador de desarrollo.

CLS: estabilidad visual durante la carga

CLS registra desplazamientos inesperados. El caso típico ocurre cuando el usuario intenta pulsar un botón y, justo antes del clic, aparece una imagen, una fuente o un banner que mueve el contenido.

Causas frecuentes de un CLS elevado

• imágenes y vídeos sin dimensiones reservadas;
• banners, formularios o avisos insertados por encima del contenido existente;
• fuentes web que cambian bruscamente el tamaño del texto;
• animaciones que alteran propiedades de diseño;
• componentes de terceros que no reservan espacio.

Cómo mejorarlo

• definir ancho, alto o relación de aspecto para recursos visuales;
• reservar espacio para componentes dinámicos;
• evitar insertar contenido tardío sobre elementos ya visibles;
• ajustar la estrategia de carga de fuentes;
• preferir animaciones basadas en transformaciones cuando corresponda.

Datos reales y laboratorio: no son intercambiables

Search Console y Chrome UX Report utilizan datos de campo: experiencias agregadas de usuarios reales durante un periodo. PageSpeed Insights también muestra esos datos cuando existe una muestra suficiente. Lighthouse y las herramientas de desarrollo producen datos de laboratorio: una prueba controlada útil para reproducir y diagnosticar problemas.

Es normal que ambos resultados sean distintos. Una prueba de laboratorio puede mostrar una mejora inmediata, mientras que el informe de campo tarda en reflejarla. También puede ocurrir lo contrario: un laboratorio rápido no representa dispositivos lentos, redes móviles o interacciones reales.

Método de auditoría de La Clicka

1. Agrupar por plantilla e intención. No se corrigen cien URLs una por una si todas dependen del mismo encabezado, plantilla de producto o módulo.
2. Leer datos de campo. Revisamos Search Console y CrUX para determinar alcance, dispositivo y distribución del problema.
3. Reproducir en laboratorio. Utilizamos PageSpeed Insights y Chrome DevTools para localizar recursos, tareas y desplazamientos concretos.
4. Aislar la causa. Diferenciamos servidor, tema, plugins, etiquetas de terceros, imágenes y código propio.
5. Priorizar por impacto. Primero corregimos cambios reutilizables que afectan tráfico, plantillas críticas y conversiones.
6. Validar después del despliegue. Comparamos laboratorio, telemetría y datos de campo; no cerramos el trabajo al ver un único puntaje verde.

¿Las Core Web Vitals mejoran el posicionamiento?

Forman parte de las señales de experiencia de página, pero no reemplazan relevancia, contenido, arquitectura, autoridad ni capacidad de satisfacer la intención de búsqueda. Una página rápida y poco útil no superará automáticamente a una respuesta más completa. Del mismo modo, una página excelente puede perder usuarios e ingresos si responde tarde o cambia de posición durante la interacción.

La oportunidad real está en trabajar rendimiento, rastreo, contenido y conversión como un sistema. Esa es la diferencia entre una optimización superficial y una consultoría SEO técnica.

Cuándo conviene realizar una auditoría

• Search Console agrupa muchas URLs como “necesita mejoras” o “deficiente”;
• el sitio utiliza numerosos plugins, etiquetas o componentes de terceros;
• una migración o rediseño empeoró el rendimiento;
• la experiencia móvil es claramente peor que la de escritorio;
• las páginas importantes cargan bien en pruebas internas, pero fallan con usuarios reales;
• el equipo aplica optimizaciones aisladas sin identificar el cuello de botella.

En La Clicka revisamos las Core Web Vitals dentro del contexto completo del negocio: plantillas, tecnología, rastreo, contenido y rutas de conversión. Si necesitas saber qué está frenando tu sitio y qué correcciones tienen prioridad, solicita una revisión técnica.

Referencia técnica: documentación de Google Search Central sobre Core Web Vitals y datos de experiencia de usuario.