Core Web Vitals: La guía completa de optimización para SEO (2026)

Los Core Web Vitals (CWV) son un conjunto de tres métricas específicas de rendimiento de página que Google utiliza como señal de ranking confirmada para evaluar la experiencia real del usuario en tu sitio web. Introducidos en 2020 y actualizados con INP reemplazando a FID en marzo de 2024, los Core Web Vitals miden la rapidez con la que tu página carga su contenido principal (LCP), la velocidad con la que responde a las interacciones del usuario (INP) y la estabilidad visual que mantiene durante la carga (CLS). Juntas, estas tres métricas determinan si tu página ofrece el tipo de experiencia que los usuarios — y Google — esperan.

En 2026, los Core Web Vitals ya no son opcionales. Son un componente confirmado del sistema de ranking de experiencia de página de Google, y influyen directamente en si tus páginas superan a competidores con calidad de contenido y autoridad similares. Más importante aún, afectan la experiencia de cada visitante en tu sitio. Una página que carga lentamente, responde con lentitud a los clics o desplaza el contenido mientras se carga ahuyenta a los usuarios — y Google lo sabe, porque mide estos comportamientos exactos de usuarios reales de Chrome en todo el mundo a través del Chrome User Experience Report (CrUX).

Esta guía cubre todo lo que necesitas saber sobre los Core Web Vitals en 2026: qué mide cada métrica, por qué importa para el SEO y la búsqueda con IA, cómo diagnosticar problemas y exactamente cómo solucionarlos. Ya seas desarrollador, profesional de SEO o propietario de un sitio web, encontrarás estrategias accionables con ejemplos de código reales, comparaciones antes/después y un flujo de trabajo de optimización claro que puedes implementar hoy mismo.

¿Qué son los Core Web Vitals?

Los Core Web Vitals son tres métricas de rendimiento centradas en el usuario que Google ha identificado como los indicadores más importantes de la calidad de experiencia de página. A diferencia de las métricas de rendimiento tradicionales que se centran en mediciones técnicas (tiempo de búsqueda DNS, tiempo hasta el primer byte), los Core Web Vitals se centran en lo que los usuarios realmente experimentan: ¿qué tan rápido parece cargar la página? ¿Con qué rapidez responde cuando hago clic en algo? ¿El diseño se mueve mientras intento leer o interactuar?

Google introdujo los Core Web Vitals en mayo de 2020 como parte de una iniciativa más amplia para estandarizar la medición de la experiencia de página. Las tres métricas originales eran LCP (Largest Contentful Paint), FID (First Input Delay) y CLS (Cumulative Layout Shift). En marzo de 2024, Google reemplazó FID con INP (Interaction to Next Paint) porque INP proporciona una medida más completa de la capacidad de respuesta que captura todo el ciclo de vida de la interacción, no solo el retraso inicial de entrada.

Lo clave que debes entender sobre los Core Web Vitals es que se miden usando datos de usuarios reales, no simulaciones de laboratorio. Google recopila datos de rendimiento de millones de usuarios de Chrome que participan en el Chrome User Experience Report (CrUX), y utiliza el percentil 75 de estos datos de campo para evaluar si una página aprueba o no cada métrica. Esto significa que no puedes manipular los Core Web Vitals optimizando solo para pruebas de laboratorio — la experiencia real de tus visitantes en el mundo real es lo que cuenta.

Umbrales de CWV de un vistazo

*TTFB no es un Core Web Vital, pero es una métrica de diagnóstico crítica que afecta directamente al LCP. Un TTFB lento hace que sea casi imposible alcanzar una buena puntuación de LCP.

LCP: Largest Contentful Paint

Largest Contentful Paint (LCP) mide el tiempo que tarda el elemento de contenido visible más grande en la ventana gráfica en terminar de renderizarse. Esto es típicamente una imagen hero, un bloque de texto grande, un póster de vídeo o una imagen de fondo. LCP responde a la pregunta fundamental del usuario: "¿Se ha cargado ya el contenido principal?" Un buen LCP es de 2,5 segundos o menos.

LCP es a menudo el Core Web Vital más difícil de optimizar porque depende de toda la cadena de entrega: tiempo de respuesta del servidor (TTFB), descubrimiento de recursos, descarga de recursos y renderizado. Cada milisegundo añadido en cualquier punto de esta cadena aumenta directamente tu LCP. Por eso la optimización de LCP requiere un enfoque holístico — solucionar un solo cuello de botella rara vez es suficiente.

