Velocità che vende, di Andrea Cardinali

1) Ciao Andrea, ci racconti i tuoi attuali focus lavorativi?

Faccio essenzialmente due cose, consulenza e formazione, più una terza che per adesso è un.

La consulenza è l’attività principale. Lavoro come fractional CTO e consulente di web performance per micro e piccole imprese, quasi sempre e-commerce che generano fatturato dal sito. Entro, guardo i numeri, capisco dove stanno perdendo soldi (un sito lento, un processo manuale da automatizzare, una scelta tecnica presa senza dati) e do una direzione. è la classica situazione caso in cui servirebbe un CTO ma non ha senso assumerne uno a tempo pieno.

Poi c’è la formazione, ed è una parte che è cresciuta molto. La faccio su due fronti. Da un lato con le agenzie SEO e di marketing, sulla SEO tecnica e sulla GEO, cioè l’ottimizzazione per i motori generativi e gli agenti AI. Dall’altro con i team di sviluppo dove mostro come efficientare i processi di sviluppo, come programmare meglio (con e senza AI) e, soprattutto, come costruire siti veloci partendo dallo sviluppo, invece di aggiustarli dopo.

La terza cosa è PerformizeRUM un software di Real User Monitoring che ho sviluppato per misurare la velocità reale dei siti sugli utenti veri incrociando anche i dati di conversione. Per ora è in closed beta e lo sto testando privatamente sui miei progetti, quindi lo cito solo per completezza.

Il filo che tiene insieme tutto è sempre lo stesso: migliorare le performance di software, processi e persone. Che sia consulenza o formazione, cambia solo il formato.

2) Come hai strutturato il tuo “Velocità che vende” e a chi si rivolge?

Il libro è diviso in due parti, ed è una scelta precisa.

La prima parte è volutamente poco tecnica. Serve a costruire il perché: perché la velocità conta, quanto costa avere un sito lento, perché non è un problema che puoi delegare e dimenticare. Questa parte culmina nel framework Smart Loading, che è il cuore del libro. È un metodo proprietario, l’ho costruito io negli anni lavorando sul campo su un sacco di progetti, e ho deciso di rilasciarlo mettendolo nero su bianco. Di siti lenti in giro ce ne sono ancora troppi e da solo non riuscirò mai a velocizzarli tutti 😅, quindi ho preferito divulgare il metodo così da poter rendere il web un posto più veloce.

La seconda parte è la guida tecnica all’implementazione. È il “come”: codice, checklist, protocolli di audit. È la parte che i più tecnici apprezzano di più, ma l’ho messa dopo di proposito. Prima capisci perché stai facendo una cosa, poi la fai. Il come senza il perché non porta risultati.

Dentro ai capitoli ho inserito dei box divisi per ruolo: “per te che decidi”, “per te che gestisci”, “per te che sviluppi”. Così ognuno trova le azioni concrete che gli competono senza doversi leggere tutto il resto.

Si rivolge, quindi a tre ruoli. Chi decide, cioè l’imprenditore o il manager che vuole capire l’impatto della velocità su fatturato e conversioni. Chi gestisce, cioè chi sta in mezzo tra business e tecnica, come marketer, SEO e designer. E chi sviluppa, che cerca gli spunti operativi.

Il senso è tutto qui: la velocità di un sito è una responsabilità di tutta l’azienda, quindi il libro doveva poter essere letto da tutta l’azienda, non solo da chi mette le mani nel codice.

3) Perché la velocità di un sito non dovrebbe essere vista solo come un tema tecnico?

Perché la velocità si decide in sala riunioni, prima ancora che nel codice.

Faccio un esempio. Su un sito ci sono i video e le immagini, e quelli solitamente li decidono il grafico e il marketing. Ci sono gli script di tracciamento, che servono al marketing per misurare le campagne. C’è la scelta del page builder o della piattaforma, che spesso viene approvata dal management. E c’è la strategia a monte, dove si decide cosa deve stare dentro al sito e cosa no. Lo sviluppatore arriva alla fine di questa catena e può solo limitare i danni di decisioni prese altrove.

