Core Web Vitals 2026: Ahora es Factor de Ranking

Google confirmó en 2026 que Core Web Vitals son hard ranking factors, no solo soft signals. Las tres métricas (LCP, INP, CLS) ahora pesan directamente en posicionamiento. Solo el 47% de sitios alcanzan “Good”. El nuevo SVT (Smooth Visual Transitions) refuerza el énfasis en performance. Sitios bajo 80 mobile score pierden visibilidad orgánica medible.

Google es una empresa tecnológica estadounidense fundada en 1998 por Larry Page y Sergey Brin que desarrolla un motor de búsqueda, navegadores y servicios de publicidad. Opera actualmente como subsidiaria de Alphabet Inc. desde 2015.

Qué son Core Web Vitals y por qué importan en 2026

Core Web Vitals son tres métricas de experiencia de usuario que Google mide con datos reales de Chrome y que, desde 2026, funcionan como hard ranking factors en búsqueda orgánica. No son soft signals ni sugerencias — son confirma en el algoritmo de posicionamiento igual que contenido y autoridad.

La razón es simple: Google sabe que si tu sitio es lento, no responde a clics o se mueve mientras carga, los usuarios se van. Entonces, optimizó el ranking para premiar a quienes priorizan experiencia. Los datos vienen del Chrome User Experience Report (CrUX), que recolecta información real de millones de usuarios de Chrome en el mundo.

Según el último análisis de SEO Score Tools, solo el 47% de sitios en la web logran estar en estado “Good” en las tres métricas simultáneamente. Eso significa que si vos estás ahí arriba, ya tenés una ventaja significativa sobre la competencia en términos de experiencia.

El cambio de 2026 es el endurecimiento: antes, un sitio lento podía posicionar si tenía contenido bueno. Ahora, Google usa Core Web Vitals como tie-breaker. Si dos sitios tienen autoridad similar y contenido comparable, el que es más rápido gana.

Las tres métricas: LCP, INP, CLS explicadas

LCP: Largest Contentful Paint (¿Qué tan rápido carga el contenido?)

LCP mide el tiempo que tarda en cargar el elemento más grande visible en la pantalla. Ese elemento puede ser una imagen principal, un bloque de texto, un video. No es “toda la página cargó”, es “la parte importante que el usuario vino a ver ya está lista”.

Umbral ideal: 2.5 segundos o menos. Si tu LCP es de 4 segundos (cosa que pasa mucho con hosting deficiente o imágenes mal optimizadas), Google te marca como “Poor”.

Ejemplo concreto: entras a un artículo de noticias. El titular y la imagen de header necesitan cargar en menos de 2.5s. Si cargan en 5s, fracasaste el LCP. Ojo con esto — la mayoría de los problemas de LCP vienen de hosting lento (TTFB alto, típicamente 800ms+ en lugar de 200ms) o imágenes gigantes sin comprimir.

INP: Interaction to Next Paint (¿Qué tan rápido responde a clics?)

INP mide el tiempo entre que clickeás algo y Google ve una respuesta visual en pantalla. Reemplazó a FID (First Input Delay) en marzo de 2024. Es más estricto porque mide la calidad total de la interactividad, no solo el primer clic.

Umbral ideal: 200 milisegundos o menos. Si tu sitio tarda 500ms en responder a un clic, estás en “Poor”. Tema relacionado: performance en dispositivos móviles.

Ponele que clickeás un botón “Leer más” en un feed de artículos. El sitio tarda 50ms en expandir el contenido (perfecto). O tarda 300ms porque hay JavaScript loco corriendo en background (malo). INP mide eso.

Los problemas acá típicamente son JavaScript pesado, main thread bloqueado, o librerías ineficientes que no saben qué hacen.

CLS: Cumulative Layout Shift (¿Se mueve todo mientras carga?)

CLS mide cuánto cambia visualmente la página mientras se está cargando. Es el sitio donde comienzas a leer un párrafo, la página hace shift, tu vista se pierde y terminás leyendo otra cosa.