Causas comunes de un LCP deficiente

• Tiempo de respuesta del servidor lento (TTFB): Si tu servidor tarda 2 segundos en responder, tu LCP no puede estar por debajo de 2,5 segundos. Los retrasos en el renderizado del lado del servidor, las consultas a la base de datos y la falta de caché son los culpables más comunes.
• Recursos que bloquean el renderizado: Los archivos CSS y JavaScript en el <head> bloquean el renderizado hasta que se descargan y analizan por completo. Los archivos CSS grandes y sin minificar o los archivos JS síncronos pueden retrasar el LCP varios segundos.
• Imágenes no optimizadas: Imágenes hero servidas en PNG en lugar de WebP/AVIF, imágenes no dimensionadas correctamente para la ventana gráfica, o imágenes cargadas sin indicaciones de precarga obligan al navegador a descubrir y descargar archivos grandes tarde en el proceso de carga.
• Renderizado del lado del cliente: Las aplicaciones de página única (React, Vue, Angular) que renderizan contenido completamente en JavaScript requieren que el navegador descargue, analice y ejecute JS antes de que aparezca cualquier contenido. Esto crea una página en blanco hasta que el framework se inicializa.
• Carga diferida del elemento LCP: Aplicar incorrectamente loading="lazy" a la imagen hero o al contenido visible inicial retrasa su carga porque el navegador espera hasta que el elemento esté cerca de la ventana gráfica antes de solicitarlo.

5 estrategias para optimizar el LCP

1. Optimiza el tiempo de respuesta del servidor

Reduce el TTFB implementando caché del lado del servidor, usando un CDN, mejorando tu hosting o cambiando a páginas renderizadas en el borde (edge). Cada reducción de 100ms en el TTFB mejora directamente el LCP.

# Nginx — Habilitar compresión gzip y caché estática
gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml;
gzip_min_length 256;

location ~* \.(css|js|jpg|jpeg|png|gif|ico|svg|woff2)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

2. Precarga la imagen LCP

Informa al navegador sobre la imagen LCP tempranamente usando una etiqueta <link rel="preload"> en el head del documento. Esto permite que el navegador comience a descargar la imagen antes de descubrirla en el DOM.

<!-- Precargar la imagen hero para un LCP más rápido -->
<link rel="preload" as="image" href="/images/hero.webp"
      type="image/webp" fetchpriority="high">

<!-- Marcar la imagen LCP con fetchpriority -->
<img src="/images/hero.webp" alt="Descripción del hero"
     width="1200" height="630" fetchpriority="high">

3. Usa formatos de imagen modernos

Convierte las imágenes a formato WebP o AVIF. WebP típicamente proporciona archivos un 25-35% más pequeños que JPEG a calidad equivalente, y AVIF puede reducir el tamaño del archivo hasta un 50%. Usa el elemento <picture> para mejora progresiva.

<picture>
  <source srcset="/images/hero.avif" type="image/avif">
  <source srcset="/images/hero.webp" type="image/webp">
  <img src="/images/hero.jpg" alt="Muestra de producto"
       width="1200" height="630" fetchpriority="high">
</picture>

4. Elimina los recursos que bloquean el renderizado

Inserta el CSS crítico directamente en el <head> y difiere las hojas de estilo no críticas. Carga JavaScript con atributos defer o async para evitar bloquear el analizador.

<!-- CSS crítico en línea para el contenido visible -->
<style>
  /* Estilos críticos para header, hero, nav */
  .header { display:flex; height:60px; }
  .hero { min-height:400px; }
</style>

<!-- Diferir CSS no crítico -->
<link rel="preload" href="/style.css" as="style"
      onload="this.onload=null;this.rel='stylesheet'">

<!-- Diferir JavaScript -->
<script src="/app.js" defer></script>

5. Usa un CDN para recursos estáticos

Sirve imágenes, CSS, JavaScript y fuentes desde una Red de Distribución de Contenido (CDN) con ubicaciones de borde cercanas a tus usuarios. Un CDN puede reducir los tiempos de descarga de recursos en un 50-80% para usuarios lejanos a tu servidor de origen. Cloudflare, Fastly y AWS CloudFront ofrecen niveles gratuitos o asequibles adecuados para la mayoría de los sitios web.

