En un test A/B de Vodafone Italia con dos paginas visual y funcionalmente identicas, mejorar el LCP un 31% basto para generar un 8% mas de ventas, segun el caso de estudio oficial de web.dev. No es un detalle tecnico para tu equipo de desarrollo: es una variable directa de ingresos. Los Core Web Vitals miden con precision esa experiencia que decide, en los primeros segundos, si un visitante compra, contacta o se va a la competencia.
Si gestionas el sitio de una empresa B2B, esto te concierne tanto como a un e-commerce. Un formulario de contacto que tarda en responder, un hero que salta mientras carga o una pagina lenta en movil son fugas silenciosas de conversion. En esta guia veras que son exactamente los Core Web Vitals, que umbrales exige Google en 2026, como medirlos con datos fiables y como optimizar cada metrica paso a paso.
Que son los Core Web Vitals y por que importan para el SEO en 2026
Los Core Web Vitals son un subconjunto de las metricas de experiencia de pagina que Google considera esenciales para evaluar la experiencia real del usuario en cualquier sitio web. No miden si una pagina "se ve bonita", sino tres dimensiones medibles de su comportamiento: cuanto tarda en mostrar el contenido principal, como responde a la interaccion del usuario y cuanto se mueve el diseno mientras carga.
En 2026 son tres metricas:
- LCP (Largest Contentful Paint) — velocidad de carga del elemento mas grande visible.
- INP (Interaction to Next Paint) — capacidad de respuesta a las interacciones.
- CLS (Cumulative Layout Shift) — estabilidad visual del diseno.
Importan para el SEO porque forman parte de las senales de experiencia de pagina que Google evalua. Pero importan aun mas para el negocio. Google ha documentado resultados como los de iCook, que aumento un 10% sus ingresos publicitarios al mejorar el CLS un 15%; Tokopedia, con un 23% mas de duracion media de sesion tras reducir el LCP un 55%; o Nykaa, que logro un 28% mas de trafico organico al mejorar el LCP un 40%. Son cifras del propio repositorio de casos de estudio de web.dev, no estimaciones de agencia.
La conclusion practica: optimizar Core Web Vitals no es "trabajo de fontaneria" que solo agrada a Google. Es una palanca de conversion, retencion y, en ultima instancia, de pipeline comercial.
LCP, INP y CLS: umbrales recomendados por Google
Google no usa una escala continua: clasifica cada metrica en tres categorias —"buena", "necesita mejorar" y "pobre"— a partir de umbrales fijos. Para aprobar, tu objetivo es siempre la categoria "buena". Estos son los valores oficiales segun la documentacion de web.dev sobre definicion de umbrales de Core Web Vitals:
| Metrica | Que mide | Bueno | Necesita mejorar | Pobre |
|---|---|---|---|---|
| LCP | Velocidad de carga del contenido principal | <= 2,5 s | 2,5 s – 4,0 s | > 4,0 s |
| INP | Capacidad de respuesta a interacciones | <= 200 ms | 200 ms – 500 ms | > 500 ms |
| CLS | Estabilidad visual (movimiento del diseno) | <= 0,1 | 0,1 – 0,25 | > 0,25 |
Hay un matiz que cambia por completo como interpretar tus informes: Google evalua estos umbrales en el percentil 75 de las visitas reales. Es decir, para que una URL apruebe una metrica, al menos el 75% de las paginas vistas debe alcanzar el umbral "bueno". Esto significa que no basta con que la pagina sea rapida en tu portatil de gama alta con fibra: tiene que serlo tambien para el cuarto usuario mas lento de cada cuatro, normalmente alguien con un movil modesto y una conexion movil irregular.
Por eso una pagina puede "sentirse rapida" cuando la pruebas tu y aun asi suspender Core Web Vitals. El percentil 75 obliga a disenar pensando en el peor escenario razonable, no en el mejor.
Por que INP sustituyo a FID en marzo de 2024
Durante anos, la metrica de respuesta fue FID (First Input Delay), que solo medias el retardo de la primera interaccion del usuario y, ademas, unicamente la demora hasta que el navegador empezaba a procesarla. Era una metrica generosa: la mayoria de sitios la aprobaban con facilidad, lo que la hacia poco util para distinguir experiencias realmente fluidas de las que no lo eran.
INP (Interaction to Next Paint) sustituyo oficialmente a FID como Core Web Vital de respuesta el 12 de marzo de 2024, tras anunciarse el 31 de enero de ese mismo ano, segun el blog de web.dev. La diferencia es sustancial:
- FID medias solo la primera interaccion; INP observa todas las interacciones de la sesion y reporta (aproximadamente) la peor.
- FID medias solo el retardo de entrada; INP mide el ciclo completo, hasta que el siguiente fotograma (next paint) refleja visualmente la respuesta.
En la practica, INP es mucho mas exigente y mucho mas representativo de como percibe el usuario la agilidad de tu sitio. Una pagina que abria menus con lentitud, validaba formularios con retraso o reaccionaba tarde a los clics —cosas invisibles para FID— ahora queda expuesta. Para sitios B2B con formularios largos, filtros de producto o configuradores, este cambio fue especialmente relevante.
Como medir tus Core Web Vitals: PageSpeed Insights, CrUX y Search Console
Aqui esta el error mas comun y mas caro: confundir datos de laboratorio con datos de campo. No son lo mismo y solo uno de ellos cuenta para el ranking.
Datos de campo vs. datos de laboratorio
- Datos de campo (field data): mediciones de usuarios reales que visitan tu sitio, recogidas a traves del Chrome User Experience Report (CrUX). Es un promedio movil de 28 dias.
- Datos de laboratorio (lab data): una simulacion controlada en un entorno fijo, generada por Lighthouse.
Segun la documentacion de web.dev sobre por que difieren los datos de laboratorio y de campo, para el ranking Google usa unicamente los datos de campo de CrUX, no los de laboratorio de Lighthouse. Estos ultimos sirven para diagnostico: te dicen por que algo va mal, pero no son la nota que cuenta. Por eso es perfectamente posible obtener un 100 en Lighthouse y aun asi suspender Core Web Vitals en CrUX si tus usuarios reales tienen una experiencia peor que la del entorno simulado.
Que herramienta usar para que
| Herramienta | Tipo de dato | Granularidad | Mejor uso |
|---|---|---|---|
| PageSpeed Insights | Campo (CrUX) + laboratorio (Lighthouse) | URL individual; CrUX actualizado a diario | Diagnostico de una pagina concreta |
| Google Search Console | Solo campo (CrUX) | Agregado por grupos de URL | Vision de salud del sitio y URLs problematicas |
| Lighthouse / DevTools | Solo laboratorio | URL individual, ejecucion puntual | Depurar y probar mejoras antes de desplegar |
Segun la documentacion de Google for Developers sobre PageSpeed Insights, la herramienta muestra tanto datos de campo de CrUX (actualizados a diario a nivel de URL) como datos de laboratorio de Lighthouse. Google Search Console, en cambio, reporta exclusivamente datos de campo de CrUX agregados por grupos de URL, lo que la convierte en el panel ideal para detectar a escala que plantillas o secciones de tu sitio fallan.
El flujo de trabajo recomendado:
- Search Console para identificar que grupos de URL suspenden.
- PageSpeed Insights para diagnosticar por que falla una URL representativa.
- Lighthouse / DevTools para iterar las correcciones en local.
- Desplegar y esperar a que el promedio movil de 28 dias de CrUX recoja la mejora.
Ese ultimo punto es clave: como CrUX es un promedio de 28 dias, una correccion no se refleja al instante. Hay que tener paciencia y no revertir cambios buenos por impaciencia.
Como optimizar cada metrica paso a paso
Cada Core Web Vital tiene causas distintas y, por tanto, soluciones distintas. Esta es una checklist priorizada por impacto tipico.
Optimizar el LCP (<= 2,5 s)
El LCP suele estar limitado por el tiempo que tarda en cargar y renderizarse el elemento principal (normalmente una imagen hero, un bloque de texto grande o un video).
- Sirve la imagen LCP con prioridad (
fetchpriority="high") y evita el lazy-loading en ese elemento concreto. - Optimiza el formato de imagen (AVIF o WebP) y dimensiona correctamente para cada breakpoint.
- Precarga los recursos criticos (fuentes, imagen hero) y elimina recursos que bloqueen el renderizado.
- Reduce el tiempo de respuesta del servidor (TTFB) con cache, CDN y rendering eficiente.
- Minimiza el CSS y el JavaScript criticos que retrasan la primera pintura.
Optimizar el INP (<= 200 ms)
El INP casi siempre se rompe por JavaScript que bloquea el hilo principal cuando el usuario interactua.
- Divide las tareas largas (long tasks) en fragmentos mas pequenos para no bloquear el hilo.
- Aplaza o elimina JavaScript de terceros no esencial (chats, widgets, tags de marketing pesados).
- Usa
content-visibilityy renderizado diferido para contenido fuera de pantalla. - Evita re-renders innecesarios en frameworks como React optimizando estado y memoizacion.
- Da feedback visual inmediato a la interaccion aunque el procesamiento continue de fondo.
Optimizar el CLS (<= 0,1)
El CLS es el mas "barato" de arreglar y el que mas molesta al usuario: elementos que saltan justo cuando va a pulsar.
- Reserva espacio para imagenes y videos con atributos
widthyheightoaspect-ratio. - Reserva hueco para anuncios y embeds antes de que carguen.
- Precarga fuentes y usa
font-display: optionaloswappara evitar reflows de texto. - Nunca insertes contenido por encima del existente salvo respuesta directa a una accion del usuario.
- Anima con
transform, no con propiedades que provoquen recalculo del layout.
Este tipo de trabajo —medicion con datos de campo, presupuestos de rendimiento y correcciones priorizadas— es exactamente lo que abordamos en un proyecto de SEO tecnico bien gobernado, donde el rendimiento deja de ser una incidencia puntual para convertirse en un estandar de calidad continuo. Y cuando el problema esta en la base del codigo, lo resolvemos en la capa de desarrollo web, interviniendo en la arquitectura del front-end, el rendering y la entrega de recursos.
Influyen realmente los Core Web Vitals en el posicionamiento?
Es la pregunta del millon, y la respuesta honesta tiene dos partes.
Si, son una senal de ranking, pero no la mas importante. Segun la documentacion de Google Search Central sobre Core Web Vitals, Google confirma que la experiencia de pagina —incluidos los Core Web Vitals— es una de las muchas senales que su sistema valora. En la misma fuente, Google recuerda de forma explicita que un gran contenido sigue siendo prioritario sobre la experiencia de pagina.
Como traducir esto a una estrategia realista:
Los Core Web Vitals no van a posicionar contenido mediocre por encima de contenido excelente. Pero cuando dos paginas compiten con contenido de calidad comparable, la experiencia de pagina puede ser el factor que incline la balanza —y, sobre todo, el que determine si el visitante que llega se queda y convierte.
Por eso el enfoque correcto no es perseguir un 100 en Lighthouse como fin en si mismo, sino:
- Asegurar primero un contenido valioso que responda a la intencion de busqueda.
- Aprobar Core Web Vitals en el percentil 75 de usuarios reales como estandar de calidad no negociable.
- Tratar el rendimiento como variable de negocio, no solo de SEO, por su impacto demostrado en conversion y retencion.
El mayor riesgo no es quedarse a unas decimas del umbral: es ignorar por completo los datos de campo y descubrir, mes tras mes, por que los usuarios abandonan sin que los datos de laboratorio expliquen nada.
Quieres saber donde pierde rendimiento tu sitio y cuanto te esta costando en conversion? En Technova Partners auditamos tus Core Web Vitals con datos de campo reales, priorizamos las correcciones por impacto y las implementamos hasta aprobar en el percentil 75. Habla con nuestro equipo y convierte el rendimiento web en una ventaja medible frente a tu competencia.
