0 Comentarios
Los Core Web Vitals son tres métricas que permiten comprobar cómo experimentan los usuarios reales aspectos concretos del rendimiento de una página: cuánto tarda en mostrarse su contenido principal, cómo responde cuando alguien interactúa con ella y si los elementos se desplazan inesperadamente mientras se utiliza.
Actualmente, las tres métricas son Largest Contentful Paint (LCP), Interaction to Next Paint (INP) y Cumulative Layout Shift (CLS). Para considerar bueno el rendimiento, Google recomienda un LCP de 2,5 segundos o menos, un INP de 200 milisegundos o menos y un CLS de 0,1 o menos, tomando como referencia el percentil 75 de las visitas.
El dato importante no es simplemente si PageSpeed Insights muestra un círculo verde. Cada métrica señala un tipo de problema diferente y, por tanto, exige un diagnóstico distinto.
| Métrica | Qué mide | Bueno | Necesita mejorar | Deficiente |
|---|---|---|---|---|
| LCP | Velocidad con la que aparece el contenido principal | ≤ 2,5 s | > 2,5 y ≤ 4 s | > 4 s |
| INP | Capacidad de respuesta ante las interacciones | ≤ 200 ms | > 200 y ≤ 500 ms | > 500 ms |
| CLS | Estabilidad visual de la página | ≤ 0,1 | > 0,1 y ≤ 0,25 | > 0,25 |
Estos valores no se evalúan utilizando simplemente el promedio. Para clasificar una página o un sitio se toma como referencia el percentil 75: el objetivo es que al menos el 75 % de las visitas queden dentro del umbral considerado bueno.
Google creó Web Vitals para acercar la medición del rendimiento a aquello que realmente percibe una persona cuando utiliza una web.
Una página puede empezar a mostrar contenido rápidamente y, aun así, ofrecer una experiencia deficiente. Puede ocurrir, por ejemplo, que el bloque principal tarde varios segundos en aparecer, que un botón no responda inmediatamente después de pulsarlo o que el contenido se desplace porque una imagen o un anuncio ocupan espacio después de haberse empezado a mostrar la página.
Los Core Web Vitals separan estos problemas en tres dimensiones:
Son métricas centradas principalmente en la experiencia de usuarios reales. Las herramientas de laboratorio siguen siendo muy útiles para investigar un problema, pero no deben confundirse con los datos recogidos en condiciones reales.
Desde el 12 de marzo de 2024, INP sustituyó a First Input Delay (FID) como Core Web Vital de capacidad de respuesta. Por tanto, cualquier guía que continúe presentando LCP, FID y CLS como las tres métricas actuales está desactualizada.
Largest Contentful Paint mide el tiempo que transcurre hasta que se renderiza el elemento de contenido de mayor tamaño visible en el viewport.
En muchas páginas ese elemento será una imagen principal, un banner, una fotografía de producto o un gran bloque de texto, aunque depende de la página y del dispositivo desde el que se visite.
Un LCP de 2,5 segundos o menos se considera bueno. Entre 2,5 y 4 segundos necesita mejorar y por encima de 4 segundos se considera deficiente.
Un LCP alto no significa automáticamente que «las imágenes pesan demasiado». La métrica puede deteriorarse en distintas fases de la carga.
Google divide el proceso de LCP en cuatro partes que resultan especialmente útiles para diagnosticar el problema:
Esta separación evita aplicar optimizaciones a ciegas.
Imagina una página cuya imagen principal pesa demasiado. Comprimirla puede reducir el tiempo de descarga. Pero si la imagen no empieza a solicitarse hasta que termina de ejecutarse determinado JavaScript, el problema principal puede estar en el retraso con el que el navegador descubre el recurso, no en su peso.
El primer paso es identificar cuál es el elemento LCP y qué fase está consumiendo más tiempo.
Si el problema está en el servidor, conviene revisar el TTFB, la caché, los redireccionamientos y la infraestructura utilizada para entregar el documento HTML.
Si el navegador descubre demasiado tarde el recurso principal, hay que comprobar si:
lazy loading al elemento que debería cargarse inmediatamente;Google recomienda que el recurso LCP pueda descubrirse lo antes posible y comience a descargarse con prioridad. En una imagen principal situada en la parte visible inicialmente, aplicar carga diferida puede conseguir justo el efecto contrario al deseado.
Si el cuello de botella está realmente en la descarga, sí tiene sentido reducir el tamaño del recurso, utilizar dimensiones adecuadas y formatos eficientes.
Y si el recurso ya se ha descargado pero tarda en mostrarse, habrá que investigar el trabajo que está bloqueando el hilo principal, el renderizado mediante JavaScript o las dependencias necesarias antes de poder pintar el elemento.
La mejora correcta depende de qué parte del LCP está consumiendo el tiempo.
Interaction to Next Paint mide la capacidad de respuesta de una página durante la visita del usuario.
No se limita al primer clic. INP observa las interacciones relevantes que se producen a lo largo de la sesión y utiliza prácticamente la de mayor latencia, aplicando un tratamiento de valores atípicos cuando existen muchas interacciones.
Un INP de 200 milisegundos o menos se considera bueno. Entre 200 y 500 milisegundos necesita mejorar y por encima de 500 milisegundos es deficiente.
Este problema suele sentirse de una manera muy concreta: haces clic en un botón, seleccionas una opción o escribes en un campo y la interfaz tarda perceptiblemente en reaccionar.
Para corregir un INP alto conviene dividir cada interacción en:
Retraso de entrada. Desde que el usuario interactúa hasta que el navegador puede empezar a procesar los manejadores del evento.
Tiempo de procesamiento. Lo que tardan en ejecutarse las funciones asociadas a esa interacción.
Retraso de presentación. Desde que termina ese procesamiento hasta que el navegador logra mostrar el siguiente frame con el resultado visible.
Supongamos que pulsas «Añadir al carrito» y la interfaz tarda 600 ms en actualizarse.
Si 400 ms corresponden a retraso de entrada porque el hilo principal estaba ocupado ejecutando otro script, optimizar exclusivamente el código del botón probablemente tenga poco efecto.
Si el retraso procede del propio manejador del evento, habrá que reducir el trabajo que realiza.
Y si el procesamiento es rápido pero el navegador tarda en representar el cambio, el problema puede estar en el renderizado, en un DOM excesivamente complejo o en modificaciones costosas de la interfaz.
Una de las causas frecuentes de un INP elevado es mantener ocupado el hilo principal con demasiado trabajo JavaScript.
Entre las medidas que pueden ayudar están reducir JavaScript innecesario, dividir tareas largas, evitar cálculos que no sean imprescindibles dentro de los manejadores de eventos y revisar scripts de terceros que ocupen el hilo principal.
También conviene evitar realizar en una sola interacción mucho trabajo que podría dividirse o posponerse.
El tamaño y la complejidad del DOM pueden influir en la fase final: cuanto más trabajo tenga que hacer el navegador para recalcular estilos, diseño y renderizado después de una interacción, mayor puede ser el retraso hasta mostrar el resultado.
Aquí también importa diagnosticar antes de optimizar. Un INP de 600 ms no explica por sí mismo qué código hay que modificar.
Cumulative Layout Shift mide los cambios inesperados de posición de los elementos visibles.
A diferencia de LCP e INP, CLS no se expresa en segundos o milisegundos. Su resultado es una puntuación sin unidad.
Un valor de 0,1 o menos se considera bueno. Entre 0,1 y 0,25 necesita mejorar y por encima de 0,25 es deficiente.
El ejemplo típico ocurre cuando empiezas a leer un artículo y, al terminar de cargarse una imagen o un anuncio situado encima, el párrafo que estabas leyendo se desplaza.
El problema es todavía más evidente cuando ese movimiento provoca una acción no deseada: ibas a pulsar un botón, la interfaz cambia de posición en el último momento y acabas pulsando otro elemento.
Una causa habitual es introducir contenido sin haber reservado previamente el espacio que necesitará.
Esto puede suceder con:
En imágenes y vídeos, definir correctamente sus dimensiones o su relación de aspecto permite al navegador reservar espacio antes de que el recurso termine de cargarse.
Los anuncios y elementos dinámicos requieren la misma lógica: si sabes aproximadamente qué espacio necesitarán, reservarlo evita que el contenido existente tenga que desplazarse.
Además, no todos los problemas de CLS aparecen durante la carga inicial. Algunos surgen mientras el usuario hace scroll o utiliza la página, por lo que una única prueba automática nada más abrir la URL puede no reproducirlos. Chrome recomienda comprobar también los desplazamientos que se producen durante flujos reales de navegación.
Una de las mayores fuentes de confusión con los Core Web Vitals aparece al comparar herramientas.
Es posible ejecutar una prueba y obtener un resultado aparentemente bueno en Lighthouse mientras Search Console continúa marcando un problema. No significa necesariamente que una de las dos herramientas se equivoque.
Están respondiendo a preguntas distintas.
Los datos de campo proceden de usuarios reales y reflejan condiciones reales: distintos móviles, ordenadores, conexiones, ubicaciones y comportamientos.
PageSpeed Insights obtiene estos datos del Chrome User Experience Report (CrUX) y muestra la experiencia registrada durante los 28 días anteriores cuando existe suficiente información para esa URL. Si una página concreta no tiene suficientes datos, puede mostrar información a nivel de origen; si tampoco existe suficiente información para el origen, no podrá mostrar datos de usuarios reales.
Estos datos son los que debes observar para saber cómo está funcionando realmente la web para su audiencia.
Los datos de laboratorio se generan bajo unas condiciones controladas y reproducibles.
Son especialmente útiles para investigar por qué existe un problema, probar modificaciones antes de publicarlas y detectar regresiones durante el desarrollo.
PageSpeed Insights incorpora datos de laboratorio generados con Lighthouse además de los datos de campo.
La consecuencia práctica es sencilla:
los datos de campo te indican qué están experimentando los usuarios; los datos de laboratorio te ayudan a encontrar por qué ocurre y a probar posibles soluciones.
No tienes que escoger uno u otro. Lo normal es utilizar ambos en fases distintas del diagnóstico.
Cada herramienta resuelve una parte diferente del problema.
| Herramienta | Tipo de datos | Para qué resulta especialmente útil |
|---|---|---|
| PageSpeed Insights | Campo + laboratorio | Analizar una URL y obtener datos reales cuando existen junto con diagnósticos técnicos |
| Google Search Console | Campo | Detectar grupos de páginas del sitio con problemas de LCP, INP o CLS |
| Chrome DevTools | Laboratorio / medición local | Reproducir problemas, inspeccionar elementos, interacciones y desplazamientos |
| Lighthouse | Laboratorio | Auditar una página en condiciones controladas y detectar oportunidades |
| CrUX | Campo | Consultar directamente datos agregados de experiencia real |
Es un buen punto de partida para una URL concreta porque reúne dos perspectivas en la misma herramienta.
En la parte de experiencia real puedes comprobar si existen datos CrUX para esa página y cómo se distribuyen sus métricas. Después, los diagnósticos de laboratorio permiten investigar las posibles causas.
Hay que tener cuidado con una diferencia: Lighthouse no puede obtener automáticamente un INP real cargando simplemente la página, porque INP depende de interacciones. En sus pruebas de carga utiliza métricas como Total Blocking Time (TBT) para detectar posibles problemas de capacidad de respuesta. TBT puede ser un indicador útil en laboratorio, pero no sustituye al INP medido con usuarios reales.
Search Console es más útil para observar el problema a escala de sitio.
El informe de Core Web Vitals utiliza datos reales y agrupa las URLs por estado, métrica y grupos de páginas similares. Una URL que aparece como ejemplo puede, por tanto, representar un conjunto mayor de páginas afectadas.
Esto permite detectar patrones: por ejemplo, que numerosas fichas de producto compartan un problema de LCP o que un conjunto de artículos tenga un CLS elevado.
La explicación no suele estar en que hayas medido «mal».
Search Console agrupa páginas similares, mientras PageSpeed Insights intenta ofrecer información para la URL concreta analizada cuando dispone de suficientes datos.
Por eso una URL puede parecer buena en PageSpeed Insights pero formar parte de un grupo marcado como mejorable en Search Console, o al contrario. Google documenta expresamente esta diferencia.
También hay que distinguir el bloque de datos reales de PageSpeed Insights del informe de Lighthouse situado más abajo.
Una prueba de Lighthouse representa una ejecución en unas condiciones concretas. Los datos CrUX resumen muchas experiencias reales acumuladas durante el periodo de recopilación.
Cambiar una imagen hoy puede mejorar inmediatamente una prueba de laboratorio, pero los datos de campo no se transformarán de golpe porque siguen incorporando visitas de días anteriores dentro de la ventana de 28 días.
Intentar subir todos los indicadores simultáneamente suele producir una colección de cambios cuyo impacto real resulta difícil de comprobar.
Una secuencia más útil es:
Este enfoque evita actuaciones como comprimir todas las imágenes cuando el verdadero problema de LCP es un servidor lento, o eliminar JavaScript aleatoriamente cuando el INP elevado procede de un componente concreto.
Los Core Web Vitals tienen relación con el posicionamiento, pero conviene evitar dos extremos: afirmar que son irrelevantes o tratarlos como si superar los tres umbrales garantizara subir posiciones.
Google indica actualmente que sus sistemas de ranking utilizan Core Web Vitals, dentro de una evaluación más amplia de la experiencia en la página. También aclara que no existe una única «señal de experiencia de página» y que obtener buenos resultados en Core Web Vitals no garantiza aparecer en las primeras posiciones.
La relevancia del contenido sigue siendo determinante. Google señala incluso que puede mostrar contenido especialmente relevante aunque su experiencia de página sea peor. Cuando existen varias páginas útiles y competitivas para una misma consulta, una buena experiencia puede contribuir al rendimiento en búsqueda.
Por eso no tiene sentido perseguir una puntuación perfecta de PageSpeed únicamente por SEO.
El objetivo debería ser eliminar problemas que afectan a usuarios reales y mantener unos Core Web Vitals saludables dentro de un trabajo más amplio de posicionamiento SEO.
Una página con LCP de 2,4 segundos no pasa a ser automáticamente una página excelente porque haya cruzado la frontera de 2,5. Del mismo modo, dedicar una gran cantidad de recursos a pasar de 2,4 a 1,8 segundos puede aportar menos que corregir un problema grave de contenido, indexación o intención de búsqueda.
Los umbrales sirven para priorizar y evaluar el rendimiento, no para sustituir el criterio SEO.
Si una única plantilla presenta un LCP alto y el elemento problemático está perfectamente localizado, la corrección puede ser relativamente acotada.
La situación cambia cuando aparecen varios síntomas a la vez: LCP alto en distintas plantillas, INP deficiente en móvil, CLS que solo se reproduce en determinados recorridos, diferencias importantes entre PageSpeed Insights y Search Console o problemas que reaparecen después de cada modificación.
En ese punto ya no estás ante un único número que haya que «poner en verde». Necesitas identificar qué parte de la infraestructura, el código, la carga de recursos o las plantillas está generando el problema y qué cambios conviene priorizar.
Una auditoría web permite ampliar el diagnóstico y valorar los Core Web Vitals junto con el resto de factores técnicos del sitio, en lugar de aplicar optimizaciones aisladas sin saber cuál será su impacto.
¿Qué te ha parecido este artículo?