INP: Interaction to Next Paint

Interaction to Next Paint (INP) mide la peor capacidad de respuesta de tu página rastreando la latencia entre una interacción del usuario (clic, toque o pulsación de tecla) y la siguiente actualización visual en pantalla. INP reemplazó a First Input Delay (FID) como Core Web Vital en marzo de 2024. Un buen INP es de 200 milisegundos o menos.

La diferencia crítica entre INP y su predecesor FID es el alcance. FID solo medía el retraso antes de que el navegador comenzara a procesar la primera interacción del usuario. INP mide la latencia completa de cada interacción a lo largo del ciclo de vida de la página e informa la peor (o casi peor, en el percentil 98). Esto significa que una página que responde rápidamente al primer clic pero se congela durante 800ms cuando un usuario abre un menú desplegable no pasará INP aunque habría pasado FID.

INP captura tres fases distintas de la latencia de interacción:

• Retraso de entrada: El tiempo entre la interacción del usuario y el momento en que el navegador comienza a ejecutar los manejadores de eventos. Esto se debe a que el hilo principal está ocupado con otras tareas (tareas largas, ejecución pesada de JavaScript).
• Tiempo de procesamiento: El tiempo que los manejadores de eventos tardan en ejecutarse. Los manejadores de eventos complejos que realizan manipulación síncrona del DOM, cálculos pesados o llamadas API bloqueantes aumentan el tiempo de procesamiento.
• Retraso de presentación: El tiempo entre que los manejadores de eventos terminan y el navegador pinta el siguiente fotograma. Esto incluye el recálculo de estilos, diseño y operaciones de pintado desencadenadas por la interacción.

Estrategias para optimizar INP

1. Divide las tareas largas

Las tareas de JavaScript que se ejecutan durante más de 50ms bloquean el hilo principal e impiden que el navegador responda a las interacciones del usuario. Divide las tareas largas en fragmentos más pequeños usando requestIdleCallback, setTimeout o la API scheduler.yield().

// Malo: Una tarea síncrona larga (bloquea el hilo principal)
function processAllItems(items) {
  items.forEach(item => heavyProcessing(item)); // 500ms+
}

// Bueno: Dividir en fragmentos con scheduler.yield()
async function processAllItems(items) {
  for (const item of items) {
    heavyProcessing(item);
    // Ceder el hilo principal entre elementos
    if (navigator.scheduler?.yield) {
      await navigator.scheduler.yield();
    } else {
      await new Promise(r => setTimeout(r, 0));
    }
  }
}

2. Reduce el tamaño del bundle de JavaScript

Los bundles de JavaScript grandes tardan más en analizarse y ejecutarse, bloqueando el hilo principal durante la carga de la página y después de las interacciones. Usa la división de código para cargar solo el JavaScript necesario para la página actual, elimina el código no utilizado con tree-shaking y difiere los scripts no críticos.

3. Aplica debounce a los manejadores de entrada

Los manejadores de eventos para scroll, resize, mousemove e input pueden dispararse cientos de veces por segundo. Aplica debounce o throttle a estos manejadores para evitar que sobrecarguen el hilo principal y causen un INP deficiente para las interacciones posteriores del usuario.

4. Evita los diseños síncronos forzados

Leer propiedades de diseño (como offsetHeight o getBoundingClientRect()) inmediatamente después de modificar el DOM obliga al navegador a realizar un cálculo de diseño síncrono, lo que bloquea el hilo principal. Agrupa tus lecturas y escrituras por separado.

CLS: Cumulative Layout Shift

Cumulative Layout Shift (CLS) mide cuánto se mueve inesperadamente el contenido visible de tu página durante su ciclo de vida. Cuantifica la inestabilidad visual — esos momentos frustrantes en los que estás a punto de hacer clic en un botón y de repente se desplaza porque se cargó un anuncio encima, o cuando el texto que estás leyendo se mueve hacia abajo porque terminó de cargar una fuente web. Una buena puntuación de CLS es 0,1 o menos.

