Cómo mejorar los Core Web Vitals de una web

Para mejorar los Core Web Vitals hay que trabajar tres métricas —LCP (velocidad de carga), INP (respuesta a la interacción) y CLS (estabilidad visual)— sobre los datos reales de tus usuarios, no solo sobre pruebas de laboratorio. Las palancas más rentables casi siempre son las mismas: optimizar las imágenes y el elemento principal que carga, reducir y dividir el JavaScript, y reservar espacio para que nada salte mientras la página se pinta. Los umbrales que Google considera "buenos" son LCP ≤ 2,5 s, INP ≤ 200 ms y CLS ≤ 0,1, medidos en el percentil 75 de las visitas.

Un aviso desde el principio para no perseguir fantasmas: aprobar los Core Web Vitals ayuda, pero no garantiza posiciones, y no necesitas un 100/100 en ninguna herramienta. El objetivo es que la mayoría de tus usuarios tengan una buena experiencia, no una puntuación perfecta de laboratorio.

Qué son los Core Web Vitals y sus umbrales

Los Core Web Vitals (se abre en una pestaña nueva) son tres métricas con las que Google mide la experiencia real de carga, interactividad y estabilidad de una página. Desde marzo de 2024, INP sustituyó a la antigua FID como métrica de interactividad.

El detalle clave es el percentil 75: Google clasifica una página como "buena" en una métrica si al menos el 75 % de las visitas cumplen el umbral. No basta con que te vaya bien en tu móvil de gama alta con buena conexión; cuenta la experiencia de la mayoría de usuarios reales. Estos valores son de web.dev/Google y pueden actualizarse, así que conviene verificarlos en la fuente.

Datos de campo vs laboratorio: mide lo que viven tus usuarios

Esta distinción es la que más confusión genera, y entenderla te ahorra optimizar a ciegas:

• Datos de campo (field): son mediciones de usuarios reales, recogidas de forma anónima por el Chrome User Experience Report (CrUX) (se abre en una pestaña nueva). Son los que Google usa para evaluar los Core Web Vitals y los que alimentan el informe de Search Console.
• Datos de laboratorio (lab): son pruebas simuladas en un entorno controlado, como las de Lighthouse, con un dispositivo y una red fijos. Sirven para depurar y reproducir problemas, pero no equivalen a la experiencia real de tus usuarios.

Consecuencia práctica: una buena puntuación de Lighthouse en tu ordenador no significa que apruebes los Core Web Vitals, porque tus usuarios navegan con dispositivos, redes y condiciones muy distintas. El laboratorio te dice por qué algo va lento; el campo te dice si de verdad va lento para la gente. Prioriza siempre los datos de campo para decidir, y usa el laboratorio para diagnosticar.

Cómo mejorar el LCP (velocidad de carga)

El LCP mide cuánto tarda en pintarse el elemento más grande visible (normalmente una imagen destacada, un banner o un bloque de texto). Según la guía de Google para optimizar el LCP (se abre en una pestaña nueva), las palancas más habituales son:

• Optimiza las imágenes: suelen ser el mayor lastre. Usa formatos modernos, comprime, sirve el tamaño adecuado a cada dispositivo y carga con prioridad la imagen del LCP (sin lazy-load en la que está por encima del pliegue).
• Reduce el tiempo de respuesta del servidor: un hosting lento o una web sin caché retrasan todo lo demás.
• Elimina recursos que bloquean el render: CSS y JavaScript que frenan el primer pintado; carga de forma crítica solo lo imprescindible.
• Cuida las fuentes: las tipografías web pueden retrasar el texto; usa font-display adecuado y precarga las fuentes clave para que el texto aparezca antes.

Si el elemento LCP es una imagen, ahí está casi siempre la mayor ganancia posible.

Cómo mejorar el INP (respuesta a la interacción)

