Il gestionale Laravel è lento e nessuno sa dire perché. Prima si misura, poi si corregge, senza fermare chi lavora

Ti riconosci in almeno due di queste?

Rispondi a mente, senza dirlo a nessuno.

• La lista ordini ci mette otto secondi ad aprirsi, e "con più dati sarà peggio".
• Il cliente chiama la mattina perché il gestionale "è fermo", e la causa non si trova nei log.
• Ogni ottimizzazione tentata ha rotto qualcos'altro: ora nessuno tocca quella parte.
• Qualcuno ha proposto di riscrivere tutto: diciotto mesi e un preventivo a sei cifre.
• Il server è già stato raddoppiato due volte, e la lentezza è tornata.

Se hai detto sì almeno due volte, il problema non è il server: è che nessuno ha ancora misurato dove va il tempo.

Quanto costa davvero una schermata lenta?

Fai il conto sul tuo gestionale, non sulla media.

• Otto secondi per aprire una lista usata venti volte al giorno da dieci persone sono più di 100 ore l'anno passate a guardare una rotellina.
• Un blocco al mese di mezza giornata, per dieci persone, vale 60 ore l'anno più i clienti che aspettano.
• Un server raddoppiato costa ogni mese; la query senza indice costa un'ora una volta sola, se la si trova.
• Una riscrittura da diciotto mesi costa anche i diciotto mesi in cui il vecchio resta lento.

Da dove si parte con un gestionale Laravel lento?

Dalla misura, non dall'opinione. La prima settimana produce numeri, non promesse.

1. Log delle query per schermata: quante, quanto pesano, quali si ripetono (il classico N+1 di Eloquent, che moltiplica una query per ogni riga).
2. Profilo delle richieste più lente in produzione, con tempi reali degli utenti, non del portatile dello sviluppatore.
3. Indici mancanti e tabelle calde: spesso il 20% delle tabelle fa l'80% del tempo.
4. Lavoro fuori dalla richiesta: email, PDF, esportazioni e chiamate a servizi esterni che oggi bloccano l'utente e domani stanno in coda.
5. Cache dove serve, e solo lì: una cache messa a caso nasconde il problema per un mese.

Alla fine della settimana c'è un report con le dieci cause ordinate per costo e per rischio, e la prima correzione già in produzione.

Come si corregge senza fermare chi lavora?

• Un test prima di ogni correzione, che descrive il comportamento attuale: così la correzione non rompe altro. Nella mia repo girano 1.480 test a ogni push, e PHPStan blocca le regressioni prima del deploy.
• Correzioni piccole e misurate: una query, un indice, una coda alla volta, con il tempo prima e dopo scritto nel ticket.
• Nessuna riscrittura: si lavora nel vostro repository, con la vostra pipeline; il codice resta vostro, con i test.
• Chi lavora non se ne accorge: i rilasci sono piccoli e reversibili, fuori dalle ore di punta.

Le tre correzioni che valgono di più, in quasi tutti i gestionali visti in quattordici anni: N+1 sulle liste, indici sulle chiavi di filtro, e lavoro pesante spostato in coda. La riscrittura serve raramente, e quando serve si fa un modulo alla volta.

Chi lo fa, e perché ti puoi fidare

Quattordici anni di PHP e Laravel in cinque software house, gli ultimi sei da tech lead; oggi sistemi industriali in produzione in sei settori. Il metodo è pubblico: la repo di questo sito ha 350.000 righe, PHPStan in CI e un baseline di errori che può solo calare. Gli interventi con i numeri prima e dopo sono anonimi e si raccontano in call, con il consenso di chi li ha commissionati.

Quanto costa?

A giornate, con tariffe di mercato (Assintel Report 2025: media 508 € al giorno per i freelance ICT in Italia, profili senior sopra): da 500 a 650 € al giorno per un senior Laravel nel vostro team, da 600 a 750 € per sicurezza applicativa e penetration test con report. La prima settimana è a giornate e si può fermare: se dopo cinque giorni non vedete numeri migliori, avete comunque il report. Il listino completo e la pagina senior Laravel per software house.

Il passo giusto è piccolo: 30 minuti gratuiti con accesso in lettura al repository o a un log di una giornata. Ne esce un documento con i tre punti da cui partire, vostro anche se non proseguite.