Core Web Vitals: optimiza LCP, INP y CLS antes de cambiar de hosting
Publicado el 2026-11-14 por frfrand
Cómo diagnosticar LCP, INP y CLS con datos de campo y laboratorio, corregir el frontend y detectar cuellos de botella de servidor.
# Core Web Vitals: optimiza LCP, INP y CLS antes de cambiar de hosting
Cambiar de servidor puede mejorar la latencia, pero no arregla automáticamente una imagen hero de 4 MB, JavaScript bloqueante o elementos que saltan al cargar. Antes de comprar otra infraestructura, identifica qué parte de la experiencia está fallando.
1. Qué mide cada indicador
| Métrica | Qué mide | Buen valor de referencia | | --- | --- | --- | | LCP | Aparición del contenido principal | 2,5 s o menos | | INP | Latencia de interacción | 200 ms o menos | | CLS | Inestabilidad visual | 0,1 o menos |
Los objetivos se evalúan normalmente en el percentil 75 de visitas reales, separando móvil y escritorio. Son umbrales orientativos de experiencia, no una garantía de ranking.
2. Campo frente a laboratorio
Consulta PageSpeed Insights y el informe Core Web Vitals de Search Console para datos reales cuando haya volumen suficiente. Usa Chrome DevTools y Lighthouse para investigar causas en un entorno reproducible. No confundas una puntuación de Lighthouse obtenida en laboratorio con la experiencia de usuarios reales. Mide rutas representativas: inicio, ficha de producto, búsqueda y proceso de pago.
3. Mejorar LCP sin cambiar hosting
Identifica el elemento LCP: banner, título o imagen. Si es imagen, usa WebP/AVIF cuando proceda, variantes responsivas, compresión, dimensiones explícitas y evita lazy loading en la imagen principal visible. Reduce el tiempo que tarda el navegador en descubrirla; puede ayudar fetchpriority="high" para un recurso hero verdaderamente prioritario. Optimiza fuentes y CSS críticos. Comprueba TTFB, pero recuerda que LCP combina más que respuesta del servidor.
4. Mejorar INP
Una interfaz con muchos listeners, JS pesado o tareas largas tarda en responder. En Performance de DevTools busca tareas bloqueantes, re-renderizados costosos y handlers lentos. Divide trabajos largos, pospone terceros, reduce hidratación innecesaria y usa virtualización para listas grandes. En React, mide antes de aplicar memorizaciones masivas: optimizar sin profiler puede complicar el código sin beneficio.
5. Mejorar CLS
Reserva ancho y alto para imágenes, embeds y anuncios. Evita insertar banners sobre contenido ya visible y elige una estrategia de fuentes que reduzca movimientos inesperados. Prueba navegación real, no únicamente la carga inicial.
6. Cuándo sí revisar servidor
Analiza TTFB por región, caché, consultas lentas, CPU, RAM, saturación de workers y proximidad al usuario. Si el HTML tarda demasiado en generarse, mejoras de base de datos, caché o hosting pueden tener un impacto real. Si TTFB es bueno y el bloqueo está en JavaScript o imágenes, cambiar VPS probablemente no resuelva la causa.
7. Plan de trabajo
Guarda línea base, identifica plantilla afectada, formula una hipótesis por cambio, despliega en staging, vuelve a medir y espera datos de campo nuevos. Prioriza mejoras que eleven experiencia y conversiones, no solo puntuaciones.
Complementa con SSR vs SSG y hosting compartido, VPS o dedicado.
Preguntas frecuentes
¿Lighthouse 100 garantiza buen SEO? No. ¿Un VPS arregla INP? Normalmente INP depende en gran medida del trabajo en el navegador. ¿Se optimiza una sola URL? Empieza por una plantilla y valida su impacto en rutas similares.
Fuente: https://web.dev/articles/vitals/