Skip to content
Volver a todos los artículos

Core Web Vitals en 2026: por qué la velocidad del sitio sigue ganando clientes

7 min de lectura
Ilustración isométrica de los Core Web Vitals sobre un fondo oscuro: tarjetas de puntuación de LCP, INP y CLS, un medidor de velocidad de página en 92, un gráfico de rendimiento a lo largo del tiempo y una lista de los principales arreglos

Un cliente rara vez abre una conversación preguntando por Interaction to Next Paint. La abre diciendo que el sitio "va lento", o que el de un competidor "va más ágil", y entonces mi trabajo es convertir esa sensación en un número y el número en un arreglo. Los Core Web Vitals siguen siendo el mejor vocabulario público para esa conversación, y los detalles que conviene conocer en 2026 han cambiado desde la última vez que se modificó el conjunto de métricas.

Esta es la versión práctica: qué miden las tres métricas, dónde se rompe cada una de verdad en los sitios de clientes que audito, y cómo demostrar que el arreglo funcionó en lugar de solo afirmarlo.

Las tres métricas que siguen importando

Largest Contentful Paint mide cuánto tarda en renderizarse el elemento visible más grande: la imagen principal, un titular, la miniatura de un vídeo. Por debajo de 2.5 segundos es bueno. Interaction to Next Paint mide el retraso entre un toque o clic y la siguiente actualización visual, por debajo de 200 milisegundos es bueno, y sustituyó a First Input Delay como métrica de capacidad de respuesta porque FID solo medía la primera interacción, no las que ocurren después de que una página haya terminado de cargar y se haya vuelto lenta. Cumulative Layout Shift mide cuánto salta de forma inesperada el contenido visible, por debajo de 0.1 es bueno.

Las tres son de aprobado o suspenso en el percentil 75 de las visitas reales, no una media ni una puntuación de laboratorio. Un sitio que es rápido para la mayoría de los visitantes y pésimo para uno de cada cinco con una conexión limitada sigue suspendiendo la métrica, porque el umbral se fija a propósito para reflejar una visita realista y más lenta, no un portátil de gama alta con fibra.

Dónde se rompe LCP de verdad

En los sitios que audito casi nunca es el framework. Es una imagen principal sin optimizar servida a cuatro veces el tamaño al que se renderiza, una fuente web que bloquea el renderizado del texto porque no se precargó, o un script de terceros —un widget de chat, una etiqueta de analítica, un píxel de marketing— cargado de forma síncrona antes que el contenido que se supone que debe medir.

El arreglo rara vez es dramático: sirve la imagen principal al tamaño al que se renderiza, en un formato moderno, con prioridad de descarga alta y sin carga diferida en la única imagen que con seguridad está por encima del pliegue; precarga el archivo de la fuente en lugar de dejar que el navegador la descubra tras analizar el CSS; y carga todos los scripts de terceros de forma asíncrona, punto, salvo que tengan una razón concreta para bloquear.

INP es un problema de JavaScript

Donde LCP es sobre todo un problema de carga, INP es casi por completo un problema del hilo principal: una tarea larga que impide al navegador responder a un toque, normalmente provocada por demasiado JavaScript ejecutándose, hidratándose o volviéndose a renderizar a la vez. Un único componente que vuelve a renderizar una lista larga entera en cada pulsación de tecla suspenderá INP incluso en una conexión rápida, porque el retraso no tiene nada que ver con la red.

El arreglo que más ha importado en los proyectos de React y Next.js este año es ser deliberado sobre qué necesita realmente ser un componente de cliente frente a qué puede quedarse renderizado en el servidor, y dividir los bundles de cliente grandes para que una interacción en una parte de la página no esté esperando a que el JavaScript de una parte no relacionada termine de ejecutarse. Aplicar debounce a los manejadores costosos y virtualizar las listas largas siguen mereciendo la pena.

CLS: el arreglo barato que nadie se molesta en hacer

El desplazamiento del diseño suele estar provocado por las mismas tres cosas: una imagen o un vídeo incrustado sin ancho y alto reservados, una fuente web que se renderiza con un ancho notablemente distinto al de la fuente de reserva que sustituye, y contenido —normalmente un hueco publicitario, un aviso de cookies o una barra promocional— inyectado por encima del contenido existente después de que la página ya se haya maquetado.

Las tres tienen un arreglo que casi no cuesta nada: fija dimensiones explícitas en cada imagen y elemento incrustado, elige una fuente de reserva métricamente cercana a la fuente web (o acepta un breve parpadeo en lugar de un desplazamiento), y reserva espacio para todo lo que se inyecta tarde en lugar de dejar que empuje hacia abajo todo lo que hay debajo de ello.

Medirlo bien

Una puntuación de Lighthouse en las herramientas de desarrollo son datos de laboratorio: una ejecución, en una máquina, con una conexión rápida, útil para diagnosticar la causa de un problema. No es el número por el que Google juzga realmente la página, que procede del Chrome User Experience Report: visitas reales, dispositivos reales, redes reales, agregados a lo largo de 28 días. Una página puede sacar 100 en Lighthouse y aun así suspender sus Core Web Vitals sobre el terreno si suficientes visitantes reales están en un móvil de gama media con un 4G irregular.

Tanto el informe de Core Web Vitals de Search Console como PageSpeed Insights muestran los datos de campo una vez que un sitio tiene tráfico suficiente para cumplir los requisitos. Para un sitio de cliente más pequeño que no ha alcanzado el umbral de tráfico de CrUX, mido las mismas tres métricas mediante un script ligero en el propio navegador, enviado a la analítica, para que el cliente obtenga números reales en lugar de una estimación de laboratorio que los sustituya.

Por qué esto sigue cerrando tratos

La mayoría de los clientes potenciales no saben leer un informe de Lighthouse, y no les hace falta: pueden sentir un sitio que responde al instante a un toque frente a otro con un instante de retraso, y se dan cuenta de que la página de un competidor carga antes de que la suya haya terminado su desplazamiento del diseño. El rendimiento es una de las pocas piezas de artesanía que es directamente perceptible sin ningún vocabulario de diseño, lo que lo hace inusualmente persuasivo en una presentación.

Además se combina con el resto del sitio: una página bellamente diseñada que se atasca en la primera carga se percibe como inacabada, y una página sencilla que responde al instante se percibe como cuidada. La velocidad no está separada del trabajo de diseño, es parte de aquello por lo que se juzga el diseño en el momento en que un visitante real lo abre.