Core Web Vitals: impacto en SEO y experiencia de página

Qué son las Core Web Vitals

Las Core Web Vitals son un conjunto de métricas centradas en la experiencia real de usuario en la página. Miden tres dimensiones concretas: velocidad de carga percibida, interactividad y estabilidad visual. Su propósito es traducir sensaciones subjetivas —“la página se siente lenta” o “todo salta al cargar”— en indicadores observables y comparables.

Las tres métricas principales

LCP (Largest Contentful Paint): mide el tiempo hasta que el elemento más grande del viewport se pinta de forma significativa; refleja cuándo el usuario percibe que el contenido principal ya está visible.

INP (Interaction to Next Paint): sustituye a FID como métrica de interactividad. Mide la latencia de las interacciones del usuario a lo largo del tiempo, enfocándose en la experiencia real ante eventos nuevos (por ejemplo, taps, clicks, entradas de teclado).

CLS (Cumulative Layout Shift): cuantifica los desplazamientos inesperados de elementos visibles durante la carga y la interacción, lo que afecta la percepción de estabilidad y puede provocar clics erróneos.

Cómo funcionan en la práctica

Las Core Web Vitals se miden en dos entornos complementarios: datos de laboratorio (simulaciones con Lighthouse o herramientas similares) y datos de campo (telemetría de usuarios reales recopilada en Chrome UX Report y en Google Search Console). Cada uno aporta información distinta: el laboratorio es reproducible y utilizable para diagnosticar, mientras que el campo muestra cómo responde la experiencia en condiciones reales de red y dispositivo.

Importante para SEO: Core Web Vitals forman parte de las señales de Page Experience que Google considera para el ranking, pero son solo una de muchas señales. En julio de 2024 Google confirmó que Googlebot Smartphone es el rastreador por defecto; además, Google eliminó las páginas en caché tradicionales a principios de 2024. Por eso, asegúrate de considerar indexabilidad y contenido junto con la experiencia de página.

Umbrales y referencia (consulta oficial)

Google mantiene umbrales orientativos para Core Web Vitals; cita la documentación de Google para valores actualizados y definidos por métrica. Usa esos umbrales como guía para priorizar, pero recuerda que la importancia real depende de tus páginas y de los objetivos de tu negocio.

Verificación y medición: herramientas y comandos útiles

Herramientas principales y para qué sirven:

• Chrome UX Report (CrUX): fuente de datos de campo agregados para páginas reales.
• PageSpeed Insights: combina datos de campo (CrUX) y un informe de laboratorio (Lighthouse).
• Lighthouse (en DevTools o CLI): pruebas de laboratorio para diagnóstico reproducible.
• Google Search Console — informe Core Web Vitals: datos de campo por grupo de URLs y por problema.
• Chrome DevTools — Performance y Rendering: inspección detallada (LCP, Layout Shifts, Long Tasks).
• Biblioteca web-vitals (JavaScript): captura de métricas RUM en tu propio analytics.

Comandos prácticos (línea de comandos)

Inspeccionar cabeceras HTTP (solo cabeceras): usa curl -I para ver encabezados de respuesta, caché y content-type. Ejemplo: curl -I https://example.com/pagina

Comprobar el HTML que el servidor devuelve a un user-agent concreto: curl -A "Mozilla/5.0" https://example.com/pagina (no usar -I si necesitas el cuerpo). Recuerda que -A establece el user-agent; úsalo para verificar variantes por dispositivo.

Captura de métricas reales en producción

Ejemplo mínimo con la biblioteca web-vitals para enviar métricas a tu analytics (fragmento):

import {getLCP, getCLS, getINP} from 'web-vitals';
getLCP(metric => sendToAnalytics('LCP', metric));
getCLS(metric => sendToAnalytics('CLS', metric));
getINP(metric => sendToAnalytics('INP', metric));

Asegúrate de que sendToAnalytics anonimice datos sensibles y agregue contexto (ruta, tipo de dispositivo, versión de la página) para analizar patrones antes de decidir cambios.