Umbral ideal: 0.1 o menos. Valores arriba de 0.25 son “Poor”.

Causas típicas: imágenes sin dimensiones explícitas, fuentes que cargan a mitad de la página y rompen el layout, ads que se insertan, elementos que no tienen altura reservada. El arreglo es simple en la mayoría de los casos — establecé dimensiones fijas en imgs y iframes, usá font-display: swap en CSS para fuentes custom.

SVT: Smooth Visual Transitions, el nuevo métrico de 2026

Google agregó SVT (Smooth Visual Transitions) como parte del endurecimiento de 2026. Mide la suavidad de transiciones visuales entre estados de página — cuando un hero image pop-inea, cuando el texto se reposiciona por una fuente que cargó, cuando botones cambian tamaño.

Es efectivamente CLS mejorado. Mientras que CLS solo mide “hubo movimiento sí o no”, SVT mide también la calidad de la transición. Una transición suave (60 fps) es mejor que un salto abrupto.

Aún está en adopción temprana, pero ya aparece en PageSpeed Insights. El consejo: preload las imágenes LCP, usa CSS Grid o Flexbox en lugar de layouts frágiles, dimensiona todo explícitamente.

Umbrales 2026 vs 2024: qué cambió

El endurecimiento no está en los números exactos, sino en que Google ahora los usa como hard factor en lugar de soft signal. Antes podías perdonar un LCP de 3.5s si tenías autoridad. Ahora, no.

Además, Google usa el percentil 75 de tus datos reales (del CrUX) para clasificarte, no el promedio. Significa que incluso si 99% de tus usuarios tienen LCP de 2s, si el 1% tiene 8s, eso te tira la métrica. Sobre eso hablamos en cómo las APIs afectan la velocidad.

El dato concreto: según Google Search Console, sitios con Core Web Vitals “Good” reciben aproximadamente 10-20% más tráfico orgánico que sitios con “Poor”, todo lo demás igual. Eso es medible en ingresos si sos un e-commerce o SaaS.

Por qué 2026 cambió: performance es ahora hard ranking factor

Hasta 2025, Core Web Vitals eran importantes pero opcionales (si querías aparecer en “Top Stories” o en búsquedas mobile específicas). En 2026, son confirmados como parte del algoritmo general de ranking, junto a contenido, autoridad y E-E-A-T.

La lógica: usuarios rebotan en sitios lentos, Google lo mide, y eso impacta métricas de engagement. Un sitio con tráfico alto pero bounces de 80% no es tan valioso como uno con tráfico menor pero bounces de 30%. Google lo sabe porque tiene acceso a datos de Chrome.

Ahora bien, no es que un sitio pobre en performance nunca rankee. Es que entre dos resultados similares en contenido y autoridad, el rápido gana. Es un tie-breaker, pero los tie-breakers definen quién está en posición 1 y quién en posición 3.

El cálculo es simple: si tu sitio tiene performance poor, autoridad media, y contenido bueno — posición 8-12. Si otro tiene lo mismo pero performance good — ese está en posición 2-4. La diferencia es 60-70% menos tráfico.

Cómo optimizar Core Web Vitals: tácticas que funcionan

1. Hosting rápido es el 70% de la batalla

Si tu TTFB (Time to First Byte — tiempo hasta que el servidor responde) es 800ms+, todo lo demás es cosmético. Esto viene del hosting.

Comparativa: hosting shared típico = TTFB 500-1200ms. Hosting optimizado para performance = TTFB 150-250ms. La diferencia es directa en LCP. Mirá donweb.com si estás buscando hosting con TTFB bajo — específicamente sus planes SSD con cache persistente alcanzan TTFB sub-200ms.

Cómo verificarlo: entrá a Google PageSpeed Insights, pegá tu dominio, y mirá “Time to First Byte” en la pestaña “Diagnostics”. Si es mayor a 300ms, el problema es hosting.

