Bambú Studio: Sprint de Core Web Vitals — 63→97 en días
Convertimos nuestro propio sitio en un caso real: de un score mobile de 63 a 97 en días, estabilizando el render del hero, optimizando imágenes críticas (AVIF/WEBP + srcset/sizes + fetchpriority), reordenando enqueues y gateando scripts de terceros. El LCP mobile bajó de 6.3s a 1.7s; FCP de 3.3s a 0.9s; CLS se mantuvo ~cero (0.001). Pasos claros y replicables—sin rodeos.
WordPress (LiteSpeed + QUIC.Cloud) — 5 días — LCP 6.3s→1.7s · CLS ≈0→0.001
Bambú Studio (antes) • Performance 63 • FCP 3.3s • LCP 6.3s — PSI mobile, 4G, 08/03/2025
Contexto (El problema real)
La homepage se veía genial, pero en mobile el primer render era lento y el elemento más grande (hero) llegaba tarde. Scripts de terceros competían por el bandwidth inicial y algunos assets no tenían dimensiones intrínsecas. Resultado: hesitación antes de scrollear y una primera impresión sluggish.Del diagnóstico a ganancias reales (el sprint)
Corrimos un mini audit desde PSI (mobile, 4G) para mapear los items de mayor impacto: LCP lento (6.3s), hero image tardío, CSS/JS render-blocking y scripts de terceros cargando demasiado temprano. Atacamos quick wins primero y validamos cada cambio.Qué hicimos — Performance
- Imágenes responsive (
srcset/sizes) + AVIF/WEBP yfetchpriority="high"en el hero para acortar el critical path. width/heightexplícitos (oaspect-ratio) para media above-the-fold para evitar reflow.- Reordenamos enqueues (CSS/JS) y agregamos exclusiones seguras de minify/combine para eliminar render-blocking.
- Gateamos/deferreamos scripts de terceros (analytics/widgets) más allá del LCP window.
- Font policy con
display=swapy preconnect donde era necesario para evitar FOIT. - LSCache + QUIC.Cloud tuning (cache TTLs, HTML/JS minify con excludes seguros) sin romper UX.
Qué hicimos — UX y Estabilidad
- Estabilizamos el comportamiento del header y reservamos espacio para elementos above-the-fold (layout predecible en viewports pequeños).
- Redujimos animaciones no críticas en la primera vista para mantener el main thread tranquilo.
| Qué hicimos | Por qué |
|---|---|
Hero preload + priority (fetchpriority) con srcset/sizes (AVIF/WEBP) | Trae el contenido first-visible antes → LCP más bajo y sensación de velocidad instantánea. |
| Dimensiones explícitas para imágenes above-the-fold | Previene layout shifts → las páginas se sienten sólidas y confiables (CLS ~0.001). |
| Reordenar enqueues + excluir minificación riesgosa | Sin render-blocking y sin romper UI; mejora FCP y Speed Index de forma segura. |
| Gateo/defer de terceros (analytics/chat/widgets) | Libera el main thread mientras los usuarios empiezan a interactuar; reduce ruido en LCP. |
Font policy (display=swap + preconnect) | El texto aparece rápido sin flicker; legibilidad inmediata. |
| LSCache + QUIC.Cloud tuning | Menor latencia y HTML más liviano sin sacrificar cart/checkout. |
| Lazy-loading para media off-viewport | Ahorra datos en 4G y mantiene el scroll suave. |
| Staging QA + mediciones repetidas | Mejoras estables, no solo spikes de lab; bajo riesgo en producción. |
Bambú Studio (después) • Performance 97 • FCP 0.9s • LCP 1.7s • TBT 30ms • CLS 0.001 — PSI mobile, 4G, 13/03/2025
FAQ — Transparencia primero
- ¿Siempre llegamos a 100? No. Scripts de terceros (ads, chat, maps, testing) pueden poner un ceiling. Maximizamos lo controlable y documentamos límites/trade-offs.
- ¿Se va a romper el diseño? No. Cambios iterativos con tests; staging primero cuando aplica.
- ¿Cuánto tiempo lleva? Audit rápido en 48h; un sprint típico es de 3–5 días dependiendo de los hallazgos.
- ¿Qué necesito de vos? Acceso WP/hosting, lista de plugins críticos e, idealmente, un entorno de staging.
Artículos interesantes
¿Listo para levantar tus Core Web Vitals?
Corremos sprints enfocados que estabilizan LCP/CLS y mantienen tu WordPress rápido—sin romper UX ni checkout.
