El rendimiento es un requisito, no una fase de optimización
Los equipos que tratan la velocidad como una preocupación posterior entregan software lento. Los presupuestos en CI cambian eso permanentemente.
Por VPFUnited Solutions
El trabajo de rendimiento programado para «después del lanzamiento» no ocurre. Para entonces la arquitectura ha absorbido las suposiciones que la hicieron lenta, y arreglarla significa deshacer decisiones que alguien ya asumió, un trabajo mucho más difícil que ajustar un parámetro.
La alternativa es poco glamurosa: fijar presupuestos y aplicarlos en el pipeline. Un tamaño máximo del bundle de JavaScript, un LCP máximo en un dispositivo de gama media con limitación, un número máximo de peticiones bloqueantes. Supera un presupuesto y el build falla, exactamente igual que un test que falla.
Esto funciona porque traslada la conversación al momento de la decisión. Un desarrollador que añade una dependencia de 90 KB se entera de inmediato, mientras echarse atrás todavía es barato, en lugar de tres meses después, cuando la dependencia ya es estructural.
Mide en el hardware que tus usuarios realmente tienen. Una máquina de desarrollo con fibra de oficina nunca revelará el problema. Una CPU y una red limitadas en CI te acercan a la verdad más que cualquier medición local.
El resultado no es dramático. No hay un sprint heroico de optimización al final, porque al software nunca se le permitió volverse lento en primer lugar. Considerablemente más barato. Considerablemente menos dramático.