CLS se calcula multiplicando la fracción de impacto (cuánto de la ventana gráfica se vio afectada por el cambio) por la fracción de distancia (cuánto se movieron los elementos). Solo cuentan los cambios inesperados — los cambios de diseño que ocurren dentro de los 500ms de una interacción del usuario (como hacer clic en un desplegable) se excluyen del CLS. Google utiliza un enfoque de "ventana de sesión" para calcular el CLS, agrupando los cambios que ocurren dentro de 1 segundo entre sí (con una ventana máxima de 5 segundos), e informando la ventana de sesión más grande.

Causas comunes de un CLS deficiente

• Imágenes y vídeos sin dimensiones: Cuando las imágenes se cargan sin atributos explícitos de width y height, el navegador no puede reservar espacio para ellas. Cuando se cargan, empujan todo el contenido debajo de ellas hacia abajo.
• Anuncios, incrustaciones e iframes sin espacio reservado: El contenido de terceros que se inyecta dinámicamente en la página sin un contenedor predefinido causa cambios de diseño significativos.
• Contenido inyectado dinámicamente: Banners, barras de notificación, modales de consentimiento de cookies o cintas de "últimas noticias" que empujan el contenido hacia abajo después del renderizado inicial.
• Fuentes web que causan FOUT (Flash of Unstyled Text): Cuando una fuente web se carga y reemplaza la fuente de respaldo, las diferencias en las métricas de la fuente (tamaño, interlineado, espaciado de letras) causan que los bloques de texto se desplacen.
• Animaciones CSS que activan el diseño: Las animaciones que usan propiedades como top, left, width o height en lugar de transform causan recálculos de diseño que cuentan como cambios.

Estrategias para corregir el CLS

1. Siempre establece dimensiones en imágenes y vídeos

<!-- Siempre incluir width y height para las imágenes -->
<img src="/product.webp" alt="Foto del producto"
     width="800" height="600" loading="lazy">

<!-- Para imágenes responsivas, usa aspect-ratio CSS -->
<style>
  .responsive-img {
    width: 100%;
    height: auto;
    aspect-ratio: 16 / 9;
    object-fit: cover;
  }
</style>

2. Reserva espacio para anuncios e incrustaciones

<!-- Reservar espacio para un espacio publicitario de 300x250 -->
<div style="min-height: 250px; width: 300px;">
  <!-- El script del anuncio se carga aquí -->
</div>

<!-- Reservar espacio para una incrustación iframe -->
<iframe src="https://embed.example.com"
        width="560" height="315"
        loading="lazy"></iframe>

3. Usa font-display: swap con fallbacks ajustados en tamaño

/* Prevenir cambios de diseño por fuentes web */
@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter.woff2') format('woff2');
  font-display: swap;
  /* Fallback ajustado en tamaño para coincidir métricas */
  size-adjust: 107%;
  ascent-override: 90%;
  descent-override: 22%;
  line-gap-override: 0%;
}

/* Alternativa: usar @font-face override */
@font-face {
  font-family: 'Inter Fallback';
  src: local('Arial');
  size-adjust: 107%;
  ascent-override: 90%;
}

4. Usa CSS transform para animaciones

/* Malo: Animar propiedades de diseño causa CLS */
.slide-in {
  animation: slideIn 0.3s ease;
}
@keyframes slideIn {
  from { left: -100%; }
  to { left: 0; }
}

/* Bueno: Usar transform (sin cambio de diseño) */
.slide-in {
  animation: slideIn 0.3s ease;
}
@keyframes slideIn {
  from { transform: translateX(-100%); }
  to { transform: translateX(0); }
}

Cómo los Core Web Vitals impactan en los rankings

Google confirmó los Core Web Vitals como señal de ranking en junio de 2021 como parte de la actualización más amplia de Experiencia de Página. Desde entonces, múltiples estudios de Searchmetrics, Semrush e investigadores de SEO independientes han analizado la correlación entre las puntuaciones de CWV y las posiciones de ranking. El consenso es claro: los Core Web Vitals son un factor de ranking real pero moderado. No anulan la calidad del contenido ni la autoridad de los backlinks, pero sirven como un desempate significativo cuando las páginas competidoras son similares en calidad y relevancia.

Los datos muestran un patrón consistente: los sitios con buenos Core Web Vitals tienden a ver mejoras de tráfico medibles, mientras que los sitios con CWV deficientes enfrentan desventajas de ranking, especialmente en los resultados de búsqueda móvil donde Google aplica más peso a las señales de experiencia de página.

