La velocità è una delle poche caratteristiche del prodotto che l'utente sente prima di poterlo spiegare. Nessuno apre un sito web e pensa che "la latenza qui è alta". Le persone hanno semplicemente la sensazione che qualcosa sia lento, diventano impazienti e se ne vanno. La latenza è invisibile finché non diventa abbandono.
Per coloro che stanno iniziando ad approfondire le prestazioni web, la prima confusione è considerare la latenza come sinonimo di "internet lenta". Non lo è. La latenza è il tempo che intercorre tra un'azione e la risposta a quell'azione ed è costruita da una catena di fattori che vanno ben oltre la connessione dell'utente. Comprendere questa catena è ciò che separa coloro che avviano le ottimizzazioni da coloro che risolvono il problema alla fonte.
Questo testo è una base. L'obiettivo non è fornire ricette, ma darti il vocabolario e il modello mentale per ragionare in modo chiaro sulla latenza, perché senza capire da dove viene, qualsiasi ottimizzazione diventa tentativi ed errori.
Cos'è la latenza, in effetti
La latenza è il tempo di attesa. Quando qualcuno fa clic su un pulsante ed è necessario che accada qualcosa sul server, si verifica un ritardo tra il clic e la risposta visibile. Questo intervallo è la latenza percepita ed è la somma di diversi tempi più piccoli.
È utile separare la latenza dal throughput, due concetti spesso confusi. La latenza è quanto tempo impiega una singola richiesta. Il throughput è il numero di richieste che il sistema può gestire al secondo. Puoi avere un sistema ad alto rendimento e ad alta latenza allo stesso tempo, serve molte persone, ma tutti aspettano. Per il singolo utente, ciò che conta è la latenza. Per l'operazione, entrambi sono importanti.
La tesi centrale di questo testo: la latenza è una somma di passaggi e si migliora solo ciò che si vede. Chiunque tratti la latenza come un singolo numero opaco è bloccato da ottimizzazioni generiche. Chi spezza la catena scopre dove il tempo è veramente perduto.
Da dove viene la latenza
Immagina il percorso di una tipica richiesta, dal clic dell'utente alla risposta sullo schermo. Ogni tratto di questo percorso aggiunge tempo.
C'è la distanza fisica. Le informazioni viaggiano attraverso la rete a una velocità limitata e la distanza tra l'utente e il server è importante. Un server in un altro continente aggiunge decine di millisecondi solo per il viaggio di andata e ritorno, prima di qualsiasi elaborazione. Per un pubblico brasiliano servito da infrastrutture distanti, questa è una parte reale del problema.
C'è la creazione della connessione. L'apertura di una connessione sicura comporta una negoziazione iniziale tra client e server che costa andata e ritorno attraverso la rete. Le connessioni riproposte pagano questo costo una volta; le nuove connessioni pagano ogni volta.
È in corso l'elaborazione sul server. Il tempo impiegato dall'applicazione per comprendere la richiesta, interrogare i database, eseguire la logica aziendale e assemblare la risposta. È qui che risiede gran parte della latenza che i team possono controllare direttamente.
C'è l'interrogazione dei dati. Il database è spesso il più grande cattivo nascosto. Una query scarsamente indicizzata, una chiamata che attiva dozzine di altre query di seguito, un servizio esterno lento nella catena, ognuno di questi trasforma una risposta rapida in un'attesa.
E c'è il rendering nel browser. Anche dopo l'arrivo della risposta, il browser deve elaborarla e disegnare lo schermo. JavaScript pesante, risorse che bloccano e immagini di grandi dimensioni aggiungono tempo nell'ultima sezione, proprio dove sta guardando l'utente.
Perché è importante per le aziende
È forte la tentazione di considerare la latenza solo come un problema tecnico. E' un errore di gestione. La latenza ha un effetto diretto sulla conversione, sulla conservazione e sulla percezione della qualità. Le applicazioni lente vengono abbandonate e l'abbandono non richiede autorizzazione.
Pensa a un portale di servizi pubblici. Il cittadino che tenta di rilasciare un duplicato, fissare un appuntamento o consultare una prestazione non ha una pazienza infinita, e spesso vi accede da un cellulare con una connessione modesta. Se ogni passaggio richiede tempo, il tasso di completamento diminuisce, il servizio in presenza aumenta e la percezione che “il sistema governativo non funziona” si rafforza. La latenza, in questo caso, costituisce una barriera all’accesso a un diritto.
Nei prodotti privati, la logica è la stessa ma sotto un altro nome: ogni secondo di attesa è denaro che esce dalla porta. Ecco perché la latenza non dovrebbe essere un problema che appare solo quando l'utente si lamenta. Dovrebbe essere un indicatore monitorato come si monitorerebbero le entrate.
Misura prima di ottimizzare
L'errore più comune commesso da coloro che imparano a conoscere la latenza è iniziare a ottimizzare prima di misurare. Aggiungi cache qui, riscrivi una funzione lì, tutto tramite intuizione, e il risultato è uno sforzo disperso senza un impatto chiaro.
La disciplina corretta è l’opposto. Prima misura dove si perde tempo, poi affronta il collo di bottiglia più grande. La latenza solitamente segue una distribuzione non uniforme: un singolo passaggio può rappresentare la maggior parte del tempo totale. Ottimizzare gli altri è uno spreco.
Vale anche la pena considerare non solo la media, ma anche i casi peggiori. La latenza media può sembrare elevata mentre una parte rilevante di utenti sperimenta lunghe attese. Sono proprio questi utenti, quelli nel percentile cattivo, che abbandonano e si lamentano. Una buona media può nascondere un’esperienza terribile per molte persone.
La trappola dell'ottimizzazione dell'invisibile
C'è un rischio dall'altra parte dell'entusiasmo per la prestazione: ottimizzare ciò che non conta. Team entusiasti trascorrono settimane risparmiando millisecondi su una parte che l'utente non nota mai, mentre l'attesa più grande rimane intatta.
Le prestazioni sono sempre una questione di proporzioni. Ridurre un passaggio che rappresenta poco del tempo totale non cambia l'esperienza. La maturità sta nel resistere alla tentazione di un'ottimizzazione elegante e chiedersi, innanzitutto, se muove il numero che l'utente sente.
Un'altra trappola è considerare la latenza come un problema risolto dopo una serie di miglioramenti. I sistemi si evolvono, i dati crescono, nuove funzionalità aggiungono chiamate. La latenza aumenta di nuovo se nessuno guarda. È un indicatore da monitorare continuamente, non un compito da cancellare dalla lista.
Chiusura
La latenza è la tassa invisibile che ogni applicazione web paga, e a farne le spese è l’utente. Comprenderne i fondamenti, che è una somma di passaggi, che viene misurato prima dell'ottimizzazione, che è importante per il business tanto quanto per l'ingegneria, è il primo passo per costruire prodotti che le persone non abbandonano per impazienza.
La velocità non è né un lusso né un dettaglio tecnico. Fa parte della promessa che fa il tuo prodotto. Coloro che trattano le prestazioni come una decisione sul prodotto e non come un aggiustamento dell’ultimo minuto, offrono esperienze che rispettano il tempo di chi sta dall’altra parte dello schermo.
Se stai iniziando a considerare più seriamente le prestazioni della tua applicazione, vale la pena farlo con le misurazioni in mano fin dall'inizio. Ci sono altri articoli qui sul blog su architettura e scalabilità che approfondiscono l'argomento.
Leggi anche
- Ridurre la latenza nelle applicazioni web: una guida rapida per attaccare i giusti colli di bottiglia
- App Web progressive per principianti: esempi e ottimizzazioni senza complicare le cose
- PWA: cos'è e come prendersi cura della performance nel quotidiano
- Test automatizzati: architettura e fondamenti
- Edge computing: perché l'elaborazione distribuita ridefinirà la tua architettura
- Architettura dell'Edge Computing: strategie per l'elaborazione distribuita
