Core Web Vitals y SEO: cómo mejorar el rendimiento de tu web para Google

Core Web Vitals: de métricas técnicas a factor de ranking

Desde 2021, Google usa las Core Web Vitals como señal de ranking. Esto convierte el rendimiento web de un tema puramente técnico a un factor directo de visibilidad en buscadores. Si tus Core Web Vitals son malos, estás perdiendo posiciones frente a competidores con mejor rendimiento, incluso si tu contenido es superior.

Actualización — Julio 2026: hemos revisado esta guía por completo. Las tres métricas y sus umbrales siguen vigentes (LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1), y hemos añadido herramientas actuales, recomendaciones por plataforma, errores frecuentes que vemos en auditorías y un plan de choque de 4 semanas.

Las tres métricas que importan

LCP (Largest Contentful Paint): el tiempo hasta que el elemento más grande del viewport es visible. Suele ser la imagen hero o el título principal. Objetivo: menos de 2.5 segundos. INP (Interaction to Next Paint): reemplazó a FID en 2024. Mide la latencia de las interacciones del usuario durante toda la sesión. Objetivo: menos de 200ms. CLS (Cumulative Layout Shift): cuánto se mueve el contenido mientras carga. Objetivo: menos de 0.1.

Qué ha cambiado (y qué no) desde 2024

Lo primero que conviene saber en 2026 es que las métricas y sus umbrales siguen siendo los mismos: INP sustituyó definitivamente a FID en marzo de 2024 y desde entonces el trío LCP-INP-CLS es estable. Google evalúa cada métrica al percentil 75 de las visitas reales, separando móvil y escritorio: no basta con que la web vaya bien «de media», tiene que ir bien para las tres cuartas partes de tus usuarios, incluidos los del móvil de gama media con cobertura regular.

Lo que sí ha cambiado es el contexto. Primero, el ecosistema de medición ha madurado: WebKit/Safari ha ido incorporando soporte para APIs de rendimiento que antes eran exclusivas de Chrome, lo que permite medir con RUM propio a una parte de usuarios que antes era invisible. Segundo, el peso de la experiencia de página ha crecido de forma indirecta: en la era de los resultados generados por IA, menos clics llegan a tu web, y desperdiciar los que llegan con una página lenta sale más caro que nunca. Y tercero, el JavaScript de terceros (consent managers, chats, analítica, píxeles de ads) sigue siendo el principal enemigo del INP — y no deja de crecer.

Cómo medir correctamente

Hay dos tipos de datos: datos de laboratorio (Lighthouse, PageSpeed Insights en modo local) y datos de campo (CrUX report, Search Console). Google usa los datos de campo para ranking. Puede que tu Lighthouse score sea 90, pero si tus usuarios reales (con conexiones lentas y dispositivos modestos) tienen mala experiencia, tus datos de campo serán malos.

Herramientas para medir en 2026

El kit básico no requiere presupuesto: PageSpeed Insights combina en una sola vista los datos de campo de CrUX y una auditoría Lighthouse de laboratorio; el informe de Core Web Vitals de Search Console agrupa las URLs con problemas por patrón (la vista más útil para priorizar); y la extensión Web Vitals de Chrome muestra las métricas en vivo mientras navegas. Para ir un paso más allá: el paquete web-vitals.js permite montar RUM propio enviando las métricas reales de tus usuarios a tu analítica, y Lighthouse CI integra presupuestos de rendimiento en cada despliegue. La regla de oro no cambia: el laboratorio sirve para diagnosticar y reproducir; el campo, para decidir y priorizar. Si tu web no aparece en CrUX por falta de tráfico, tu RUM propio es la única fuente de verdad de campo.

Optimizar LCP

Las causas más comunes de LCP lento: imagen hero sin optimizar (usa preload, fetchpriority=high, formatos modernos), CSS o JavaScript que bloquean el render (mueve JS al final, usa critical CSS inline), respuesta del servidor lenta (optimiza TTFB con caché, CDN, y un hosting adecuado). En el 80% de los casos, optimizar la imagen hero y el TTFB resuelve el problema de LCP.

Optimizar INP

INP mide la respuesta a las interacciones. Los problemas suelen venir de: JavaScript que bloquea el main thread (event handlers pesados, re-renders excesivos en frameworks JS), hydration lenta en SSR, y third-party scripts que compiten por el main thread. Usa Web Workers para cálculos pesados, optimiza los event handlers, y difiere la carga de scripts no esenciales.

Optimizar CLS

CLS se soluciona asegurando que cada elemento tiene dimensiones reservadas antes de cargar: atributos width/height en imágenes, min-height en contenedores de contenido dinámico, preload de fuentes con font-display:optional, y evitar insertar contenido encima del viewport después del render inicial.

El TTFB y la capa de servidor: donde empieza todo

