Storicamente, il problema della velocità di caricamento è stato considerato esclusivamente come una metrica ingegneristica, ma con l'introduzione dei Core Web Vitals negli algoritmi di ricerca e la crescita del traffico mobile, è diventato evidente che le prestazioni sono una caratteristica di prodotto. Gli approcci classici per valutare l'impatto della velocità affrontano un'endogenicità fondamentale: gli utenti con dispositivi veloci e internet stabile convertono meglio indipendentemente dall'ottimizzazione del sito, creando una correlazione spuria.
Il problema si aggrava quando si utilizza l'Edge Computing e architetture CDN moderne, dove non è possibile garantire una suddivisione coerente del traffico in gruppi a causa della cache aggressiva sui server edge. Inoltre, esiste un effetto di auto-selezione: gli utenti con connessioni lente tendono a lasciare il sito prima di completare il caricamento, distorcendo la distribuzione nel campione e rendendo impossibile un vero confronto A/B.
La soluzione ottimale combina il Regression Discontinuity Design (RDD) al limite della soglia di "buone" prestazioni (ad esempio, LCP = 2,5 secondi) con strumental variables (IV) come strumento. Come variabile strumentale si utilizza la vicinanza geografica dell'utente al server edge più vicino o il tipo di connessione (3G vs 4G), che incide casualmente sulla velocità, ma non correla direttamente con l'intenzione di acquisto. Per l'analisi coorte è utilizzato il synthetic control method, dove il gruppo di controllo è costruito da dati storici di utenti con una struttura di dispositivi e geolocalizzazioni simile, permettendo di isolare l'effetto netto dell'ottimizzazione dalla stagionalità e dalle macro-tendenze.
In un grande progetto di e-commerce, il team frontend ha effettuato una rivoluzione: ha convertito le immagini in formati moderni (WebP, AVIF) con lazy-loading e ha ottimizzato il percorso critico di rendering, riducendo il LCP da 4,2 secondi a 1,8 secondi tra gli utenti con buona connessione. Il team di prodotto ha registrato un aumento della conversione del 12% nel periodo "dopo il rilascio", ma sono sorti dubbi sulla causalità, poiché parallelamente è stata lanciata una campagna pubblicitaria stagionale e aggiornato il catalogo prodotti.
Opzione 1: Confronto naif delle coorti prima e dopo
Gli analisti hanno proposto di confrontare la conversione degli utenti per una settimana prima e una settimana dopo l'ottimizzazione, stratificando per regioni. Pro: semplicità di implementazione e assenza di necessità di un'infrastruttura complessa. Contro: completa ignoranza della stagionalità (settimana pre-festiva), delle differenze nella composizione del pubblico (nuovi utenti provenienti da pubblicità con un'altra intenzione) e della sopravvivenza (survivorship bias) – utenti lenti "scomparsi" dal campione post-esclusione, creando l'illusione di crescita.
Opzione 2: Analisi della correlazione tra velocità e conversione
Il secondo approccio prevedeva la costruzione di una regressione, dove la variabile indipendente era il LCP effettivo dell'utente, e la variabile dipendente era il fatto di conversione. Pro: utilizzo di tutti i dati disponibili e granularità fino alla sessione. Contro: endogenicità fatale: utenti con dispositivi costosi e internet veloce sono inizialmente più ricchi e motivati ad acquistare, mentre gli utenti con dispositivi economici su 3G hanno una bassa intent-to-buy indipendentemente dalla velocità del sito, dando un coefficiente di distorsione verso l'alto del 40-60%.
Opzione 3: Regression Discontinuity Design con strumento geografico
Il team ha scelto un metodo ibrido: ha utilizzato la distanza dal server edge più vicino come variabile strumentale, correlata alla velocità, ma non al comportamento di acquisto. Gli utenti al confine della zona di copertura (dove il segnale "si rompe" e la velocità scende drasticamente a 2,6-2,8 secondi LCP) hanno formato un campione localmente casuale attorno alla soglia di 2,5 secondi. Applicando il Local Average Treatment Effect (LATE) in una finestra di ±0,3 secondi dalla soglia, hanno misurato l'effetto netto del miglioramento della velocità per i complainers (utenti la cui velocità è cambiata specificamente a causa dell'infrastruttura, non del dispositivo).
Soluzione scelta e risultato
È stato implementato l'approccio RDD+IV con un'ulteriore filtrazione degli utenti di ritorno tramite un'analisi del localStorage per cercare risorse memorizzate nella cache. La valutazione finale ha mostrato che il vero effetto incrementale dell'ottimizzazione è stato del +8,5% sulla conversione per nuovi utenti e del +3,2% per i ritorni (dove l'effetto della novità è minore), giustificando così gli investimenti nell'infrastruttura di Edge Computing con un ROI del 340% in un anno.
Perché la regressione OLS standard delle prestazioni rispetto alla conversione fornisce stime distorte, e quale meccanismo di endogenicità qui domina?
La risposta risiede nel doppio auto-selezione (double selection bias): in primo luogo, gli utenti con dispositivi lenti tendono a cadere sistematicamente fuori dal campione delle "sessioni di successo" (abbandonano prima del caricamento), creando truncation bias; in secondo luogo, la velocità di internet è correlata con lo stato socio-economico e la geografia, che influenzano direttamente la capacità di spesa. Senza variabili strumentali o RDD, la regressione mescola l'effetto di "internet veloce come marker di ricchezza" con l'effetto di "sito veloce come trigger di conversione", sovrastimando il vero effetto causale di 1,5-2 volte.
In che modo la memorizzazione nella cache lato client (client-side caching) e le visite ripetute distorcono la valutazione dell'effetto dell'ottimizzazione nell'analisi longitudinale, e quale metodo consente di filtrare la "contaminazione del trattamento"?
I visitatori di ritorno che hanno visitato il sito prima dell'ottimizzazione hanno risorse pesanti vecchie nella HTTP-cache o nel Service Worker, quindi per loro il "trattamento" (la nuova versione veloce) potrebbe non applicarsi parzialmente o completamente, creando contaminazione tra trattamento e controllo. I candidati spesso dimenticano di controllare gli header If-None-Match o di analizzare i first-party cookie con il timestamp della prima visita. L'approccio corretto è l'analisi intent-to-treat (ITT) con divisione in "nuove sessioni pulite" (nuovi utenti + cache svuotata) contro "ritorni contaminati", o usare difference-in-differences (DiD) con effetti fissi dell'utente, isolando il cambiamento within-user dalla selezione between-user.
Qual è la differenza tra l'analisi ITT (Intent-to-Treat) e l'analisi TOT (Treatment-on-the-Treated) nella valutazione dell'effetto dei Core Web Vitals, e perché è fondamentale riferire esattamente l'ITT per le metriche di prodotto durante la pianificazione dell'espansione?
ITT misura l'effetto per l'intera popolazione, inclusi coloro che non hanno ricevuto il miglioramento della velocità (ad esempio, utenti su 2G o con JavaScript disattivato), mentre TOT (o LATE nel contesto IV) misura l'effetto solo per i "complainers" – coloro che hanno realmente beneficiato dell'ottimizzazione. I candidati spesso segnalano erroneamente al business una stima TOT (+15% di conversione per coloro che avrebbero avuto un caricamento veloce), ma quando l'ottimizzazione viene scalata al 100% del traffico, l'effetto reale sarà più vicino a ITT (+6-8%), poiché una parte del pubblico tecnicamente non potrà ricevere il miglioramento (dispositivi obsoleti, reti lente). Per la pianificazione aziendale e le previsioni di fatturato è fondamentale utilizzare una stima conservativa ITT, per evitare l'errore di overcommitment.