Le prestazioni sono architettura, non un dettaglio da sistemare dopo

In troppi progetti le prestazioni vengono trattate come un passaggio finale, qualcosa da «ottimizzare più avanti». A quel punto sono ormai diventate un problema di architettura con una scadenza incombente, e le soluzioni economiche non ci sono più. I sistemi veloci sono progettati per esserlo fin dall'inizio.

La lentezza raramente dipende da un singolo bug: è il peso accumulato di cento piccole decisioni, tra query ridondanti, payload senza limiti, nessuna strategia di caching e operazioni che bloccano il rendering. Quando la lentezza diventa visibile, risolverla significa cambiare l'architettura, non modificare un'impostazione.

La soluzione è fare delle prestazioni un requisito misurato a ogni rilascio, non una speranza. Core Web Vitals, latenza p95 e budget per le dimensioni dei payload diventano criteri vincolanti: una modifica che li peggiora non viene rilasciata finché il problema non è risolto. Ciò che si misura e si vincola resta veloce.

• Distribuzione all'edge e una strategia di caching mirata per il percorso critico.
• Un livello dati che non genera query N+1 sotto carico.
• Payload e immagini delle giuste dimensioni, serviti in formati moderni.
• Osservabilità, per individuare i peggioramenti prima che li notino gli utenti.

Progettate per il giorno peggiore dell'anno (picchi di traffico, cache vuote, il grande lancio) e il giorno medio si gestirà da sé. Le prestazioni non sono una rifinitura: sono architettura.