De 4.2s a 1.1s: optimizar para el hardware que la gente sí tiene

El rendimiento no es una métrica de vanidad. Cuando construí Kybernet — una plataforma multi-tenant para negocios pequeños mexicanos — la carga promedio era de 4.2 segundos. En mi laptop de desarrollo se sentía bien. En la computadora de una barbería con 4 GB de RAM y Chrome con quince pestañas abiertas, era el momento exacto en que el usuario cerraba la página.

El rendimiento es UX: en hardware modesto, 3 segundos ahorrados deciden si la herramienta se usa.

Primero medir, nunca adivinar

Antes de tocar una línea, abrí el panel de Performance y un throttling de CPU 4x con red 'Fast 3G'. Simular el equipo real cambia todo: el bundle de JavaScript que en fibra tardaba 200 ms bloqueaba el hilo principal casi dos segundos. El cuello de botella no era la red — era el parseo y ejecución de JS.

1. Code splitting por ruta

El error clásico: todo el panel de administración viajaba en el bundle inicial, aunque el 90% de las sesiones nunca lo abría. Moví cada vista pesada detrás de un import dinámico, con un fallback ligero mientras carga.

// Antes: todo en el bundle inicial
import AdminDashboard from "./AdminDashboard";

// Después: se carga solo cuando se necesita
const AdminDashboard = lazy(() => import("./AdminDashboard"));

<Suspense fallback={<PanelSkeleton />}>
  <AdminDashboard />
</Suspense>

2. Assets: el peso invisible

• Imágenes servidas en WebP con tamaños responsivos en vez de PNG de 1 MB.
• Fuentes con display: swap y subsetting — solo los caracteres latinos que uso.
• Íconos como SVG inline, no una librería de 300 KB por tres glifos.

Anécdota real de este mismo portafolio: encontré un favicon.png de 954 KB. Un favicon. Regenerado desde su SVG quedó en 11 KB. Nadie lo nota hasta que auditas — y esos detalles son exactamente lo que separa un sitio que 'se siente rápido' de uno que lo es.

3. No bloquear el render

Lo último fue orden de carga: datos críticos primero, todo lo demás después del primer pintado. El realtime de Supabase, los gráficos y la analítica se suscriben tras montar, no antes. El usuario ve la interfaz utilizable mientras lo secundario llega en segundo plano.

El resultado

Carga promedio de 4.2s a 1.1s en el mismo hardware de gama baja. Ninguna reescritura mágica — solo medir el equipo real, partir el bundle, adelgazar los assets y ordenar la carga. La lección que me quedó: optimiza para la peor máquina de tu usuario, no para la mejor de tu escritorio.