La tua web app è lenta? Il problema non è il server.

La web app è lenta. Gli utenti si lamentano. Il team propone di comprare un server più grande. Il server più grande costa il triplo, migliora le cose per qualche mese, e poi il problema torna. A quel punto qualcuno suggerisce di "riscrivere tutto". E il ciclo ricomincia.

Se questo scenario ti suona familiare, probabilmente il tuo problema non è il server. Non è nemmeno il linguaggio di programmazione o il framework. Il problema, nella maggior parte dei casi, è come il codice parla con il database. E il tuo team potrebbe non saperlo.

Come funziona il problema (spiegato senza tecnicismi)

Ogni volta che un utente apre una pagina del tuo prodotto, il codice fa delle richieste al database per recuperare le informazioni da mostrare. Fin qui, tutto normale.

Il problema è quante richieste fa.

Immagina di dover compilare un elenco di 100 clienti con il loro ultimo ordine. Un essere umano andrebbe in archivio, prenderebbe la lista dei clienti e i loro ordini in un colpo solo. Logico, efficiente.

Il software, se scritto in un certo modo, fa l'equivalente di: vai in archivio, prendi il nome del primo cliente, torna alla scrivania. Vai in archivio, prendi l'ordine del primo cliente, torna alla scrivania. Vai in archivio, prendi il nome del secondo cliente, torna alla scrivania. E così via, 201 volte invece di una.

Questo si chiama problema N+1, ed è la causa più comune di lentezza nelle applicazioni web. Non è un bug — il risultato è corretto, i dati mostrati sono giusti. Ma il modo in cui vengono recuperati è drasticamente inefficiente.

La parte insidiosa? Il codice che causa questo problema sembra perfettamente scritto. Rispetta tutte le convenzioni del framework, passa le code review, e nessuno si accorge del problema finché non misura.

Perché succede (e perché il tuo team potrebbe non accorgersene)

I framework moderni — Laravel, Symfony, Rails, Django — usano strumenti chiamati ORM che permettono agli sviluppatori di lavorare con il database senza scrivere direttamente le query. È come avere un traduttore simultaneo: lo sviluppatore parla in PHP o Python, e l'ORM traduce in linguaggio database.

Il vantaggio è la velocità di sviluppo. Lo svantaggio è che lo sviluppatore non vede più le query. Non sa quante ne vengono generate, non sa se sono efficienti, non sa se stanno rallentando tutto. È come guidare un'auto senza contachilometri: puoi andare a 200 all'ora senza rendertene conto.

Il risultato è un paradosso che chi gestisce un prodotto dovrebbe conoscere: il codice più "pulito" secondo le best practice del framework può essere il più lento in produzione. Il team segue le convenzioni, scrive codice leggibile e manutenibile, e intanto il database è sotto stress per centinaia di query inutili.

Per un approfondimento tecnico su questo problema, ho scritto un articolo dedicato: Il tuo ORM non ti sta aiutando.

I segnali d'allarme che dovresti riconoscere

Non serve essere tecnici per capire se il tuo prodotto ha questo problema. Ecco cosa cercare.

Le pagine diventano più lente col tempo

All'inizio tutto funzionava bene. Con 100 utenti e pochi dati, il prodotto era scattante. Ora con 10.000 utenti le pagine ci mettono secondi a caricare. Se il rallentamento è proporzionale alla crescita dei dati, quasi certamente il problema è nel modo in cui vengono interrogati — non nella quantità.

I costi di infrastruttura crescono più velocemente del business

Il numero di utenti è raddoppiato, ma i costi server sono triplicati. Questo squilibrio è un classico segnale di query inefficienti: il database lavora molto di più del necessario, e servono macchine sempre più potenti per compensare.

Il team propone soluzioni hardware a problemi software

"Ci serve un database più grande", "dovremmo aggiungere un livello di cache", "passiamo a un servizio managed più costoso". Queste frasi spesso significano: il software non è ottimizzato, ma è più facile spendere soldi che riscrivere codice.

Un server più potente maschera il problema. La cache aggiunge complessità (e bug). Il servizio managed costa di più ogni mese. Nessuna di queste soluzioni affronta la causa.

Le feature nuove rallentano tutto il resto

Il team aggiunge una nuova sezione al prodotto e improvvisamente anche le pagine esistenti diventano più lente. Questo succede quando le nuove query si sommano a quelle esistenti, e il database — che era già al limite — non regge il carico aggiuntivo.

Quanto costa non intervenire

Parliamo di impatto concreto sul business.

Utenti che se ne vanno