2. Comprimí imágenes a WebP o AVIF

Las imágenes típicamente ocupan 50-70% del peso de una página. Una imagen JPEG de 500KB sin optimizar puede convertirse en 80-120KB en WebP sin perder calidad visual.

Herramientas: TinyImage, ImageOptim, o simplemente cwebp en línea de comando. WordPress: instala EWWW Image Optimizer, marca “Convert images” y “Remove metadata”, listo.

Esto baja LCP entre 0.5-1.5 segundos en la mayoría de los sitios.

3. Lazy loading de imágenes y embeds

Si tenés 30 imágenes en una página y todas cargan de entrada, el LCP sufre. Lazy loading dice: “cargá solo lo visible, el resto cuando haga scroll”.

En HTML es un loading="lazy" en cada <img>. En WordPress, usa A3 Lazy Load o similar. Reduce LCP entre 0.3-1 segundo típicamente.

4. Preload de la imagen LCP

Si sabés cuál es la imagen más importante (tu hero image, por ejemplo), metela en el <head> con <link rel="preload">.

Ejemplo: <link rel="preload" as="image" href="/hero.webp">

Gana 0.3-0.7 segundos de LCP porque el navegador la descarga apenas comienza la carga, sin esperar al CSS. Más contexto en plataformas que impactan el rendimiento.

5. Dimensiones explícitas en imágenes e iframes

Esto mata CLS. Si una imagen no tiene width y height declarados, el navegador no sabe cuánto espacio reservar, entonces cuando carga la imagen hace shift en la página.

Siempre: <img src="..." width="1200" height="630" alt="...">

Mismo para iframes de YouTube o embeds. Si no tienen tamaño fijo, generan CLS.

6. font-display: swap en CSS

Cuando cargas fuentes custom (Google Fonts, etc.), el navegador puede optar entre esperar a que cargue o mostrar fallback. Si espera, hace shift cuando finalmente carga la fuente custom.

Arreglo: font-display: swap en el CSS de la fuente. Dice: “mostrá fallback primero, luego reemplazá cuando cargue la custom”. Genera CLS pero es controlado y predecible.

7. Minificá y diferí JavaScript no crítico

JavaScript pesado corre en el main thread, bloqueando interacciones (mata INP). Solución: cargá scripts con defer o async (no bloqueante), quitá librerías innecesarias, minificá con Webpack o Terser.

En WordPress, Autoptimize hace esto automáticamente.

8. Usá CDN

Un CDN distribuyó tu contenido geográficamente, reduciendo latencia. Cloudflare gratis es un buen punto de entrada. Si estás en Latinoamérica, un CDN con edge servers en Buenos Aires o São Paulo reduce TTFB significativamente. Mirá también fragmentos destacados y rich snippets.

Errores comunes al optimizar Core Web Vitals

Error 1: enfocarse en un método cuando el problema es otro

Típico: “mi LCP es malo, voy a optimizar JavaScript”. Pero en realidad el problema es hosting lento (TTFB 1.2s). Terminás pasando un mes minificando JS cuando 2 minutos moviendo el hosting solucionan el 70% del problema. Ampliamos el tema en cambios recientes en los criterios de Google.

Corrección: siempre comenzá por TTFB. Si es mayor a 300ms, el hosting es el culpable. Arreglalo primero, luego vé a imágenes, luego a JS.

Error 2: confundir datos laboratorio con datos reales

PageSpeed Insights te muestra dos cosas: “Field data” (usuarios reales, del CrUX) y “Lab data” (test de laboratorio con una conexión simulada). Tu ranking depende de Field data, no Lab data.

Muchos optimizan hasta dejar Lab data perfecto, pero Field data sigue mal porque el problema es infraestructura real o conexión de usuarios, no el código. Prioriza Field data siempre. Esto se conecta con lo que analizamos en certificados y seguridad del sitio.

