La mayoría de developers optimiza Core Web Vitals para la métrica equivocada
Después de más de 100 proyectos de optimización de Core Web Vitals y una certificación directa de Google, puedo afirmar con confianza: el 90% de los developers que «optimizan» CWV lo hacen mal. No porque sean malos programadores — sino porque no entienden cómo Google mide realmente la experiencia del usuario.
Error #1: Optimizar para Lighthouse en lugar de para usuarios reales
El error más extendido. Un developer abre Lighthouse, ve una puntuación de 60, hace cambios hasta llegar a 90 y declara victoria. Problema: Lighthouse muestra datos de laboratorio. Google usa datos de campo (CrUX — Chrome User Experience Report) para rankear.
¿La diferencia? Lighthouse simula una conexión 4G en un dispositivo de gama media. Tus usuarios reales pueden estar en un iPhone 15 con fibra óptica o en un Android de hace 4 años con 3G. Los datos de campo capturan esta diversidad — Lighthouse no.
Qué hacer: Configura tracking de CWV con datos de campo reales. La librería web-vitals de Google enviada a Google Analytics 4 o a un dashboard de Looker Studio te da la imagen real.
Error #2: No entender INP
Desde marzo 2024, Interaction to Next Paint (INP) reemplazó a First Input Delay (FID) como Core Web Vital. Y la diferencia es brutal:
- FID solo medía el primer input y solo el delay (tiempo hasta que el browser empieza a procesar). La mayoría de sitios pasaba fácilmente.
- INP mide todas las interacciones durante toda la sesión y el tiempo completo (delay + processing + presentación visual). Es mucho más exigente.
Resultado: sitios que tenían FID de 50ms (excelente) pueden tener INP de 500ms (pobre). Muchos developers ni se han enterado del cambio.
Error #3: Lazy loading agresivo que mata LCP
Lazy loading es una optimización importante. Pero cuando aplicas loading="lazy" a todas las imágenes — incluyendo la hero image o el LCP element — estás diciéndole al browser que no cargue tu contenido más importante hasta que no sea visible. Resultado: LCP se dispara.
Regla: Las imágenes above-the-fold (especialmente el LCP element) deben tener loading="eager" y fetchpriority="high". Solo las imágenes below-the-fold deben ser lazy.
Error #4: Fonts que bloquean el render
Cargar Google Fonts con un simple link tag bloquea el rendering. El browser espera a descargar el CSS de fonts antes de pintar nada. Solución: self-hosting con font-display: swap y preload de los archivos woff2 críticos.
Error #5: JavaScript que bloquea el hilo principal
Tag managers, analytics, chat widgets, A/B testing tools — todos ejecutan JavaScript en el hilo principal. Cada script compite por tiempo de CPU. Cuando un usuario hace clic, el browser no puede responder hasta que termine de ejecutar el JS actual. Resultado: INP alto.
Soluciones:
- Defer todos los scripts no críticos
- Usa
requestIdleCallbackpara tareas no urgentes - Implementa un tag manager que cargue scripts condicionalmente
- Mide el Long Task budget de cada script third-party
Cómo hacemos nosotros la optimización CWV
- Diagnóstico con datos reales: No Lighthouse — configuramos RUM (Real User Monitoring) con la librería web-vitals de Google.
- Identificación del cuello de botella: ¿Es LCP? ¿INP? ¿CLS? Cada métrica requiere un enfoque diferente.
- Quick wins primero: Imágenes, fonts, caching — cambios que mejoran las métricas en días.
- Optimización profunda: JS splitting, SSR, edge rendering — cambios que requieren desarrollo.
- Monitorización continua: Dashboard en Looker Studio con alertas de regresión.
¿Tu PageSpeed no mejora por más que lo intentes? En ZDS tenemos certificación de Google y más de 100 proyectos de CWV optimizados. Solicita una auditoría técnica.