El INP mide cuánto tarda la página en responder cuando el usuario hace clic, toca o escribe. Es una métrica difícil de mejorar porque depende del JavaScript que se ejecuta en el navegador. Según las formas más efectivas de mejorar los Core Web Vitals (se abre en una pestaña nueva):

• Reduce el JavaScript que se carga y ejecuta: menos código, menos trabajo para el navegador.
• Divide las tareas largas: trocea el trabajo pesado para que el hilo principal pueda atender la interacción del usuario en lugar de quedarse bloqueado.
• Aplaza lo no crítico: carga después lo que no hace falta para la primera interacción.
• Vigila el JavaScript de terceros (chats, widgets, tests A/B): a menudo son los que bloquean la respuesta.

El renderizado también cuenta: una web que depende de mucho JavaScript en el cliente para mostrar y activar el contenido tiende a tener peor INP que una que sirve lo esencial ya listo.

Cómo mejorar el CLS (estabilidad visual)

El CLS mide cuánto se mueve el contenido de forma inesperada mientras la página carga (ese salto molesto que hace que pulses el botón equivocado). Las causas y soluciones más frecuentes:

• Reserva espacio para las imágenes y vídeos: define siempre width y height (o el aspect-ratio por CSS) para que el navegador reserve el hueco antes de cargarlos.
• Reserva espacio para anuncios, embeds e iframes: los bloques de tamaño variable que se insertan tarde son una causa clásica de saltos.
• No insertes contenido por encima del existente: banners, avisos o elementos que empujan hacia abajo lo que el usuario ya estaba viendo.
• Gestiona las fuentes: los cambios de tipografía al cargar pueden reajustar el texto; una carga de fuentes cuidada reduce el efecto.

El CLS suele ser el más "barato" de arreglar de los tres, porque casi todo se resuelve reservando espacio de antemano.

Resumen de causas y palancas

Como referencia rápida, estas son las causas más habituales de cada métrica y por dónde empezar:

Herramientas oficiales para medir y diagnosticar

Tres herramientas de Google trabajan juntas, cada una con su papel:

• PageSpeed Insights: muestra a la vez los datos de campo (CrUX, si tu página tiene suficientes visitas) y los datos de laboratorio (Lighthouse). Mira primero el campo para saber si hay un problema real, y el laboratorio para investigar la causa.
• Search Console: su informe de Core Web Vitals usa datos de campo y agrupa las URLs por estado (buena, necesita mejora, deficiente) y por tipo de problema, lo que ayuda a ver qué plantillas fallan a escala, no página a página.
• CrUX y las herramientas de desarrollo del navegador: para profundizar en el comportamiento real y depurar en local.

Google detalla estos flujos en su guía de Core Web Vitals con herramientas (se abre en una pestaña nueva). La idea: campo para decidir, laboratorio para diagnosticar.

Cómo priorizar (y por qué no persigues el 100/100)

Con recursos limitados, el orden importa más que hacerlo todo:

1. Empieza por los datos de campo, no por la puntuación de laboratorio. Si el campo dice que estás en "bueno", no gastes horas persiguiendo décimas en Lighthouse.
2. Ataca primero la métrica peor y la que más usuarios afecta.
3. Prioriza las plantillas más visitadas (portada, fichas, artículos): arreglar una plantilla mejora miles de URLs de golpe.
4. Quédate en los umbrales "buenos", no en la perfección. Un 100/100 de Lighthouse no es el objetivo ni es necesario.

Y una advertencia de fondo, para no vender lo que no es: Google documenta que la experiencia de página —Core Web Vitals incluidos— es una señal, pero que unos buenos resultados no garantizan aparecer arriba y que el contenido relevante sigue siendo lo primero (lo explica en su documentación sobre Core Web Vitals y la Búsqueda (se abre en una pestaña nueva)). El rendimiento quita fricción y mejora la experiencia; no sustituye a responder bien a la búsqueda. Por eso encaja dentro de una visión más amplia de cómo influye el diseño web en el SEO, y su diagnóstico es una de las áreas que revisa una auditoría SEO.