Problemas comunes y soluciones prácticas

LCP: causas habituales y qué hacer

Causas frecuentes: imágenes/hero grandes sin formato optimizado, CSS o JS que bloquea el render, respuesta lenta del servidor o ausencia de caché, recursos críticos no precargados.

Soluciones prácticas:
• Preload para la imagen o fuente crítica del LCP (usa <link rel="preload" as="image" href="/hero.jpg"> para el recurso hero).
• No lazy-loadear el elemento LCP; las imágenes below-the-fold sí pueden ir con lazy-loading.
• Minimizar CSS crítico y aplazar CSS no esencial.
• Mejorar tiempos de servidor: usar caché, CDN y optimizar backend.

INP: causas y arreglos

Causas frecuentes: tareas largas en el hilo principal (evaluación de grandes bundles JS), terceros que ejecutan scripts sin control, y listeners sin prácticas de rendimiento.

Soluciones prácticas:
• Dividir bundles y cargar código según necesidad (code-splitting, route-based splitting).
• Mover trabajo pesado a Web Workers cuando sea posible.
• Evitar bloqueos largos: dividir tareas en trozos más pequeños y usar requestIdleCallback o setTimeout para trabajo no crítico.
• Revisar scripts de terceros y cargar con prioridades más bajas o en iframes cuando sea posible.

CLS: por qué ocurre y cómo evitarlo

Causas frecuentes: imágenes sin dimensiones, anuncios que insertan elementos dinámicamente, fuentes que provocan reflujo (FOIT/FOUT), y animaciones que cambian el layout en lugar de usar transform.

Soluciones prácticas:
• Siempre especifica width/height en imágenes o usa CSS aspect-ratio para reservar espacio.
• Dimensiona contenedores de anuncios y usa placeholders con tamaño fijo o adaptativo.
• Prefiere transform/opacity para animaciones.
• Usa font-display: swap o estrategias de carga de fuentes que reduzcan shifts percibidos.

Checklist rápido de implementación (prioridad)

1) Identifica las páginas de mayor valor (tráfico, conversiones) y actúa sobre ellas primero.
2) Obtén datos de campo (Search Console, CrUX o RUM propio) para priorizar métricas reales.
3) En laboratorio, reproduce problemas con Lighthouse/DevTools y captura traces.
4) Corrige la causa raíz: servidor/CDN, recursos críticos, long tasks o elementos que causan shift.
5) Implementa RUM (web-vitals) para verificar mejoras en producción y ajustar según resultados reales.

Solución de problemas avanzada

Diagnóstico paso a paso para una página con mala puntuación en campo:

• Recolecta datos de campo por URL o grupo de URLs (Search Console Core Web Vitals o RUM propio).
• Ejecuta Lighthouse en condiciones similares a las de los usuarios afectados y guarda el trace para inspeccionar LCP y Long Tasks.
• En DevTools Performance, busca Long Tasks (>50 ms), identifica scripts culpables y reduce su coste.
• Revisa la carga de recursos con Network y prueba preload para recursos críticos.
• Verifica HTML renderizado en dispositivos reales o con curl -A para detectar diferencias por user-agent.

Consejo: los proveedores de terceros (widgets, analytics, ads) suelen ser responsables de problemas recurrentes. Evalúa su valor editorial/comercial frente al coste en experiencia y carga. Cuando no puedas modificar el script, carga el tercero de forma asincrónica, en un iframe aislado o con una política de prioridad baja.

Medir el impacto: qué esperar y cómo reportarlo

Mejorar Core Web Vitals no garantiza subidas automáticas en rankings: son una señal entre muchas. Sin embargo, reducen fricción para usuarios reales, lo que suele mejorar engagement y conversiones. Mide antes/después con tus propias métricas (RUM + conversiones) y comunica cambios de forma cuantitativa: porcentaje de URLs que pasan umbrales, distribución de métricas por tipo de dispositivo y correlación con KPIs de negocio.

FAQ