Core Web Vitals y PageSpeed: por qué las páginas lentas cuestan clientes y posicionamiento

Los Core Web Vitals son tres métricas definidas por Google para medir la experiencia de usuario de un sitio web: Largest Contentful Paint (LCP) para el rendimiento de carga, Interaction to Next Paint (INP) para la interactividad y Cumulative Layout Shift (CLS) para la estabilidad visual. Influyen en el posicionamiento de Google como señal de experiencia de página. Situación en 2026.

¿Qué son los Core Web Vitals y qué tres métricas cuentan en 2026?

Los tres Core Web Vitals actuales son Largest Contentful Paint (LCP), Interaction to Next Paint (INP) y Cumulative Layout Shift (CLS). Según web.dev (Google), miden el rendimiento de carga, la interactividad y la estabilidad visual de una página. Con ello cubren los tres momentos en los que los usuarios perciben una página como rápida o lenta: la carga, la respuesta a los clics y la quietud del diseño.

Un cambio importante: INP pasó a ser oficialmente un Core Web Vital el 12 de marzo de 2024 y sustituyó a First Input Delay (FID), como confirma web.dev (Google). FID ya no es un Core Web Vital. Quien aún optimiza para FID está midiendo la métrica equivocada.

¿Qué umbrales se consideran «bueno», «mejorable» y «malo»?

Google fija límites concretos para cada Core Web Vital, medidos en el percentil 75 de todas las visitas a la página. Esto significa que una página solo se considera «buena» cuando 3 de cada 4 visitas alcanzan el nivel objetivo. Importante: según web.dev (Google, 2020), los umbrales en sí son idénticos para móvil y escritorio; lo que se mide por separado según el tipo de dispositivo es el percentil 75, no el límite.

Los valores entre «bueno» y «malo» se consideran «mejorables». Estos umbrales no son arbitrarios: Google confirma expresamente en web.dev (2020) que los límites de 2,5 s / 4 s para el LCP y de 0,1 / 0,25 para el CLS están fundamentados y equilibran una buena experiencia de usuario con una alcanzabilidad realista.

¿Qué mide el Largest Contentful Paint (LCP) y por qué 2,5 segundos?

El LCP mide cuánto tarda en renderizarse el elemento visible más grande de la ventana gráfica, normalmente una imagen principal o un titular grande. Según web.dev (Google), el LCP es «bueno» con ≤ 2,5 segundos y «malo» con > 4 segundos, en ambos casos en el percentil 75.

Los 2,5 segundos marcan el punto hasta el cual los usuarios aún perciben una página como de carga ágil. Si el elemento principal se retrasa más allá, la página parece lenta, aunque el resto lleve tiempo cargado. El LCP refleja así la velocidad de carga percibida, no solo el primer píxel.

¿Qué significa Interaction to Next Paint (INP) y en qué se diferencia de FID?

El INP mide la rapidez con que una página responde visiblemente a las acciones del usuario. Según web.dev (Google), es «bueno» con ≤ 200 milisegundos y «malo» con > 500 milisegundos (percentil 75). Se mide el intervalo desde la acción hasta el siguiente fotograma renderizado.

La diferencia con el FID, ya sustituido, es decisiva: FID solo medía el retraso de entrada de la primerísima interacción. Según web.dev, el INP observa todas las interacciones de una página, desde el retraso de entrada y los controladores de eventos hasta el siguiente fotograma renderizado. Así, el INP detecta también las reacciones entrecortadas en pleno uso, que FID simplemente ignoraba.

¿Qué es el Cumulative Layout Shift (CLS) y por qué salta mi diseño?

El CLS mide cuánto se desplaza de forma inesperada el diseño durante la carga. Según web.dev (Google), el valor es «bueno» con ≤ 0,1 y «malo» con > 0,25 (percentil 75). A diferencia del LCP y el INP, el CLS no es un tiempo, sino una métrica de desplazamiento sin dimensión.

Los saltos de diseño suelen deberse a imágenes sin espacio reservado, anuncios insertados después o fuentes que se cargan tarde. El perjuicio práctico: si quiere pulsar un botón y justo en ese momento el diseño salta, acaba en el elemento equivocado. El CLS penaliza precisamente esa frustración.

¿Influyen realmente los Core Web Vitals en el posicionamiento de Google?

Sí, pero como parte de un conjunto, no como factor aislado. En Google Search Central, Google incluye los Core Web Vitals entre los aspectos de la experiencia de página: «This, along with other page experience aspects, aligns with what our core ranking systems seek to reward.» Es, por tanto, una señal relevante para el posicionamiento, pero no una palanca ponderada por sí sola que catapulte una página débil hacia arriba.

La valoración honesta: unos buenos Core Web Vitals no sustituyen a un buen contenido. Con una relevancia comparable, sin embargo, pueden inclinar la balanza, y los valores malos son una desventaja evitable. Un sitio construido con solidez técnica, como el que ofrece un diseño web profesional, domina esta base desde el principio.

¿Las páginas lentas cuestan clientes reales?

Sí, y se puede cuantificar. Según datos de Google/SOASTA, la probabilidad de rebote en páginas móviles aumenta un 32 % cuando el tiempo de carga pasa de 1 a 3 segundos, como acredita Think with Google / SOASTA (2017). De 1 a 5 segundos es un +90 %, de 1 a 10 segundos un +123 %.

