Puntos clave
- Las Core Web Vitals son tres métricas: LCP (carga), INP (respuesta) y CLS (estabilidad visual).
- Google evalúa el percentil 75 de los datos de usuarios reales, no las pruebas de laboratorio.
- Conviene priorizar por plantillas con mucho tráfico y valor comercial, no por URL sueltas.
- La forma más fiable de conocer el impacto en ventas es cruzar las métricas de cada visita con la conversión.
¿Qué son las Core Web Vitals?
Las Core Web Vitals son las tres métricas con las que Google mide la experiencia real de carga e interacción de una página. LCP mide cuánto tarda en aparecer el contenido principal. INP mide la rapidez de respuesta a los clics y CLS, la estabilidad visual durante la carga.
| Métrica | Qué mide | Buena | Mejorable | Deficiente |
|---|---|---|---|---|
| LCP | Tiempo hasta mostrar el elemento principal | ≤ 2,5 s | 2,5–4 s | > 4 s |
| INP | Tiempo de respuesta a las interacciones | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS | Desplazamientos inesperados del contenido | ≤ 0,1 | 0,1–0,25 | > 0,25 |
Una página supera la evaluación cuando al menos el 75 % de las visitas se sitúa en el umbral «bueno» de las tres métricas. Los datos proceden del Chrome User Experience Report, que agrega la experiencia de usuarios reales de Chrome durante los últimos 28 días.
Desde marzo de 2024, INP sustituye a FID como métrica de interactividad. El cambio endureció la evaluación. FID solo medía el retraso de la primera interacción, mientras que INP tiene en cuenta prácticamente todas las interacciones de la visita.
¿Influyen las Core Web Vitals en el posicionamiento?
Sí, forman parte de las señales de experiencia en la página que Google tiene en cuenta, pero su peso es moderado. La relevancia del contenido sigue siendo el factor determinante. Una página rápida no supera a otra más útil, aunque entre dos resultados comparables la experiencia puede inclinar la balanza.
El efecto indirecto pesa más. Una web lenta acumula abandonos antes de terminar la carga, reduce las páginas vistas por sesión y convierte menos. Esa pérdida afecta a todo el tráfico, orgánico o de pago, y encarece cada visita.
En los proyectos de posicionamiento SEO, la velocidad se trata como un requisito de base. No atrae tráfico por sí sola, pero evita desperdiciar el que consiguen el contenido y los enlaces. Las páginas que dependen de JavaScript para mostrar su contenido principal suelen tener peor LCP. También resultan más difíciles de leer para los rastreadores que alimentan a los asistentes, como explica la guía de SEO para buscadores de IA.
¿Cómo afecta la velocidad a la conversión?
Cada métrica frena la conversión en un momento distinto del recorrido. Un LCP lento provoca abandonos antes de ver la oferta. Un INP alto hace dudar al usuario cuando pulsa «Añadir al carrito», y un CLS elevado genera clics erróneos en formularios y pasos de pago.
El LCP afecta sobre todo a la entrada. En móvil, quien llega desde un anuncio o un resultado de búsqueda espera ver algo enseguida. Si la imagen principal o el titular tardan, vuelve atrás. Ese abandono a menudo ni siquiera se registra como sesión, porque la etiqueta de analítica aún no se ha cargado.
El INP pesa en los momentos de decisión, como filtrar un listado, elegir una talla o enviar un formulario. Cuando la página tarda en reaccionar, el usuario repite el clic o piensa que algo ha fallado. En un proceso de compra, esa duda basta para abandonar.
El CLS resta confianza. Un botón que se desplaza justo cuando el usuario va a pulsarlo transmite descuido. Lo mismo ocurre con un banner que empuja el formulario hacia abajo, y ambos provocan errores en los pasos donde un fallo cuesta más caro.
La forma más fiable de conocer el impacto en un negocio concreto es medirlo con sus propios datos. Registrar las Core Web Vitals de cada visita en la herramienta de analítica permite comparar la conversión de las sesiones rápidas con la de las lentas. Conviene segmentar por dispositivo y tipo de página, porque las causas cambian de una plantilla a otra. Es el punto de partida habitual en los proyectos de analítica y CRO.
La correlación entre velocidad y conversión no demuestra por sí sola la causa. Las sesiones lentas suelen proceder de móviles antiguos o de conexiones peores, que también convierten menos por otros motivos. Para aislar el efecto, lo más sólido es una prueba A/B que mejore solo la velocidad de una plantilla.
¿Qué páginas conviene mejorar primero?
Conviene empezar por las plantillas que combinan mucho tráfico, mucho valor comercial y métricas en rojo. En una tienda online suelen ser las fichas de producto y los listados. En una web de servicios, las páginas de destino de las campañas y las páginas de servicio con formulario.
Trabajar por plantillas y no por URL es lo que hace rentable el esfuerzo. Una corrección en la plantilla de ficha de producto mejora a la vez miles de páginas, y Search Console ya agrupa las URL con problemas similares.
| Tipo de página | Métrica que suele fallar | Causa habitual |
|---|---|---|
| Ficha de producto | LCP | Galería de imágenes pesada o carrusel en la cabecera |
| Listado de categoría | INP y CLS | Filtros con mucho JavaScript y productos que se cargan sin espacio reservado |
| Carrito y pago | INP | Scripts de terceros de pago, chat y medición |
| Página de destino | LCP | Vídeo o imagen de cabecera sin comprimir |
| Artículo del blog | CLS | Anuncios, vídeos incrustados y avisos que aparecen tarde |
Los listados merecen atención especial porque concentran filtros, paginación y carga de productos. Su rendimiento depende en buena parte de la arquitectura de categorías de la tienda online. En las páginas de destino de las campañas de Google Ads y Meta Ads, cada abandono por lentitud es un clic que ya se ha pagado.
Qué mejoras priorizar en cada métrica
Las mejoras con más retorno suelen ser pocas y se repiten en casi todas las webs. Este es el orden en que las abordamos en los proyectos de desarrollo web, de menor a mayor esfuerzo.
Para mejorar el LCP
- Identificar el elemento LCP real de cada plantilla en móvil, que a veces es el aviso de cookies y no la imagen principal.
- Servir la imagen principal en AVIF o WebP, con las dimensiones justas y un
srcsetpara cada tamaño de pantalla. - Priorizar su carga con
fetchpriority="high"y no aplicarle carga diferida. - Reducir el tiempo de respuesta del servidor con caché de página completa y una CDN.
- Alojar las tipografías en el propio dominio, limitar las variantes y cargarlas con
font-display: swap.
Para mejorar el INP
- Inventariar los scripts de terceros y retirar los que nadie consulta, como mapas de calor antiguos o píxeles de campañas cerradas.
- Cargar el resto bajo demanda; el chat, por ejemplo, puede cargarse al pulsar su botón.
- Dividir las tareas largas de JavaScript para que el navegador pueda responder entre una y otra.
- Simplificar el DOM en listados extensos y evitar recalcular toda la página al aplicar un filtro.
Para mejorar el CLS
- Declarar ancho y alto, o
aspect-ratio, en imágenes, vídeos e iframes. - Reservar espacio para avisos, banners promocionales y bloques que se cargan después.
- Mostrar el aviso de consentimiento superpuesto al contenido, sin desplazarlo.
- Ajustar las tipografías de sustitución para que ocupen lo mismo que las definitivas.
Errores frecuentes en las auditorías de velocidad
Trabajar para la puntuación de Lighthouse
Una puntuación de 95 en un portátil con fibra dice poco del usuario que compra desde un móvil de gama media con cobertura irregular. Google evalúa los datos de campo. Es habitual encontrar webs con buena nota de laboratorio que no superan la evaluación en Search Console.
Olvidar el aviso de cookies
En Europa, el aviso de consentimiento que exige el RGPD aparece en la primera visita de cada usuario. Si es un bloque de texto grande, el navegador puede tomarlo como elemento LCP. Si se inserta empujando el contenido, dispara el CLS, así que conviene cargarlo pronto, superpuesto y con un tamaño contenido.
Convertir el gestor de etiquetas en un cajón de sastre
Cada etiqueta ejecuta código en el navegador del usuario. Con los años se acumulan píxeles duplicados y herramientas de prueba olvidadas que degradan el INP. Una revisión periódica ayuda, y también trasladar parte de la medición al servidor, como se hace con la API de Conversiones de Meta en ecommerce.
Aplicar carga diferida a la imagen principal
Muchas plantillas y plugins añaden loading="lazy" a todas las imágenes por defecto. En la imagen de cabecera el efecto es el contrario al buscado. El navegador retrasa la petición hasta calcular el diseño y el LCP empeora.
¿Cómo medir las Core Web Vitals con datos reales?
Los datos reales se consultan en el informe de Core Web Vitals de Search Console y en PageSpeed Insights, que muestran el percentil 75 de los usuarios de Chrome. Para relacionarlos con la conversión hace falta, además, registrar las métricas de cada visita en la herramienta de analítica propia.
| Herramienta | Tipo de datos | Uso principal |
|---|---|---|
| Search Console | Campo, agrupados por URL similares | Detectar plantillas que no superan los umbrales |
| PageSpeed Insights | Campo y laboratorio | Diagnosticar una URL concreta |
| Chrome DevTools | Laboratorio | Analizar interacciones lentas paso a paso |
Librería web-vitals | Campo, por visita | Cruzar velocidad y conversión en la analítica |
Las pruebas de laboratorio sirven para diagnosticar, pero Google evalúa los datos de campo. Tras corregir un problema, la validación en Search Console puede tardar hasta 28 días, porque trabaja con un periodo móvil de esa duración.
Cómo implantar las mejoras paso a paso
El orden de trabajo importa tanto como las correcciones. Un proyecto de mejora de rendimiento suele seguir estas fases.
- Medir la situación de partida por plantilla y dispositivo, con datos de campo.
- Cruzar esas métricas con el tráfico y la conversión de cada plantilla para ordenar prioridades.
- Diagnosticar en laboratorio la causa concreta de cada métrica en rojo.
- Aplicar las correcciones en un entorno de pruebas y comprobar que no rompen la medición ni el consentimiento.
- Publicar por plantillas y anotar la fecha de cada cambio en la analítica.
- Seguir la evolución de los datos de campo durante las cuatro semanas siguientes.
- Fijar un presupuesto de rendimiento en el proceso de desarrollo para que las nuevas funciones no deshagan lo conseguido.
Cada décima de segundo que tarda en aparecer la oferta es tiempo que el visitante dedica a decidir si se queda.
Juan Berges, CEO de The Baller Company
Por dónde empezar
Lo más rentable es abrir el informe de Core Web Vitals de Search Console, filtrar por móvil y localizar la plantilla con más tráfico que no supera la evaluación. Sobre esa plantilla conviene comparar la conversión de las visitas rápidas y las lentas antes de invertir en desarrollo. Si la diferencia es relevante, las primeras correcciones casi siempre están en la imagen principal y en los scripts de terceros.
Preguntas frecuentes
¿Qué diferencia hay entre los datos de campo y los de laboratorio?
Los datos de campo proceden de usuarios reales de Chrome y son los que Google evalúa. Los de laboratorio se obtienen con una simulación controlada, como Lighthouse, y sirven para diagnosticar causas y comprobar una corrección antes de publicarla.
¿Por qué una web rápida en ordenador falla en Search Console?
Search Console evalúa por separado móvil y ordenador. En móvil pesan los procesadores modestos y las conexiones inestables, que multiplican el coste del JavaScript y de las imágenes grandes. Una web que carga bien en la oficina puede suspender con usuarios reales desde el teléfono.
¿Influye la velocidad de la página de destino en Google Ads?
Sí. Google Ads valora la experiencia en la página de destino dentro del nivel de calidad, y una página lenta pierde parte de los clics pagados antes de cargar. Mejorarla abarata cada conversión que llega desde las campañas.
¿Cada cuánto conviene revisar las Core Web Vitals?
Una revisión mensual del informe de Search Console suele bastar, junto con una comprobación tras cada cambio de plantilla, tema o scripts de terceros. Los nuevos píxeles, chats y herramientas de pruebas son el origen más frecuente de empeoramientos repentinos.
