PageSpeed Front-end (NDA): como aceleramos sitios reales sin romper el flujo del producto

La mayoria de equipos se encuentra con performance demasiado tarde.

Al principio todo parece normal: las animaciones van fluidas en tu portatil, el diseño esta aprobado y el sprint cierra a tiempo. Luego llega un reporte real desde un dispositivo real en una red floja, y de pronto la pagina que parecia moderna se abre como una app pesada de 2014.

Este texto no va de perseguir una captura perfecta de Lighthouse. Va de hacer que el sitio se sienta rapido para personas que no tienen hardware perfecto, Wi-Fi perfecto ni paciencia infinita.

Cuando trabajamos en un sitio cargado de contenido, modales, media sections y bloques interactivos, la mejora mas fuerte vino de un cambio de mentalidad: dejar de cargarlo todo "por si acaso".

1. Cargar por intencion, no por miedo

Mucho front-end lento nace del mismo reflejo: importar todo en el entry principal porque tal vez se use. Eso infla JS, castiga parseo y desplaza trabajo al peor momento posible: la carga inicial.

Empezamos a mover logica y modulos a puntos de activacion concretos:

• por click;
• por scroll;
• al abrir un modal;
• al entrar en un bloque visible;
• al llegar a una ruta donde de verdad hace falta.

No es una idea nueva. La diferencia esta en aplicarla con disciplina.

2. Composables pequenos y predecibles

En vez de dejar listeners y side effects repartidos por componentes grandes, sacamos piezas pequenas y reutilizables. Eso redujo ruido, facilito profiling y nos permitio ver con claridad que codigo corria demasiado pronto.

Cuando el comportamiento esta encapsulado en un composable sano, tambien es mas facil decidir si debe vivir en carga inicial o en import dinamico.

3. Dynamic imports activados por comportamiento real

Un patron que dio muy buen resultado fue cargar ciertas partes solo despues de una accion del usuario o una senal clara del viewport.

const openGallery = async () => {
  const { initGallery } = await import('./gallery')
  initGallery()
}

No cargamos una galeria pesada para cada visita. La cargamos cuando alguien realmente quiere usarla.

Lo mismo con widgets secundarios, zonas administrativas, pickers avanzados o bloques que quedan muy abajo en la pagina.

4. Scroll como señal, no como excusa para abuso

Scroll-triggered loading funciona bien cuando se usa con criterio. No para montar una feria de observers sin control.

Si un bloque esta lejos del viewport, no hay razon para pagarlo en el primer segundo. Pero el umbral y el fallback importan. Si lo cargas demasiado tarde, la experiencia tambien se siente rota.

Performance util no es "cargar menos a toda costa". Es cargar en el momento correcto.

5. Sprite splitting y assets con sentido

Otra mejora real vino de revisar imagenes e iconos, no solo JavaScript. Cuando un sprite o un paquete de assets se vuelve demasiado gordo, cada pantalla paga por recursos que ni siquiera muestra.

Dividir sprites, mover iconos no criticos y limpiar assets heredados suele parecer poco glamuroso, pero tiene impacto real en tiempo de carga y en sensacion de ligereza.

6. Menos obsesion por score, mas atencion a flujo

Uno de los errores mas comunes es optimizar para una captura de Lighthouse y romper el flujo del producto. Si escondes cosas utiles, retrasas interacciones clave o introduces flashes raros solo para ganar unos puntos, no estas mejorando el producto. Solo estas maquillando una metrica.

Nosotros miramos score, claro. Pero mas importante era esto:

• la pagina responde mas rapido;
• el contenido principal aparece antes;
• la interaccion clave no espera basura secundaria;
• el usuario siente menos friccion.

7. Performance como parte del sistema

La optimizacion que de verdad aguanta no vive en una sola PR heroica. Vive en reglas repetibles:

• no importar pesado arriba sin necesidad;
• revisar que modulos pueden ir por demanda;
• vigilar third-party scripts;
• revisar assets antes de meterlos;
• volver a medir despues de cambios visuales.

Si el equipo trata performance como disciplina, el sitio se mantiene sano. Si lo trata como una campaña puntual, la regresion vuelve rapido.

Cierre

En produccion, PageSpeed no mejora por magia ni por una tweak secreta. Mejora cuando el equipo deja de cargar todo por reflejo y empieza a cargar por contexto real.

Menos peso inicial. Menos codigo ansioso. Mas respeto por el flujo del producto.

Eso es lo que de verdad hace que un sitio se sienta rapido.