Core Web Vitals: qué son y cómo mejorar la velocidad web

Qué son las Core Web Vitals y por qué importan para el SEO

Las Core Web Vitals son un conjunto de tres métricas que Google usa para medir la experiencia real de un usuario al cargar e interactuar con una página web. Miden tres cosas distintas: cuánto tarda en aparecer el contenido principal (LCP), qué tan rápido responde la página cuando el usuario hace clic o toca algo (INP), y qué tanto se mueven los elementos mientras la página termina de cargar (CLS). Google las incorporó a su algoritmo de posicionamiento en 2021 como parte de la señal de "experiencia de página".

Importan para el SEO por una razón directa: son un factor de ranking. Entre dos páginas con contenido de calidad y relevancia similares, Google favorece a la que ofrece mejor experiencia de carga. No es el factor más importante —el contenido y los enlaces pesan más—, pero sí es un desempate real, y su efecto se nota especialmente en búsquedas competitivas y en dispositivos móviles, donde la mayoría de las conexiones son más lentas.

Hay un segundo motivo, menos comentado pero igual de importante: la velocidad afecta a la conversión antes que al ranking. Un usuario que espera cuatro segundos a que aparezca el contenido de una tienda a menudo se va antes de ver el producto. Mejorar las Core Web Vitals mejora dos cosas a la vez —el posicionamiento y las ventas— y por eso vale la pena aunque el impacto SEO fuera nulo.

Una aclaración de vocabulario que evita confusiones: las Core Web Vitals son las tres métricas "principales" (LCP, INP, CLS), pero existen otras métricas de rendimiento web —como el TTFB o el FCP— que Google llama "Web Vitals" a secas y que ayudan a diagnosticar, aunque no cuenten directamente para el ranking. Cuando alguien habla de "las Vitals" en SEO, se refiere casi siempre a esas tres.

Las tres métricas, explicadas con ejemplos

Las tres Core Web Vitals miden aspectos completamente distintos de la experiencia, y por eso una página puede aprobar una y fallar otra. LCP mide la velocidad de carga, INP mide la capacidad de respuesta y CLS mide la estabilidad visual. Verlas por separado, con un ejemplo concreto de cada una, es la única forma de saber cuál arreglar.

### LCP (Largest Contentful Paint): la velocidad de carga

El LCP mide el tiempo que tarda en dibujarse el elemento visible más grande de la página dentro de la ventana del navegador. Su umbral de buena experiencia es de 2,5 segundos o menos, medido en el percentil 75 de las visitas (LCP explicado). En la práctica ese "elemento más grande" suele ser la imagen de portada, el video destacado o el bloque de texto principal de un artículo.

Un ejemplo concreto: entras a la página de un producto y lo que domina la pantalla es la foto grande del artículo. El LCP es el tiempo transcurrido desde que hiciste clic hasta que esa foto aparece dibujada y legible. Si tarda 1,8 segundos, la página aprueba con holgura; si tarda 4 segundos, Google la clasifica como "pobre" y el usuario ya empezó a impacientarse. El LCP es la métrica que más depende del servidor y de las imágenes, y por eso es la primera que hay que atacar.

### INP (Interaction to Next Paint): la capacidad de respuesta

El INP mide cuánto tarda la página en responder visualmente después de que el usuario interactúa con ella —un clic, un toque en la pantalla o una pulsación de tecla—. Su umbral de buena experiencia es de 200 milisegundos o menos. El 12 de marzo de 2024, INP reemplazó oficialmente a FID (First Input Delay) como métrica estable de Core Web Vitals (INP: qué es).

El cambio importa porque INP es más exigente que su antecesor. FID solo medía el retraso de la primera interacción de la visita; si el primer clic era rápido pero los siguientes se arrastraban, FID daba un aprobado engañoso. INP mide todas las interacciones y reporta prácticamente la peor, así que refleja la experiencia real de alguien que usa la página, no solo la de su primer clic. Un ejemplo: abres un menú desplegable y pasan 400 milisegundos hasta que se despliega. Ese retraso, causado casi siempre por JavaScript que bloquea el hilo principal, es lo que INP penaliza.

### CLS (Cumulative Layout Shift): la estabilidad visual

