Core Web Vitals explicado: LCP, INP y CLS en lenguaje claro

Core Web Vitals no es un test de personalidad para tu sitio web

Core Web Vitals suele tratarse como una misteriosa tarjeta de puntuación. Una página recibe un número rojo, alguien publica una captura en Slack y el equipo empieza a discutir sobre frameworks de JavaScript.

Eso no es especialmente útil.

Una forma mejor de pensar en Core Web Vitals es más sencilla: son tres mediciones de si una página se siente usable para una persona real en un dispositivo real. No capturan todos los aspectos del rendimiento, la accesibilidad o la calidad. Pero sí detectan tres fuentes comunes de frustración:

• El contenido principal tarda demasiado en aparecer.
• La página responde lentamente cuando el usuario intenta hacer algo.
• El diseño salta mientras el usuario está leyendo o tocando.

Esas son las tres Core Web Vitals: LCP, INP y CLS.

Google las utiliza como parte de sus señales de experiencia de página, pero el ángulo SEO no es la mejor razón para prestarles atención. La mejor razón es que las páginas lentas, inestables y poco responsivas hacen perder tiempo a los usuarios. También suelen convertir peor, ser más difíciles de mantener y envejecer mal.

Las tres métricas en una frase cada una

Antes de entrar en detalles, esta es la versión en lenguaje claro:

• LCP, o Largest Contentful Paint, mide cuánto tarda en cargarse el contenido visible principal.
• INP, o Interaction to Next Paint, mide con qué rapidez responde la página a las interacciones del usuario durante la visita.
• CLS, o Cumulative Layout Shift, mide cuánto se mueve inesperadamente la página.

Los umbrales habituales son:

| Métrica | Bueno | Necesita mejorar | Deficiente | |---|---:|---:|---:| | LCP | 2.5s o menos | 2.5s–4.0s | Más de 4.0s | | INP | 200ms o menos | 200ms–500ms | Más de 500ms | | CLS | 0.1 o menos | 0.1–0.25 | Más de 0.25 |

Estos números normalmente se evalúan en el percentil 75 de las visitas de usuarios reales. Eso importa. No intentas conseguir una ejecución de laboratorio perfecta. Intentas que la experiencia sea buena para la mayoría de los usuarios, incluidas las personas con teléfonos más lentos y redes más irregulares.

Si estás mirando un informe automatizado y no sabes por dónde empezar, ayuda separar el diagnóstico del pánico. Tenemos una guía aparte sobre cómo leer un informe de Lighthouse sin entrar en pánico que cubre ese flujo de trabajo con más detalle.

LCP: ¿cuándo se siente cargada la página?

Largest Contentful Paint mide el tiempo de renderizado del elemento de contenido visible más grande dentro del viewport. En la práctica, suele ser:

• una imagen hero,
• un encabezado grande,
• una imagen destacada de un artículo,
• una imagen de producto,
• un bloque grande de texto.

LCP no pregunta cuándo terminaron de cargarse todos los scripts, píxeles de seguimiento e imágenes por debajo del pliegue. Pregunta: ¿cuándo se hizo visible lo principal que el usuario vino a ver?

Eso convierte a LCP en una métrica más humana que el antiguo “tiempo de carga de la página”. Una página puede terminar técnicamente de cargarse tarde y aun así sentirse rápida si el contenido principal aparece pronto. Lo contrario también es cierto: una página puede disparar el evento de carga mientras el área hero sigue en blanco, borrosa o bloqueada por un retraso de renderizado.

Causas comunes de un LCP deficiente

La mayoría de los problemas graves de LCP vienen de unos pocos lugares previsibles:

1. Respuesta lenta del servidor

Si el documento HTML llega tarde, todo lo demás empieza tarde.

1. CSS o JavaScript que bloquean el renderizado

El navegador tiene el contenido, pero todavía no puede pintarlo.

1. Imágenes hero no optimizadas

El elemento más grande es demasiado grande, está en el formato incorrecto, no está priorizado o se carga de forma diferida por error.

1. Fuentes web que retrasan el renderizado del texto

Un encabezado grande puede ser el elemento LCP, y la carga de fuentes puede retrasarlo o alterarlo visualmente.

1. Retrasos por renderizado del lado del cliente

Si la página necesita un gran paquete de JavaScript antes de poder mostrar contenido significativo, LCP se resiente.

Cómo mejorar LCP

Empieza por el elemento LCP real. No optimices recursos al azar hasta saber qué está midiendo el navegador.

Algunas correcciones prácticas incluyen:

