Core Web Vitals

Cada una describe una forma distinta en que una página puede parecer rota, y por eso son tres y no una sola puntuación. Se miden en el percentil 75 de las cargas de página, así que la pregunta no es si la página suele ir bien, sino si va bien en tres de cada cuatro visitas.

Esta es la distinción que causa la mayor parte de la confusión en los informes para clientes. Lighthouse y el modo de laboratorio de PageSpeed Insights simulan una carga de la página en un dispositivo y una red artificiales, y dan una puntuación al momento. Las Core Web Vitals se evalúan con el Chrome User Experience Report: cargas reales, de visitantes reales, con los dispositivos y conexiones que tienen de verdad.

CrUX agrega los datos en una ventana móvil de 28 días. Así que una corrección que se publica hoy no mueve la cifra hoy. Entra en la ventana de inmediato y solo pesa más que el resto un mes después, cuando van saliendo de la ventana las cargas lentas de antes de la corrección.

La consecuencia para una agencia es totalmente previsible y aun así pilla por sorpresa: se publica el trabajo, el cliente mira PageSpeed Insights a la mañana siguiente, ve los datos de campo sin cambios y concluye que no ha pasado nada. Explicar la ventana antes de publicar cuesta una frase. Explicarla después suena a excusa.

Además, una web con poco tráfico puede no tener ningún dato de campo, y en ese caso Google recurre a los datos del dominio o no tiene nada que evaluar. Conviene comprobarlo antes de prometer a un cliente que mejorará una puntuación.

Google ha sido coherente, y especialmente claro, en que la experiencia en la página es una señal modesta: un criterio de desempate entre resultados de relevancia parecida, no algo que coloque una página floja por encima de una buena. Una agencia que vende el trabajo en Core Web Vitals como estrategia de posicionamiento está exagerando.

La forma honesta de plantearlo es que deja de ser una desventaja, no que se convierte en una ventaja. Si dos páginas responden igual de bien a la búsqueda y una de ellas se mueve bajo el dedo del lector, la otra tiene ventaja. Si una página responde a la búsqueda y la otra no, la velocidad no es lo que decide.

Por eso el argumento más sólido es comercial. Las páginas lentas pierden visitantes antes de que lean nada, y esa pérdida se puede medir en la propia analítica del cliente en lugar de deducirse de un gráfico de posiciones. Que una página que carga un segundo más rápido convierta mejor es algo que el cliente puede comprobar.

Esto importa para cómo se vende el trabajo. Presentado como posicionamiento, compite con el contenido y los enlaces, y normalmente pierde. Presentado como conversión, compite con el trabajo en las landing pages y a menudo gana, porque ayuda a todas las páginas a la vez.

Lo habitual es abrir la página de inicio en PageSpeed Insights, y la página de inicio rara vez es donde está el dinero. Las páginas que merece la pena arreglar son las que reciben tráfico que convierte: las landing pages de las campañas de pago, las páginas de producto o de servicio y los artículos que traen visitas desde los buscadores.

Arreglar la página de inicio mientras esas siguen lentas es la forma más habitual de que este trabajo consiga una puntuación mejor sin mejorar el negocio, y pasa porque la página de inicio es la URL que prueba todo el mundo.

Dentro de una página, las tres métricas tienen costes muy distintos. El CLS suele ser el más barato de arreglar y el que más nota una persona: reserva espacio para las imágenes, los anuncios y los elementos insertados para que nada se mueva. El LCP suele depender de una imagen grande o de una fuente que bloquea la carga. El INP es el más difícil, porque normalmente lo causan scripts de terceros, y los scripts de terceros normalmente son una decisión de marketing y no técnica.

Esto último conviene planteárselo claramente al cliente. Un gestor de etiquetas con once scripts es un problema de INP que ningún tiempo de desarrollo resuelve, y la conversación sobre cuáles de los once siguen haciendo falta corresponde tanto a la agencia como al desarrollador.