Las Core Web Vitals son las tres métricas con las que Google mide cómo se vive una página: cuánto tarda en verse lo principal (LCP), cuánto tarda en reaccionar cuando la tocas (INP) y cuánto se mueve mientras carga (CLS). Una página las aprueba cuando, en el 75 % de las visitas reales (por separado en móvil y en ordenador), las tres métricas quedan en la columna «Buena» (web.dev):
| Métrica | Buena | Mejorable | Mala |
|---|---|---|---|
| LCP (carga) | hasta 2,5 s | de 2,5 a 4 s | más de 4 s |
| INP (respuesta) | hasta 200 ms | de 200 a 500 ms | más de 500 ms |
| CLS (estabilidad) | hasta 0,1 | de 0,1 a 0,25 | más de 0,25 |
Las siglas vienen del inglés: Largest Contentful Paint, Interaction to Next Paint y Cumulative Layout Shift. El INP sustituyó al antiguo FID el 12 de marzo de 2024 (web.dev). Si una guía todavía habla del FID, está desactualizada.
¿Cuentan para salir en Google?
Sí, pero no lo deciden todo. Google confirma que sus sistemas de clasificación usan las Core Web Vitals y, a la vez, que siempre intenta mostrar el contenido más relevante, aunque la experiencia de la página sea mejorable (Google Search Central). Una web rápida no compensa un contenido que no responde a lo que se busca; entre dos páginas igual de útiles, ayuda.
Donde más se nota la velocidad es en el negocio. En un estudio que Google encargó a Deloitte y 55 sobre 37 marcas europeas y estadounidenses, mejorar 0,1 s la velocidad de la web en el móvil subió un 8,4 % las conversiones de las tiendas online y un 10,1 % las de las webs de viajes; en las webs de captación de clientes, un 21,6 % más de usuarios llegaron a la página de envío del formulario (web.dev). Son datos de 2019, medidos con métricas anteriores a las actuales, pero en tiendas y viajes la dirección es clara.
Dónde ver los datos de tu web
- Datos de campo, los que cuentan para Google: salen de visitas reales con Chrome (el informe CrUX). Los ves en el informe de Core Web Vitals de Search Console, que resume los últimos 28 días y agrupa las páginas parecidas (Ayuda de Search Console), y en la parte de arriba de PageSpeed Insights. Si tu web tiene pocas visitas, puede que todavía no haya datos.
- Datos de laboratorio: una prueba simulada, como la de Lighthouse en la parte de abajo de PageSpeed Insights. Sirven para encontrar el problema, pero no son lo que mide Google. La prueba de Lighthouse de PageSpeed Insights no puede medir el INP, porque nadie toca la página durante la prueba, y usa en su lugar el tiempo total de bloqueo (TBT) (web.dev).
Cuando arregles algo, en Search Console puedes pulsar «Empezar revisión»: Google vigila esas páginas durante 28 días antes de darlo por resuelto.
Cómo mejorar cada una
LCP: que lo principal llegue primero
- No retrases la imagen principal. Nunca con carga diferida (
loading="lazy"), y mejor confetchpriority="high"para que el navegador la pida antes (web.dev). - Imágenes ligeras: en WebP o AVIF y del tamaño en que se muestran, no más grandes.
- Un servidor que responda rápido y una red de distribución (CDN) cerca de tus visitantes.
- La imagen principal, en el HTML: si la pinta JavaScript después, el navegador no la descubre a tiempo.
INP: que la página responda al momento
- Menos JavaScript, y el que haya, repartido en tareas cortas: mientras el navegador ejecuta una tarea larga, no puede atender un toque (web.dev).
- Revisa los scripts de terceros, como chats, píxeles de publicidad o widgets: todos compiten por el mismo hilo.
- Responde enseguida con algo visible, aunque sea un «cargando», y deja el trabajo pesado para después.
- Una página no demasiado grande: cuantos más elementos tiene, más le cuesta al navegador pintar cada cambio.
CLS: que nada se mueva
- Ancho y alto en todas las imágenes y vídeos (
widthyheight, oaspect-ratioen CSS), para que el navegador reserve su sitio (web.dev). - Reserva el hueco de lo que llega tarde: anuncios, vídeos incrustados o un aviso que aparece arriba. Mejor que floten por encima a que empujen el contenido.
- Fuentes web con un respaldo ajustado a sus medidas (
size-adjust), para que el texto no salte cuando cambia la fuente. - Anima con
transform, no moviendotopoleft.
Cómo lo hacemos en Vetro
Nuestra propia web es una experiencia 3D, y la velocidad entra en el diseño desde el principio:
- el texto llega en el HTML;
- el logotipo de la pantalla de carga va con prioridad alta y con su tamaño reservado;
- las fuentes tienen respaldos ajustados a sus medidas;
- la escena 3D solo se carga si el navegador dibuja con la tarjeta gráfica y quien visita no ha pedido reducir el movimiento. Si no, recibe una versión ligera con el mismo contenido.
En PageSpeed Insights, que en nuestras pruebas mide sin aceleración gráfica y por eso recibe esa versión ligera, la portada saca 100 en rendimiento en el móvil (medido el 5 de octubre de 2026). Es lo mismo que aplicamos en cada web que diseñamos.
Preguntas frecuentes
Si mi web saca buena nota en PageSpeed Insights, ¿ya aprueba las Core Web Vitals? No necesariamente. La nota es una prueba de laboratorio; lo que cuenta para Google son los datos de tus visitas reales de los últimos 28 días.
¿Por qué la nota cambia cada vez que repito la prueba? Porque cambian las condiciones: la red, el servidor o el dispositivo de prueba (Chrome for Developers). Repítela varias veces y fíjate en la tendencia, no en un número suelto.
¿Qué hago si mi web tiene pocas visitas y no hay datos de campo? Guíate por el laboratorio y corrige lo que señale. Cuando haya visitas suficientes, Search Console empezará a mostrar los datos reales.
Fuentes
- Métricas web esenciales: qué son y sus umbrales (web.dev).
- El INP pasa a ser una Core Web Vital el 12 de marzo de 2024 (web.dev).
- La experiencia de página en los resultados de Google (Google Search Central).
- Informe de Core Web Vitals (Ayuda de Search Console).
- Optimizar el LCP, el INP y el CLS (web.dev).
- Milliseconds make millions: el estudio de Deloitte para Google (web.dev).
- Cómo se calcula la nota de rendimiento de Lighthouse (Chrome for Developers).