El CLS mide cuánto se mueven los elementos de la página de forma inesperada mientras carga, sin que el usuario haya hecho nada para provocarlo. Es una puntuación sin unidad, y su umbral de buena experiencia es de 0,1 o menos. A diferencia de las otras dos, el CLS no mide tiempo: mide desplazamiento.

El ejemplo clásico lo ha vivido todo el mundo: vas a tocar un botón, en ese instante carga un banner de publicidad arriba, todo el contenido baja de golpe y terminas tocando otra cosa. Cada uno de esos saltos suma al CLS. Las causas más comunes son imágenes sin dimensiones declaradas (el navegador no reserva su espacio hasta que la descarga), anuncios que se insertan tarde y fuentes web que cambian el tamaño del texto al cargar. Un CLS alto no ralentiza la página, pero la vuelve frustrante y provoca clics erróneos.

Tabla de umbrales: bueno, necesita mejora y pobre

Cada Core Web Vital tiene tres rangos definidos por Google —bueno, necesita mejora y pobre— y todos se evalúan en el percentil 75 de las visitas reales. "Percentil 75" significa que el 75 % de las cargas debe alcanzar el valor o mejorarlo; basta con que una de cuatro visitas sea peor de la cuenta para no aprobar. Esta es la referencia completa, con lo que afecta a cada métrica:

Los umbrales de esta tabla están tomados de la documentación oficial de Google, donde también se explica que se definieron equilibrando la experiencia del usuario con lo que es técnicamente alcanzable (cómo se definen los umbrales). Una regla práctica para leerla: una página aprueba las Core Web Vitals solo si las tres métricas están en verde. Estar bien en dos y mal en una equivale a no aprobar.

Cómo medir las Core Web Vitals: campo vs laboratorio

Se miden con herramientas gratuitas de Google, pero hay que entender una distinción que confunde a casi todo el mundo: los datos de campo y los datos de laboratorio no son lo mismo y muchas veces no coinciden. Los datos de campo son los que cuentan para el posicionamiento; los de laboratorio sirven para diagnosticar. Confundirlos lleva a "arreglar" un número que Google ni siquiera mira.

Datos de campo (CrUX): provienen de usuarios reales de Chrome que aceptaron compartir estadísticas. Google los agrupa en el Chrome User Experience Report (CrUX) sobre una ventana móvil de 28 días y son los que usa para evaluar las Core Web Vitals de tu sitio (qué es CrUX). Reflejan la variedad del mundo real: teléfonos viejos, conexiones lentas, ubicaciones lejanas. Su desventaja es que tardan: un cambio bueno demora semanas en verse porque el promedio arrastra 28 días de datos.

Datos de laboratorio (Lighthouse): provienen de una prueba simulada, con un dispositivo y una red fijos, ejecutada en el momento. Lighthouse te da un resultado inmediato y te dice por qué una página es lenta, pero no mide directamente las Core Web Vitals que Google usa para rankear —de hecho, no puede medir INP, porque no hay un usuario interactuando—. Son ideales para diagnosticar y para verificar un arreglo al instante.

Estas son las herramientas que conviene usar, todas gratuitas:

• PageSpeed Insights (pagespeed.web.dev): pega una URL y muestra a la vez los datos de campo (CrUX) y los de laboratorio (Lighthouse). Es el punto de partida para cualquier página concreta.
• Google Search Console: su informe de Core Web Vitals agrupa todas las URLs del sitio por estado —buena, necesita mejora, pobre— usando datos de campo. Es la mejor vista de conjunto y avisa cuándo un grupo de páginas cae en rojo.
• La extensión Web Vitals de Chrome: muestra las tres métricas en tiempo real mientras navegas tu propio sitio. Útil para cazar un CLS que solo ocurre al hacer scroll.

Una situación frecuente que conviene anticipar: tu página saca 95 en Lighthouse pero aparece en "pobre" en los datos de campo. No es un error. Significa que tus usuarios reales navegan en condiciones peores que las del laboratorio —móviles modestos, redes 4G saturadas—, y son ellos los que definen tu ranking. Cuando campo y laboratorio discrepan, gana el campo.

Cómo mejorar el LCP

Para bajar el LCP hay que atacar dos frentes: que el servidor entregue el HTML rápido y que la imagen principal cargue cuanto antes. El LCP es la suma del tiempo de respuesta del servidor más el tiempo de descarga y renderizado del elemento más grande, así que ambos cuentan. Estas son las acciones con mayor impacto, en orden de rentabilidad:

