Performance del codice AI: ottimizzazioni reali

Il codice generato con assistenti AI funziona. Ma "funziona" non significa "funziona velocemente, scalabilmente, economicamente". L'AI ottimizza per "fai funzionare la feature", non per "fai in modo che 10.000 utenti contemporanei non facciano collassare il server".

In questa guida vediamo dove guardare per ottimizzare davvero un'app vibe-coded, in ordine di ROI: dalle vittorie facili agli interventi profondi.

Quattro categorie di ottimizzazione

Le ottimizzazioni si dividono in quattro grandi famiglie, ognuna con investimento e impatto diverso:

Si parte sempre dalle prime due. Le ultime due hanno senso quando l'app cresce davvero.

1. Frontend: Core Web Vitals

Sono le metriche che Google misura ufficialmente: LCP, CLS, INP. Pesano sul ranking SEO e sull'esperienza utente. Le ottimizzazioni qui sono spesso quick win.

Interventi tipici:

• Comprimere immagini con formati moderni (WebP, AVIF)
• Lazy loading per immagini below-the-fold
• Caricamento font con display: swap
• Riduzione del JavaScript inviato al client
• CSS critico inline, resto async

Risultato atteso: LCP da 4-5 secondi a sotto 2.5, drastico miglioramento della percezione utente, +punti SEO.

2. Database: dove vince/perde un'app

Il 70% dei problemi di performance sta nel database. L'AI raramente ottimizza le query: scrive il codice che funziona, non il codice che è veloce.

Cosa cercare:

• Query senza indici sulle colonne usate in WHERE / JOIN
• N+1 query problem (una query nel loop che doveva essere unica)
• Mancanza di paginazione (caricare 10.000 record a ogni request)
• Connection pool non configurato

Strumenti utili: ogni database ha tool di profilazione che mostrano le query lente. Il pareto è quasi sempre presente: il 5% delle query causa il 95% del tempo.

3. Backend: caching e operazioni asincrone

Quando lo stesso dato viene letto 1000 volte ma cambia poche volte al giorno, leggerlo dal database ogni volta è uno spreco.

Tecniche standard:

• Caching applicativo in memoria dedicata per dati ad alta lettura
• Caching HTTP (CDN o edge) per asset e pagine pubbliche
• Operazioni asincrone: invio email, generazione report → in coda, non bloccano la response
• Batch processing: aggregare richieste simili invece di processarle una a una

ROI: caching ben fatto può ridurre il carico backend del 60-80% senza cambiare una riga di logica di business.

4. Costi cloud: il bottleneck nascosto

Una variante dell'ottimizzazione che spesso si dimentica: ridurre i costi di infrastruttura.

Aree tipiche:

• Container sovradimensionati che girano al 5% di CPU
• Storage non pulito (log, backup, file orfani)
• Servizi attivi 24/7 quando servono solo in orario lavorativo
• Outbound traffic non ottimizzato (no CDN)

Un audit costi di un'app cloud trova quasi sempre il 30-50% di risparmio possibile senza degradare il servizio.

Anti-pattern frequenti nelle app AI-generated

Tre pattern che vediamo ricorrere:

1. Caricamento sequenziale di chiamate API parallelizzabili

L'AI scrive await chiamata1; await chiamata2; await chiamata3; quando le tre chiamate sono indipendenti. Risultato: 600ms invece di 200ms.

Fix: parallelizzare con Promise.all o equivalente.

2. Rendering di tutto, sempre

Pagine che caricano l'intero dataset all'apertura, anche se l'utente ne vede 10 elementi. CPU sprecata, RAM sprecata, esperienza utente lenta.

Fix: paginazione, virtual scrolling, lazy loading sezioni.

3. Configurazione produzione = configurazione sviluppo

Stesse impostazioni in dev e prod: log a livello debug, no compressione asset, no caching. Ottimo in dev, disastroso in prod.

Fix: configurazioni ambiente-specifiche, con prod ottimizzata.

Sequenza pratica di ottimizzazione

In un audit performance seguiamo sempre questo ordine:

1. Profilazione baseline: misurazione delle pagine più visitate
2. Quick win frontend: immagini, font, CSS — in 1-2 giorni
3. Database optimization: indici, query lente — in 2-5 giorni
4. Caching strategy: dove e come — in 2-3 giorni
5. Async operations: code, batch — in 1-3 giorni
6. Cloud cost review: pulizia + rightsizing — in 1-2 giorni
7. Verifica finale: misurazione post-ottimizzazione, report

Totale: 8-15 giorni per un round di ottimizzazione su un'app di media complessità.

Conclusione

L'ottimizzazione di un'app AI-generated è quasi sempre un'ottima fonte di valore: gli LLM lasciano molto sul tavolo perché ottimizzano per "funziona", non per "è veloce". Un primo round di ottimizzazione mirata produce risultati visibili — sia in performance percepita che in costi cloud — con investimento contenuto.

La regola d'oro: misurare prima, ottimizzare poi. Senza dati reali, qualsiasi ottimizzazione è ipotesi. Con dati reali, è investimento.