Core Web Vitals: LCP, INP y CLS explicados

Las Core Web Vitals son las métricas puente entre el SEO técnico y la experiencia real del usuario. Traducen conceptos abstractos de rendimiento en tres valores medibles que Google recoge directamente de los navegadores de visitantes reales. Este artículo explica LCP, INP y CLS en detalle, sitúa su peso real como señal de ranking y muestra cómo mejorar estas métricas de forma específica en un stack moderno con Next.js, Edge/CDN y HTTP/3. El foco está en el uso móvil, por el que pasa, por ejemplo en Austria, la mayor parte de los accesos a internet.

Por qué las Core Web Vitals importan para el SEO técnico

Las Core Web Vitals son la parte de la experiencia en la página que Google promueve y utiliza en sus sistemas de ranking. En su documentación oficial, Google deja claro que no existe una única señal de experiencia en la página, pero que los sistemas de ranking sí utilizan las Core Web Vitals y que una buena experiencia en la página puede contribuir al éxito en búsquedas para las que existe mucho contenido útil (Google Search Central). Por tanto, las tres métricas no son un factor de posicionamiento principal, pero sí una señal de calidad sólida que inclina la balanza sobre todo cuando compiten varios resultados equivalentes en contenido.

La práctica muestra cuánto margen de mejora queda. Según el Web Almanac 2024, solo el 43 por ciento de los orígenes móviles supera las tres Core Web Vitals; en escritorio, el 54 por ciento (HTTP Archive, Web Almanac 2024). Si trabajas bien este aspecto, te distingues de más de la mitad de la web móvil. Para Austria esto es especialmente relevante, porque el uso de internet allí es marcadamente móvil: en junio de 2024, el 81,5 por ciento de los accesos a internet en el país se realizó desde dispositivos móviles. Una gran parte correspondió a apps. A través de la web móvil se produjo el 31,6 por ciento de todos los accesos (Statista, Österreichische Webanalyse). Para las Core Web Vitals solo cuenta la parte del navegador, y también esta es en gran medida móvil.

Las tres métricas y sus umbrales

Google clasifica la evaluación en good, needs improvement y poor, y mide siempre en el percentil 75 de las visitas, por separado para móvil y escritorio. Los umbrales «good» oficiales son: LCP de 2,5 segundos o menos, INP de 200 milisegundos o menos y CLS de 0,1 o menos (web.dev). En concreto, el percentil 75 significa que tres de cada cuatro visitas deben alcanzar el umbral; el peor cuarto no cuenta. Una página solo supera una Core Web Vital cuando es rápida de forma fiable, no solo en el caso ideal.

• Largest Contentful Paint (LCP): mide cuándo se ha renderizado el elemento visible más grande del viewport. Es el indicador que representa la velocidad de carga percibida.
• Interaction to Next Paint (INP): mide la latencia entre una interacción del usuario y la siguiente actualización visible de la pantalla, a lo largo de toda la sesión.
• Cumulative Layout Shift (CLS): mide la mayor ráfaga de desplazamientos inesperados del diseño durante toda la vida útil de la página, es decir, lo estable que se mantiene el contenido (web.dev).

A nivel de métricas individuales, el panorama en el segmento móvil es desigual. En 2024, el 59 por ciento de las páginas móviles alcanzó un LCP bueno, el 74 por ciento un INP bueno y el 79 por ciento un CLS bueno (Web Almanac 2024). Así, en dispositivos móviles el LCP es, de las tres, la métrica que más a menudo no se cumple.

LCP en detalle: optimizar la percepción de carga

En el LCP casi siempre se trata de una imagen. El 73,3 por ciento de las páginas móviles tiene una imagen como elemento LCP (Web Almanac 2024). Por eso, la imagen LCP es la palanca de optimización individual más importante. Las causas típicas de un LCP lento se concentran en tres áreas: un tiempo de respuesta del servidor elevado (TTFB), recursos que bloquean el renderizado, como CSS y JavaScript en la ruta crítica, y el propio tiempo de carga del recurso LCP.

Las contramedidas más eficaces actúan justo ahí:

• Controlar la prioridad: marca la imagen LCP con fetchpriority="high" y, si es necesario, solicítala pronto mediante <link rel="preload"> para que el navegador no la ponga en cola detrás de recursos menos importantes.
• No cargar nunca la imagen LCP en diferido: es un antipatrón muy extendido. El 16 por ciento de las páginas móviles carga su imagen LCP en diferido, y el 9,5 por ciento incluso mediante el loading="lazy" nativo (Web Almanac 2024). El elemento LCP está above the fold y debe cargarse en modo eager.
• Usar formatos de imagen modernos: AVIF y WebP reducen notablemente el tamaño de archivo frente a JPEG y acortan así el tiempo de carga del recurso.
• Reducir el TTFB con Edge/CDN: servir desde un nodo de CDN cercano al usuario y usar protocolos de transporte modernos acorta el tiempo de respuesta del servidor antes incluso de que se renderice un solo píxel.