• Optimiza las imágenes y usa formatos modernos. Convierte las imágenes a WebP o AVIF, que pesan entre un 25 % y un 50 % menos que un JPG a la misma calidad. Y sirve cada imagen al tamaño real en que se muestra: una foto de portada no necesita 3.000 píxeles de ancho para llenar un contenedor de 800.
• No apliques lazy loading a la imagen del hero. El lazy loading (carga diferida) retrasa la descarga de las imágenes hasta que el usuario se acerca a ellas al hacer scroll, y es excelente para las imágenes de más abajo. Pero si lo aplicas a la imagen principal —justo la que suele ser el elemento LCP—, le estás pidiendo al navegador que la cargue tarde, y arruinas la métrica. Regla simple: carga diferida para todo menos para el hero.
• Activa la caché de página. Un WordPress sin caché ejecuta PHP y consulta la base de datos en cada visita, aunque la página no cambie en meses. Con caché, el servidor entrega HTML ya generado y el TTFB se desploma.
• Usa una CDN. Una CDN (Content Delivery Network, red de distribución de contenido) guarda copias de tus archivos estáticos en servidores repartidos por el mundo, de modo que un visitante descarga las imágenes y el CSS desde el nodo más cercano en lugar de cruzar el planeta.
• Precarga el recurso LCP. Una etiqueta <link rel="preload"> sobre la imagen principal le dice al navegador que la descargue con prioridad, sin esperar a descubrirla en el HTML.

Cómo mejorar el INP

El INP mejora reduciendo el trabajo de JavaScript que bloquea el hilo principal del navegador. El hilo principal es la única "cola" donde el navegador procesa tanto las interacciones del usuario como la ejecución de scripts; si un script largo la ocupa, el clic del usuario tiene que esperar su turno, y ese tiempo de espera es lo que INP mide. Bajarlo consiste en despejar esa cola.

• Reduce y divide el JavaScript. Elimina scripts que no usas —plugins de WordPress abandonados, librerías cargadas "por si acaso"— y divide el código en trozos que se carguen solo cuando hacen falta (code splitting). Menos JavaScript ejecutándose es menos hilo principal bloqueado.
• Difiere lo que no es urgente. Los scripts de analítica, chat o publicidad no necesitan ejecutarse durante la carga inicial. Cargarlos con defer o después del evento de carga libera el hilo justo cuando el usuario está interactuando.
• Fragmenta las tareas largas. Una función que tarda 300 ms bloquea cualquier interacción durante ese tiempo. Partirla en varias tareas cortas, cediendo el control al navegador entre ellas, permite que un clic se atienda en medio.
• Quita plugins y scripts de terceros que no aporten. Cada widget externo —un mapa embebido, un feed de redes, un contador— trae su propio JavaScript. Los que no generan valor real son deuda de rendimiento pura.

Un matiz honesto: el INP es, de las tres, la métrica que menos depende del hosting y más del código y del tema de tu sitio. Cambiar de servidor no arregla un INP malo causado por una plantilla con 200 KB de JavaScript. Si ese es tu caso, el trabajo está en el frontend, no en la infraestructura.

Cómo mejorar el CLS

El CLS se arregla reservando por adelantado el espacio de todo lo que carga tarde. La causa de casi cualquier salto de diseño es la misma: un elemento aparece y empuja al resto porque el navegador no le había reservado sitio. La solución, en consecuencia, es siempre reservar ese espacio antes.

• Declara siempre width y height en las imágenes. Cuando el navegador conoce las dimensiones de una imagen desde el HTML, reserva su rectángulo antes de descargarla y nada salta cuando aparece. Es la corrección de CLS más rentable que existe y suele ser trivial de aplicar.
• Reserva espacio para los anuncios y los embebidos. Si insertas publicidad o un video de YouTube, define de antemano un contenedor con la altura que va a ocupar. Así, cuando el anuncio carga, entra en su hueco en lugar de empujar el contenido.
• Usa font-display en las fuentes web. La propiedad CSS font-display: swap hace que el texto se muestre de inmediato con una fuente del sistema y cambie a la fuente web cuando termine de descargar. Para minimizar el salto que provoca ese cambio, conviene precargar la fuente y elegir una de respaldo de tamaño parecido.
• Evita insertar contenido encima de lo que el usuario ya está viendo. Banners de cookies, avisos y barras que aparecen arriba y desplazan todo hacia abajo son una fuente clásica de CLS. Colócalos como capas superpuestas o reserva su espacio desde el inicio.