La forma más sólida de tener buenos Core Web Vitals es no tener que rescatarlos: partir de un diseño web con SEO técnicamente cuidado, con imágenes optimizadas y una base rápida desde el primer día, evita arrastrar problemas difíciles de corregir después. Y como el rendimiento es solo una pieza de una estrategia completa, mantener la visibilidad a largo plazo exige además contenidos, autoridad y seguimiento continuo, que es el terreno de un servicio de SEO y GEO mensual. En mi experiencia optimizando webs, la mayor parte de las mejoras de Core Web Vitals se concentran en dos frentes: las imágenes y el JavaScript.

Preguntas frecuentes

¿Cuáles son los umbrales buenos de los Core Web Vitals?

Google considera "buenos" estos valores: LCP de 2,5 segundos o menos, INP de 200 milisegundos o menos y CLS de 0,1 o menos. Lo importante es que se miden en el percentil 75 de las visitas: una página se clasifica como buena en una métrica cuando al menos el 75 % de las visitas cumplen el umbral, es decir, teniendo en cuenta a la mayoría de usuarios reales y no solo un dispositivo potente con buena conexión. Estos umbrales pueden cambiar con el tiempo, así que conviene confirmarlos en la documentación oficial de web.dev y Google antes de darlos por definitivos.

¿La diferencia entre datos de campo y de laboratorio importa tanto?

Sí, es fundamental. Los datos de campo proceden de usuarios reales (a través del Chrome User Experience Report) y son los que Google usa para evaluar los Core Web Vitals. Los datos de laboratorio, como los de Lighthouse, son pruebas simuladas en un entorno controlado y sirven para diagnosticar y reproducir problemas, pero no equivalen a la experiencia real de tus usuarios. Una buena puntuación de Lighthouse en tu ordenador no significa que apruebes los Core Web Vitals. La regla práctica es decidir con datos de campo y depurar con datos de laboratorio.

¿Aprobar los Core Web Vitals mejora el posicionamiento?

Ayuda, pero no lo garantiza. Google documenta que la experiencia de página, que incluye los Core Web Vitals, es una señal, pero que prioriza el contenido más útil aunque su experiencia sea mejorable, y que obtener buenos resultados no asegura aparecer en las primeras posiciones. Dicho de otra forma: un buen rendimiento quita fricción y mejora la experiencia del usuario, pero no compensa un contenido que no responde a la búsqueda ni sustituye a la autoridad. Merece la pena cuidarlo, sí, pero como parte de un trabajo más amplio, no como un atajo hacia el ranking.

¿Necesito un 100/100 en PageSpeed Insights o Lighthouse?

No. La puntuación de Lighthouse es una medida de laboratorio orientada a diagnóstico, y perseguir un 100/100 no es el objetivo ni es necesario. Lo que cuenta para los Core Web Vitals son los datos de campo de usuarios reales y estar dentro de los umbrales "buenos". Optimizar los últimos puntos de una puntuación de laboratorio suele dar rendimientos decrecientes y puede distraerte de lo que de verdad afecta a tus usuarios. Si el campo dice que estás en "bueno", tu esfuerzo rinde más en contenido, enlazado o conversión que en exprimir décimas de una métrica sintética.

¿Qué mejora primero si mi web va lenta?

Empieza por los datos de campo para saber qué métrica está peor y qué páginas afectan a más usuarios. En la práctica, las dos palancas más rentables suelen ser las imágenes (para el LCP: optimizarlas, dimensionarlas y priorizar la principal) y el JavaScript (para el INP: reducirlo, dividir las tareas largas y vigilar los scripts de terceros). El CLS suele ser el más fácil, reservando espacio para imágenes, anuncios y embeds. Y prioriza las plantillas más visitadas, porque corregir una plantilla mejora de golpe todas las URLs que la usan.