Los efectos indirectos de los Core Web Vitals son posiblemente aún más importantes que el impacto directo en el ranking. Las páginas que cargan rápido, responden inmediatamente y permanecen visualmente estables tienen tasas de rebote más bajas, mayor engagement, sesiones más largas y más conversiones. Google mide las señales de engagement del usuario (tiempo de permanencia, pogo-sticking) como parte de sus algoritmos de ranking, así que las mejoras de comportamiento del usuario derivadas de un buen CWV crean un ciclo de retroalimentación positiva que fortalece aún más tus rankings.

El flujo de trabajo de optimización de Core Web Vitals

Optimizar los Core Web Vitals no es una tarea única — es un proceso iterativo. Sigue este flujo de trabajo de cinco pasos para identificar, diagnosticar, corregir, verificar y mantener sistemáticamente el rendimiento de tus CWV a lo largo del tiempo.

Paso 1 — Medir: Comienza consultando tus datos reales (de campo) en el informe de Core Web Vitals de Google Search Console y PageSpeed Insights. Los datos de campo de CrUX reflejan las experiencias reales de los usuarios durante los últimos 28 días. Si no tienes suficiente tráfico para datos de CrUX, usa los datos de laboratorio de Lighthouse como punto de partida, pero recuerda que las puntuaciones de laboratorio son aproximaciones, no garantías del rendimiento en campo.

Paso 2 — Diagnosticar: Usa el panel de Rendimiento de Chrome DevTools para identificar cuellos de botella específicos. Para LCP, examina la cascada de red para encontrar qué está retrasando el recurso LCP. Para INP, usa el seguimiento de interacciones del panel de Rendimiento para encontrar tareas largas que bloquean el hilo principal. Para CLS, activa la superposición de "Layout Shift Regions" para ver exactamente qué elementos se están moviendo y cuándo.

Paso 3 — Optimizar: Aplica correcciones específicas basadas en tu diagnóstico. Prioriza la métrica que esté más lejos del umbral "bueno". Usa las estrategias de optimización específicas detalladas en esta guía para cada métrica.

Paso 4 — Probar: Después de implementar las correcciones, prueba en el entorno de staging usando Lighthouse y WebPageTest. Compara las puntuaciones antes y después. Asegúrate de que las mejoras se mantengan en diferentes tipos de dispositivos y condiciones de red. Usa la vista de filmstrip de WebPageTest para confirmar visualmente que el contenido carga más rápido y no se desplaza.

Paso 5 — Monitorear: Despliega en producción y monitorea los datos de CrUX en Search Console. Los datos de campo tardan 28 días en actualizarse completamente, así que ten paciencia. Configura Monitoreo de Usuarios Reales (RUM) con la biblioteca JavaScript web-vitals para obtener datos de rendimiento en tiempo real de tus visitantes reales. Establece umbrales de alerta para que se te notifique si alguna métrica empeora.

// Instalar: npm install web-vitals
import { onLCP, onINP, onCLS } from 'web-vitals';

function sendToAnalytics(metric) {
  // Enviar datos de la métrica a tu endpoint de analítica
  const body = JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating, // 'good', 'needs-improvement', o 'poor'
    delta: metric.delta,
    id: metric.id,
    navigationType: metric.navigationType,
  });

  // Usar sendBeacon para entrega confiable
  navigator.sendBeacon('/api/vitals', body);
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

Antes vs Después: Resultados reales de optimización

6 técnicas clave de optimización

Estas seis técnicas cubren las optimizaciones de mayor impacto en los tres Core Web Vitals. Implementar las seis abordará la gran mayoría de los problemas de CWV en la mayoría de los sitios web.

Técnicas de optimización por métrica

Herramientas de diagnóstico para Core Web Vitals

La optimización efectiva de CWV requiere las herramientas de medición adecuadas. Aquí tienes una comparación completa de las herramientas disponibles en 2026, organizadas por sus fortalezas y casos de uso ideales.

