Una guía práctica de Core Web Vitals Explicado

Son tres métricas y no diez: Core Web Vitals explicado se reduce a LCP, INP y CLS, que describen lo que siente el usuario y no lo que mide un servidor.

Core Web Vitals son el pequeño conjunto de métricas de rendimiento centradas en el usuario de Google: pintura con contenido más grande, interacción con la siguiente pintura y cambio de diseño acumulativo. Importan porque describen lo que sienten los visitantes: si la página se carga rápidamente, si responde cuando se toca o se hace clic y si evita saltar de un lado a otro.

La documentación actual de Web Vitals de Google identifica LCP, INP y CLS como Core Web Vitals estable y explica el ciclo de vida de la métrica (web.dev Web Vitals). INP reemplazó oficialmente el retraso de la primera entrada como Core Web Vital el 12 de marzo de 2024, como anunció Google en su actualización de Search Central.

Trate Core Web Vitals como una señal de diagnóstico y de experiencia de una página, no como un interruptor mágico SEO. Mejores signos vitales pueden ayudar a los usuarios y eliminar una desventaja en la clasificación, pero no reemplazan la relevancia, la calidad del contenido, la autoridad o la adecuación del producto.

Los Tres Core Web Vitals

Pintura con contenido más grande (LCP)

LCP mide cuándo termina de renderizarse el elemento de contenido visible más grande. Ese elemento es, en la mayoría de las páginas, la imagen principal, un título grande, una imagen de producto o el bloque de contenido principal.

Objetivo: bueno LCP es 2,5 segundos o más rápido para la mayoría de las cargas de página.

Problemas comunes con LCP:

• Respuesta lenta del servidor
• Grandes imágenes de héroes no optimizadas
• CSS que bloquea el renderizado
• Retrasos en la renderización del lado del cliente
• Fuentes web que bloquean texto
• Carga diferida de la imagen principal por error.

Cómo mejorarlo:

• Sirve HTML rápidamente desde el borde o desde un origen rápido.
• Comprimir y cambiar el tamaño de las imágenes de los héroes.
• Utilice formatos modernos como AVIF o WebP cuando corresponda.
• Precargue la imagen real LCP.
• CSS en línea o priorizado.
• Evite hacer que el contenido principal espere a análisis, herramientas de consentimiento o administradores de etiquetas.

Interacción con la siguiente pintura (INP)

INP mide la capacidad de respuesta en todas las interacciones, no solo en la primera entrada. Capta cuánto tiempo tarda la página en responder visiblemente después de hacer clic, tocar e interactuar con el teclado.

Objetivo: bueno INP está por debajo de 200 milisegundos.

INP a menudo se ve afectado por JavaScript. Tareas largas, hidratación, scripts de análisis, widgets de chat, herramientas de personalización y etiquetas pesadas de terceros pueden competir por el hilo principal.

Cómo mejorarlo:

• Reducir el JavaScript enviado a la página.
• Dividir paquetes grandes.
• Aplazar scripts de terceros no críticos.
• Evite trabajos costosos en manipuladores de clics.
• Utilice trabajadores web para cálculos pesados.
• Divida las tareas largas en partes más pequeñas.
• Probar dispositivos móviles de gama baja, no sólo portátiles de desarrolladores.

Analytics puede afectar a INP cuando adjunta demasiados detectores de eventos, realiza trabajo sincrónico o carga a través de un administrador de etiquetas voluminoso. Un script pequeño que dé prioridad a la privacidad no sólo es mejor para la confianza; a menudo es mejor para la capacidad de respuesta.

Cambio de diseño acumulativo (CLS)

CLS mide el movimiento visual inesperado. Una página se siente rota cuando el texto, los botones o las imágenes cambian después de que el usuario comienza a leer o tocar.

Objetivo: bueno CLS es 0,1 o inferior.

Problemas comunes con CLS:

• Imágenes sin dimensiones
• Anuncios o embeds inyectados sin espacio reservado.
• Banners de cookies que envían contenido después de la carga.
• Las fuentes web se cambian tarde
• Contenido dinámico insertado sobre el contenido existente.

Cómo mejorarlo:

• Establecer ancho y alto o relación de aspecto para los medios.
• Reserve espacio para banners, incrustaciones y anuncios.
• Evite insertar contenido en la mitad superior de la página después de la carga.
• Utilizar estrategias de carga de fuentes que minimicen los turnos.
• Pruebe con banners de consentimiento reales y etiquetas de marketing reales habilitadas.

