Rendimiento

Core Web Vitals en 2026: qué miden LCP, INP y CLS y cómo mejorarlos

Core Web Vitals son tres métricas que miden cosas distintas de la experiencia de carga, y se arreglan de tres formas distintas. Confundirlas es la causa principal de que muchas optimizaciones no muevan la aguja: se trabaja sobre la métrica equivocada. Este artículo explica qué mide cada una, qué la deteriora en la práctica y en qué orden abordarlas.

Core Web Vitals: cronómetro, medidor de rendimiento y barras de tiempo de carga
Core Web Vitals: tres métricas, tres causas distintas y un orden de trabajo que evita esfuerzo desperdiciado.

Datos de campo frente a datos de laboratorio

Core Web Vitals se evalúa con datos de usuarios reales, así que una prueba puntual en tu equipo no representa la experiencia de tus visitantes. Es la primera distinción que hay que interiorizar, porque explica la contradicción más frecuente: el desarrollador ve una web rapidísima y las métricas de campo siguen en rojo.

Qué aporta cada tipo de medición
TipoPara qué sirvePara qué no sirve
Datos de campoSaber si cumples las métricas: son los que se evalúanDiagnosticar la causa concreta de un problema
Datos de laboratorioReproducir y aislar la causa de un problema detectado en campoDecidir si cumples o no: son una simulación
Monitorización sintéticaDetectar regresiones tras un despliegueRepresentar la diversidad real de dispositivos y redes

La evaluación se hace sobre el percentil 75 de las visitas reales. Eso significa que no es una media: el 25 % de tus peores casos también cuenta. Una web que carga en medio segundo para los visitantes con fibra y en nueve segundos para el resto no cumple, aunque la media parezca aceptable.

LCP · cuándo aparece lo principal

LCP mide cuánto tarda en pintarse el elemento más grande visible en la primera pantalla, y suele tratarse de la imagen principal, un titular grande o un bloque de vídeo. Lo que mide es la percepción de «ya está cargando algo útil», no la carga completa del documento.

Las cuatro causas que encontramos casi siempre, en este orden de frecuencia:

  • El servidor tarda en responder. Si el tiempo hasta el primer byte es alto, nada de lo que hagas después lo compensa. Es la primera cosa que se comprueba.
  • La imagen principal no tiene prioridad. Sin declarar prioridad alta y sin precarga, el navegador la descubre tarde, después de otros recursos que no importan.
  • El renderizado está bloqueado por estilos. Hojas de estilo completas cargadas de forma bloqueante antes de poder pintar nada.
  • El elemento principal se cambia por JavaScript. Un componente que sustituye la imagen por otra versión después de hidratar reinicia la medición.

Identifica primero el elemento exacto Antes de optimizar nada, averigua cuál es el elemento LCP de cada plantilla. Optimizar una imagen que no es la candidata es el error más común y el más caro en tiempo perdido.

INP · cuándo responde la página

INP mide cuánto tarda la página en dar respuesta visual a una interacción del usuario: desde que se hace clic o se pulsa una tecla hasta que la pantalla refleja el cambio. Sustituyó a la métrica anterior de latencia porque esta solo medía el primer retraso de entrada y no reflejaba la experiencia completa de uso.

La causa raíz es casi siempre la misma: JavaScript ejecutándose en el hilo principal en el momento de la interacción. El navegador solo tiene un hilo para ejecutar código y pintar; si está ocupado, el clic se queda esperando aunque el usuario no lo perciba como lentitud de red.

Scripts de tercerosAnalítica, chat, mapas, gestores de consentimiento y pruebas A/B. Es la causa más habitual y la más difícil de negociar, porque suele haber un área de negocio detrás.
Trabajo de hidrataciónMarcos de trabajo que reejecutan la página entera en el cliente al cargar. Cuanto más grande sea el árbol de componentes, más tarda en quedar interactiva.
Manejadores de eventos pesadosCódigo que se ejecuta en cada pulsación y hace cálculos, consultas o renderizados costosos antes de devolver el control al navegador.
Fuentes y estilos que se recalculanCambios frecuentes de estilos que obligan al navegador a recalcular posiciones de toda la página en el momento de la interacción.

CLS · cuánto se mueve el contenido

CLS mide cuánto se desplaza el contenido visible mientras la página termina de cargar, y su causa principal es no reservar espacio para lo que aparece después. El síntoma que ve el usuario es ese momento en el que va a pulsar un botón y el botón se mueve.

  • Imágenes y vídeos sin dimensiones declaradas. Si el navegador no sabe cuánto van a ocupar, reserva cero y todo lo de abajo se desplaza al cargarse.
  • Avisos, banners o barras que se insertan después. Un aviso de cookies que empuja todo el contenido hacia abajo al aparecer.
  • Tipografías que cambian de métrica al cargarse. Si la fuente de reserva ocupa distinto que la definitiva, el texto se recoloca.
  • Contenido insertado por JavaScript por encima del contenido visible. Bloques promocionales que se inyectan antes de lo que el usuario está leyendo.