Recomendación: Usa una combinación de herramientas. Comienza con Google Search Console para la visión general (qué páginas pasan, cuáles fallan y cómo son las tendencias). Usa PageSpeed Insights para diagnóstico por página con datos reales de CrUX. Usa Chrome DevTools para depuración interactiva cuando necesites rastrear un cuello de botella específico. Usa WebPageTest para análisis competitivo y para probar cambios antes de desplegar. Usa seoscore.tools para ver cómo los CWV encajan en tu panorama SEO general junto con más de 136 factores de ranking adicionales.

Priorización: Mejoras rápidas vs Correcciones a largo plazo

Core Web Vitals y búsqueda con IA

Quizás te preguntes si los Core Web Vitals importan para la visibilidad en búsqueda con IA — después de todo, los sistemas de IA como ChatGPT, Perplexity y Google AI Overview procesan contenido de forma programática, no a través de un navegador. La respuesta es matizada pero importante: los Core Web Vitals afectan la visibilidad en búsqueda con IA de forma indirecta pero significativa.

Así es como los CWV se conectan con la búsqueda con IA:

Influencia del índice de búsqueda: Google AI Overview extrae sus fuentes del índice de búsqueda de Google, donde los CWV son un factor de ranking. Las páginas con buenos CWV se posicionan más alto en la búsqueda tradicional, lo que las hace más propensas a aparecer en el grupo de candidatos del que AI Overview selecciona. Si tu página está en la posición 15 debido a CWV deficientes, es mucho menos probable que sea citada en AI Overview que una página en la posición 3 con contenido idéntico pero mejor rendimiento.

Eficiencia de rastreo: Los rastreadores de IA (incluidos los de Perplexity y el modo de navegación de ChatGPT) tienen presupuestos de tiempo limitados para obtener y analizar páginas. Una página de carga lenta que tarda 6 segundos en renderizarse puede agotar el tiempo o renderizarse solo parcialmente durante las operaciones de rastreo de IA. Las páginas rápidas y limpias se rastrean e indexan de forma más confiable por los sistemas de IA.

Accesibilidad del contenido: Las páginas con cambios de diseño significativos o renderizado dependiente de JavaScript pueden presentar contenido diferente a los rastreadores de IA que a los visitantes humanos. Si tu contenido principal requiere una ejecución pesada de JavaScript para renderizarse (deficiente para INP y LCP), los rastreadores de IA pueden perdérselo completamente. El contenido renderizado del lado del servidor con buenos CWV es el que se analiza de forma más confiable por los sistemas de búsqueda tanto tradicionales como de IA.

La experiencia del usuario como señal de calidad: Google ha utilizado cada vez más las señales de comportamiento (tasa de rebote, engagement, tiempo de permanencia) como factores de ranking indirectos. Las páginas con CWV deficientes generan peores señales de comportamiento, lo que deprime los rankings, lo que reduce la probabilidad de citación por IA. Es una reacción en cadena donde el rendimiento deficiente a nivel de usuario se propaga en forma de visibilidad reducida ante la IA.

Errores comunes de Core Web Vitals

Incluso los desarrolladores y profesionales de SEO experimentados cometen estos errores al optimizar los Core Web Vitals. Evitarlos te ahorrará horas de depuración y prevendrá regresiones.