Datos de campo versus datos de laboratorio

Las herramientas de laboratorio como Lighthouse son útiles para la depuración porque ejecutan pruebas controladas. Los datos de campo son lo que experimentaron los usuarios reales. Necesitas ambos.

Utilice datos de laboratorio para reproducir y solucionar problemas. Utilice datos de campo para priorizar. Una página que obtiene una buena puntuación en el laboratorio aún puede tener un rendimiento deficiente para visitantes reales en dispositivos lentos, redes móviles congestionadas o navegadores afectados por scripts de terceros.

El Informe de experiencia del usuario de Chrome (CrUX) de Google es una fuente de datos de campo públicos para orígenes elegibles. Su propio seguimiento de usuarios reales puede ser más específico porque puede segmentar por plantilla, dispositivo, campaña, estado de inicio de sesión y versión de lanzamiento.

Al medir las mejoras, mantenga el método consistente. Compare las mismas plantillas, clases de dispositivos, países y ventanas de lanzamiento. Utilice el percentil 75 porque los umbrales Core Web Vitals se evalúan a través de cargas de página, no uno que se ejecuta mejor en una computadora portátil de desarrollador.

Por qué son importantes las opciones de análisis

Los presupuestos de rendimiento se centran en imágenes y paquetes de aplicaciones, ignorando los scripts de medición. Eso es un error.

Los administradores de etiquetas pueden cargar varios proveedores, cada uno con solicitudes de red, ejecución de JavaScript, cookies y detectores de eventos. Las plataformas de gestión de consentimiento también pueden afectar el rendimiento cuando bloquean la representación, inyectan una interfaz de usuario tardía o activan la reevaluación de etiquetas después de la elección del usuario.

Auditoría:

• Peso total del script de terceros
• Número de solicitudes de red antes de LCP
• Tiempo de bloqueo del hilo principal a partir de análisis y etiquetas publicitarias.
• Si la analítica se cargan antes que el contenido crítico.
• Si la interfaz de usuario de consentimiento provoca un cambio de diseño
• Si las etiquetas no utilizadas aún se activan

Elimine las etiquetas que no respalden una decisión actual. Reemplace la analítica pesados ​​con mediciones agregadas más eficientes cuando sea posible.

Un orden de optimización práctico

1. Mida LCP, INP y CLS de usuarios reales en plantillas de claves.
2. Identifique la peor plantilla, no la peor URL individual.
3. Primero arregle la respuesta del servidor y la entrega de la imagen LCP.
4. Elimine o aplace JavaScript no crítico.
5. Reserve espacio de diseño para medios, incrustaciones, anuncios y banners.
6. Vuelva a realizar la prueba en el móvil.
7. Observe los datos de campo durante al menos un ciclo de tráfico completo.

No persiga una puntuación perfecta de Lighthouse a expensas de usuarios reales. Una página de pago con JavaScript un poco más pesado puede ser aceptable si responde y es estable. Una página de marketing sin lógica de aplicación debería ser extremadamente sencilla.

Core Web Vitals Control de calidad

Antes de cantar victoria, comprueba:

• Los datos de laboratorio y de campo se movieron en la dirección esperada.
• Se mejoraron las peores plantillas móviles, no solo la página de inicio.
• Se habilitaron banners de consentimiento, GTM, anuncios, chat y análisis durante pruebas realistas.
• Los cambios LCP, INP y CLS están relacionados con la conversión, el registro, la interacción con el contenido, la desviación del soporte o la calidad de los ingresos.
• Los resultados del backend se concilian con la analítica del navegador al medir el impacto empresarial.

Mantenga las métricas de diagnóstico separadas de las métricas de decisión. Una mejor puntuación INP explica por qué un formulario parece más rápido; la métrica empresarial es si más personas lo terminan.

El resultado final

Core Web Vitals recompensa el mismo comportamiento que los visitantes ya recompensan: contenido rápido, controles responsivos y diseños estables. El camino más rápido no es exótico. Envíe menos JavaScript, priorice el contenido principal, reserve espacio y deje de cargar etiquetas que no le reporten beneficios.

Preguntas frecuentes

¿Cuáles son los tres Core Web Vitals?

