Nota técnica
De 4s a 1.5s en plataformas internas bancarias
Qué medimos y qué cambiamos en Santander Consumer para bajar tiempos de carga ~62% en apps React/Next.js que procesan 600+ operaciones por día.
En números
600+
Operaciones / día
−62%
Tiempo de carga
4s → 1.5s
LCP aprox.
100%
TypeScript
Contexto real
En Santander Consumer trabajo sobre plataformas internas: seguros, asistencia y sistemas bancarios de uso diario por operadores y clientes. No es un landing marketing — hay formularios largos, tablas con paginación, validaciones y llamadas a varios servicios REST. Cuando una pantalla tarda 4 segundos en ser usable, el costo no es solo UX: frena operación y genera retrabajo en soporte.
Medir antes de optimizar
El primer paso fue acordar qué medíamos: Lighthouse en CI, Web Vitals en staging y revisión manual de las 5 pantallas con más tráfico. Encontramos tres patrones repetidos: bundles demasiado grandes en el first load, waterfalls de fetch secuenciales al montar la página, y componentes pesados renderizados aunque no estaban visibles.
Cambios que sí movieron la aguja
Aplicamos lazy loading de rutas y de módulos secundarios, movimos data fetching a server components / loaders donde el stack lo permitía, y paralelizamos requests independientes en el cliente. Para tablas grandes, paginación server-side y skeletons en lugar de bloquear toda la vista. Nada exótico — pero aplicado de forma consistente en los flujos críticos.
// Antes: waterfall al montar el dashboard
const customer = await fetchCustomer(id);
const policies = await fetchPolicies(id);
const claims = await fetchClaims(id);
// Después: requests independientes en paralelo
const [customer, policies, claims] = await Promise.all([
fetchCustomer(id),
fetchPolicies(id),
fetchClaims(id),
]);Calidad en entorno regulado
En banca no alcanza con que cargue rápido: TDD en lógica de negocio, PRs con typecheck estricto y pipelines CI/CD con Git. También trabajamos con Docker/Kubernetes en una arquitectura de microservicios y flujos event-driven con funciones serverless (AWS Lambda) para ciertos procesos. La performance y la mantenibilidad van juntas cuando el deploy es frecuente.
Resultado
Pasamos de ~4s a ~1.5s en las pantallas objetivo (~62% de mejora). El cambio más valioso no fue un truco puntual sino repetir el mismo checklist en cada feature nueva: medir, recortar bundle, paralelizar IO, validar en staging con datos reales.
Takeaways
- Medir en pantallas de alto tráfico, no en promedios globales
- Paralelizar fetches independientes antes de micro-optimizar CSS
- Lazy loading de rutas y módulos secundarios en apps internas pesadas
- CI/CD + TypeScript estricto evitan regresiones de performance
- ~62% menos tiempo de carga con cambios incrementales, no rewrite