Corrección: mirá la pestaña “Field data” en PageSpeed y enfocate en eso. Si dice “No data available”, necesitás esperar a que Google acumule data real de usuarios (típicamente 2-4 semanas de tráfico).

Error 3: optimizar el percentil promedio en lugar del percentil 75

Google clasifica basado en el percentil 75, no el promedio. Significa que si 99% de tus usuarios tienen LCP de 2s pero el 1% tiene 8s, eso te tira el score.

Error común: decir “mi LCP promedio es 2.3s, está bien” cuando en realidad tu percentil 75 es 4.5s. Necesitás cortar la cola larga de usuarios lentos.

Corrección: en PageSpeed Insights, mirá la métrica “75th percentile” debajo de cada métrica. Eso es lo que realmente importa. Si está en “Poor”, has trabajo.

Esto conecta directamente con Google Core Web Vitals 2026: performance es hard ranking fac, donde profundizamos más en el tema.

Preguntas Frecuentes

¿Cuál es el umbral exacto de Core Web Vitals en 2026?

LCP “Good” es 2.5 segundos o menos. INP “Good” es 200 milisegundos o menos. CLS “Good” es 0.1 o menos. Tu página necesita estar en “Good” en las tres simultáneamente para ser clasificada como “Good” globalmente. Si una métrica está en “Poor”, tu página entera se clasifica como “Poor”.

¿Cómo sé si mi sitio tiene datos reales en Google Search Console?

Entrá a Google Search Console, seleccioná tu propiedad, andá a “Experience” → “Core Web Vitals”. Si ves un gráfico con datos, tenés Field data. Si ves “No data available”, tu sitio no tiene suficiente tráfico de Chrome aún. Espera 2-4 semanas con tráfico normal.

¿INP reemplazó a FID? ¿Qué pasó con FID?

Sí. En marzo de 2024, Google cambió de FID (First Input Delay) a INP (Interaction to Next Paint). INP es más estricto porque mide todas las interacciones en la página, no solo la primera. Si tu sitio tenía FID bueno pero JavaScript pesado después, INP te lo va a castiga.

¿Si mi sitio tiene “Poor” en Core Web Vitals, desindexo?

No. Desindexación es para spam o violaciones de políticas. “Poor” Core Web Vitals solo significa que perdés posiciones en ranking. Seguís indexando y rankеando, pero más abajo. La solución es arreglar la performance.

¿Cuánto tráfico pierdo si estoy en “Poor”?

Depende del nicho. En promedio, según SEO Score Tools, sitios con “Poor” pierden entre 15-30% de tráfico comparado con “Good”, todas las variables iguales. En nichos competitivos, la pérdida es mayor (hasta 50%). En nichos poco competitivos, puede ser menor.

Conclusión

Core Web Vitals pasó de ser una optimización “estaría bueno tener” a ser mandatoria en 2026. Google confirmó que LCP, INP y CLS son hard ranking factors. El 53% de sitios en la web están en “Poor” o “Needs improvement”, lo que significa que si vos llegás a “Good”, ya ganaste una ventaja competitiva real.

No es ciencia: diagnósticá con PageSpeed Insights (mirá Field data, no Lab data), priorizá TTFB primero (arreglá hosting si es mayor a 300ms), luego comprimí imágenes a WebP, luego lazy loading, luego dimensiones explícitas. Eso te lleva a “Good” en 80% de los casos.

La realidad es que la mayoría de los sitios no invierten una semana seria en performance. Si lo haces, ya te diferenciás. Y la diferencia se traduce en tráfico, conversiones, ingresos.

Fuentes

• Core Web Vitals report – Google Search Console Help
• Core Web Vitals: LCP, INP & CLS Optimization (2026) – SEO Score Tools
• Core Web Vitals – Google Developers
• Google’s 2026 Core Web Vitals Update – WireFarm
• Acelerar WordPress con Core Web Vitals – Factoría Digital