Traducido a la vida diaria: cada segundo de tiempo de carga cuesta alcance antes de que el contenido llegue siquiera a verse. Quien invierte presupuesto en anuncios o contenido regala una parte a una página lenta. La velocidad no es, por tanto, un detalle técnico, sino un factor de conversión.

Datos de laboratorio frente a datos de campo: ¿qué indica realmente PageSpeed Insights?

PageSpeed Insights combina dos fuentes de datos que a menudo se confunden. Los datos de campo proceden de sesiones reales de usuarios: según Google for Developers, la herramienta muestra valores de FCP, INP, LCP y CLS del Chrome User Experience Report (CrUX) de los últimos 28 días. Estos datos de campo son relevantes para el posicionamiento.

Los datos de laboratorio, en cambio, proceden de una medición simulada de Lighthouse en condiciones estándar: reproducible, pero no lo que experimentan los usuarios reales. Según Google, la puntuación de rendimiento de Lighthouse es buena a partir de 90, mejorable entre 50 y 89 y mala por debajo de 50. Importante: la puntuación de laboratorio es una herramienta de diagnóstico; los datos de campo de CrUX son la referencia para la evaluación.

¿Cómo mejoro mis Core Web Vitals de forma concreta?

Las palancas más eficaces varían según la métrica. web.dev (Google) indica, para cada una de las tres métricas, medidas concretas con el mayor efecto.

Mejorar el LCP: priorizar el rendimiento de carga

• Hacer que el recurso LCP sea detectable en el HTML inicial (un img src real en lugar de cargarlo después mediante JavaScript).
• Establecer fetchpriority="high" en la imagen LCP y eliminar allí loading="lazy".
• Usar una CDN: según web.dev, solo el 33 % de los documentos HTML se sirven a través de una CDN.

Mejorar el INP: aumentar la capacidad de respuesta

• Dividir las tareas largas y «ceder el control» con frecuencia para que el hilo principal quede libre.
• Reducir el JavaScript innecesario, mediante la división de código (code splitting) y la eliminación de código muerto.
• Minimizar el trabajo de renderizado, por ejemplo evitando los Forced Layouts y empleando CSS Containment.

Mejorar el CLS: estabilizar el diseño

• Definir width/height o dimensiones CSS para las imágenes: según web.dev, el 66 % de las páginas tiene al menos una imagen sin dimensiones.
• Activar la caché de retroceso/avance (bfcache).
• Evitar las animaciones que modifican el diseño y usar en su lugar CSS transform.

FAQ: preguntas frecuentes sobre Core Web Vitals y PageSpeed

¿Cuáles son los tres Core Web Vitals en 2026?

Los tres Core Web Vitals son LCP (rendimiento de carga), INP (interactividad) y CLS (estabilidad visual), tal como los define web.dev (Google). Desde el 12 de marzo de 2024, INP sustituye al antiguo First Input Delay (FID).

¿Qué valor de LCP es bueno?

El LCP es «bueno» con ≤ 2,5 segundos y «malo» con > 4 segundos, medido en el percentil 75 de todas las visitas a la página (fuente: web.dev, Google).

¿Es INP lo mismo que FID?

No. FID solo medía el retraso de la primera interacción. INP observa todas las interacciones de una página hasta el siguiente fotograma renderizado y es, desde el 12 de marzo de 2024, el Core Web Vital oficial (fuente: web.dev, Google).

¿Cuál es la diferencia entre datos de laboratorio y datos de campo?

Los datos de laboratorio proceden de una medición simulada de Lighthouse; los datos de campo, de sesiones reales de usuarios en el Chrome User Experience Report durante 28 días. Para la evaluación cuentan los datos de campo (fuente: Google for Developers).

¿A partir de qué puntuación PageSpeed es buena una página?

La puntuación de rendimiento de Lighthouse es buena a partir de 90, mejorable entre 50 y 89 y mala por debajo de 50 (fuente: Google for Developers). Esta puntuación de laboratorio es un valor de diagnóstico, no la referencia del posicionamiento.

¿Influyen los Core Web Vitals en el posicionamiento?

Sí, como parte de las señales de experiencia de página, pero no como factor aislado. Google los describe como un aspecto que coincide con lo que recompensan los sistemas de posicionamiento principales (fuente: Google Search Central).

¿Cómo afecta el tiempo de carga a los rebotes?

Si el tiempo de carga móvil pasa de 1 a 3 segundos, la probabilidad de rebote aumenta un 32 % (fuente: Think with Google / SOASTA, 2017). De 1 a 5 segundos es un +90 %.

Fuentes

• web.dev (Google) – Web Vitals (2024)
• web.dev (Google) – How Core Web Vitals thresholds were defined (2020)
• web.dev (Google) – INP becomes a Core Web Vital on March 12 (2024)
• Google Search Central – Understanding Core Web Vitals and Google Search (2024)
• Think with Google / SOASTA Research – Mobile Page Speed Benchmarks (2017)
• Google for Developers – About PageSpeed Insights (2024)
• web.dev (Google) – The most effective ways to improve Core Web Vitals (2024)

Nota: este artículo ofrece información técnica general y no constituye una garantía vinculante de rendimiento ni de posicionamiento. Los umbrales y la lógica de evaluación reflejan la situación documentada por Google en 2026 y pueden cambiar. Autor: Alexander Weipprecht. Fecha: junio de 2026.