Cada pocos años, Google recuerda al sector que la velocidad y la fluidez de una web no son un lujo, sino parte del contrato con el usuario. Los Core Web Vitals son la forma que tiene el buscador de poner número a esa experiencia, y en 2026 el conjunto de métricas está más maduro —y más exigente— que nunca. Si en 2020 hablábamos de LCP, FID y CLS casi como una novedad, hoy son un estándar consolidado que condiciona el posicionamiento, la conversión y la percepción de calidad de cualquier plataforma.
El cambio más relevante de los últimos dos años tiene nombre propio: INP (Interaction to Next Paint). En marzo de 2024 sustituyó al veterano FID como métrica oficial de capacidad de respuesta, y con ello movió el foco desde «¿cuánto tarda mi web en reaccionar al primer clic?» hacia una pregunta mucho más honesta: «¿qué experimenta el usuario cada vez que interactúa, durante toda la visita?». Para los equipos técnicos, ese matiz lo cambia todo.
En esta guía repasamos qué son los Core Web Vitals en 2026, por qué el INP es la métrica que más quebraderos de cabeza está dando, qué umbrales debes vigilar y —lo más importante— cómo optimizar cada una de las tres métricas sin romper el resto de la web. Está pensada para CTOs, responsables de IT y equipos de desarrollo que necesitan pasar del diagnóstico a la acción con criterio.
1. Qué son los Core Web Vitals y por qué en 2026 siguen mandando
Los Core Web Vitals son un subconjunto de las métricas de experiencia de página que Google considera esenciales. No miden lo bonita que es tu web ni cuántas funciones tiene: miden cómo se siente al usarla. En 2026 se apoyan en tres pilares —carga, interactividad y estabilidad visual— y siguen siendo una señal de ranking dentro del sistema de page experience. No son la señal más potente (el contenido relevante y los enlaces siguen pesando más), pero actúan como criterio de desempate y, sobre todo, como multiplicador de conversión.
La clave para entenderlos es distinguir entre datos de campo (lo que experimentan tus usuarios reales, recogido en el informe CrUX de Chrome) y datos de laboratorio (una simulación controlada, como la de Lighthouse). Google evalúa el posicionamiento con datos de campo, medidos en el percentil 75 de tus visitas: si el 75% de tus usuarios tiene una buena experiencia, apruebas. Esto obliga a mirar la web como la ve la mayoría, no solo tu portátil de gama alta con fibra. Ya explicamos esta relación en detalle en nuestra guía sobre Core Web Vitals y SEO, y conviene tenerla presente antes de tocar una sola línea de código.
Antes de optimizar, hay que medir bien. Una auditoría de rendimiento web con las herramientas y métricas adecuadas es el punto de partida obligatorio: sin una línea base fiable, cualquier mejora es un acto de fe.
2. INP: la métrica que destronó a FID
Si solo puedes prestar atención a una novedad de los Core Web Vitals, que sea esta. El INP es, con diferencia, la métrica que más webs está suspendiendo en 2026, porque castiga precisamente lo que más ha crecido en la última década: el exceso de JavaScript.
2.1 De FID a INP: qué cambió realmente
El antiguo FID (First Input Delay) solo medía el retraso de la primera interacción, y únicamente la parte de espera hasta que el navegador empezaba a procesarla. Era una métrica benévola: muchas webs la aprobaban sin merecerlo, porque no reflejaba lo que pasaba después del primer clic. El INP corrige esas dos limitaciones. Primero, observa todas las interacciones de la visita (clics, toques y pulsaciones de teclado) y reporta esencialmente la peor. Segundo, mide el ciclo completo: desde que el usuario interactúa hasta que el navegador pinta el siguiente frame con el resultado visible.
En la práctica, esto significa que un menú que tarda medio segundo en abrirse, un botón de «añadir al carrito» que congela la interfaz o un filtro de producto que bloquea el hilo principal ya no pasan desapercibidos. El INP los saca a la luz.
2.2 Cómo se calcula el INP
Cada interacción tiene una latencia compuesta por tres fases: el retraso de entrada (input delay), el tiempo de procesamiento de los event handlers, y el retraso de presentación hasta pintar el siguiente frame. El INP toma la duración total de esas interacciones a lo largo de la visita y, para páginas con muchas interacciones, descarta los picos extremos para quedarse con un valor representativo del peor caso habitual. El resultado se expresa en milisegundos.
2.3 Umbrales: bueno, mejorable y deficiente
Los umbrales oficiales en 2026 son claros: un INP igual o inferior a 200 ms es «Bueno»; entre 200 y 500 ms es «Necesita mejorar»; y por encima de 500 ms es «Deficiente». Recuerda que se mide en el percentil 75, así que no basta con que vaya rápido en tu equipo: tiene que ir bien también en el móvil de gama media de tu cliente con quince pestañas abiertas.
3. LCP y CLS en 2026: los otros dos pilares
El INP acapara titulares, pero suspender LCP o CLS es igual de dañino. Estas dos métricas llevan más tiempo entre nosotros y sus umbrales se mantienen estables, lo que no significa que sean fáciles de aprobar.
3.1 LCP (Largest Contentful Paint): la sensación de carga
El LCP mide cuánto tarda en renderizarse el elemento de contenido más grande visible en la ventana: normalmente una imagen hero, un vídeo o un bloque de texto destacado. Es la métrica que responde a «¿ya ha cargado esto?» desde el punto de vista del usuario. El umbral «Bueno» es de 2,5 segundos o menos. Los grandes culpables de un LCP lento suelen ser un servidor lento (TTFB alto), imágenes sin optimizar, fuentes que bloquean el renderizado y recursos críticos que se descubren demasiado tarde.
3.2 CLS (Cumulative Layout Shift): la estabilidad visual
El CLS cuantifica cuánto «salta» el contenido de forma inesperada mientras la página carga: ese banner que empuja el texto hacia abajo justo cuando ibas a pulsar un enlace, o esa imagen sin dimensiones que desplaza medio layout. El umbral «Bueno» es de 0,1 o menos. Es la métrica más barata de arreglar y, sin embargo, una de las que más irritación genera cuando se descuida.
4. Datos de campo vs laboratorio: dónde miras importa
Uno de los errores más comunes es optimizar contra la herramienta equivocada. Lighthouse y la pestaña de laboratorio de PageSpeed Insights te dan una simulación útil para depurar, pero no deciden tu ranking. Lo que Google usa son los datos de campo del informe CrUX, que también verás en la parte superior de PageSpeed Insights y, de forma agregada, en el informe de Core Web Vitals de Google Search Console.
Para equipos que quieren ir más allá, un sistema de RUM (Real User Monitoring) permite recoger las métricas de tus usuarios en tiempo real, segmentarlas por dispositivo, país o plantilla, y detectar regresiones antes de que Google las promedie. La regla práctica: usa el laboratorio para diagnosticar y reproducir problemas, pero valida siempre con datos de campo. Si necesitas montar ese proceso de medición con rigor, es justo el tipo de trabajo que abordamos en una auditoría de rendimiento estructurada.
¿Tu web suspende los Core Web Vitals y no sabes por dónde empezar?
En Keliam auditamos tu rendimiento real, priorizamos las mejoras por impacto y las implementamos sin comprometer la estabilidad de tu plataforma. De la medición al INP en verde.
5. Cómo optimizar el INP paso a paso
Optimizar el INP es, en el fondo, un ejercicio de disciplina con el hilo principal del navegador. Todo lo que ejecuta JavaScript, calcula estilos o repinta compite por ese único hilo, y cada milisegundo que lo mantienes ocupado es un milisegundo que el usuario espera.
5.1 Divide las tareas largas y cede el hilo
Una «tarea larga» es cualquier bloque de trabajo que ocupa el hilo principal más de 50 ms. Durante ese tiempo, el navegador no puede responder a interacciones. La solución es trocear ese trabajo y ceder el hilo periódicamente para que el navegador atienda al usuario. Técnicas como scheduler.yield(), cuando está disponible, o los clásicos setTimeout y requestIdleCallback permiten insertar puntos de respiro. La idea es simple: primero responde a lo que el usuario acaba de hacer, y deja el trabajo no urgente para después del siguiente frame.
5.2 Reduce y difiere el JavaScript
La causa raíz de la mayoría de los INP deficientes es, sencillamente, demasiado JavaScript ejecutándose en el momento equivocado. Audita tus bundles, elimina dependencias que no usas, aplica code splitting para cargar solo lo necesario en cada ruta y difiere los scripts de terceros (chats, analítica, píxeles publicitarios) que no son críticos para la interacción. Cada tag de marketing que añades tiene un coste medible en capacidad de respuesta.
5.3 Optimiza los event handlers
Evita hacer trabajo pesado y síncrono dentro de un manejador de eventos. Si al pulsar un botón recalculas todo el DOM, filtras un array enorme o disparas varias peticiones bloqueantes, el INP se dispara. Separa la respuesta visual inmediata (mostrar un spinner, cambiar el estado del botón) del trabajo pesado, que puede ejecutarse después de pintar el frame o incluso en un Web Worker fuera del hilo principal.
5.4 Cuida el renderizado
Propiedades CSS como content-visibility permiten al navegador saltarse el renderizado de secciones fuera de pantalla, aligerando el trabajo en cada interacción. Vigila también los DOM excesivamente grandes: cuantos más nodos, más caro es cada recálculo de estilo y cada repintado. Menos nodos y componentes más ligeros se traducen directamente en mejor INP.
6. Optimizar LCP y CLS sin romper nada
Con el INP bajo control, el siguiente objetivo es asegurar la carga y la estabilidad. Aquí las victorias suelen ser más rápidas y con menos riesgo.
6.1 LCP: imagen, servidor y fuentes
Para mejorar el LCP, empieza por el elemento que lo provoca (PageSpeed te lo indica). Si es una imagen, sírvela en formatos modernos como WebP o AVIF, dimensiónala correctamente, aplícale fetchpriority="high" y evita el lazy-loading en el hero. Reduce el TTFB con caché de servidor y CDN, precarga las fuentes críticas con preload y usa font-display: swap para que el texto no quede invisible mientras carga la tipografía. Estas mismas palancas las detallamos aplicadas a casos concretos en nuestra guía para optimizar la velocidad de una tienda Shopify y en el repaso de rendimiento en WordPress para desarrolladores.
6.2 CLS: reserva espacio siempre
El CLS se arregla con una regla de oro: reserva el espacio antes de que el contenido llegue. Especifica siempre width y height (o aspect-ratio) en imágenes y vídeos, reserva contenedores para anuncios y embeds, y evita insertar contenido por encima del que el usuario ya está viendo. Precargar las fuentes también reduce los saltos por reflujo cuando cambia la tipografía. En catálogos grandes, como los que gestionamos en proyectos de optimización de rendimiento en Magento 2, estos detalles marcan la diferencia entre una ficha estable y una que baila con cada carga.
7. Más allá de los Core Web Vitals: qué viene
Los Core Web Vitals no son un conjunto cerrado. Google trabaja de forma continua en métricas experimentales que podrían incorporarse o complementar a las actuales. Dos líneas merecen atención en 2026. La primera es la Long Animation Frames API (LoAF), que ofrece un diagnóstico mucho más granular que las antiguas long tasks: identifica qué scripts concretos alargan cada frame y facilita depurar problemas de INP con precisión quirúrgica. La segunda son las soft navigations, un intento de medir correctamente el rendimiento en aplicaciones de tipo SPA, donde la navegación no recarga la página y las métricas tradicionales se quedan cortas.
Ninguna sustituye todavía a LCP, INP o CLS como señal de ranking, pero conviene tenerlas en el radar: quien domine el diagnóstico fino hoy llegará con ventaja el día que se conviertan en estándar.
8. Del dato al negocio: qué gana tu empresa
Es fácil perderse en los milisegundos y olvidar por qué importan. Los Core Web Vitals no son un capricho de Google: correlacionan de forma consistente con métricas de negocio. Una web que responde rápido retiene más usuarios, reduce el abandono de carrito, mejora la tasa de conversión y transmite una imagen de solvencia técnica que pesa en decisiones B2B. En rendimiento, cada 100 ms cuentan.
La otra cara es organizativa. Mantener los Core Web Vitals en verde no es un proyecto de una tarde, sino un proceso continuo: cada despliegue, cada plugin nuevo y cada campaña con sus tags puede introducir una regresión. Por eso muchas empresas se plantean si tiene sentido resolverlo con recursos internos o apoyarse en un equipo de desarrollo dedicado frente a freelancers, una decisión que depende del volumen de cambios y de la criticidad de la plataforma. Sea cual sea la vía, la clave es que alguien vigile el rendimiento de forma sistemática y no solo cuando algo se rompe.
Conclusión
Los Core Web Vitals en 2026 son un estándar consolidado y el INP se ha convertido en su métrica más exigente, porque mide lo que de verdad experimenta el usuario cada vez que interactúa. La buena noticia es que las palancas están claras: menos JavaScript en el momento equivocado, tareas troceadas que ceden el hilo, imágenes y fuentes optimizadas para el LCP, y espacio reservado para evitar saltos de CLS. La menos buena es que mantenerlo en verde exige medir con datos de campo y vigilar cada despliegue. Si abordas el rendimiento como un proceso —medir, priorizar, optimizar, verificar— en lugar de como un apagafuegos, los Core Web Vitals dejan de ser una amenaza para el SEO y se convierten en una ventaja competitiva medible.
Preguntas frecuentes
¿Cuál es un buen valor de INP en 2026?
Un INP igual o inferior a 200 milisegundos se considera «Bueno». Entre 200 y 500 ms «Necesita mejorar», y por encima de 500 ms «Deficiente». Se mide en el percentil 75 de tus usuarios reales.
¿El INP sustituyó por completo al FID?
Sí. Desde marzo de 2024 el INP es la métrica oficial de capacidad de respuesta dentro de los Core Web Vitals y el FID quedó retirado. El INP es más estricto porque evalúa todas las interacciones de la visita, no solo la primera.
¿Los Core Web Vitals afectan al posicionamiento en Google?
Sí, forman parte del sistema de experiencia de página y actúan como señal de ranking, especialmente como criterio de desempate entre páginas de contenido similar. Su mayor impacto, sin embargo, suele verse en la conversión y la retención.
¿Debo optimizar contra Lighthouse o contra los datos de campo?
Usa Lighthouse y el laboratorio para diagnosticar y reproducir problemas, pero valida siempre con los datos de campo del informe CrUX y de Search Console, que son los que Google emplea para evaluar tu web.
