Saltar al contenido

SEO · 5 min

Core Web Vitals: qué miden y qué merece la pena arreglar

Qué miden LCP, INP y CLS, cuáles son sus valores recomendados, cómo interpretar PageSpeed Insights y qué conviene priorizar antes de perseguir una puntuación perfecta.

Por Roke Studio5 min

Core Web Vitals sirve para medir tres partes bastante concretas de la experiencia de una web:

  • cuánto tarda en aparecer su contenido principal;
  • cómo responde cuando alguien interactúa;
  • y cuánto se mueve inesperadamente mientras carga.

Son LCP, INP y CLS.

Google recomienda conseguir buenas Core Web Vitals y explica que están alineadas con lo que sus sistemas de ranking buscan recompensar. Pero también deja claro que no hay una única señal de experiencia de página y que intenta mostrar el contenido más relevante aunque la experiencia de la página sea mejorable.

Una web rápida con contenido poco relevante sigue teniendo ese problema.

Y una puntuación de 100 en Lighthouse tampoco debería convertirse en el objetivo del proyecto.

Las tres Core Web Vitals

MétricaQué intenta medirBueno
LCPCuándo aparece el contenido principal≤ 2,5 s
INPCómo responde la página a las interacciones≤ 200 ms
CLSCuánto se mueve el contenido inesperadamente≤ 0,1

Google evalúa estos valores en el percentil 75 de las visitas, por separado en móvil y escritorio.

Eso significa que no se juzga la web por una única carga perfecta desde tu ordenador.

Se intenta observar qué experiencia recibe la mayoría de usuarios reales.

LCP: cuándo aparece lo importante

Largest Contentful Paint mide cuándo se muestra el elemento más grande visible en la primera pantalla: normalmente una imagen, un bloque de texto o un vídeo.

Si tarda demasiado, algunas causas habituales son:

  • una imagen principal pesada o mal servida;
  • respuesta lenta del servidor;
  • fuentes, CSS o JavaScript que retrasan el render;
  • cargar con lazy un elemento que debería aparecer inmediatamente.

No se trata de hacer que toda la página termine de cargar en 2,5 segundos.

LCP mide algo mucho más concreto.

INP: cómo responde cuando haces algo

Interaction to Next Paint mide cuánto tarda la página en mostrar una respuesta visual después de interacciones como hacer clic, tocar o utilizar el teclado.

Un INP alto suele hacer que una web se sienta torpe incluso si aparentemente cargó rápido.

JavaScript pesado, tareas largas o scripts de terceros son causas habituales.

INP sustituyó a FID como Core Web Vital en 2024.

CLS: que la página no se mueva debajo de ti

Cumulative Layout Shift mide desplazamientos inesperados.

El típico ejemplo: vas a pulsar un botón, carga una imagen, todo baja y terminas pulsando otra cosa.

Reservar espacio para imágenes y embeds, controlar cómo cargan las fuentes y evitar insertar elementos inesperadamente encima del contenido ayuda a reducirlo.

PageSpeed Insights mezcla dos tipos de datos

Esta distinción importa más que perseguir el número grande de arriba.

Datos de campo

Son experiencias de usuarios reales recogidas mediante Chrome UX Report (CrUX).

Cuando hay suficiente información, PageSpeed Insights puede mostrarlos y Search Console los utiliza para su informe de Core Web Vitals.

Son los datos más útiles para saber qué está ocurriendo realmente a las personas que visitan la web.

Una web nueva o con poco tráfico puede no tener suficientes.

Eso no significa que haya un problema.

Significa que todavía no existe una muestra suficiente.

Datos de laboratorio

Son una prueba realizada en condiciones controladas.

Lighthouse entra aquí.

Sirven muchísimo para encontrar problemas y probar cambios durante desarrollo, pero no reproducen todos los dispositivos, conexiones e interacciones de los usuarios reales.

Por eso puedes tener un Lighthouse excelente y datos de campo mejorables, o al revés.

Además, en una prueba de carga normal Lighthouse no mide INP, porque nadie interactúa con la página durante la prueba. Utiliza otras métricas, como Total Blocking Time, como aproximación para detectar problemas relacionados, aunque no lo sustituyen.

¿Y el TTFB?

Time to First Byte mide cuánto tarda en empezar a llegar la respuesta del servidor.

No es una Core Web Vital.

Puede ser útil para diagnosticar un LCP lento porque todo lo que ocurre después depende de que la respuesta empiece a llegar.

Como orientación, web.dev sitúa 0,8 segundos o menos como un buen objetivo para muchas webs.

Pero no perseguiría ese número de forma aislada si la experiencia real ya es buena.

Cómo las revisaría

Mi orden sería bastante simple:

  1. Mira primero si existen datos de campo. Search Console y PageSpeed Insights pueden decirte si usuarios reales están teniendo un problema.
  2. Identifica qué métrica falla. LCP, INP y CLS suelen tener causas bastante diferentes.
  3. Utiliza laboratorio para investigar. DevTools y Lighthouse ayudan a encontrar qué imagen, script o comportamiento está provocándolo.
  4. Prioriza las páginas que realmente importan. Una landing principal, un servicio o una tienda merece atención antes que una URL residual sin tráfico.
  5. Corrige la causa y vuelve a medir.

Los datos de campo no cambian inmediatamente después de desplegar una mejora.

Necesitan nuevas visitas y tiempo para reflejarla.

No optimices una web contra su propia función

Hay mejoras evidentes: una imagen enorme que puede servirse mejor, JavaScript innecesario, un layout que salta, una fuente mal cargada.

Hazlas.

Pero eliminar una fotografía necesaria, un formulario útil o una funcionalidad importante únicamente para conseguir unas décimas mejores puede estar resolviendo el problema equivocado.

Core Web Vitals sirve para detectar experiencias mejorables.

No para decidir qué debe tener tu negocio en la web.

Qué importa al final

Intentaría conseguir buenos valores en las tres.

Pero no utilizaría Core Web Vitals como una puntuación de calidad global de la web ni como una promesa SEO.

Son una parte de algo más amplio: contenido, estructura, usabilidad, accesibilidad, funcionamiento y experiencia real.

Si quieres saber qué problemas merece la pena priorizar antes de empezar a tocar cosas, es lo que revisamos en una Auditoría web.

Y si trabajas con Next.js y buscas una revisión técnica más amplia, tienes también nuestra checklist de SEO técnico para Next.js.

Roke StudioWeb · SEO · Software

Escribimos sobre decisiones que aparecen en proyectos reales: cómo estructurar una web, cómo captar demanda y cuándo la tecnología puede simplificar un negocio.

Web + SEO

¿Quieres que tu web haga este trabajo?

Estudiamos qué busca tu cliente, cómo debería estructurarse la web y qué tiene que pasar para convertir esa visibilidad en oportunidades.

Ver Web + SEO ↗