Corinthavexi

Mejorar LCP en 200 milisegundos llevó tres semanas completas

Mejorar LCP en 200 milisegundos llevó tres semanas completas

El LCP está en 3.2 segundos. No es terrible, pero tampoco pasa el umbral de 2.5 segundos. Ya optimizamos imágenes, implementamos lazy loading, configuramos CDN. Los números apenas se movieron.

Empiezo cada día revisando datos de campo en Search Console. El percentil 75 varía entre 3.1 y 3.4 segundos dependiendo del dispositivo. Las páginas de producto son peores que las de categoría. Móvil es consistentemente 800ms más lento que desktop.

Identificar cuellos de botella reales

Uso Chrome DevTools en throttling 4G para simular condiciones reales. El elemento LCP es la imagen principal del producto, pero no es el problema. El problema es que el contenedor de la imagen no tiene dimensiones hasta que carga un CSS crítico de 45KB que incluye estilos para todo el sitio.

Extraigo solo los estilos necesarios para above-the-fold y los inlineo en el HTML. Eso reduce el blocking time en 400ms. Pero ahora el siguiente problema: las fuentes web bloquean el render durante 600ms adicionales. Implemento font-display swap y precargo solo los weights que usamos arriba del fold.

Ganancias incrementales

Cada cambio mejora LCP entre 100 y 200 milisegundos. Después de tres semanas de ajustes: preconnect a dominios externos, resource hints específicos, optimizar el orden de carga de scripts, el LCP baja a 2.7 segundos.

Todavía no es verde. Faltan 200ms. El siguiente cuello de botella está en el servidor: el TTFB es de 400ms. Eso ya no lo puedo solucionar desde frontend. Toca hablar con infraestructura sobre caché de servidor y database queries.

¿Te resultó útil este artículo?