Es la métrica más sencilla de corregir de las tres, porque en la mayoría de los casos se resuelve declarando dimensiones y reservando el espacio de los elementos que se insertan de forma dinámica.

Los umbrales y cómo se evalúan

Umbrales de evaluación por métrica, sobre el percentil 75 de visitas reales
MétricaQué mideCorrectoA mejorarDeficiente
LCPPintado del elemento más grande visible≤ 2,5 s2,5–4 s> 4 s
INPRespuesta visual a una interacción≤ 200 ms200–500 ms> 500 ms
CLSDesplazamiento acumulado del contenido≤ 0,10,1–0,25> 0,25

Los umbrales son los publicados por Google para la evaluación de Core Web Vitals. Para una evaluación por URL completa hay que añadir otras dos métricas: el tiempo hasta el primer byte y el tiempo de respuesta visual de la primera interacción. Una URL «buena» cumple todas.

En qué orden mejorarlas

Empieza por la métrica que afecta a más URLs y a más visitas, no por la que resulta más fácil de arreglar. Es la diferencia entre una mejora que se nota y una semana de trabajo que no mueve ningún dato.

1º

INP. Es la métrica que más sufre con el tiempo, porque cada herramienta nueva que se añade la degrada. Y es la que más afecta a la conversión: un clic que no responde se abandona.

2º

LCP. Suele resolverse con intervenciones concretas y acotadas: optimizar la imagen candidata, priorizar su carga y reducir el tiempo de respuesta del servidor.

3º

CLS. La más mecánica de las tres. Declarar dimensiones y reservar espacio elimina la mayor parte del problema en una sola iteración.

4º

Monitorizar. Sin alerta automática, cualquier despliegue puede devolver las tres métricas al punto de partida en un día.

El factor que más estropea todo: terceros

El código de terceros es hoy la principal causa de degradación de rendimiento en webs por lo demás bien construidas. Cada herramienta añadida —analítica, chat, mapas, píxeles publicitarios, pruebas A/B, gestores de consentimiento— suma solicitudes, peso y trabajo en el hilo principal, y la mayoría se ejecuta en el momento menos oportuno.

El trabajo aquí no es técnico, es de negociación. Cada script de terceros responde a una necesidad de un área de la organización, y el criterio que aplicamos es el siguiente: si no puedes explicar qué decisión de negocio mejora esa herramienta y cómo se mide, no debería estar en la página. Y si se queda, se carga de forma diferida, fuera del camino crítico y después de que el usuario pueda interactuar.

Fuentes verificables sobre Core Web Vitals: definición oficial de las métricas web esenciales en web.dev y Lighthouse, con el que puedes medir LCP, INP y CLS en tu propio navegador antes de publicar.

Preguntas frecuentes sobre Core Web Vitals

LCP por debajo de 2,5 segundos, INP por debajo de 200 milisegundos y CLS por debajo de 0,1. La evaluación se hace sobre el percentil 75 de las visitas reales, no sobre una media, lo que significa que el 25 % de tus peores casos también cuenta en el resultado.

No como fuente principal. Las herramientas de laboratorio son útiles para reproducir y diagnosticar, pero la evaluación se hace con datos de usuarios reales. Un resultado bueno en laboratorio con datos de campo malos indica que tu equipo tiene una conexión y un dispositivo que tus visitantes no tienen, y es el caso más habitual que encontramos.

Casi siempre porque ha entrado JavaScript nuevo: una etiqueta de terceros, un script de personalización, un chat o un gestor de consentimiento que se ejecuta en el momento de la interacción. INP mide la respuesta visual a un clic, así que cualquier código que ocupe el hilo principal en ese instante lo empeora. Conviene revisar qué se añadió alrededor de la fecha en que empezó el deterioro.

Cumplirlas te evita una desventaja frente a los competidores que también las cumplen, y mejora la experiencia de tus visitantes, lo que casi siempre se traduce en más conversiones. No es una palanca de posicionamiento por sí misma: no convierte una página que no responde a la intención de búsqueda en una página que sí lo hace. Tienes el marco completo en el checklist de auditoría SEO técnica.

Seguir leyendo

¿Cómo van tus Core Web Vitals?

Comprobamos los datos de campo de tu dominio, identificamos la métrica que más te cuesta y te decimos qué la causa.