Core Web Vitals 2026: INP y velocidad real en Perú
Si tu web carga “más o menos” pero se siente pesada al hacer clic, ahí pierdes: gente, retención y dinero (incluido AdSense). Core Web Vitals es la forma en que Google estandariza esa experiencia.
Umbrales clave (los que importan de verdad)
INP es el que más se siente: es “hago clic y responde” vs “hago clic y se queda pensando”. Estos son los umbrales recomendados:
Objetivo rápido
- INP: bueno < 200 ms · 200–500 ms necesita mejora · > 500 ms es malo
- LCP: bueno ≤ 2.5 s
- CLS: bueno ≤ 0.1
Si tienes que priorizar: INP (sensación) + LCP (primera impresión) + CLS (confianza).
| Métrica | Bueno | Necesita mejora | Malo | ¿Qué siente el usuario? |
|---|---|---|---|---|
| INP | < 200 ms | 200–500 ms | > 500 ms | La web responde (o se traba) cuando haces clic/scroll/tap |
| LCP | ≤ 2.5 s | 2.5–4.0 s | > 4.0 s | “Ya cargó lo importante” (hero/heading/imagen principal) |
| CLS | ≤ 0.1 | 0.1–0.25 | > 0.25 | Se mueve el contenido y terminas haciendo clic donde no era |
Diagnóstico express (sin volverte técnico)
1) PageSpeed Insights (mobile)
- Arriba: datos reales (CrUX / “field data”).
- Abajo: diagnóstico de laboratorio (Lighthouse) para encontrar causas.
2) Search Console → Core Web Vitals
Te agrupa URLs con problemas similares para que ataques por bloques (no una por una). Prioriza primero mobile.
3) Lo que debes mirar primero (orden práctico)
- ¿Qué URLs están “Poor” en mobile?
- ¿Cuál métrica falla? (INP vs LCP vs CLS)
- ¿Qué cambió? (ads nuevos, scripts, fuentes, banners, widgets)
Regla simple
Field data te dice si duele en la vida real. Lab data te dice por qué duele y qué tocar.
Acciones de alto impacto (lo que suele arreglar 80% del problema)
Para mejorar INP (respuesta real al clic)
- Reduce “long tasks” de JavaScript: divide trabajo en bloques pequeños (no todo en un solo hilo).
- Difiere scripts no críticos (analytics extra, widgets, trackers redundantes).
- Menos librerías, menos peso: cada librería extra suele ser más parsing + más ejecución.
- Handlers livianos: evita listeners pesados en scroll/resize; usa debounce/throttle cuando aplique.
Para mejorar LCP (carga de lo importante)
- Identifica tu elemento LCP (PSI/Lighthouse te lo indica).
- Precarga el recurso principal (imagen hero o fuente crítica) y optimiza tamaño/formato.
- Lazy load para lo que está fuera del primer pantallazo.
- Fuentes con swap para que el texto aparezca rápido (sin bloqueo).
- Back-end: mejora TTFB con caché, compresión y plantillas eficientes (clave en Django).
Para mejorar CLS (que no “salte” tu página)
- Reserva espacio para imágenes, embeds y banners (width/height o aspect-ratio).
- Evita popups tardíos que empujen contenido.
- No insertes elementos arriba del contenido ya cargado (especialmente ads y barras).
AdSense sin arruinar tu CLS
AdSense puede empeorar CLS si los anuncios empujan contenido. Para evitarlo:
- Define contenedores con altura mínima para tus slots (en especial above-the-fold).
- Evita insertar ads “arriba” después de cargar (primero el contenido, luego el relleno).
- No saturar de scripts: cada script extra puede pegarle a INP (sobre todo en mobile).
- Revisa PSI con ads activos: optimizar sin ads y publicar con ads es auto-sabotaje.
Nota: optimización mejora experiencia, pero no garantiza aprobación o ingresos. Lo que sí garantiza: menos rebote por frustración.
Prompt para tu dev (o para ti mismo si tocas front)
Pega tus resultados de PageSpeed (mobile) y tu stack. Esto te devuelve un plan accionable:
Actúa como performance engineer.
Con este reporte de PageSpeed (pego resultados) y mi stack (Django + templates),
dame:
1) 5 long tasks probables y cómo trocearlas
2) scripts de terceros a diferir/eliminar (en orden de prioridad)
3) cuál es mi elemento LCP y cómo precargarlo
4) fixes CLS típicos para mi layout (incluyendo slots de AdSense)
5) checklist de QA antes de deploy (mobile-first)
Devuélveme acciones en orden: impacto alto → medio → bajo.QA y monitoreo (donde la mayoría falla)
QA práctico (15 minutos)
- Simula 4G lento + CPU x4 (para acercarte al mundo real).
- Prueba con y sin extensiones (modo incógnito) para evitar falsos positivos.
- Revisa tu página con ads/trackers activos (ahí se rompe INP/CLS).
- Haz 3 acciones humanas: scroll, clic en menú, clic en un CTA. Si “se traba”, INP te está matando.
Monitoreo simple (semanal)
- Search Console: mira el reporte de Core Web Vitals (mobile primero).
- PageSpeed Insights: revisa 3 URLs clave (home + 2 posts top).
- Log de cambios: cada vez que agregues un script o formato de ads, anótalo. Te ahorra horas de “¿por qué se rompió?”.
Preguntas frecuentes
¿Por qué INP me afecta tanto aunque la web “cargue rápido”?
Porque INP mide respuesta a interacciones. Puedes tener un buen LCP, pero si el JavaScript está ocupado, el clic se siente lento y la web “se traba”.
¿Qué debo priorizar si tengo poco tiempo?
Empieza por mobile y por URLs en estado “Poor”. Luego ataca la métrica que falla (INP/LCP/CLS) con acciones de alto impacto (scripts, imágenes, espacios reservados).
¿PageSpeed me da bien, pero Search Console me da mal. ¿A quién creo?
A Search Console (field data). PSI también muestra datos reales arriba, pero el score y diagnóstico de abajo es laboratorio. El objetivo final es mejorar experiencia real.
¿Esto mejora mi SEO automáticamente?
Mejora experiencia y puede ayudar, pero SEO es multivariable (contenido, autoridad, intención, técnico). Lo que sí suele mejorar rápido: retención, rebote y conversión.
