Mejorar los Core Web Vitals: LCP, INP y CLS en la práctica

Los Core Web Vitals se mejoran más rápido si primero averigua con datos de campo cuál de las tres métricas (LCP, INP o CLS) suspenden sus visitantes y después corrige su causa principal: respuesta del servidor o imagen principal en el LCP, JavaScript en el hilo principal en el INP, marcadores de espacio ausentes en el CLS. Se consideran buenos un LCP de hasta 2,5 segundos, un INP de hasta 200 milisegundos y un CLS de hasta 0,1.

Los Core Web Vitals son las métricas de Google sobre la experiencia de usuario al cargar, manejar y leer una página. Son un factor más entre muchos para la visibilidad y no sustituyen a los contenidos relevantes, pero muestran con fiabilidad dónde esperan o abandonan los visitantes. Este artículo explica cómo medir bien, qué causas hay tras los valores malos y cómo mantener la mejora.

Las tres métricas y sus umbrales

Métrica	Mide	Bueno	Mejorable	Malo
LCP (Largest Contentful Paint)	cuándo se ha cargado el mayor contenido visible de la primera pantalla	hasta 2,5 s	2,5–4,0 s	más de 4,0 s
INP (Interaction to Next Paint)	con qué rapidez la página responde visiblemente tras un clic, toque o pulsación	hasta 200 ms	200–500 ms	más de 500 ms
CLS (Cumulative Layout Shift)	cuánto se desplazan los contenidos visibles sin previsión	hasta 0,1	0,1–0,25	más de 0,25

Se evalúa el percentil 75 de los datos de campo, por separado en móvil y escritorio: al menos tres de cada cuatro visitas deben cumplir el umbral. El INP sustituyó en 2024 a la métrica anterior FID. Tiene en cuenta las interacciones de toda una visita y en esencia informa de la más lenta, no solo de la primera. Una visión general de los términos ofrece la entrada del glosario sobre los Core Web Vitals.

Medir bien: primero campo, luego laboratorio

• Datos de campo (visitantes reales): el informe “Core Web Vitals” de Google Search Console, PageSpeed Insights basado en el Chrome User Experience Report (CrUX) y una monitorización propia de usuarios reales con la biblioteca web-vitals.
• Datos de laboratorio (reproducibles): Lighthouse, las herramientas de desarrollo de Chrome y WebPageTest para el diagnóstico; el Total Blocking Time sirve como aproximación al INP.

Tres particularidades frenan a los impacientes. Primero, los datos CrUX de Search Console y PageSpeed Insights abarcan un periodo móvil de 28 días, por lo que las mejoras solo se ven poco a poco. Segundo, las páginas con poco tráfico no tienen datos de campo propios; entonces ayuda mirar el nivel del dominio o usar una monitorización propia que no debería recoger datos personales. Tercero, la puntuación de Lighthouse no es un valor de Core Web Vitals: puede mostrar 100 mientras los visitantes reales con smartphones antiguos en redes móviles lo pasan bastante peor.

Mejorar LCP, INP y CLS de forma específica

LCP: cuatro fases, cuatro puntos de partida

Primero hay que determinar qué elemento es el LCP, normalmente una imagen principal, el póster de un vídeo o un titular grande. PageSpeed Insights y las herramientas de desarrollo lo muestran. Después se ve en cuál de las cuatro fases se pierde el tiempo:

Fase	Causa típica	Medida
Respuesta del servidor (TTFB)	alojamiento lento, falta de caché, consultas pesadas a la base de datos, muchos plugins	caché de página y de servidor, CDN, consultas ligeras, alojamiento adecuado
Inicio de la carga del recurso	la imagen principal se descubre tarde, se carga como fondo CSS o por script, o se difiere por error	servir la imagen como img en el HTML, no diferir su carga y priorizarla con fetchpriority=high
Duración de la carga del recurso	archivo de imagen demasiado grande, sin formato moderno	tamaños adecuados con srcset, compresión, WebP o AVIF
Renderizado (retraso de render)	CSS o JavaScript que bloquean el renderizado, página construida solo en el navegador por un framework	CSS crítico al principio, scripts con defer, renderizado en servidor en lugar de construcción solo en cliente

Un error clásico: la imagen del LCP lleva loading=lazy, un reflejo de una optimización de imágenes bienintencionada. La carga diferida (lazy loading) solo corresponde a imágenes situadas por debajo de la primera pantalla. Si la respuesta del servidor se lleva la mayor parte del tiempo, optimizar imágenes sirve de poco: primero hay que revisar caché y alojamiento.

INP: aliviar el hilo principal

El INP consta de tres fases: retraso de entrada (el hilo principal está ocupado), procesamiento (se ejecutan los controladores de eventos) y retraso de presentación (hasta que se dibuja el siguiente fotograma). Los valores malos suelen deberse a que demasiado JavaScript bloquea el hilo principal.

• Dividir las tareas largas de más de 50 milisegundos en pasos menores y dar respiro al navegador entre ellos, por ejemplo con scheduler.yield() donde el navegador lo admita, o con setTimeout.
• Evaluar los scripts de terceros (gestor de etiquetas, chat, seguimiento, herramientas de consentimiento) según su utilidad, cargarlos solo tras el consentimiento o la interacción y eliminar lo que nadie analiza.
• Mantener ligeros los controladores de eventos, trasladar lo que consume mucho cálculo a web workers y no alternar lecturas y cambios de maquetación.
• Mantener pequeño el DOM y virtualizar las listas muy largas, porque cada actualización de páginas grandes es costosa.
• Mostrar de inmediato una respuesta, por ejemplo un estado de carga, aunque el procesamiento tarde más.
• En los frameworks, revisar la hidratación y los re-renderizados y no hidratar componentes sin interacción.