Los Core Web Vitals son Largest Contentful Paint, Interaction to Next Paint y Cumulative Layout Shift. La documentación de Web Vitals de Google identifica estos tres como los Core Web Vitals estables. Juntos cubren la carga, la capacidad de respuesta y la estabilidad visual, que es lo que la mayoría de los visitantes nota sobre la velocidad de una página.

¿Qué se considera una buena puntuación de LCP?

Una buena puntuación de LCP es 2,5 segundos o menos para la mayoría de las cargas de página. LCP mide cuándo termina de renderizarse el elemento de contenido visible más grande, a menudo una imagen destacada o un encabezado grande. Una respuesta lenta del servidor, imágenes destacadas sin optimizar y CSS que bloquea el renderizado son las causas habituales de una puntuación baja.

¿Qué se considera una buena puntuación de INP?

Una buena puntuación de INP es menos de 200 milisegundos. INP mide cuánto tarda una página en responder de forma visible a clics, toques y entradas de teclado, no solo a la primera interacción. Las tareas largas de JavaScript, la hidratación y los scripts pesados de terceros son las causas más comunes de una puntuación baja.

¿Qué se considera una buena puntuación de CLS?

Una buena puntuación de CLS es 0,1 o menos. CLS mide el movimiento visual inesperado, el que ocurre cuando el texto o los botones se desplazan mientras alguien está leyendo o tocando la pantalla. Las imágenes sin dimensiones definidas y las fuentes web que cambian tarde son causas frecuentes.

¿Cuándo sustituyó INP a First Input Delay como Core Web Vital?

INP sustituyó oficialmente a First Input Delay como Core Web Vital el 12 de marzo de 2024. Google anunció el cambio en su actualización de Search Central. El cambio trasladó la medición de la capacidad de respuesta de una sola primera interacción a todo el rango de clics, toques y pulsaciones de teclado en una página.

¿Los Core Web Vitals afectan directamente al posicionamiento en Google?

Unos Core Web Vitals mejores pueden eliminar una desventaja de posicionamiento y mejorar la experiencia de los visitantes, pero no funcionan como una palanca de posicionamiento independiente. Son un diagnóstico y una señal de experiencia de página entre muchas otras. La relevancia, la calidad del contenido, la autoridad y el ajuste al producto siguen determinando el resultado.

¿Cuál es la diferencia entre datos de campo y datos de laboratorio?

Los datos de laboratorio provienen de herramientas controladas como Lighthouse y sirven para reproducir y corregir problemas concretos. Los datos de campo reflejan lo que los usuarios reales experimentaron en sus propios dispositivos y redes, y son los que deben guiar la priorización. Una página puede obtener buena puntuación en el laboratorio y aun así rendir mal para visitantes reales en dispositivos lentos o redes congestionadas.

¿Por qué los scripts de analítica pueden perjudicar el INP?

Los scripts de analítica pueden perjudicar el INP cuando agregan demasiados escuchadores de eventos, ejecutan trabajo síncrono o se cargan mediante un gestor de etiquetas pesado, todo lo cual compite por el hilo principal. Los gestores de etiquetas suelen cargar varios proveedores a la vez, cada uno con sus propias solicitudes de red y ejecución de JavaScript. Un script más pequeño y centrado en la privacidad es más ligero para el hilo principal además de generar más confianza.

¿Por qué se miden los Core Web Vitals en el percentil 75?

Los umbrales de Core Web Vitals se evalúan a través de todas las cargas de página, no de una sola ejecución perfecta en un portátil de desarrollador. El percentil 75 refleja una visión realista de lo que experimenta la mayoría de los visitantes, incluidos los dispositivos y conexiones más lentos del conjunto. Comparar las mismas plantillas, clases de dispositivo, países y ventanas de lanzamiento en este percentil mantiene la medición consistente a lo largo del tiempo.

¿Qué suele causar el Cumulative Layout Shift?

Las causas habituales incluyen imágenes o elementos incrustados sin espacio reservado, anuncios insertados sin un tamaño fijo, banners de cookies que empujan el contenido después de la carga y fuentes web que cambian tarde. El contenido dinámico insertado encima de lo que ya está en la página es otro desencadenante frecuente. Reservar espacio para medios y banners de antemano, y probar con herramientas de consentimiento reales activadas, resuelve la mayoría de estos casos.