Respuesta rápida
Core Web Vitals 2026: ¿qué cambia y cómo se miden?
En 2026 el cambio clave sigue siendo el de marzo de 2024: INP sustituyó a FID como métrica de Core Web Vitals, midiendo la latencia de todas las interacciones, no solo la primera. Los umbrales de referencia son LCP bueno menos de 2,5s, INP menos de 200ms y CLS menos de 0,1. Para SEO solo cuentan los datos de campo (CrUX), no Lighthouse: una web con Lighthouse 95 y CrUX malo pierde posiciones igualmente.
| Métrica | Bueno | Malo |
|---|---|---|
| LCP | < 2,5s | > 4s |
| INP | < 200ms | > 500ms |
| CLS | < 0,1 | > 0,25 |
Qué cambió de 2024 a 2026
El cambio más visible fue en marzo de 2024, cuando Google reemplazó FID (First Input Delay) por INP (Interaction to Next Paint) en la familia Core Web Vitals. INP no mide solo la primera interacción — mide la latencia de todas las interacciones durante la sesión. La consecuencia práctica: webs que antes pasaban en FID porque el primer click era rápido empezaron a fallar en INP porque el resto de clicks/taps eran lentos.
Entre 2024 y 2026 el umbral de INP no se ha movido (200ms bueno, 500ms malo) pero su peso relativo ha crecido. La razón es simple: FID era una métrica casi cosmética en webs interactivas — la mayoría pasaba por la mínima — mientras que INP refleja problemas reales de hilos bloqueados, JavaScript pesado y handlers de eventos mal escritos. Las métricas que aportan información valiosa terminan ganando peso aunque nadie lo anuncie.
En paralelo, Google ha estado experimentando con nuevas métricas de "engagement" y "scroll quality" que se discutirán como Core Web Vitals candidatas en 2026-2027. Por ahora ninguna está oficializada, pero están en el radar de cualquiera que quiera anticiparse.
Las tres métricas Core Web Vitals en detalle
LCP — Largest Contentful Paint
Tiempo desde que el usuario llega a la página hasta que se ha pintado el elemento de contenido más grande visible (normalmente la imagen hero o el bloque principal de texto).
Causas típicas de LCP malo: imágenes hero sin loading="lazy" y sin compresión adecuada, fonts bloqueando el render, servidor lento sin caché, exceso de CSS crítico inline.
INP — Interaction to Next Paint
Latencia desde que el usuario interactúa (click, tap, tecla) hasta que la página pinta la respuesta visible. Se mide a lo largo de toda la sesión, devolviendo el percentil 98 de las interacciones.
Causas típicas de INP malo: handlers de eventos pesados, scripts de terceros (chatbots, analítica) que bloquean el hilo principal durante segundos, animaciones JavaScript en lugar de CSS, listeners en cada elemento en vez de delegación.
CLS — Cumulative Layout Shift
Suma de los desplazamientos visuales no esperados durante la sesión. Una página con CLS alto es la que mientras lees, se mueve sola porque carga una imagen tarde, una banner de cookies se inserta tras 2 segundos o un ad se infla y empuja el contenido hacia abajo.
Causas típicas de CLS malo: imágenes sin atributos width y height, fonts cambiando el ancho del texto al cargar, banners insertados dinámicamente sin reserva de espacio, ads o iframes que se redimensionan.
Datos de campo vs datos de laboratorio: la diferencia que casi nadie entiende
Esta es la confusión más común y la que genera más decisiones equivocadas. Hay dos fuentes de datos:
| Datos de laboratorio (Lab) | Datos de campo (Field) | |
|---|---|---|
| Origen | Lighthouse, PageSpeed Insights (sección lab), DevTools | CrUX (Chrome User Experience Report) |
| Cómo se generan | Simulación controlada (un test, tu máquina, perfil 4G simulado) | Mediciones reales de usuarios reales con Chrome |
| Velocidad de respuesta | Inmediata (mides ahora) | Tarda 28 días en agregarse |
| Sirve para | Diagnosticar y desarrollar | Saber qué viven tus usuarios, lo que cuenta para SEO |
| Lo que mira Google para ranking | No | Sí |
La consecuencia clave: una web con Lighthouse 95 y CrUX malo está perdiendo en SEO, porque Google evalúa por CrUX. Y al revés: si CrUX es bueno pero Lighthouse es mediocre, técnicamente vas bien para Google aunque las herramientas de auditoría den verde-amarillo.
Por eso una auditoría SEO técnica seria mira siempre el campo primero (PageSpeed Insights muestra los dos paneles, el de "Datos de origen" es el que cuenta para SEO) y solo entrega Lighthouse como herramienta de debug, nunca como argumento principal.
Caso real: Web Vitals de este portfolio en producción
Aplicando lo anterior al propio sitio donde estás leyendo esto, los datos de campo del portfolio en CrUX (28 días, mayo 2026) están en estado bueno para las tres métricas. Aquí los números aproximados:
- LCP móvil: ~1,8s (bueno). Lo limita la imagen hero del index y los webfonts. Optimizado con WebP,
preloadde la fuente principal ydisplay=swap. - INP móvil: ~140ms (bueno). El secreto fueron dos cambios: usar event delegation en los gadgets en lugar de handlers individuales por card, y mover los scripts de los gadgets pesados (Three.js) a carga lazy con
IntersectionObserver. - CLS móvil: ~0,02 (bueno). Todas las imágenes con
width/heightexplícitos, fonts confont-display: swapy la pre-reserva del espacio del menú.
Lighthouse en local da números algo peores (LCP simulado 2,4s) porque Lighthouse simula 4G lenta a propósito. Lo importante es que en campo el dato real es 1,8s. Esa diferencia laboratorio-campo es exactamente la que confunde a tantas webs: optimizan para Lighthouse y no para usuarios reales.
Tres problemas concretos que tuve y cómo los resolví
1. INP malo en gadgets pesados (Three.js, particle simulator). Cuando un usuario abría un gadget, el JS se ejecutaba en el hilo principal y bloqueaba clicks durante 600-900ms. Solución: cargar el JS del gadget solo cuando entra al viewport (IntersectionObserver) y dividir la inicialización en chunks con requestIdleCallback. Resultado: INP de 800ms a 140ms. El caso más extremo fue el simulador del sistema solar: cuento cómo está construido y qué costó cada decisión de rendimiento en el deep dive del Solar System en Three.js.
2. CLS por banner de cookies tardío. El consentimiento de cookies se inyectaba tras 1 segundo, empujando todo el contenido. Solución: reservar el espacio con CSS min-height antes de la inyección. Resultado: CLS de 0,18 a 0,02.
3. LCP móvil mediocre por la imagen hero. Hero imagen original 350KB JPEG. Solución: convertir a WebP con Pillow quality 80 (paso de 350KB a 95KB), añadir fetchpriority="high" y preload. Resultado: LCP móvil de 3,1s a 1,8s.
Herramientas para medir Web Vitals correctamente
Ordenadas de menor a mayor utilidad para SEO:
- Chrome DevTools (Performance panel): para debug local rápido. No sirve como prueba final, sirve para reproducir un problema concreto.
- Lighthouse: simula una visita en condiciones controladas. Útil para CI/CD y para ver el efecto de un cambio antes de desplegarlo.
- PageSpeed Insights (web): combina Lighthouse + CrUX en una sola pantalla. Es lo más práctico para una decisión de negocio: ves qué experimentan usuarios reales y qué dice la simulación.
- Search Console > Core Web Vitals: agrupa URLs por estado (bueno/mejorable/malo) usando datos de campo. Vital para priorizar qué páginas arreglar primero.
- web-vitals.js (librería oficial): si quieres integrar las métricas en tu propia analítica para tener datos en tiempo real, esta librería de Google las captura del navegador del usuario y permite enviarlas a Google Analytics, Datadog o tu backend.
- CrUX BigQuery: para análisis avanzado a nivel de dominio. Para una PYME normalmente es overkill.
Usar la 1, 2 y 3 cubre el 95% de los casos. La 4 es imprescindible si tienes Search Console activo. La 5 solo si necesitas alertas en tiempo real.
Errores comunes al medir Web Vitals
- Confundir Lighthouse con SEO: el más extendido. Una agencia entrega "Lighthouse 95" como entregable final, el cliente lo paga, y el SEO no se mueve porque CrUX seguía en rojo. Pide siempre datos de campo.
- Optimizar para escritorio cuando el tráfico es móvil: en muchas webs (turismo, ecommerce local), el 70-80% del tráfico es móvil. Si sólo miras desktop, vas ciego. CrUX por defecto separa móvil y escritorio: revisa siempre la pestaña móvil.
- Tomar decisiones con una sola medición de Lighthouse: cada ejecución de Lighthouse da resultados ligeramente distintos por la variabilidad de la simulación. Para conclusiones serias: ejecutar 5 veces y quedarse con la mediana.
- Ignorar el percentil 75: Google evalúa al P75 — si tu peor 25% de visitas tiene LCP de 5s pero la mediana es 2s, Google considera tu página mala. La mediana es un dato que distrae.
- No medir tras cambios grandes: cuando despliegas un cambio que toca rendering (nueva tipografía, librería, imagen hero), Web Vitals puede degradarse sin que lo notes hasta el siguiente reporte CrUX (28 días después). Mide en lab inmediatamente después del cambio para detectar regresiones rápido.
- Confundir "página rápida" con "todas las páginas rápidas": CrUX agrupa por URL. Si tu home está en verde y los posts del blog en rojo, la home se beneficia y los posts se penalizan independientemente. Hay que arreglar cada grupo de URLs por separado.
Qué hacer si tus Web Vitals están mal (orden de prioridad)
El orden importa porque cada arreglo tiene un coste/beneficio distinto:
- Arregla CLS primero. Es lo más barato (declarar dimensiones de imágenes, reservar espacio para componentes dinámicos) y lo más visible para el usuario. Suele ser una tarde de trabajo y mueve la métrica drásticamente.
- Optimiza la imagen hero (LCP). WebP/AVIF, dimensiones correctas,
preloadconfetchpriority="high". Otra tarde de trabajo, impacto inmediato. - Reduce JavaScript no crítico (INP). Mover scripts de terceros a defer, eliminar trackers innecesarios, lazy-load de gadgets. Más trabajo, pero impacto grande en INP.
- Optimiza fonts.
font-display: swap, preload de la fuente principal, subset si solo usas latín. Pequeño impacto, fácil de hacer. - Caché y CDN. Si tu LCP sigue mediocre tras todo lo anterior, el cuello de botella es el servidor. Activar caché agresiva o un CDN (Cloudflare gratuito) suele ser el último empuje.
Para webs de hostelería/turismo de la Costa Daurada o el Baix Penedès donde el tráfico es móvil-pesado y vienen de redes 4G inestables, este orden multiplica resultados. Para ecommerce y software con muchos elementos interactivos, INP suele ser el cuello de botella y conviene atacar el punto 3 antes que el 1.
Errores que cometí yo mismo con Web Vitals
- Optimizé Lighthouse durante meses sin mirar CrUX. Mi obsesión por el "Lighthouse 100" me hizo perder de vista que el dato que cuenta es CrUX. Cambié estrategia hace año y medio y la mejora real en SEO se vio justo después.
- Subestimé la diferencia móvil-desktop. En desktop tenía LCP 1,2s (excelente) y asumí que móvil iría parecido. CrUX móvil decía 3,4s. La razón: imagen hero sin sizes responsive, los móviles bajaban la versión grande. Lección: mira CrUX móvil y desktop por separado siempre.
- Metí Three.js en gadgets sin lazy load. El bundle sumaba 480KB que se descargaban al cargar la home aunque el usuario no abriera ningún gadget. INP en gadgets pasó de 800ms a 140ms tras lazy-load por
IntersectionObserver. Lo cuento en detalle en la arquitectura Vanilla JS de los gadgets IA. - No reservé espacio para banner de cookies. Asumí que el usuario lo cerraría rápido y no notaría el shift. CrUX me corrigió: CLS 0,18. Aprendí a reservar espacio para todo lo que se inyecta tarde, sin excepciones.
Conclusión: Web Vitals como base, no como obsesión
Los Web Vitals son una de esas señales de SEO donde el coste de tenerlas mal es muy alto pero el beneficio de tenerlas perfectas es decreciente. Pasar de rojo a verde puede mover decenas de posiciones en keywords competidas. Pasar de verde a verde-óptimo no mueve casi nada.
La estrategia honesta para una PYME: arreglar lo que está en rojo cuanto antes, mantener todo en verde sin reventar el equipo, y dedicar el tiempo restante a contenido y enlaces que mueven más posiciones. Si quieres una visión completa, la auditoría SEO técnica paso a paso aterriza el resto del SEO técnico, y para entender el peso relativo de cada palanca de SEO, mira cómo se interrelaciona con datos estructurados Schema.org y la optimización local con Google Business Profile.
¿Tus Web Vitals están en rojo?
Auditoría técnica gratuita: revisión de campo (CrUX) y laboratorio (Lighthouse), priorización de arreglos por coste/impacto y plan de acción concreto.
Solicitar auditoría gratuitaO escríbeme a hola@cristiancorrales.com
Preguntas frecuentes sobre Web Vitals 2026
Core Web Vitals son tres métricas con las que Google evalúa la experiencia técnica de tu web: LCP, INP (reemplazó FID en marzo 2024) y CLS. En 2026 los umbrales se mantienen pero el peso de INP ha aumentado en el ranking porque mide algo que FID no captaba: cómo se comporta la página después de los primeros segundos.
Para SEO, los datos de campo (CrUX) son los únicos que cuentan. Lighthouse es una simulación útil para diagnosticar y desarrollar, pero Google penaliza o premia en función de lo que viven los usuarios reales según CrUX. Una página puede tener Lighthouse 95 y CrUX malo si la simulación no replica el comportamiento real del tráfico.
LCP: bueno < 2,5s, malo > 4s. INP: bueno < 200ms, malo > 500ms. CLS: bueno < 0,1, malo > 0,25. La métrica se evalúa en el percentil 75 de visitas — el 75% de tus usuarios deben tener experiencia 'buena' para que la página se considere buena.
Si el tráfico es muy bajo, Google no calcula CrUX (necesita un mínimo de muestra). Cuando hay tráfico suficiente y CrUX es regular, Google lo usa como señal negativa relativa frente a la competencia. Mejor estrategia: empezar bien técnicamente desde el principio, así cuando el tráfico crezca el CrUX sea ya bueno por defecto.
En keywords muy competidas con varios competidores empatados en autoridad, Web Vitals desempata. En keywords poco competidas o con uno o dos resultados dominantes, Web Vitals tiene peso pero el contenido y los enlaces pesan más. Regla práctica: arregla Web Vitals si están en rojo, pero no esperes saltos de posición si todo lo demás está flojo.
¿Tu web no trae clientes?
Diseño webs que cargan rápido y convierten, para negocios de Tarragona y alrededores. Precios claros desde el primer día.
Ver el servicio de diseño web →¿Quieres una cifra orientativa ya? Configura tu web y ve el precio al instante →
¿Quieres más tácticas como esta?
Te escribo solo cuando tengo algo que te trae clientes desde Google: un fallo típico, una táctica probada, un dato del mercado local. Sin spam y baja en un clic.