Ninguna optimización de frontend salva a un servidor lento. El TTFB (tiempo hasta el primer byte) es el suelo sobre el que se construye el LCP: si el HTML tarda 1,2 segundos en empezar a llegar, cumplir el umbral de 2,5 segundos es casi imposible. Las palancas, por orden de impacto: caché de página completa (que la mayoría de visitas no toquen PHP ni base de datos), un hosting dimensionado para tus picos reales, CDN para servir estáticos cerca del usuario (y HTML cacheado si tu arquitectura lo permite), compresión Brotli, HTTP/2 o HTTP/3, y una base de datos sin consultas lentas. En ecommerce, además, cuidado con la trampa habitual: la home vuela porque está cacheada, pero el checkout y las páginas de cliente — que no se pueden cachear — se arrastran. Esas plantillas dinámicas son las que hay que medir y optimizar aparte.

Core Web Vitals por plataforma: WordPress, WooCommerce, Shopify, Magento y Drupal

Los principios son universales, pero cada CMS tiene sus puntos débiles típicos:

• WordPress / WooCommerce: el patrón clásico es el exceso de plugins que cargan CSS y JS en todas las páginas aunque solo se usen en una. Un plugin de optimización bien configurado (critical CSS, defer de JS) y una selección disciplinada de plugins marcan la diferencia — lo tratamos en nuestra guía de plugins imprescindibles para WooCommerce.
• Shopify: los temas modernos parten de buena base, pero las apps de terceros inyectan scripts que degradan el INP. Auditar qué apps siguen instaladas sin usarse es el primer paso; tienes la guía completa en cómo optimizar la velocidad de tu tienda Shopify.
• Magento / Adobe Commerce: plataforma potente pero pesada de frontend; en catálogos grandes, la indexación y el caching (Varnish, hole punching) son determinantes — lo desarrollamos en optimización de Magento 2 para catálogos grandes.
• Drupal: con BigPipe, caché de fragmentos y Varnish bien configurados es de lo más rápido que existe; el problema suele ser no activarlos — la receta está en rendimiento en Drupal: caché, BigPipe y Varnish.

Monitorización continua

Las Core Web Vitals cambian con cada despliegue, cada plugin nuevo y cada campaña de ads que añades. Implementa monitoring continuo: alertas de regresión en CI/CD (con Lighthouse CI), revisión mensual de datos de campo en Search Console, y pruebas de rendimiento antes de cada release mayor.

Imágenes y fuentes: los sospechosos habituales

Si hubiera que apostar dónde está el problema de LCP de una web cualquiera, las imágenes serían la apuesta segura. La lista de comprobación es concreta: servir formatos modernos (AVIF o WebP, con AVIF ganando por compresión), dimensionar cada imagen al tamaño real de render (no una foto de 2400px encogida por CSS), usar srcset para servir versiones distintas por dispositivo, cargar en diferido (loading="lazy") todo lo que está fuera del viewport inicial — y justo lo contrario para la imagen hero: fetchpriority="high" y nada de lazy loading, porque retrasar el elemento LCP es sabotearse a uno mismo.

Las fuentes web son el segundo sospechoso, con doble delito: bloquean el render (afectando al LCP) y provocan saltos de layout cuando la fuente definitiva sustituye a la del sistema (afectando al CLS). El tratamiento: alojar las fuentes en tu propio dominio en formato WOFF2, precargar solo las variantes críticas, usar font-display: swap u optional según la tolerancia al parpadeo, y ajustar la fuente de respaldo con size-adjust para que el cambio no mueva el texto. Con imágenes y fuentes bajo control, una parte sorprendente del trabajo ya está hecha.

Rendimiento y conversión: el caso de negocio

Aunque el SEO sea la puerta de entrada a este tema, el argumento más sólido para invertir en rendimiento es la conversión. La correlación está documentada desde hace años y es intuitiva: cada segundo de espera en un móvil multiplica los abandonos, y la fricción en el checkout — la parte más dinámica y menos cacheada de una tienda — se paga directamente en carritos abandonados. Por eso recomendamos tratar las Core Web Vitals como un indicador de negocio, no solo técnico: junto al dato de LCP conviene mirar la tasa de rebote y la conversión por plantilla. Cuando la mejora de rendimiento se presenta como «el checkout convierte un 8% más», la conversación con dirección cambia de tono. Un presupuesto de rendimiento (por ejemplo: máximo 200 KB de JavaScript por página, LCP bajo 2 segundos en producto) convierte esa intención en una regla verificable en cada despliegue.

SPAs, frameworks JavaScript y el caso especial del INP

Las webs construidas como single page application (React, Vue, Angular) tienen una relación complicada con las Core Web Vitals. La primera carga suele ser su punto débil: el HTML llega casi vacío y el usuario espera a que el JavaScript descargue, parsee y ejecute antes de ver nada — un LCP castigado de serie. Las soluciones pasan por renderizado en servidor (SSR) o generación estática, hidratación parcial o diferida, y división agresiva del código para que cada ruta cargue solo lo suyo.

