Core Web Vitals, explicados para negocios de servicios.

Los Core Web Vitals son tres métricas que Google publica como el resumen público de cómo se siente su sitio para un visitante real en una conexión real. LCP (Largest Contentful Paint) es el tiempo desde el inicio de la navegación hasta que se dibuja el elemento visible más grande, con un umbral de "bueno" en 2.5 segundos (Google, 2024). INP (Interaction to Next Paint) es el tiempo entre una acción del usuario y la siguiente actualización visual, con un umbral de "bueno" en 200 milisegundos (Google, 2024). CLS (Cumulative Layout Shift) es el puntaje acumulado del movimiento inesperado del diseño durante la vida de la página, con un umbral de "bueno" en 0.1 (Google, 2024).

La vara con la que Google lo califica es el percentil 75 de las sesiones de usuarios reales, segmentado entre móvil y escritorio, muestreado sobre los 28 días más recientes (Google, 2024). Tres cuartas partes de sus visitantes tienen que dar "bueno" en cada métrica para que la página cuente como aprobada. Un sitio que puntúa bien en pruebas de laboratorio y lento en producción va a reprobar esta puerta. Un sitio que carga bien en una laptop de gama alta y mal en un Android de gama media va a reprobar esta puerta.

Google introdujo los Core Web Vitals en mayo de 2020 como la parte visible de la señal de experiencia de página, y reemplazó el viejo rumor de la "velocidad del sitio" con tres métricas de campo ancladas en datos de visitantes reales (Walton, 2020). LCP captura si la página cargó. INP captura si la página responde cuando se toca. CLS captura si el contenido se queda donde el usuario lo espera. Tres números, tres modos de falla independientes, tres rutas de código distintas para arreglarlos.

INP reemplazó a First Input Delay (FID) como Core Web Vital estable en marzo de 2024 (Sullivan y Viscomi, 2024). La razón importa. FID medía solo el retraso antes de que se procesara la primera acción, que casi todos los sitios aprobaban con facilidad porque el navegador agenda rápido el primer manejador de eventos. INP mide cada interacción a lo largo de la visita y reporta la más lenta, con peso hacia el percentil alto de las observaciones, lo que expone las tareas largas y los costos de hidratación que FID venía tapando. La métrica se puso más dura. La mayoría de los sitios que aprobaban FID hoy no aprueban INP.

La velocidad de página se paga sola en conversiones. El reporte State of Online Retail Performance de Akamai (2017) encontró que cada 100 milisegundos de retraso en la carga se correlacionaban con una caída del 7% en conversión, sobre miles de tiendas en línea. El estudio Milliseconds Make Millions de Deloitte Digital (2020), encargado por Google y corrido sobre 30 sitios móviles de retail, midió un aumento promedio de 8.4% en conversión de retail y de 10.1% en viajes por cada 0.1 segundo de mejora en la velocidad del sitio móvil.

El efecto se acumula en negocios de servicios con tráfico de alta intención. Un plomero cuyo sitio móvil carga en cinco segundos en lugar de dos no pierde el 60% de sus prospectos de un salto; la pérdida es gradual a lo largo del embudo, con los cortes más grandes en la primera impresión, donde la decisión de abandonar ocurre en los primeros tres segundos (An, 2017). La cifra que se cita en todas partes, que el 53% de los usuarios móviles abandona un sitio que tarda más de tres segundos en cargar, viene del análisis de Daniel An de 2017 para Think with Google sobre referencias de velocidad móvil.

LCP es el tiempo desde el inicio de la navegación hasta que termina de dibujarse el elemento visible más grande de la parte alta de la página. En la mayoría de los sitios de negocios de servicios, ese elemento es la imagen principal o el titular H1. Si la portada es un video, es el elemento que se haya dibujado antes del póster del video. La métrica ignora todo lo que está debajo del pliegue y todo lo que está fuera de pantalla (Google, 2024).

LCP falla por un puñado de razones identificables. La imagen principal es demasiado grande o no está optimizada. Un script bloqueante en el head retrasa el primer dibujado. El intercambio de una fuente web empuja el dibujado del titular más allá del umbral del candidato de LCP. El tiempo de respuesta del servidor es lento porque la página se arma bajo demanda desde una consulta a base de datos que debió estar en caché. La secuencia de arreglo que sigo en cada auditoría es:

• Servir la imagen principal en un formato moderno (AVIF o WebP) a un tamaño sensato para cada punto de quiebre.
• Eliminar el JavaScript bloqueante arriba del pliegue. Diferir o cargar de forma asíncrona todo lo que no haga falta para el primer dibujado.
• Precargar la imagen de LCP con <link rel="preload"> para que el navegador la pida en paralelo con el HTML.
• Mover el trabajo pesado del servidor a una ruta en segundo plano o a una capa de caché, para que el tiempo de respuesta del HTML se quede por debajo de 200 milisegundos.

En un sitio típico de negocio pequeño, esos cuatro cambios mueven el LCP del rango de 4 a 6 segundos al rango de menos de 2.5 segundos, sin tocar el framework de abajo.

INP mide la capacidad de respuesta de la página a lo largo de toda la visita. Cada clic, toque o tecla dispara la métrica; el valor reportado se pondera hacia las interacciones más lentas observadas (Sullivan y Viscomi, 2024). Un sitio puede aprobar LCP y CLS con holgura y aun así reprobar INP, porque las tres métricas miden cosas independientes.

