Core Web Vitals: Velocidad y experiencia

Google no solo evalúa tu contenido—también evalúa cómo se siente usar tu sitio. Los Core Web Vitals son las métricas oficiales que Google usa para medir esta experiencia.

¿Por qué importan los Core Web Vitals?

En 2021, Google confirmó que los Core Web Vitals son factores de ranking. Un sitio con buenas métricas tiene ventaja sobre competidores con métricas pobres.

Pero más allá del SEO, estas métricas impactan directamente tu negocio:

Mejora	Impacto en negocio
0.1s menos en carga	+8% conversiones (Walmart)
1s más de carga	-7% conversiones (Amazon)
Página lenta	53% usuarios abandonan en móvil

Realidad: Los usuarios no esperan. En 2026, esperan que tu sitio cargue en menos de 3 segundos.

---

Los 3 Core Web Vitals explicados

1. LCP (Largest Contentful Paint)

¿Qué mide? El tiempo hasta que el elemento más grande visible en la pantalla termina de cargar.

En palabras simples: ¿Cuánto tarda en aparecer el contenido principal?

Usuario llega → Pantalla blanca → Contenido aparece
                                         ↑
                                    Esto es LCP

Umbrales de Google:

Calificación	Tiempo LCP
Bueno (verde)	≤ 2.5 segundos
Necesita mejora (amarillo)	2.5 - 4.0 segundos
Pobre (rojo)	> 4.0 segundos

Elementos que típicamente son el LCP:

• Imagen hero grande
• Video de fondo
• Bloque de texto principal
• Imagen de producto destacada

Causas comunes de LCP lento

1. Imágenes sin optimizar

<!-- Malo: imagen de 3MB -->
<img src="hero-original.jpg">

<!-- Bueno: imagen optimizada con lazy loading -->
<img src="hero-optimized.webp"
     loading="lazy"
     width="1200"
     height="600"
     alt="Descripción">

2. Servidor lento (TTFB alto)

• Hosting de baja calidad
• Sin CDN
• Base de datos no optimizada

3. CSS y JavaScript bloqueantes

<!-- Malo: bloquea renderizado -->
<link href="styles.css" rel="stylesheet">
<script src="analytics.js"></script>

<!-- Mejor: carga crítico inline, resto diferido -->
<style>/* CSS crítico inline */</style>
<link href="styles.css" rel="stylesheet" media="print" onload="this.media='all'">
<script src="analytics.js" defer></script>

4. Fuentes web lentas

/* Malo: espera a que cargue la fuente */
@font-face {
  font-family: 'MiFuente';
  src: url('fuente.woff2');
}

/* Mejor: muestra texto mientras carga */
@font-face {
  font-family: 'MiFuente';
  src: url('fuente.woff2');
  font-display: swap;
}

---

2. INP (Interaction to Next Paint)

¿Qué mide? El tiempo desde que el usuario interactúa (clic, toque, tecla) hasta que el navegador responde visualmente.

En palabras simples: ¿Tu sitio responde rápido cuando el usuario hace clic?

Nota: INP reemplazó a FID (First Input Delay) en marzo 2024 como Core Web Vital oficial.

Usuario hace clic → Procesamiento → Respuesta visual
                                          ↑
                                     Esto es INP

Umbrales de Google:

Calificación	Tiempo INP
Bueno (verde)	≤ 200 milisegundos
Necesita mejora (amarillo)	200 - 500 milisegundos
Pobre (rojo)	> 500 milisegundos

Causas comunes de INP lento

1. JavaScript pesado en el hilo principal

// Malo: bloquea el hilo principal
function procesarDatos() {
  for (let i = 0; i < 10000000; i++) {
    // Cálculos pesados
  }
}

// Mejor: usar Web Workers para tareas pesadas
const worker = new Worker('procesar.js');
worker.postMessage(datos);

2. Event handlers lentos

// Malo: handler hace demasiado trabajo
boton.addEventListener('click', () => {
  actualizarUI();
  enviarAnalytics();
  cargarDatos();
  procesarResultados();
  renderizarGraficos();
});

// Mejor: dividir y diferir trabajo no crítico
boton.addEventListener('click', () => {
  actualizarUI(); // Solo lo visual inmediato
  requestIdleCallback(() => {
    enviarAnalytics();
    // Resto del trabajo
  });
});

3. Demasiados scripts de terceros

• Widgets de chat
• Píxeles de tracking
• Embeds de redes sociales
• Scripts de publicidad

4. Frameworks JavaScript pesados

Algunos frameworks pueden afectar INP si no se optimizan correctamente:

• Hidratación lenta en SSR
• Re-renders innecesarios
• Bundles grandes sin code splitting

---

3. CLS (Cumulative Layout Shift)

¿Qué mide? Cuánto se mueve el contenido inesperadamente mientras la página carga.

En palabras simples: ¿Los elementos "saltan" mientras intentas leer o hacer clic?

Texto visible → Imagen carga arriba → Todo se mueve hacia abajo
                                              ↑
                                    Esto causa mal CLS

Umbrales de Google:

Calificación	Puntuación CLS
Bueno (verde)	≤ 0.1
Necesita mejora (amarillo)	0.1 - 0.25
Pobre (rojo)	> 0.25

Causas comunes de mal CLS

1. Imágenes sin dimensiones

<!-- Malo: navegador no sabe el tamaño hasta que carga -->
<img src="foto.jpg">

<!-- Bueno: navegador reserva espacio -->
<img src="foto.jpg" width="800" height="600">

<!-- Mejor: con aspect-ratio en CSS -->
<img src="foto.jpg" style="aspect-ratio: 4/3; width: 100%;">