• Servir HTML rápidamente: usa caché cuando corresponda, reduce el trabajo del backend y evita redirecciones lentas.
• Optimizar la imagen LCP: usa las dimensiones, la compresión y el formato adecuados.
• No cargues de forma diferida la imagen hero por encima del pliegue.
• Usa fetchpriority="high" con cuidado para la imagen principal cuando realmente sea la prioridad.
• Inserta CSS crítico en línea solo cuando reduzca de forma significativa el retraso de renderizado.
• Reduce el JavaScript necesario antes del primer renderizado significativo.
• Usa font-display: swap u otra estrategia de fuentes intencional.

Las imágenes y las fuentes son culpables frecuentes. En imágenes, la compensación no es simplemente “archivo pequeño bueno”. La elección del formato, el esfuerzo de codificación y la compatibilidad del navegador también importan, por eso mantenemos un árbol de decisión práctico sobre cuándo AVIF supera a WebP y cuándo no. En páginas con mucho texto, las fuentes web siguen siendo una de las mejoras de rendimiento más fáciles, porque muchos sitios envían más archivos de fuentes de los que utilizan.

INP: ¿responde la página cuando se toca?

Interaction to Next Paint mide la capacidad de respuesta. Más específicamente, observa el retraso entre una interacción del usuario y la siguiente actualización visual después de que el navegador haya procesado esa interacción.

Las interacciones incluyen cosas como:

• hacer clic en un botón,
• tocar un menú,
• seleccionar una casilla de verificación,
• escribir en un campo de formulario,
• abrir un acordeón.

INP reemplazó a First Input Delay como Core Web Vital en 2024. Fue un buen cambio. First Input Delay solo miraba la primera interacción. INP es más amplio: considera las interacciones durante toda la visita a la página e informa una interacción de alta latencia como la puntuación de capacidad de respuesta de la página.

En lenguaje claro: INP detecta páginas que parecen cargadas pero se sienten bloqueadas.

Probablemente has usado una página así. Parece lista. Tocas el menú. No pasa nada durante medio segundo. Tocas otra vez. Entonces ocurren dos cosas a la vez. Eso es un problema de INP.

Causas comunes de un INP deficiente

INP suele ser un problema del hilo principal. El navegador quiere responder, pero JavaScript, el trabajo de renderizado o el cálculo de layout están en medio.

Las causas típicas incluyen:

• paquetes de JavaScript grandes,
• manejadores de eventos costosos,
• trabajo de hidratación en aplicaciones renderizadas en el cliente,
• scripts de terceros que compiten por el hilo principal,
• tareas de larga duración después de la carga de la página,
• actualizaciones complejas del DOM desencadenadas por interacciones pequeñas,
• layout thrashing, donde el código lee y escribe repetidamente valores de layout.

Las etiquetas de marketing, analítica, widgets de chat y banners de consentimiento pueden contribuir. Esto no significa “eliminarlo todo”. Significa que cada script de la página tiene un coste, y la latencia de interacción es donde ese coste suele hacerse visible.

Cómo mejorar INP

Mejorar INP tiene menos que ver con un atributo mágico y más con reducir la contención del hilo principal.

Algunos enfoques útiles incluyen:

• Dividir las tareas largas de JavaScript en fragmentos más pequeños.
• Diferir el trabajo no esencial hasta después de que la página sea usable.
• Eliminar JavaScript no utilizado en lugar de simplemente minificarlo.
• Mantener los manejadores de eventos pequeños y predecibles.
• Evitar volver a renderizar grandes partes de la interfaz por cambios mínimos de estado.
• Usar CSS para estados visuales simples cuando sea posible.
• Auditar scripts de terceros y cargarlos solo donde sean necesarios.

También observa el diseño de la interacción. Un botón que ofrece feedback visual inmediato puede sentirse más responsivo, aunque el trabajo posterior tarde más. No sustituye al rendimiento, pero forma parte de una buena ingeniería de interfaz. Nuestra lista de comprobación para botones web accesibles se solapa con esto: estados claros, semántica adecuada y comportamiento predecible ayudan tanto a los usuarios como a los navegadores.

CLS: ¿la página permanece donde el usuario espera?

Cumulative Layout Shift mide el movimiento inesperado de elementos visibles. Si un usuario empieza a leer un párrafo y un anuncio, imagen o banner se carga por encima, empujando el texto hacia abajo, eso contribuye a CLS.

CLS no se mide en segundos. Es una puntuación basada en cuánto contenido se movió y cuánto se desplazó. Cuanto más baja, mejor.