INP en detalle: garantizar la interactividad

INP reemplazó a FID como Core Web Vital el 12 de marzo de 2024 y, al mismo tiempo, pasó a figurar en Search Console en lugar de FID (web.dev). El cambio no fue cosmético: FID solo medía el retraso de la primera interacción, mientras que INP evalúa todas las interacciones de una sesión y es bastante más estricto. Eso se refleja en las cifras: con FID, en 2024 el 48 por ciento de las páginas móviles habría tenido unas CWV buenas; con INP, solo el 43 por ciento (Web Almanac 2024).

El INP se compone de tres fases: el input delay (tiempo de espera hasta que puede arrancar el controlador de eventos), el processing time (ejecución del controlador) y el presentation delay (tiempo hasta el siguiente fotograma). Con diferencia, la causa más frecuente de un INP malo es el JavaScript bloqueante, que ocupa el hilo principal y acumula interacciones. De ahí salen tres palancas que el artículo Optimizar el INP trata en detalle:

• Dividir las tareas largas (task splitting): fragmenta las tareas grandes de JavaScript en partes más pequeñas y devuelve el control al navegador entre medias, por ejemplo con scheduler.yield() o aplazándolas, para que las entradas del usuario no tengan que esperar.
• Desacoplar eventos (debouncing): limita la frecuencia de los controladores que se disparan a menudo, como los eventos de scroll o de entrada, para que no se ejecute lógica costosa con cada píxel.
• Externalizar el trabajo (Web Workers): traslada el trabajo de cálculo intensivo que no afecta a la interfaz a un Web Worker para mantener libre el hilo principal.

CLS en detalle: mantener la estabilidad visual

El CLS evalúa la estabilidad visual de una página: penaliza los contenidos que siguen saltando después del primer renderizado. Las causas son bien conocidas: imágenes e iframes sin dimensiones fijas, contenido cargado dinámicamente por encima del contenido existente, fuentes web que cargan tarde y provocan saltos de diseño, y espacios publicitarios sin hueco reservado. Las contramedidas son preventivas en todos los casos:

• Definir las dimensiones: para imágenes y vídeos, establece siempre width y height o un aspect-ratio para que el navegador reserve el espacio antes de la carga.
• Reservar espacio para elementos dinámicos: prevé huecos fijos en el diseño para anuncios, embeds y banners cargados después, en lugar de insertarlos en el flujo.
• Suavizar el cambio de fuente: con font-display y fuentes precargadas, minimiza el reflujo del texto al sustituir la fuente.

Con un 79 por ciento de valores buenos en móviles, el CLS es la métrica mejor dominada de las tres (Web Almanac 2024). Esto se debe a que las contramedidas son técnicamente sencillas y basta con aplicarlas una vez.

Buenas prácticas: CWV en un stack con Next.js y Edge

