Lo único que mide tu cliente
El usuario no mide TTFB ni LCP. Mide "¿se siente rápido?". Esa percepción depende de tres momentos: cuándo aparece el contenido, cuándo se puede interactuar, y cuán fluido es el scroll. El resto es ruido.
La lista corta
1. Carga el HTML rápido
Server-side rendering, edge cache de páginas estáticas, y un servidor cercano al usuario. Si tu HTML inicial tarda más de 500 ms, ningún truco de frontend lo arregla.
2. No bloquees el primer pintado
Fuentes con font-display: swap, scripts diferidos (async o defer), CSS crítico inline si es agresivo. El navegador necesita pintar algo en menos de 1.5 s.
3. Lazy-load lo pesado
3D, animaciones complejas, editores ricos: cargan después de la interacción, no en el bundle inicial. requestIdleCallback es tu amigo para hidratar lo no crítico.
4. Imágenes responsables
Formato moderno (AVIF/WebP), srcset por densidad y tamaño, loading="lazy" salvo el hero. Un solo PNG de 2 MB destruye todo el trabajo de optimización.
5. Cuida el scroll
will-change solo donde lo necesitas y por poco tiempo. Animaciones de opacity y transform, no de top/left/blur. Un scroll que se traba pesa más que medio segundo de carga.
La trampa de los puntajes
Lighthouse puntúa en un laptop ideal con red simulada. Tu usuario tiene un Android medio y wifi de café. Mide con throttling realista o con datos reales (CrUX, Web Vitals en producción).
En cinco palabras
Menos JS, menos bloqueo, más cache.