La palabra clave es inesperado. Los cambios de layout causados por una acción del usuario normalmente no se cuentan de la misma manera. Si alguien toca “mostrar más” y el contenido se expande, eso es esperado. Si un banner de newsletter aparece en la parte superior después de tres segundos y empuja todo hacia abajo, no lo es.

Causas comunes de un CLS deficiente

Los fallos de CLS suelen ser mundanos:

• imágenes sin atributos de anchura y altura,
• anuncios o incrustaciones sin espacio reservado,
• banners de cookies insertados por encima del contenido,
• fuentes web que se intercambian con métricas diferentes,
• barras promocionales de carga tardía,
• contenido inyectado dinámicamente cerca de la parte superior de la página.

La solución suele ser reservar espacio antes de que llegue el contenido. El navegador debería conocer la forma de la página lo antes posible.

Cómo mejorar CLS

Empieza por los desplazamientos visibles. Mira una grabación o usa herramientas del navegador para identificar qué elementos se mueven.

Luego aplica las correcciones aburridas:

• Añade atributos explícitos width y height a las imágenes.
• Usa CSS aspect-ratio para contenedores multimedia responsivos.
• Reserva espacio fijo o mínimo para anuncios, incrustaciones e iframes.
• Evita inyectar banners por encima del contenido existente después de la carga.
• Elige fuentes de reserva con métricas similares a la fuente final.
• Evita animaciones que cambien propiedades de layout como top, left, width o height; prefiere transformaciones.

CLS es una de las pocas métricas de rendimiento donde la disciplina gana a la astucia. Si la página tiene cajas estables, tiende a puntuar bien.

Los datos de campo y los datos de laboratorio son útiles, pero responden a preguntas distintas

Una fuente común de confusión es que distintas herramientas muestran números distintos. Eso es normal.

Los datos de campo provienen de usuarios reales. Reflejan dispositivos, redes, ubicaciones y condiciones de navegador reales. El Chrome User Experience Report de Google es un ejemplo de datos de campo.

Los datos de laboratorio provienen de un entorno de prueba controlado. Lighthouse es el ejemplo familiar. Es repetible y útil para depurar, pero no es lo mismo que la experiencia vivida por tus usuarios.

Usa datos de campo para decidir si los usuarios tienen un problema real. Usa datos de laboratorio para reproducir y depurar ese problema.

Recuerda también que Core Web Vitals suele evaluarse por URL o grupo de URL, no como una propiedad abstracta única de tu marca. Tu página de inicio, artículo de blog, página de precios y checkout pueden tener cuellos de botella muy diferentes.

Un orden de trabajo sensato

Si las tres métricas son deficientes, la tentación es empezar por todas partes. Resístela.

Un orden práctico es:

1. Corrige primero los problemas evidentes de CLS

Las dimensiones de imagen faltantes y los banners inestables suelen ser victorias rápidas.

1. Mejora LCP en plantillas importantes

Concéntrate en las páginas que importan: páginas de producto, landing pages, artículos, flujos de registro.

1. Investiga INP con interacciones reales

Haz clic en lo que los usuarios realmente hacen clic. Menús, filtros, formularios y controles de checkout suelen revelar más que la traza de carga inicial.

1. Audita scripts de terceros

Conserva los que justifican su coste. Elimina o retrasa los que no.

1. Define un presupuesto de rendimiento

Sin un presupuesto, las mejoras de rendimiento se degradan. Nuevos scripts, imágenes y componentes de diseño desharán el trabajo en silencio.

El punto importante: no optimices para una insignia. Optimiza para el recorrido del usuario. Una mejora marginal de puntuación en una página con poco tráfico puede importar menos que una interacción de checkout ligeramente imperfecta pero mucho más rápida.

<!-- tool-cta:start -->

💡 Prueba esto: Como el LCP suele ser un problema de imagen, reduce el tamaño de tu recurso hero con Image Compressor como una primera mejora fácil.

<!-- tool-cta:end -->

Lo que Core Web Vitals no te dice

Core Web Vitals es útil, pero incompleto.

No te dice si tu contenido es bueno. No te dice si tu navegación tiene sentido. No garantiza la accesibilidad. No mide privacidad, seguridad, confianza, legibilidad ni si la página responde a la pregunta del usuario.

Tampoco reemplaza el criterio. Una página puede aprobar Core Web Vitals y aun así ser desagradable. Una aplicación compleja puede no alcanzar un umbral y aun así estar diseñada responsablemente dentro de sus limitaciones.

Trata LCP, INP y CLS como detectores de humo. Cuando suenen, investiga. Cuando estén en silencio, sigue manteniendo el edificio.