I dati sono noti: il 53% degli utenti mobile abbandona una pagina che impiega più di 3 secondi a caricare. Per un e-commerce, ogni secondo di ritardo nel caricamento riduce le conversioni del 7%. Se il tuo prodotto è lento, stai perdendo utenti e non lo sai — perché chi se ne va non ti scrive per dirti perché.

Scaling impossibile

Se con 10.000 utenti il database fa 2 milioni di query al giorno quando potrebbe farne 200.000, cosa succede quando arrivi a 100.000 utenti? Non puoi semplicemente comprare un server 10 volte più grande. Arriva un punto in cui il costo dell'infrastruttura supera il budget, o il database fisicamente non regge — indipendentemente da quanto spendi.

Le aziende che hanno query ottimizzate scalano linearmente: doppi utenti, doppio costo. Quelle con query inefficienti scalano esponenzialmente: doppi utenti, costo quadruplicato.

Velocità di sviluppo che rallenta

Quando il database è costantemente sotto stress, ogni nuova feature diventa rischiosa. Il team inizia a muoversi con cautela, i tempi di sviluppo si allungano, e la risposta a "possiamo aggiungere questa funzionalità?" diventa sempre più spesso "sì, ma ci vorranno mesi". Il debito tecnico sulle performance si trasforma in debito su tutta la roadmap.

La domanda che dovresti fare al tuo team

C'è una domanda semplice che rivela immediatamente se il tuo prodotto ha questo problema:

"Quante query al database fa la nostra pagina principale?"

Se il team risponde con un numero preciso — "12 query, le abbiamo misurate la settimana scorsa" — probabilmente state bene. Il team monitora, sa cosa succede, e interviene quando serve.

Se la risposta è un'esitazione, un "non lo so di preciso", o un "dovrei controllare" — è un segnale. Non necessariamente di incompetenza: molti team eccellenti non misurano perché nessuno glielo ha chiesto. Ma se non misurano, non possono sapere se c'è un problema.

Altre domande utili:

• "Abbiamo un sistema di monitoring delle query?" Se la risposta è no, il team sta guidando alla cieca.
• "Quanto tempo impiega la query più lenta in produzione?" Se nessuno lo sa, nessuno sta guardando.
• "Le performance sono peggiorate negli ultimi sei mesi?" Se sì, il trend continuerà finché qualcuno non interviene.

Cosa fare concretamente

Se sospetti che il tuo prodotto abbia un problema di performance legato al database, ecco un piano d'azione realistico.

Fase 1: Misurare (1 giorno)

Chiedi al team di installare uno strumento di monitoring delle query. In Laravel è un plugin che si aggiunge in un'ora. In altri framework esistono equivalenti. Il primo passo è vedere quante query fa ogni pagina e quanto tempo impiegano. Spesso il risultato è una sorpresa.

Fase 2: Identificare i punti critici (2-3 giorni)

Una volta che vedete i numeri, i problemi saltano fuori da soli. La pagina della dashboard che fa 347 query. L'endpoint dell'API che impiega 4 secondi. Il report che manda il database in ginocchio ogni lunedì mattina. Fate una lista ordinata per impatto.

Fase 3: Ottimizzare le query critiche (1-2 settimane)

Non serve riscrivere tutto. Nella maggior parte dei casi, il 20% delle pagine causa l'80% del carico. Ottimizzare quelle poche query critiche — passando da centinaia di richieste inefficienti a poche richieste mirate — produce un miglioramento drammatico con un investimento contenuto.

Fase 4: Prevenire (continuo)

Una volta risolti i problemi esistenti, il passo più importante è non tornare alla situazione precedente. Un alert automatico quando una pagina supera un certo numero di query, una metrica di performance nella dashboard del team, un check nelle code review. Piccoli accorgimenti che costano quasi nulla e prevengono il ripetersi del problema.

Il costo dell'intervento vs il costo dell'inazione

Riepiloghiamo.

Intervenire costa 2-3 settimane di lavoro del team — una volta — più un minimo di monitoring continuativo. Il risultato: un prodotto più veloce, costi server ridotti, capacità di scalare, utenti più soddisfatti.

Non intervenire costa server sempre più grandi (centinaia o migliaia di euro al mese in più), utenti persi, sviluppo rallentato, e prima o poi la proposta di "riscrivere tutto da zero" — che costa mesi e non garantisce che il problema non si ripresenti.

Il calcolo è semplice. Ma richiede che qualcuno faccia la prima domanda: "quante query fa questa pagina?"

Se sospetti che il tuo prodotto abbia problemi di performance e vuoi capire da dove partire, parliamone. Un'analisi mirata spesso rivela miglioramenti significativi con interventi contenuti.