Mida el INP en lo posible en campo, porque depende de las interacciones reales. En laboratorio ayuda el panel de rendimiento de las herramientas de desarrollo. La ejecución estándar de Lighthouse no registra interacciones y ofrece en su lugar el Total Blocking Time como indicio.

CLS: reservar espacio

• Dar dimensiones fijas a imágenes, vídeos, mapas e iframes mediante width y height o aspect-ratio.
• Reservar espacio para banners, publicidad, contenidos incrustados y avisos de cookies; es mejor mostrar los banners como superposición en el borde que empujar el contenido hacia abajo.
• Precargar las fuentes web, elegir font-display con criterio y usar una fuente de reserva con medidas similares para que los saltos de línea no cambien al cargarse.
• No insertar nunca contenido por encima de contenido ya visible.
• Implementar las animaciones con transform y opacity, no con valores de tamaño o posición.

Terceros, CMS y alojamiento: dónde surge realmente el esfuerzo

En los sitios web de empresa, gran parte de la carga suele proceder no del propio código, sino del gestor de etiquetas, el widget de chat, el banner de consentimiento, los mapas, los contenidos de redes sociales y los plugins. Revise la lista script por script: ¿quién lo usa?, ¿quién lo analiza?, ¿cuánto tiempo de carga cuesta? En los sitios con CMS, los plugins suelen cargar CSS y JavaScript en todas las páginas, incluso donde no hacen falta. Cómo hacer WordPress más seguro y ligero a la vez lo describe el artículo Proteger WordPress.

Mantenerse rápido: presupuestos y proceso

Nuevos plugins, imágenes más grandes y etiquetas de seguimiento adicionales empeoran poco a poco los valores. Por eso el rendimiento necesita un procedimiento fijo:

1. Ordenar las plantillas por tráfico y relevancia de negocio: primero la página de inicio, las páginas de servicios o productos y las landing pages; después las subpáginas poco usadas.
2. Fijar presupuestos por plantilla: tamaño del bundle, peso de las imágenes, número de scripts de terceros y valores de Lighthouse como alerta temprana.
3. Comprobar los presupuestos en el pipeline de compilación para detectar excesos antes de la publicación; más en el artículo DevOps y pipelines GitOps.
4. Revisar con regularidad los datos de campo y medir antes y después de las publicaciones más grandes.
5. Incluir el rendimiento en la definición de terminado y en las notas de versión, como las actualizaciones de seguridad.

Palanca	Esfuerzo (orientativo)	Actúa sobre todo en
Optimizar y priorizar la imagen principal	bajo	LCP
Fijar dimensiones de imágenes y contenidos incrustados	bajo	CLS
Activar caché de página y de servidor	bajo a medio	LCP
Precargar fuentes y ajustar la fuente de reserva	bajo a medio	CLS, LCP
Reducir o diferir scripts de terceros	medio	INP, LCP
Dividir JavaScript, reducir la hidratación	medio a alto	INP
Cambiar el alojamiento o la arquitectura	alto	LCP, INP

Ejemplo práctico: páginas de servicios de un proveedor

Supongamos que un proveedor con un sitio WordPress ve en Search Console que las páginas de servicios en móvil suspenden en LCP y CLS. El análisis muestra causas típicas: la imagen principal está como fondo CSS en un slider y un plugin la carga de forma diferida, el banner de consentimiento empuja el texto hacia abajo y el widget de chat se carga en todas las páginas. Un ciclo de optimización de cuatro semanas sería así:

1. Semana 1 – línea base: registrar los datos CrUX, los valores de Lighthouse y el Server-Timing de las plantillas más importantes.
2. Semanas 2 a 3 – optimización: servir la imagen principal como img con prioridad alta y excluirla de la carga diferida, reservar espacio para el banner y cargar el chat solo tras una interacción.
3. Semana 4 – nueva medición: comparación con la línea base y documentación con capturas de antes y después.

El objetivo: un LCP en el percentil 75 por debajo de 2,5 segundos, sin distorsionar el seguimiento de marketing. Precisamente con banners de consentimiento y herramientas de análisis se necesitan soluciones que equilibren protección de datos, medibilidad y velocidad. En los datos de campo el éxito se refleja solo poco a poco por la ventana de 28 días.

Errores típicos y lista de control

Errores típicos

• Perseguir la puntuación perfecta de Lighthouse en la página de inicio mientras se ignoran las subpáginas más visitadas
• Medir las optimizaciones solo en laboratorio; en producción el gestor de etiquetas carga scripts adicionales
• diferir la carga de la imagen del LCP o insertarla solo mediante script
• añadir después banner de cookies, chat o seguimiento sin volver a medir

Lista de control para páginas rápidas

• Revisar con regularidad los datos de campo en Search Console, móvil y escritorio por separado.
• Imagen principal optimizada, incluida en el HTML y con prioridad de carga alta.
• Dimensiones fijas para imágenes, vídeos y contenidos incrustados.
• Fuentes críticas precargadas y fuente de reserva ajustada.
• Scripts de terceros reducidos a lo necesario y cargados tras el consentimiento o la interacción.
• Presupuestos de rendimiento definidos en el pipeline.
• Medición antes y después en cada publicación importante.

Cómo le apoya Nano Concepts

Primero registramos los datos de campo, los valores de Lighthouse y el Server-Timing de sus plantillas más importantes, aplicamos las medidas y demostramos el efecto con una nueva medición, en el marco de la optimización de PageSpeed o como parte del SEO técnico y relanzamiento web. Nano Concepts se encarga del desarrollo; el diseño y el marketing online los realizamos junto con nuestra agencia asociada LOMA DESIGN. En la primera consulta gratuita aclaramos dónde está su sitio y qué palancas compensan primero.