CORRIGE CADA CORE WEB VITAL

Largest Contentful Paint suele ser una imagen hero, un titular grande o un fotograma de póster. Encuentra ese elemento. Todo lo demás es secundario hasta que sea rápido.

Palancas que mueven LCP: comprime y redimensiona el recurso, usa un formato moderno, establece dimensiones, precarga la URL exacta cuando se descubre tarde, ponla en un CDN y reduce TTFB para que los bytes puedan empezar. Evita lazy-loading en la imagen LCP. Evita carruseles que retrasen el nodo LCP real.

Ángulo del servidor: si el HTML en sí es lento, ningún truco de imagen te salva. Arregla caché y origen primero.

Punto clave: Nombra el elemento LCP, luego haz ese archivo y su ruta de descubrimiento aburridamente rápidos.

Interaction to Next Paint se preocupa por qué tan rápido responde la página después de un toque o clic. JavaScript pesado en el hilo principal es el villano usual: hidratación grande, manejadores caros, scripts de terceros que corren para siempre.

Palancas: elimina o difiere terceros, divide manejadores, evita componentes sincronos grandes en páginas de marketing, prefiere HTML renderizado en servidor con islas pequeñas, y prueba en un dispositivo Android de gama media real, no solo en presets de throttling de escritorio.

Punto clave: INP mejora cuando quitas trabajo del hilo principal, no cuando microoptimizas una transición CSS.

Cumulative Layout Shift es inestabilidad visual. Imágenes sin dimensiones, fuentes que cambian tarde y redimensionan texto, anuncios e incrustaciones que abren un agujero en el layout, banners inyectados encima del contenido.

Palancas: ancho y alto o aspect-ratio en CSS en medios, espacios reservados para anuncios, estrategias de font-display que no detonan layout, y sin UI de carga tardía encima del contenido existente. Prefiere transformar espacio existente sobre insertar bloques nuevos en la parte superior.

Idea clave: Si algo aparece después, reserva su espacio antes.

Idea clave: La mayoría de los fallos repetidos son errores de proceso, no micro-optimizaciones faltantes.

Orden de operaciones en un sitio que falla: resuelve LCP, luego INP, luego CLS. Vuelve a medir datos de campo entre pasos. Usa la lista de verificación de CWV como compuerta de lanzamiento y la guía de sitio lento cuando aún no puedas distinguir servidor de front end.

Pasar los tres en el percentil 75 en móvil es suficiente. No retengas un lanzamiento por 100s de laboratorio una vez que los datos de campo estén saludables.

Idea clave: Resuelve LCP primero. INP y CLS son más fáciles una vez que la ruta del contenido principal es honesta.

Día 1: obtén datos de campo, identifica el elemento LCP en las tres plantillas principales, lista cada script de terceros con un propietario. Días 2 y 3: implementa solo los arreglos de media y descubrimiento de LCP. Día 4: elimina o difiere los peores terceros y vuelve a verificar INP en un teléfono. Día 5: reserva espacio para los infractores de CLS que puedas ver en la experiencia de campo. Días 6 y 7: vuelve a medir, documenta lo que queda, y decide si el trabajo restante es bloqueante para el lanzamiento.

Esa semana supera un mes de refactores mixtos porque cada día tiene una métrica y un ciclo de evidencia. Si LCP sigue en rojo después del día 3, no inicies una limpieza del sistema de diseño. Mantente en el elemento LCP hasta que se mueva.

Idea clave: Una métrica por día con re-medición supera un backlog de rendimiento mixto.