El papel del hosting: por qué un servidor lento arruina el LCP

El hosting afecta directamente al LCP a través del TTFB, y este es el factor de velocidad que más se subestima. El TTFB (Time To First Byte) es el tiempo que pasa desde que el navegador pide la página hasta que recibe el primer byte de respuesta del servidor. Hasta que ese byte no llega, el navegador no puede empezar a dibujar absolutamente nada. Por eso el TTFB es el "suelo" del LCP: si tu servidor tarda 1,5 segundos en responder, tu LCP nunca bajará de 1,5 segundos por muy optimizadas que estén las imágenes.

Un ejemplo aclara la aritmética. Imagina dos sitios con las imágenes igual de optimizadas. El sitio A está en un servidor saturado con TTFB de 1,4 segundos; su LCP termina en 3,6 segundos: pobre. El sitio B está en un servidor rápido con TTFB de 0,3 segundos; el mismo contenido rinde un LCP de 2,4 segundos: bueno. La única diferencia es el servidor. Ningún ajuste de frontend habría salvado al sitio A, porque su problema empezaba antes de que el navegador recibiera una sola imagen.

¿Qué hace que un servidor tenga TTFB bajo? Tres cosas concretas, no marketing:

• Discos NVMe, conectados directo al bus PCIe, con tiempos de acceso muy por debajo de los discos SATA. En cualquier sitio con base de datos —y todo WordPress lo es— el disco suele ser el cuello de botella real.
• Un servidor web con caché eficiente como LiteSpeed, que sirve páginas ya generadas sin volver a ejecutar PHP en cada visita, en lugar de un Apache por defecto que reconstruye la página cada vez.
• Baja latencia de red y buena capacidad, para que la respuesta salga del servidor y llegue al visitante sin cuellos de botella. Alojar cerca del público —en Ecuador si tu audiencia es ecuatoriana— reduce la latencia por una razón física: los datos viajan menos distancia.

En nuestros planes de hosting, esos tres componentes vienen de serie —discos NVMe, LiteSpeed con su módulo de caché y puertos de 10 Gbps sin límite de transferencia—, junto con la posibilidad de elegir la ubicación más cercana a tu público entre Guayaquil y cuatro ubicaciones en Estados Unidos. Si tu sitio corre sobre WordPress, la guía específica de hosting WordPress en Ecuador detalla cómo esa infraestructura se traduce en un TTFB bajo y, con él, en un mejor LCP.

Una salvedad para ser justos: el hosting resuelve el LCP y ayuda al TTFB, pero no arregla un INP malo ni un CLS causado por el tema o los plugins. Si tu web es lenta porque carga 45 plugins y seis fuentes distintas, migrarla a un servidor más rápido solo cambia cuánto pagas por la lentitud. El orden correcto es medir primero, identificar cuál de las tres métricas falla y atacar su causa real; a veces es el servidor y a veces no.

Un plan de acción en cinco pasos

Mejorar las Core Web Vitals no es un misterio: es un proceso ordenado que empieza por medir y termina por verificar. Seguirlo en este orden evita el error más común, que es optimizar a ciegas cosas que no eran el problema.

1. 1 Mide con PageSpeed Insights y Search Console. Averigua tu estado actual en datos de campo y anota cuál de las tres métricas está en rojo. No optimices nada todavía.
2. 2 Ataca primero el LCP, que suele ser el más fácil de mover: optimiza imágenes a WebP/AVIF, activa la caché, revisa que el hero no tenga lazy loading y comprueba el TTFB de tu servidor.
3. 3 Corrige el CLS, casi siempre barato: declara dimensiones en las imágenes y reserva espacio para anuncios y embebidos.
4. 4 Trabaja el INP si sigue en rojo: reduce y difiere JavaScript, y elimina scripts de terceros que no aporten.
5. 5 Espera y vuelve a medir. Como los datos de campo se calculan sobre 28 días, dales varias semanas para reflejar el cambio. Usa Lighthouse mientras tanto para confirmar que el arreglo funcionó de inmediato.