Come ottenere tempi di risposta rapidi per le applicazioni

Sia i team di sviluppo che quelli operativi hanno la responsabilità di garantire tempi di risposta rapidi per le applicazioni. Segui questi consigli per misurare e ridurre i ritardi.

Il settore dello sviluppo software è ossessionato dalle metriche e la maggior parte di queste metriche riempie di disprezzo. Tuttavia, quando si tratta di tempi di risposta delle applicazioni, queste misurazioni si rivelano utili.

I tempi di risposta delle applicazioni per il software tendono a peggiorare progressivamente a causa del codice ce si gonfia. Tuttavia, le aspettative dei clienti continuano a crescere. Se eseguite correttamente, le misurazioni del tempo di risposta delle applicazioni potrai prevenire la fuga degli utenti o il fallimento del tuo sito web.

Conoscere gli standard del tempo di risposta delle applicazioni

Qual è il tuo punto di riferimento? L’occhio umano può percepire ritardi di circa 0,25 secondi. Quindi, se riduci la velocità di caricamento della pagina da 0,25 a 0,001 secondi, probabilmente spenderai soldi per miglioramenti che nessun cliente noterà nemmeno.

Oltre 0,25 secondi, entriamo nel tempo di risposta per applicazioni reali. Alcune organizzazioni scelgono di intervistare i clienti per definire le aspettative, ma Geoff Kenyon, esperto di marketing e SEO, una volta ha condotto uno studio che includeva le seguenti scoperte sui tempi di risposta dei siti Web:

• Se il tuo sito si carica in 5 secondi, è più veloce di circa il 25% del Web.
• Se il tuo sito si carica in 2,9 secondi, è più veloce di circa il 50% del Web.
• Se il tuo sito si carica in 1,7 secondi, è più veloce di circa il 75% del Web.
• Se il tuo sito si carica in 0,8 secondi, è più veloce di circa il 94% del Web.

Ci sono decine di strumenti per misurare i tempi di caricamento delle pagine, dai semplici plugin del browser ai complessi software basati su cloud che valutano le prestazioni end-to-end con accesso al sito da una dozzina di posizioni.

Cerca di mantenere le misurazioni il più possibile end-to-end e realistiche. Le prestazioni del sistema sono, dopotutto, la somma di tutti i componenti del sistema. Una volta completate le misurazioni, suddividile in latenza e tempi di risposta.

Differenza tra latenza e tempo di risposta

La latenza è il tempo impiegato per spostare un messaggio dal server al client. Il tempo di risposta è il tempo sul server.

Lo strumento da riga di comando ping prende una pagina web o un indirizzo IP e invia una richiesta di eco tramite Internet Control Message Protocol (ICMP). L’ICMP non ha porte e non avrà quasi tempo sul server. Ciò significa che il tempo di ping, diviso per due, equivale più o meno al tempo di latenza.

In questo esempio del comando ping, nota come la media di andata e ritorno impieghi circa 134 millisecondi, ovvero circa 67 millisecondi per viaggio.

Nell’uso reale, tuttavia, i tempi di risposta delle applicazioni in genere richiedono i log dal server. Gli sviluppatori dovrebbero includere i log nel tempo di elaborazione, quindi rendere disponibili tali dati tramite un sistema big data ricercabile. Utilizza questo sistema per eseguire query per medie e statistiche relative alle prestazioni delle applicazioni.

Esiste un altro modo per misurare i tempi di risposta in Google Chrome. Seleziona l’opzione Strumenti per sviluppatori dal menu. Seleziona la scheda Rete, quindi esegui un hard refresh del browser.

Visualizzerai un diagramma a cascata dei caricamenti di immagini ed elementi di pagina.

Questi strumenti misurano il tempo impiegato dalla richiesta per completare un round trip. Prendi il tempo totale, sottrai la latenza e otterrai il tempo di risposta. Esistono strumenti simili per i dispositivi mobili.

Dai alle applicazioni un aumento delle prestazioni