El INP merece atención especial: una hidratación pesada deja el hilo principal ocupado justo cuando el usuario empieza a interactuar, y los re-renders en cascada convierten cada clic en una espera. Trocear las tareas largas (con scheduler.yield o similares), memoizar componentes caros y mover cálculos a Web Workers son las herramientas del oficio. Y una advertencia de medición: las navegaciones internas de una SPA («soft navigations») no generan una carga de página tradicional, así que las métricas de campo atribuyen toda la sesión a la URL de entrada — conviene tenerlo en cuenta al interpretar los datos de CrUX en este tipo de webs.

La lección de fondo: elegir framework también es una decisión de rendimiento. Para una web de contenido o un catálogo, un CMS bien cacheado rinde de maravilla sin un solo framework de frontend; reserva la complejidad de una SPA para las aplicaciones que de verdad la necesitan.

Un último apunte sobre WordPress y las SPAs a medias: muchos page builders y themes «modernos» cargan frameworks completos para animar un menú. Si tu web de contenido arrastra cientos de kilobytes de JavaScript sin ser una aplicación, la optimización más rentable no es técnica sino de criterio: eliminar lo que no aporta. En nuestras auditorías, la pregunta «¿qué hace este script y quién lo necesita?» ha mejorado más INPs que cualquier microoptimización de código. El rendimiento sostenible nace de una arquitectura frugal: cada dependencia que entra en la página debe justificar su coste en milisegundos, no solo su funcionalidad.

Errores comunes que vemos en auditorías

Tras años auditando webs y tiendas online, los mismos fallos aparecen una y otra vez: optimizar solo la home cuando el 80% del tráfico SEO entra por fichas de producto o artículos; fiarse del Lighthouse local (con tu portátil y tu fibra) e ignorar los datos de campo; cargar todos los scripts de marketing en todas las páginas, incluido el checkout; instalar un plugin de optimización sin configurarlo — o con dos que se pisan entre sí —; y no volver a medir tras cada cambio, con lo que las regresiones pasan inadvertidas durante meses. El rendimiento no es un proyecto puntual: es una disciplina que forma parte del SEO técnico, como explicamos en nuestra guía de auditoría SEO y en la de SEO técnico para ecommerce.

Plan de choque: 4 semanas para mejorar tus Core Web Vitals

Si tus métricas están en rojo, esta es la secuencia que aplicamos en proyectos reales: la semana 1 se dedica al diagnóstico con datos de campo (CrUX y Search Console) y a priorizar las plantillas con más tráfico; la semana 2, al LCP (imagen hero, critical CSS, caché y CDN); la semana 3, al INP y al CLS (JavaScript de terceros, tareas largas, espacios reservados); y la semana 4, a consolidar con monitorización para que la mejora no se evapore con el siguiente despliegue.

Preguntas frecuentes

¿Cuánto afectan las Core Web Vitals al posicionamiento?

Son un factor de desempate, no el principal: el contenido relevante sigue mandando. Pero en nichos competitivos, donde varios resultados responden igual de bien a la búsqueda, la experiencia de página inclina la balanza. Y su efecto indirecto es mayor: una web rápida convierte más y retiene mejor, se posicione donde se posicione.

¿Por qué PageSpeed me da 90 y Search Console me marca URLs «pobres»?

Porque son datos distintos: la nota de PageSpeed es una prueba de laboratorio en condiciones simuladas, y Search Console refleja los datos de campo de tus usuarios reales durante 28 días. Google usa los segundos. Si divergen, manda el campo — y la explicación suele estar en dispositivos y conexiones peores que las simuladas.

¿Cuál es la métrica más difícil de arreglar?

Hoy, el INP. El LCP y el CLS se resuelven con técnicas bien conocidas; el INP exige revisar el JavaScript de la página — especialmente el de terceros — y eso a menudo implica decisiones de negocio (¿de verdad necesitamos ese widget?), no solo técnicas.

¿Cada cuánto debo revisar las métricas?

Los datos de campo, una vez al mes como mínimo, y siempre tras cambios relevantes: nuevo plugin, rediseño, campaña con nuevos píxeles. Idealmente, con Lighthouse CI en el pipeline de despliegue para cazar las regresiones antes de que lleguen a producción.

¿Esto lo arreglo yo o necesito ayuda externa?

Depende del diagnóstico: comprimir imágenes y configurar caché está al alcance de cualquier equipo; los problemas de INP en JavaScript, la caché de página en ecommerce dinámico o un TTFB alto de origen suelen requerir perfil técnico. Una auditoría corta que identifique el 20% de causas que genera el 80% del problema evita meses de prueba y error.

Conclusión

Las Core Web Vitals llevan desde 2021 dejando claro que el rendimiento es parte del SEO, y en 2026 la conclusión se ha reforzado: los umbrales son estables, las herramientas son maduras y ya no hay excusa para no medir con datos reales. La receta es la misma para casi todos: arregla el LCP con la imagen hero y el servidor, doma el INP recortando JavaScript de terceros, elimina el CLS reservando espacios, y protege lo ganado con monitorización continua. Es trabajo metódico, no magia — y es de las inversiones técnicas con mejor retorno en visibilidad y conversión.