En Next.js, muchas optimizaciones de CWV ya vienen integradas en los componentes del framework, pero hay que usarlas de forma consciente. next/image obliga a definir dimensiones y sirve formatos modernos. Para la imagen más importante, fetchPriority="high" eleva la prioridad de carga, lo que repercute directamente en el LCP. Hasta Next.js 14, el atributo priority establecía este valor automáticamente. Desde Next.js 15, priority solo se encarga del preload y la carga eager; fetchPriority="high" tienes que establecerlo tú (Next.js, Pull Request #67351). Desde Next.js 16, priority está marcado como obsoleto en favor de preload, y la documentación de Next.js recomienda en la mayoría de los casos fetchPriority="high" o loading="eager". next/font carga las fuentes en local y autoalojadas, y evita así el salto de diseño provocado por las fuentes, que empeora el CLS. El streaming mediante SSR y React Server Components reduce el JavaScript enviado al cliente, lo que atenúa la causa principal de un INP elevado.

El punto más crítico del App Router es la hidratación. Cada componente de cliente interactivo tiene que hidratarse en el navegador, y demasiado JavaScript de cliente genera precisamente las tareas largas que disparan el INP. En la práctica, esto significa: dejar todo lo posible como Server Component, limitar la interactividad a pequeñas islas de cliente y cargar los componentes pesados de forma diferida y selectiva.

La infraestructura técnica refuerza estos efectos. En la web, el 54 por ciento de más de 1,3 mil millones de solicitudes ya se sirve a través de una CDN, mientras que HTTP/3 está disponible en alrededor del 30 por ciento de las páginas, pero solo se usa realmente en el 7 al 9 por ciento de las primeras visitas (Web Almanac 2024, HTTP). El caching en el edge y HTTP/3 reducen el TTFB y, con ello, el punto de partida del LCP, sin necesidad de cambiar nada en el código del frontend.

Una entrega más rápida y bien cacheada beneficia además al crawl budget y a los crawlers de IA, que acceden a la web en volumen creciente: Googlebot creció un 96 por ciento entre mayo de 2024 y mayo de 2025 y mantiene alrededor del 50 por ciento de la cuota de crawlers, mientras que GPTBot pasó del 2,2 al 7,7 por ciento (Cloudflare). Una página con buen rendimiento y una entrega predecible es, por tanto, también una ventaja para la Generative Engine Optimization (GEO).

Errores frecuentes al optimizar las CWV

• Tomar los valores de laboratorio por la realidad: una puntuación verde de Lighthouse en el laboratorio no dice nada sobre lo que evalúa Google. Lo determinante es el percentil 75 de los usuarios reales.
• Cargar la imagen LCP en diferido: el error autoinfligido más frecuente en el LCP. El elemento situado above the fold nunca debe cargarse con retraso.
• Confundir INP con FID: si sigues optimizando para FID, estás midiendo la magnitud equivocada. Desde marzo de 2024, INP es la única métrica de interactividad relevante.
• Revisar el CLS solo al principio de la página: los saltos de diseño suelen producirse al hacer scroll o con inserciones tardías. El CLS se mide durante todo el ciclo de vida de la página.
• Probar solo en escritorio: Google evalúa móvil y escritorio por separado, y en móvil muchos menos orígenes superan los tres valores (43 frente a 54 por ciento, Web Almanac 2024). Las pruebas deben hacerse en móvil con CPU y red limitadas.

Medición: laboratorio frente a campo y las herramientas adecuadas

La distinción más importante es la que hay entre datos de laboratorio y datos de campo. Los datos de laboratorio (lab) se generan en un entorno controlado, por ejemplo en Lighthouse, y sirven para depurar y para comparaciones reproducibles. Pero no influyen en el ranking. Los datos de campo (field) proceden de usuarios reales y se evalúan en el percentil 75 (web.dev). Solo estos datos de usuarios reales cuentan para la evaluación.

• Chrome UX Report (CrUX): la fuente oficial de datos de campo, agregados a partir de usuarios reales de Chrome. Es la base del informe de Search Console y de PageSpeed Insights.
• PageSpeed Insights: combina los datos de campo de CrUX en la parte superior con una ejecución de laboratorio de Lighthouse debajo. Ideal para ver juntos el estado real y la causa técnica.
• Informe de CWV de Search Console: agrupa las URL en good, needs improvement y poor a partir de datos de campo y muestra la evolución en el tiempo para toda la propiedad.
• RUM y web-vitals.js: una medición propia con usuarios reales en el código, por ejemplo con la biblioteca web-vitals.js, proporciona datos de campo continuos y un diagnóstico granular, también para herramientas como DebugBear.

Si separas sistemáticamente laboratorio y campo, evitas el error de interpretación más habitual: tomar un buen resultado de laboratorio por una Core Web Vital superada.

Las CWV como señal de ranking y su caso de negocio

La expectativa realista es esta: las Core Web Vitals no sustituyen ni la relevancia ni el contenido de calidad. Google afirma expresamente que no existe una única señal y que siempre quiere mostrar la respuesta más relevante, incluso con una experiencia en la página mejorable, pero que una buena experiencia en la página puede marcar la diferencia en búsquedas para las que existe mucho contenido útil (Google Search Central). Así, las CWV actúan como amplificador y criterio de desempate, no como atajo para esquivar un contenido flojo.

La palanca más potente suele ser la conversión. El caso práctico de redBus documentado por Google muestra que una optimización específica del INP aumentó las ventas un 7 por ciento, con una mejora del propio INP del 72 por ciento, entre otras cosas gracias a controladores de scroll con debounce y a menos consultas a la API (web.dev, redBus). Estas cifras proceden de un caso internacional, pero el mecanismo es trasladable: las interacciones más rápidas reducen los abandonos y aumentan las compras. En el contexto austriaco, donde la mayor parte de los accesos a internet se realiza desde el móvil (Statista), cada mejora móvil del INP o del LCP llega directamente a una gran parte de los visitantes. Por eso, el caso de negocio de las CWV es menos un argumento de SEO que un argumento de ventas con efecto secundario en el SEO.

Para profundizar

Las Core Web Vitals son más eficaces cuando se integran en todo el stack de SEO técnico. El LCP depende del TTFB y, por tanto, del caching en Edge/CDN y de HTTP/3; el INP, de la estrategia de JavaScript y de renderizado; y las tres se benefician de una arquitectura limpia en Next.js con un JavaScript de cliente mínimo. Si inviertes aquí, mejoras a la vez la entrega a los crawlers clásicos y a los de IA y, con ello, la visibilidad en GEO. Puedes profundizar en el tema con los artículos sobre SEO para JavaScript y renderizado, HTTP/3 e infraestructura de rendimiento, Edge SEO a nivel de CDN, CDN y ubicación del servidor y sobre la arquitectura SEO en Next.js.