Una volta capito il tempo di risposta, ottimizza e regola le prestazioni. In genere, l’idea è semplice: trova il servizio che causa il ritardo maggiore o più dirompente, quindi suddividilo in diverse categorie di tempo, come su rete, su server Web e su API. Una volta trovato il componente lento, suddividilo in parti. Scopri cosa causa quel ritardo e risolvilo. Se puoi, esegui le richieste in parallelo.

Se il problema è la latenza, non c’è molto da fare per i programmatori, poiché il problema è l’infrastruttura tra il client e il server web. La latenza è nelle mani del personale operativo.

La maggior parte delle applicazioni web include una grande quantità di contenuto statico, file che sono esattamente gli stessi, ogni volta, principalmente sotto forma di pagine web, JavaScript e immagini. Se servi le immagini dal data center, un modo per migliorare la latenza è spostare il data center vicino ai punti di scambio Internet. Più realisticamente, una rete di distribuzione dei contenuti (CDN) può posizionare i file in decine di posti in tutto Internet, quindi instradare le richieste al data center più vicino. Le operazioni potrebbero anche configurare i server web per includere tag di entità nelle loro risposte, in modo che il browser possa memorizzare nella cache le immagini, invece di ricaricarle: ecco come i tempi di caricamento sono scesi a 0 millisecondi nell’immagine sopra.

Le immagini di minore complessità riducono le dimensioni dei file, mentre il codice minimizzato riduce le dimensioni dei file di testo. Su un gran numero di file, queste modifiche aumentano modestamente le prestazioni complessive dell’applicazione web.

Alcuni progettisti di software si affidano al rendering incrementale, in cui gli elementi della pagina vengono caricati e visualizzati pezzo per pezzo per creare una migliore esperienza utente anche quando i tempi di risposta complessivi non migliorano. Ad esempio, se vai sul sito di vendita al dettaglio di Amazon, noterai che viene visualizzato come un mucchio di caselle. Se Visualizzati di recente o Consigliato per te non viene visualizzato, il sito mostra comunque tutto il resto. Proprio come gli sviluppatori eseguono un lavoro incrementale sui progetti software, puoi strutturare i tuoi siti web allo stesso modo.

Cosa costituisce un tempo di risposta problematico dell’applicazione

A volte, le metriche non raccontano la storia. Pochissime persone decidono di farsi tagliare i capelli misurandoli con un righello. Più probabilmente, basi quella decisione su una pianificazione, un numero specifico di settimane o mesi. Altri potrebbero esprimere questo giudizio soggettivamente quando si guardano allo specchio.

Queste idee di tempo si traducono in tempi di risposta dell’applicazione. Se io, come essere umano, riesco a percepire un ritardo nel caricamento, allora il ritardo è probabilmente superiore a 0,5 secondi.

Ma, anche se avverti il ​​ritardo, potrebbe non avere importanza. Se il software è stato creato per un gruppo interno di assistenza clienti, i tempi di caricamento potrebbero non essere una priorità. Allo stesso modo, se il software è nuovo e innovativo, senza veri concorrenti, un ritardo fino a un secondo potrebbe essere un tempo di risposta accettabile, per ora. Una volta che il software ha dei concorrenti, i clienti possono navigare senza pensarci due volte.

L’esperienza utente è importante

Come ho scoperto quando ho avviato la mia azienda, c’è un vero valore aziendale nel dire al cliente che stai lavorando a un problema. Dopotutto, tutto si collega all’esperienza utente.

Uno dei miei clienti sta attualmente lavorando su una barra di avanzamento. Funziona con un timer, il che significa che non ha alcuna relazione con la durata effettiva del processo. La barra attraversa lo schermo in 15 secondi, dopodiché, se i dati non sono stati caricati, il sistema va in timeout. Se gli elementi vengono caricati in cinque secondi, l’app non passa alla schermata successiva. Invece, riempie rapidamente la barra di avanzamento. Potrebbero volerci altri 0,5 secondi in più prima che l’indicatore di avanzamento scorra sullo schermo, ma sembra più coerente e credibile per l’utente. Quel mezzo secondo potrebbe portare a una migliore esperienza utente.

Per migliorare la velocità del tuo sito leggi anche l’articolo:
Come ottenere 100/100 su Pagespeed