Primi aspetti.
Lunedì mattina. Apro il mio sito da una connessione 4G normale. Cronometro mentale. Uno, due, tre… nove… undici secondi. Undici secondi prima che la home sia utilizzabile.
Che dire*, potrei battere qualsiasi record.*
Dopotutto sto utilizzando render piano free e un database gratuito. Perché insomma, la qualità si paga. Si sa.
Il problema non è la pazienza dei nerd come me, abituati a tutto. Il problema è il cliente che cerca su Google "software gestionale su misura", clicca sul mio sito, e nei primi tre secondo decide se sono affidabile o meno. Se il sito è lento, la risposta è no. Chiude la tab. Apre quello dopo. E io ho perso un'opportunità senza nemmeno saperlo.
Il cliente giustamente non sa per quale motivo è lento. Io si, dietro a questa web app c'è un sistema di page building (simile a wix, quindi il DB non sta caricando quattro stringhe in croce con qualche FK, bensì un intero payload complesso).
Sappiamo dalle ricerche di Google che oltre il 50% degli utenti abbandona una pagina che impiega più di tre secondi a caricare. Sappiamo che la velocità è un fattore di ranking confermato. Eppure abbiamo tutti almeno un sito, da qualche parte, che fa undici secondi. Il mio era uno di quelli.
Cosa ho deciso di fare
Non un redesign. Non una nuova grafica. Non un cambio di tecnologia.
Volevo capire una cosa molto specifica: perché un sito relativamente semplice, scritto bene, riesce a essere così lento.
Qualcuno prenderebbe che per tirchieria non voglio spendere 7 o 24 euro al mese. (In effetti sì, tantovale che compro una VPS e ho tutto).
Ma non è solo questo il punto. Per me è diventata una sfida.
Voler ottimizzare un sistema che ha un database gratuito e un server con CPU 0.1
È questo quello che fa venire lo stimolo di sfida e dire "Sono bravo, perché sono riuscito ad ottimizzare l'impossibile"
Mi sono dato una regola. Niente intuizioni. Solo numeri.
Ho aperto gli strumenti di sviluppo del browser, ho misurato ogni richiesta, ho calcolato quanto tempo passava a scaricare cosa. Ho fatto la stessa misura prima di toccare anche solo una riga di codice, e l'ho ripetuta dopo ogni intervento. Senza misura prima e dopo non si ottimizza: si tira a indovinare.
Quello che ho trovato
Tre colpevoli, ognuno indipendente.
Il primo è il modo in cui il computer del server interpreta il codice. Per default, ogni richiesta ricomincia da zero come se fosse la prima della giornata. Esiste una scorciatoia che permette al server di ricordare il lavoro già fatto, ma è spenta nella configurazione standard. È un po' come avere un'auto e tenere il freno a mano tirato ad ogni semaforo verde.
Il secondo riguarda come il sito chiedeva al database le informazioni da mostrare. Per costruire un menu con tre livelli di profondità, il sito faceva una domanda al database per ogni voce, poi una per ogni sotto-voce, poi una per ogni sotto-sotto-voce. Risultato: decine di domande dove sarebbe bastata una sola, ben formulata, all'inizio.
Il terzo era il bagaglio del browser. Il sito caricava il codice di tutti i pulsanti, le icone, gli editor di testo che esistono nell'applicazione, anche se la pagina che stavi vedendo ne usava una decima parte. È come se andassi a fare la spesa portandoti dietro il barbecue, la moto del cuoco e l'intera collezione di pentole, ogni volta che esci di casa per prendere il latte.
Tre problemi, tre interventi.
Cosa ho cambiato, raccontato in italiano
Ho acceso la "memoria a breve termine" del server, ho implemtato un sistema di caching compesso. La prima volta che il sito risponde a una richiesta, ricorda il lavoro fatto. Le richieste successive partono già al 60% del percorso.
Ho ridotto il bagaglio del browser: il sito ora carica solo quello che serve alla pagina che stai vedendo, esattamente come quando entri in un'app sul telefono e si caricano solo le schermate che apri. In numeri, sono passato da 519 a 247 file caricati per visita. Più della metà in meno.
E ho aggiunto piccole cose collaterali. Le immagini ora viaggiano in un formato moderno che pesa il 40% in meno a parità di qualità visibile. Il browser viene istruito a tenere in cache locale tutto quello che non cambia, così alla seconda visita di un utente molti file non vengono nemmeno richiesti al server.
I risultati, senza retorica
Prima: 11,5 secondi di caricamento. 519 richieste. 1,84 megabyte di traffico.
Dopo: 4 secondi di caricamento. 247 richieste. 1,6 megabyte di traffico.
Il caricamento è sceso del 65%. Le richieste del 52%. Sono numeri misurati su un articolo reale del blog, con il browser pulito da cache, in produzione. Non sono il "best case" da slide commerciale: sono la realtà di un visitatore qualsiasi.
Quattro secondi non sono ancora il valore che voglio. L'obiettivo è sotto il secondo e mezzo. Ma sono già un altro mondo rispetto a undici secondi, e l'effetto sul tasso di rimbalzo si vedrà nei prossimi trenta giorni di analytics.
Perché un sito veloce non è una pignoleria tecnica
Tre motivi, uno per ogni stakeholder.
Per chi vende, il sito veloce è una promessa implicita: dice "questa azienda lavora con cura". Se hai due fornitori sulla stessa fascia di prezzo e uno carica in tre secondi e l'altro in dieci, su quale clicchi il pulsante "richiedi preventivo"?
Per chi guarda le metriche di marketing, la velocità è una leva diretta su due numeri. Il primo è la posizione su Google: i Core Web Vitals, da anni, sono parte del ranking factor ufficiale. Un sito veloce sale, un sito lento scende. Il secondo è il tasso di conversione: ogni secondo guadagnato sui tempi di caricamento si traduce, sui dati pubblici di Amazon e Walmart, in qualche punto percentuale di vendite in più.
Per chi gestisce l'infrastruttura, ottimizzare significa anche pagare meno.
Server che lavorano meno, traffico che pesa meno, immagini che occupano meno spazio.
È una linea di costo che non si vede sul P&L finché non la guardi, e quando la guardi capisci che potevi risparmiare.
Il bottleneck che resta
Onestà: dei 4 secondi attuali, circa 3 sono tempo che il server impiega a generare la risposta. Solo 1 secondo è effettivo download e visualizzazione. Significa che il prossimo round di ottimizzazione non passa più dal frontend: passa da capire perché il backend ci mette 3 secondi.
Ho già installato gli strumenti per misurarlo. Quando avrò i numeri, scriverò il secondo episodio di questa cronaca, con prima e dopo, esattamente come questo.
Cosa porti via da questo articolo
Se la velocità del tuo sito non l'hai mai misurata, fallo oggi. Apri pagespeed.web.dev, incolla l'URL della home, leggi il punteggio. Se è verde, congratulazioni. Se è giallo o rosso, hai uno strumento concreto in mano: un punto di partenza misurabile, e una conversazione da aprire con chi gestisce il tuo sito.
Se i numeri non ti piacciono e vuoi un audit indipendente che ti dica con onestà cosa si può migliorare, dove, e con quanto sforzo, scrivimi tramite il form contatti.
Lavoro per progetti su misura, partendo sempre dai numeri reali e mai dalle metriche di vanity.
Il secondo episodio arriva quando avrò abbattuto i tre secondi di backend. Stay tuned.
Top comments (0)