Il risultato è che, se ogni reparto guarda solo il proprio orticello, ognuno performa bene da solo ma insieme performano tutti male. Il sito è un amplificatore: prende tutte queste micro-decisioni e ne somma l’impatto.

Ecco perché dico che è un problema di cultura, non di tecnica. Non si aggiusta nel codice a fine giro, si decide a monte quando scegli cosa mettere nel sito. Solo quando la velocità diventa un criterio condiviso, il lavoro di tutti gli altri, sviluppatori compresi, diventa molto più semplice. Diversamente, al team tecnico viene chiesto di fare miracoli su decisioni già sbagliate in partenza.

Aggiungo una cosa per chi fa SEO, visto che qui probabilmente in molti la pensano così. Ridurre la velocità a un semplice fattore di ranking è un altro modo di rimpicciolire il problema. La velocità non serve solo a posizionarti meglio: serve soprattutto a non far scappare le persone che hai già pagato per portare sul sito. È una leva di fatturato prima ancora che una best practice da seguire perchè l’ha detto Google.

4) Che cosa significa collegare le web performance al fatturato?

Partiamo da come funziona un sito che vende. I visitatori arrivano, e una parte di loro compra, converte. Ma portare quei visitatori sul sito ha un costo. Un costo diretto, perché il traffico spesso lo paghi, con le ADS. E un costo indiretto, perché fare SEO, produrre contenuti, mandare le newsletter, qualunque attività che ha come obiettivo portare traffico costa comunque tempo e soldi.

Ora, se tutto questo traffico atterra su una pagina bianca, o su un sito che funziona male perché è lento, quei visitatori non comprano. E i soldi che hai investito per portarli sul sito sono sprecati. È come prepararti per mesi a una maratona e poi mollare a 100 metri dal traguardo.

Collegare le performance al fatturato vuol dire mettere in fila questa cosa e darle un numero. Nel libro ho inserito una semplice formula: visitatori della pagina, moltiplicato per la percentuale di persone che abbandonano per la lentezza, moltiplicato per il tasso di conversione, moltiplicato per il valore medio dell’ordine. Il risultato è quanto ti sta costando essere lento, oggi, in euro. 

Un possibile modo per vedere questo spreco nero su bianco sono i log del server. A volte ci trovo gli status code 499, che vuol dire una cosa precisa: l’utente ha chiuso il browser mentre il server stava ancora rispondendo. Se ne è andato prima che la pagina finisse di caricarsi. Quel click l’imprenditore l’aveva già pagato. Ha pagato per mandare qualcuno su una pagina che quella persona non ha nemmeno visto. Ecco cosa vuol dire collegare la velocità al fatturato: rendere visibile uno spreco che altrimenti non trovi in nessun report.

5) Quali metriche contano quando si valuta la velocità di un sito?

Parto da quella che non conta, perché è quella che tutti guardano: il punteggio di PageSpeed. Quel numero non misura la velocità reale del tuo sito. È una simulazione, per giunta fatta in condizioni che non rappresentano i tuoi utenti veri, e valuta una pagina alla volta come se tutto il traffico arrivasse lì. In più si può truccare: l’algoritmo è pubblicamente disponibile su Github, ed esistono plugin e SaaS che fanno cloaking.  In pratica mostrano allo strumento un codice html ottimizzato basandosi sullo user agent, mentre gli utenti continuano ad avere un’esperienza pessima. Il punteggio verde ti dà una falsa sicurezza perché pensi di avere il sito veloce, quando in realtà non lo è, così come avere un punteggio rosso non significa avere un sito lento.

