CORREGIR CADA INDICADOR DE WEB VITAL
Tres métricas, tres trabajos distintos. Las soluciones concretas que influyen en cada una de ellas, sin entrar en detalles teóricos.
← Todas las guías Todas las guías de este tema
LCP: haz que el contenido principal se cargue rápido
El «Largest Contentful Paint» suele ser una imagen destacada, un titular grande o un recuadro de póster. Identifica ese elemento. Todo lo demás es secundario hasta que se cargue rápidamente.
Factores que influyen en el LCP: comprime y redimensiona el recurso, utiliza un formato moderno, establece las dimensiones, precarga la URL exacta cuando se pueda detectar más tarde, alójala en una CDN y reduce el TTFB para que los bytes puedan empezar a cargarse. Evita la carga diferida de la imagen del LCP. Evita los carruseles que retrasen el nodo real del LCP.
Perspectiva del servidor: si el propio HTML llega tarde, ningún truco con imágenes te salvará. Arregla primero la caché y el origen.
Conclusión clave: Asigna un nombre al elemento LCP y, a continuación, haz que ese archivo y su ruta de acceso se carguen con una rapidez asombrosa.
INP: mantener libre el hilo principal
«Interaction to Next Paint» mide la rapidez con la que responde la página tras un toque o un clic. El JavaScript pesado en el hilo principal suele ser el culpable: una «hidratación» excesiva, controladores que consumen muchos recursos y scripts de terceros que se ejecutan sin fin.
Medidas: eliminar o posponer el uso de terceros, dividir los gestores, evitar componentes síncronos de gran tamaño en las páginas de marketing, dar prioridad al HTML renderizado en el servidor con pequeñas «islas», y realizar pruebas en un dispositivo Android real de gama media, no solo en un entorno de escritorio con configuración preestablecida de limitación de rendimiento.
Conclusión clave: el INP mejora cuando se retira trabajo del hilo principal, no cuando se realiza una microoptimización de una transición CSS.
CLS: evitar que la página salte
El «Cumulative Layout Shift» (cambio acumulativo de diseño) es una inestabilidad visual. Imágenes sin dimensiones, fuentes que se cambian tarde y que modifican el tamaño del texto, anuncios y elementos incrustados que dejan un hueco en el diseño, y banners insertados encima del contenido.
Herramientas: ancho y alto o relación de aspecto CSS en los medios, espacios reservados para anuncios, estrategias de visualización de fuentes que no alteren el diseño y ausencia de elementos de interfaz de usuario de carga tardía sobre el contenido existente. Se prefiere transformar el espacio existente antes que insertar nuevos bloques en la parte superior.
Conclusión clave: Si algo va a aparecer más adelante, reserva su espacio con antelación.
Los errores que siguen repitiéndose cada
| Métrico | Errores habituales | Será mejor que me vaya |
|---|---|---|
| LCP | Carga diferida del «hero» | Eager + precargar la URL real del LCP |
| LCP | Optimización de una imagen que no es LCP | Identifica primero el nodo LCP |
| INP | Culpar a las animaciones CSS | Eliminar JS y elementos de terceros |
| INP | Pruebas realizadas únicamente en ordenador de sobremesa | Utiliza un móvil de gama media |
| CLS | Ignorar las métricas de las fuentes | Seleccionar fuentes, reservar espacio |
| CLS | Banners de cookies sin espacio | Reserva o superpone con cuidado |
Conclusión clave: La mayoría de los fallos recurrentes se deben a errores en los procesos, no a la falta de microoptimizaciones.
Cómo aprobar las tres asignaturas
Orden de las operaciones en un sitio con fallos: borra primero el LCP, luego el INP y, por último, el CLS. Vuelve a medir los datos de campo entre cada paso. Utiliza la lista de comprobación del CWV como punto de partida y la guía para sitios lentos cuando aún no puedas distinguir entre el servidor y el front-end.
Basta con superar los tres en el percentil 75 en dispositivos móviles. No retrases el lanzamiento a la espera de obtener puntuaciones de 100 en las pruebas de laboratorio una vez que los datos de campo sean satisfactorios.
Conclusión clave: Resuelve primero el LCP. El INP y el CLS resultan más fáciles una vez que la ruta principal del contenido es fiable.
Un plan de rescate de una semana
Día 1: recopilar datos de campo, nombrar el elemento LCP en las tres plantillas principales y enumerar todos los scripts de terceros con un responsable. Días 2 y 3: implementar únicamente las correcciones de LCP relacionadas con los medios y el descubrimiento. Día 4: eliminar o posponer los scripts de terceros más problemáticos y volver a comprobar el INP en un teléfono. Día 5: reservar espacio para los casos de incumplimiento de CLS que se observen en la experiencia de usuario. Días 6 y 7: volver a medir, documentar lo que queda y decidir si el trabajo pendiente supone un obstáculo para el lanzamiento.
Esa semana es mejor que un mes de refactorizaciones variadas, porque cada día tiene una métrica y un ciclo de verificación. Si el LCP sigue en rojo después del tercer día, no empieces a limpiar el sistema de diseño. Sigue trabajando en el elemento del LCP hasta que cambie.
Conclusión clave: Una métrica al día, con una nueva medición, es mejor que un historial de resultados dispares.