• Optimizar solo para datos de laboratorio. Una puntuación de Lighthouse de 100 no garantiza buenos datos de CrUX. Las pruebas de laboratorio se ejecutan en un dispositivo fijo con una red fija; los usuarios reales tienen dispositivos, conexiones y contextos de navegación muy diferentes. Siempre valida las mejoras de laboratorio contra los datos de campo. Si tu puntuación de Lighthouse es 95 pero tu INP de CrUX es 450ms, la prueba de laboratorio te está engañando.
• Aplicar carga diferida al elemento LCP. Agregar loading="lazy" a imágenes hero, banners visibles o imágenes de contenido principal es uno de los errores de LCP más comunes y dañinos. La carga diferida retrasa estos recursos críticos porque el navegador espera hasta que el elemento esté cerca de la ventana gráfica antes de solicitarlo. El elemento LCP siempre debe cargarse de forma inmediata con fetchpriority="high".
• Ignorar scripts de terceros. Los scripts de analítica, widgets de chat, incrustaciones sociales, scripts publicitarios y herramientas de testing A/B a menudo contribuyen más a unos CWV deficientes que tu propio código. Un solo widget de chat no optimizado puede añadir más de 500ms al INP bloqueando el hilo principal. Audita cada script de terceros, difiere los no críticos y usa el atributo Partitioned para iframes de terceros.
• Corregir CLS en desarrollo pero no en producción. El CLS a menudo se comporta de manera diferente en producción debido a los anuncios, banners de consentimiento de cookies, variaciones de tests A/B y contenido generado por usuarios que no existen en los entornos de desarrollo. Siempre mide el CLS en producción con configuraciones de anuncios reales y flujos de usuario reales.
• Usar demasiadas fuentes web. Cargar 4-6 pesos y estilos de fuentes desde Google Fonts o un servicio de fuentes autoalojado añade una latencia significativa al LCP y causa CLS cuando las fuentes se intercambian. Limítate a un máximo de 2-3 archivos de fuente. Usa font-display: swap con fallbacks ajustados en tamaño para prevenir cambios de diseño, y precarga solo el archivo de fuente más crítico.
• No establecer dimensiones explícitas en imágenes responsivas. Los atributos HTML width y height funcionan perfectamente con CSS responsivo (width: 100%; height: auto;). El navegador usa la relación de aspecto de los atributos para reservar el espacio correcto antes de que la imagen se cargue. No hay conflicto entre imágenes responsivas y dimensiones explícitas — omitirlas es siempre un error.
• Asumir que un sitio rápido en WiFi significa un sitio rápido en todas partes. Prueba tus páginas en conexiones 3G y 4G simuladas, y prueba en dispositivos Android de gama media reales. Los datos de CrUX de Google están dominados por usuarios móviles en conexiones variables. Tu página podría obtener "bueno" en tu MacBook Pro con fibra óptica pero "deficiente" para la mayoría de tus usuarios reales en dispositivos móviles.
• No monitorear después del despliegue. Las regresiones de rendimiento ocurren constantemente a medida que se añaden nuevas funcionalidades, anuncios, scripts de terceros y contenido. Sin monitoreo continuo, un solo PR que añada una imagen hero no optimizada o un nuevo script de analítica puede deshacer meses de trabajo de optimización. Configura alertas automatizadas usando la biblioteca web-vitals o un servicio de RUM.

Preguntas frecuentes

Conclusiones clave

1. Los Core Web Vitals son un factor de ranking confirmado de Google. LCP, INP y CLS influyen directamente en tus rankings de búsqueda como parte de la señal de experiencia de página. Los sitios que superan los tres umbrales tienen una ventaja medible, especialmente en móvil.
2. INP reemplazó a FID en marzo de 2024 y es mucho más difícil de pasar. A diferencia de FID, que solo medía el retraso de entrada de la primera interacción, INP mide la latencia completa de cada interacción en la página. Muchos sitios que pasaban FID fácilmente no pasan INP. Audita tu INP específicamente — no asumas que estás a salvo.
3. Optimiza para usuarios reales, no para puntuaciones de laboratorio. Google usa datos de campo del Chrome User Experience Report (CrUX), medidos en el percentil 75. Una puntuación perfecta de Lighthouse no significa nada si tus usuarios reales en dispositivos reales tienen experiencias deficientes. Siempre valida con datos de campo de CrUX.
4. Existen mejoras rápidas y deberían hacerse primero. La compresión de imágenes, precargar el elemento LCP, establecer dimensiones explícitas de imagen y habilitar caché pueden mejorar dramáticamente los CWV con un esfuerzo mínimo. Comienza por ahí antes de invertir en cambios arquitectónicos complejos.
5. Los CWV afectan la búsqueda con IA de forma indirecta pero significativa. Las páginas más rápidas y estables se posicionan mejor en la búsqueda tradicional (de la que se nutren los sistemas de IA), son rastreadas de forma más confiable por los rastreadores de IA y generan mejores señales de engagement del usuario. Optimizar los CWV mejora la visibilidad tanto en la búsqueda tradicional como en la impulsada por IA.
6. El monitoreo continuo es innegociable. Las regresiones de rendimiento por nuevas funcionalidades, anuncios y scripts de terceros son constantes. Usa la biblioteca web-vitals para rastrear métricas de usuarios reales y configura alertas para que las regresiones se detecten inmediatamente. Consulta seoscore.tools regularmente para ver cómo tus CWV encajan en tu salud SEO general.