La mayoría de las fallas de INP que veo en campo vienen de una de tres fuentes.

• El costo de hidratación en la primera interacción después de que se dibuja una página de React, Vue o Angular, cuando la página se ve lista pero el framework todavía no ha enganchado los manejadores de eventos.
• Tareas largas en scripts de terceros, sobre todo analítica, widgets de chat y gestores de etiquetas, que bloquean el hilo principal por cientos de milisegundos en momentos impredecibles.
• Trabajo síncrono pesado dentro del propio manejador del clic, sobre todo en páginas que vuelven a dibujar árboles de componentes grandes con un solo cambio de estado.

Los arreglos son distintos para cada una. La primera pide trabajo a nivel de framework, como hidratación diferida o selectiva. La segunda pide una auditoría de scripts de terceros y carga diferida agresiva. La tercera pide useTransition de React y memorización de componentes. INP premia la disciplina, no el heroísmo.

CLS es un puntaje acumulado, no un tiempo. Suma el impacto de cada movimiento inesperado del diseño durante la vida de la página, ponderado por cuánta área de pantalla se movió y qué tan lejos se movió. El umbral de "bueno" es 0.1, lo que significa que se toleran los movimientos pequeños, pero un solo salto a media carga de un bloque principal completo lo reprueba por sí solo (Google, 2024).

CLS es la más arreglable de las tres porque los modos de falla son conocidos y los arreglos son mecánicos.

• Las imágenes y los videos sin atributos explícitos de ancho y alto mueven el contenido cuando cargan. Declare los dos, incluso en recursos responsivos.
• Las fuentes web con comportamiento FOIT o FOUT empujan el texto hacia abajo cuando la fuente carga. Use font-display: optional o size-adjust para que el intercambio no cambie la altura de línea.
• Los anuncios y los embebidos insertados sobre contenido existente empujan el resto de la página hacia abajo. Reserve el espacio con un contenedor de min-height antes de que el embebido cargue.
• Los avisos de cookies y las puertas de consentimiento que entran animados desde arriba deberían deslizarse sobre la página, no empujarla.

La mayoría de los sitios puede pasar de un CLS de 0.3 a menos de 0.05 en un día enfocado de trabajo. CLS es la métrica que hay que arreglar primero cuando necesita una victoria rápida antes de un proyecto de rendimiento más grande.

Importan tres herramientas. PageSpeed Insights, en pagespeed.web.dev, devuelve datos de laboratorio, generados sobre un dispositivo simulado de gama media con conectividad limitada, y datos de campo, tomados del Chrome User Experience Report (CrUX) para sitios con suficiente tráfico real. Lighthouse, el mismo motor que PSI usa para los datos de laboratorio, corre localmente en Chrome DevTools y es lo que quiere mientras itera sobre un arreglo, porque es rápido y reproducible. El propio Chrome User Experience Report, consultable vía BigQuery para sitios en producción, es la fuente de verdad subyacente que Google usa para sus señales de posicionamiento (Google Search Central, 2021).

Los datos de laboratorio y los de campo se contradicen seguido. Una página puede sacar 95 en Lighthouse y reprobar los Core Web Vitals en CrUX, porque Lighthouse simula una conexión 4G rápida en un dispositivo de gama media, mientras que el tráfico real incluye dispositivos más lentos, redes más lentas y sesiones más largas donde las fallas de INP se acumulan. Los datos de campo son los que Google usa para posicionarlo. Confíe siempre en CrUX por encima de Lighthouse para lo que de verdad determina su posición en búsqueda.

Pathlight automatiza la medición y el diagnóstico en 90 segundos, y devuelve un reporte con puntaje contra su propia URL y los arreglos priorizados debajo. Vale la pena correrlo antes de una auditoría casera de cuatro horas, aunque sea solo para confirmar en qué va a gastar esas cuatro horas. La referencia más larga sobre lo que cubre una auditoría de rendimiento de verdad, y lo que las herramientas gratuitas dejan pasar en silencio, está en la página de servicio.

Optimizar para el puntaje de Lighthouse en lugar de CrUX. Un Lighthouse perfecto que reprueba CrUX es una métrica de vanidad. Un Lighthouse de 78 que aprueba CrUX es el que posiciona. Trate a Lighthouse como el ciclo de iteración y a CrUX como la fuente de verdad.

Tratar INP como si fuera FID. Los sitios que aprobaban FID heredaron a menudo la idea de que "la interactividad está bien, ya pasamos la prueba". INP es una prueba más estricta que incluye cada interacción de la visita. Si no ha medido INP desde marzo de 2024, no ha medido INP.

Ignorar los scripts de terceros. La mayoría de los sitios de negocios de servicios cargan entre cinco y doce scripts de terceros: analítica, gestores de etiquetas, widgets de chat, agendadores, píxeles sociales, embebidos de reseñas. Cada uno corre JavaScript en el hilo principal. El Web Almanac 2024 reporta que el sitio mediano carga 22 peticiones de terceros, y el percentil 90 carga más de 100 (HTTP Archive, 2024). Las fallas de INP se agrupan alrededor de esas peticiones. Audite sin piedad. Quite lo que no pueda justificar.

Optimizar solo la página de inicio. Los Core Web Vitals se miden página por página, no por sitio. Una página de inicio con 95 y doce páginas de detalle de servicio con 60 se posiciona por las páginas de detalle en las búsquedas de detalle. Audite cada URL comercialmente importante, no solo la puerta de entrada.