Guías

Los Core Web Vitals son un conjunto de métricas definidas por Google para capturar cómo se siente realmente una página al usarla, en contraposición a lo rápida que es en abstracto. Se centran en tres experiencias reales: con qué rapidez aparece el contenido principal, cuán estable es el diseño mientras carga, y con qué prontitud responde la página a tu interacción. Como se miden en visitas reales, premian a las páginas que se sienten bien en lugar de a las que solo puntúan bien en laboratorio.

LCP, CLS e INP explicados

La primera métrica, el Largest Contentful Paint, mide cuánto tarda en renderizarse el elemento visible más grande — normalmente una imagen principal, un titular o un bloque de texto. Es un indicador de «¿cuándo parece cargada la página?» Un LCP lento significa que los visitantes miran una pantalla en blanco o a medio construir, y es una de las razones más comunes por las que una página se siente lenta aunque sea técnicamente funcional.

La segunda, el Cumulative Layout Shift, mide el movimiento inesperado del contenido mientras la página carga. Has sentido un mal CLS cada vez que un botón ha saltado justo cuando ibas a tocarlo, porque una imagen o un anuncio se cargó encima y lo empujó todo hacia abajo. Cuantifica esa inestabilidad molesta, y mejorarlo consiste en gran parte en reservar el espacio del contenido antes de que llegue.

La tercera, la Interaction to Next Paint, mide la capacidad de respuesta — con qué rapidez reacciona la página de forma visible después de que haces clic, tocas o escribes. Un mal INP significa que la interfaz se siente lenta y poco receptiva, a menudo porque el hilo principal del navegador está ocupado ejecutando JavaScript cuando intentas interactuar. Para apps con mucho script, suele ser la más difícil de las tres de lograr.

Corregir cada métrica

Mejorar el LCP suele reducirse a entregar antes el contenido importante. Optimiza y dimensiona correctamente las imágenes, sírvelas en formatos modernos, y usa las pistas de carga y prioridad que ofrece la plataforma; asegúrate de que tu servidor o CDN responda rápido; y evita bloquear el renderizado inicial con scripts y hojas de estilo innecesarios. El objetivo es que los píxeles más importantes lleguen lo antes posible.

• LCP — rapidez con que aparece el contenido principal; optimiza imágenes y respuesta del servidor
• CLS — estabilidad del diseño; reserva espacio para imágenes, incrustaciones y fuentes
• INP — capacidad de respuesta; reduce y trocea el JavaScript del hilo principal
• SPA: troceado de código, carga diferida, bundles podados; SSR para un primer pintado rápido
• Mide con datos reales de campo (CrUX), no con una sola pasada de laboratorio

Arreglar el CLS consiste sobre todo en reservar espacio por adelantado. Define siempre un ancho y un alto explícitos (o una relación de aspecto) en imágenes e incrustaciones para que el navegador deje sitio antes de que se carguen, evita insertar contenido por encima de lo que el usuario ya está leyendo, y ten cuidado con las fuentes web para que el texto no se reflujo cuando la fuente personalizada se activa. Son cambios pequeños y mecánicos con un efecto desmesurado en lo estable que se siente una página.

Mejorar el INP significa hacer menos trabajo en el hilo principal en el momento de la interacción. Trocea las tareas JavaScript largas, aplaza o elimina los scripts que no se necesitan de inmediato, y sé disciplinado con el código de terceros, una causa frecuente e invisible de falta de respuesta. Cuanto menos tenga que hacer el navegador cuando un usuario hace clic, más rápido puede pintar el resultado.

Atención especial para las SPA

Las single-page applications necesitan aquí una atención particular, porque sus fortalezas y sus riesgos en los Core Web Vitals provienen de la misma fuente. El bundle de JavaScript que hace que la navegación se sienta instantánea también puede retrasar el primer pintado y bloquear las interacciones si crece demasiado. El troceado de código para que cada ruta cargue solo lo que necesita, la carga diferida de componentes pesados y la poda de dependencias son las palancas que mantienen una SPA a la vez fluida y rápida de cargar.

El renderizado en servidor y la generación estática ayudan a las SPA en exactamente estas métricas. Al enviar contenido real renderizado en la primera respuesta — vía Nuxt, Next.js o un build estático — le das al usuario un LCP rápido en lugar de una pantalla en blanco esperando los scripts. La app se hidrata luego a su forma interactiva, así que mantienes la navegación fluida mientras corriges el problema de primera carga pesada que perjudica a los Vitals.

Mide con datos reales de campo

Por último, mide con datos reales, no solo con un test de laboratorio puntual. Herramientas como PageSpeed Insights y Lighthouse son útiles para el diagnóstico, pero los datos de campo de usuarios reales — a través del Chrome User Experience Report o tu propia monitorización — te dicen qué experimentan de verdad los visitantes según dispositivos y redes. Mejorar los Core Web Vitals es un hábito continuo de medir, corregir al peor infractor, y volver a medir, más que una casilla que marcas una sola vez.