Quello che conta davvero sono i dati raccolti sugli utenti veri, mentre navigano. Le metriche di riferimento sono i Core Web Vitals. L’LCP misura il tempo necessario a mostrare l’elemento più grande nel viewport. L’INP misura la reattività, cioè quanto la pagina risponde in fretta quando ci clicchi o interagisci. Il CLS misura la stabilità, cioè quanto gli elementi “ballano” mentre la pagina carica. Oltre a questi è doveroso considerare il TTFB, il tempo di risposta del server: finché il server non risponde, l’utente vede solo una pagina bianca.

Attenzione però, perché anche i Core Web Vitals hanno un limite grosso, e dipende da dove li prendi. Quelli che ti fornisce Google provengono dal Chrome UX Report e sono raccolti dai browser degli utenti, ma con parecchi paletti. 

• Sono in ritardo di 28 giorni.
• Non sono disponibili per le pagine con poco traffico. 
• Non sono disponibili per le pagine in noindex, quindi mancano carrello, checkout e aree riservate, che poi sono le pagine dove si gioca la partita. 
• E coprono solo Chrome, quindi si perdono tutti i browser in-app, gli utenti su Safari e i browser Chromium-based (che non condividono i dati con il CrUX).
   

Per avere il quadro vero conviene raccoglierli in autonomia, con uno strumento di Real User Monitoring, invece di aspettare che te li passi Google a modo suo. Questo è possibile, perchè tutti i principali browser compresi Safari e Firefox forniscono un api per leggere tramite javascript i web vitals.

E qui arrivo all’ultima considerazione, quella che spesso si dimentica. La velocità non è un valore unico per tutto il sito. Ogni pagina ha la propria. Ma non finisce lì: cambia anche tra utente loggato e non loggato, e può cambiare a seconda del browser. Vuol dire che il modo in cui di solito si fanno le analisi, un test sulla home e via, non basta per avere un quadro completo. La home può volare mentre il carrello o il checkout fare schifo, che poi sono esattamente la pagina dove tendenzialmente si perdono più utenti e soldi.

6) Qual è l’errore più comune delle aziende quando parlano di performance web?

Di errori comuni ce ne sono diversi, mi piacerebbe fosse uno solo ma non è così. Ti dico i principali.

Il primo è misurarla male, la velocità. Riprendo un attimo il punto di prima: se la misuri con gli strumenti sbagliati, il punteggio di PageSpeed o tool come GTmetrix, parti già con un’idea distorta di come sta messo il sito. Prima di ottimizzare bisogna imparare a misurare, altrimenti insegui il numero sbagliato.

Il secondo è dare per scontato che un sito venga costruito veloce. Spesso manca proprio la cultura tecnica: chi realizza il sito dovrebbe sapere come si costruisce un sito veloce, e invece si usano gli strumenti sbagliati, tipo i page builder. Con un page builder è facilissimo tirare su un sito velocemente, mentre sarà molto meno facile ottenere un sito veloce. Sono due cose diverse che vengono continuamente confuse.

Il terzo riguarda l’hosting, e qui vedo due estremi opposti. Da un lato chi si aspetta un sito che vola pagando un hosting da quattro soldi. Dall’altro chi si lamenta che il sito va piano nonostante abbia un server potentissimo. La verità sta in mezzo: il server conta, deve essere adeguato al traffico che deve reggere, ma non basta da solo. Se il codice è scritto male, anche con il server più veloce del mondo il sito continua ad andare lento. E’ per questo che senza aver fatto prima una diagnosi adeguata non è possibile sapere perchè il sito è lento. 

E poi c’è l’errore di considerare la velocità come una cosa da fare una volta e dimenticare. Fai degli interventi una tantum, il sito diventa veloce, fine. Ma sei mesi dopo è di nuovo lento, perché nel frattempo ci hanno messo mano in tanti senza un criterio. Rendere veloce un sito è un progetto. Mantenerlo veloce richiede un metodo di lavoro condiviso, ed è quella che nel libro chiamo la cultura della velocità.