2. Anuncios y embeds dinámicos

<!-- Malo: el anuncio empuja contenido al cargar -->
<div id="ad-container"></div>
<p>Contenido importante</p>

<!-- Mejor: reservar espacio con min-height -->
<div id="ad-container" style="min-height: 250px;"></div>
<p>Contenido importante</p>

3. Fuentes web que cambian tamaño

/* Malo: fuente fallback muy diferente */
body {
  font-family: 'FuentePersonalizada', Arial;
}

/* Mejor: usar font-display y métricas similares */
@font-face {
  font-family: 'FuentePersonalizada';
  src: url('fuente.woff2');
  font-display: swap;
  size-adjust: 105%; /* Ajustar para minimizar cambio */
}

4. Contenido inyectado dinámicamente

// Malo: insertar contenido arriba
contenedor.prepend(nuevoElemento);

// Mejor: insertar al final o en espacio reservado
espacioReservado.replaceWith(nuevoElemento);

---

Cómo medir tus Core Web Vitals

Herramientas de campo (datos reales de usuarios)

1. Google Search Console

• Reporte "Core Web Vitals"
• Datos de usuarios reales
• Agrupado por tipo de página

2. PageSpeed Insights

• Sección "Datos de campo"
• Basado en Chrome User Experience Report (CrUX)

3. Chrome UX Report

• Datos públicos de BigQuery
• 28 días de datos reales

Herramientas de laboratorio (pruebas simuladas)

1. Lighthouse (en Chrome DevTools)

F12 → Lighthouse → Generar reporte

2. PageSpeed Insights

• Sección "Datos de laboratorio"
• Simula conexión móvil 4G

3. WebPageTest

• Pruebas desde diferentes ubicaciones
• Filmstrip visual del proceso de carga

Diferencias importantes

Datos de campo	Datos de laboratorio
Usuarios reales	Simulación
75th percentil	Condiciones controladas
Lo que Google usa para ranking	Útil para debugging
Refleja variedad de dispositivos	Un tipo de dispositivo

Clave: Google usa datos de campo para ranking. Los datos de laboratorio son para diagnosticar y mejorar.

---

Plan de acción para mejorar cada métrica

Mejorar LCP (objetivo: < 2.5s)

Paso 1: Identificar el elemento LCP

• Usa Lighthouse o Performance tab en DevTools
• Identifica qué elemento está siendo medido

Paso 2: Optimizar ese elemento

Si es imagen:

• Comprimir y convertir a WebP/AVIF
• Usar loading="eager" para imagen hero
• Implementar fetchpriority="high"
• Servir desde CDN

Si es texto:

• Precargar fuentes críticas
• Usar font-display: swap
• Inline CSS crítico

Paso 3: Optimizar servidor

• Implementar CDN
• Habilitar compresión gzip/brotli
• Optimizar TTFB (< 600ms)

Mejorar INP (objetivo: < 200ms)

Paso 1: Identificar interacciones lentas

• Usa Performance tab en DevTools
• Graba interacciones y analiza

Paso 2: Optimizar JavaScript

• Dividir tareas largas (> 50ms)
• Usar requestIdleCallback para trabajo no crítico
• Implementar code splitting

Paso 3: Reducir scripts de terceros

• Auditar todos los scripts
• Cargar de forma diferida lo no esencial
• Considerar alternativas más ligeras

Mejorar CLS (objetivo: < 0.1)

Paso 1: Identificar elementos que causan shift

• Usa Lighthouse o Layout Shift Debugger
• Observa qué elementos se mueven

Paso 2: Reservar espacio

• Agregar width/height a todas las imágenes
• Definir min-height para contenedores dinámicos
• Usar aspect-ratio en CSS

Paso 3: Evitar inyección de contenido

• No insertar contenido arriba de contenido existente
• Cargar fuentes de forma que no cause reflow

---

Ejercicio práctico

Audita los Core Web Vitals de tu sitio

1. Ve a PageSpeed Insights (pagespeed.web.dev)

2. Ingresa tu URL y espera el análisis

3. Documenta tus métricas actuales:

Métrica	Móvil	Desktop	Estado
LCP			Verde/Amarillo/Rojo
INP			Verde/Amarillo/Rojo
CLS			Verde/Amarillo/Rojo

4. Identifica las recomendaciones principales:

   • ¿Qué sugiere para mejorar LCP?
   • ¿Qué sugiere para mejorar INP?
   • ¿Qué sugiere para mejorar CLS?

5. Prioriza: Empieza por la métrica en peor estado

---

Puntos clave de esta lección

• LCP mide velocidad de carga del contenido principal (objetivo: < 2.5s)
• INP mide qué tan rápido responde tu sitio a interacciones (objetivo: < 200ms)
• CLS mide estabilidad visual durante la carga (objetivo: < 0.1)
• Google usa datos de campo (usuarios reales) para ranking
• Cada métrica tiene causas específicas y soluciones concretas
• Las mejoras en Core Web Vitals impactan tanto SEO como conversiones

Próxima lección

Con las métricas de velocidad claras, en la siguiente lección aprenderás sobre estructura del sitio y URLs amigables—cómo organizar tu contenido para que Google y usuarios lo naveguen fácilmente.

---

Quiz de comprensión

1. ¿Cuáles son los umbrales "buenos" para cada Core Web Vital?
2. ¿Por qué Google usa datos de campo en lugar de datos de laboratorio para ranking?
3. ¿Qué cambio simple puedes hacer para mejorar CLS en imágenes?
4. ¿Qué métrica reemplazó a FID y por qué?