Server Client e Tempi di Risposta

Come funziona la comunicazione tra un client (browser / bot) e un server web? Quali sono gli step che vengono effettuati tra la richiesta e la pagina visualizzata?

È un argomento che ho forzatamente introdotto al mio corso SEO per WMR Academy perché quotidianamente mi pongono domande in merito o mi danno risposte palesemente frutto di un’errata interpretazione del processo di comunicazione web (client-server).

Di base quello che avviene l’ho riportato in questa immagine:

Web Communication: Client-Server

  1. Il client (browser o bot) richiede una pagina
  2. Il server web ne dichiara la disponibilità (status code)
  3. Se disponibile il server effettua il necessario per condividere la pagina al client
  4. Parte il download dell’HTML
  5. Il browser elabora l’HTML (processo di rendering) e mostra la pagina

L’aspetto spesso più ostico pare sia quello di capire perché una pagina web è lenta. E’ fondamentale capire il processo che avviene tra la richiesta e la visualizzazione di pagina per identificare di chi è la colpa della lentezza.

A seguire un processo più dettagliato dei vari step che avvengono:Web Communication: Processo Client-Server

I principali colpevoli di una pagina non veloce sono:

  • Tempo di creazione di una pagina (server)
  • Tempo di rendering di una pagina (client)

 

Tempo di creazione di una pagina

Il tempo di creazione di una pagina è il tempo che ci mette il web server a montare l’HTML ovvero a produrre l’HTML completo da condividere con il client. Se la pagina è una risorsa statica (un file HTML finito) il tempo è molto basso, quasi nullo: non c’è un processo di elaborazione è il web server deve solo fare partire il download.

Se invece la pagina è una pagina dinamica significa che il server web NON ha l’HTML pronto, ma ha a disposizione solamente un template, ovvero un modello (una griglia), ove inserire dei dati.

Ad esempio, una pagina che stampa tutti gli alunni di un corso SEO avrà una struttura formata  da: un titolo, un testo, una tabella con nome, cognome, email. Solitamente tali dati verranno richiesti al database. Banalizzando:

  • una richiesta al DB per ottenere titolo e testo
  • una richiesta al DB per ottenere l’elenco dei partecipanti con i campi necessari: con tali dati l’application server (elemento logico che processa le pagine dinamiche) creerà una riga in tabella per ogni alunno

La pagina così montata sarà salvata (su file o su altra memoria) e sarà resa disponibile al web server che si occuperà di fare partire il download.

Riassumendo:

  • web server: si occupa di condividere risorse statiche o di chiamare in causa l’application server
  • application server: si occupa di eseguire i comandi di programmazione del template, di recuperare i dati (da database o da altre fonti) e preparare la pagina per il server web

Il tempo tra la richiesta del client e il primo byte spedito dal Web Server si chiama TTFB ovvero Time To First Byte. Lato client NON è possibile in alcun modo capire quale delle azioni dietro al web server ha impegnato tempo per creare la pagina onfly, al volo. Solo un monitoraggio sistemistico può dare risposte su chi è LENTO!

A livello server è possibile prevedere dei sistemi di cache che agiscono creando versioni statiche di pagina o di query al database, in modo che il processo non debba essere eseguito costantemente.

Se il tuo sito è basato su CMS ad ogni pagina (URL) verranno eseguite decine e decine di query al database (se non hai sistemi di cache) ogni volta che una pagina viene richiesta. Considera che un CMS come WordPress è basato su una unica pagina index.php la quale poi richiama i plugin, i template, il database, …!

 

Tempo di rendering di una pagina

Da quando il server web fa partire il download l’attività è a carico del client (browser o bot). Qui le cause di lentezza sono legate a:

  • dimensioni della pagina
  • velocità di download (linea client, linea server)
  • tempo di scaricare risorse aggiuntive (file css, file js, immagini, video, …)
  • tempo di renderizzare la pagina completa, che può essere pesantemente modificata da css e js

In questo processo ci sono diversi indici di velocità in base allo stato della pagina. Il primo è il tempo di download della pagina (o tempo di risposta del server) che è il tempo necessario per scaricare l’HTML.

Poi si succedono una serie di indicazioni temporali, fino ad arrivare al tempo di completamento del processo.

Strumenti come GTMetrix, WebPageTest, LightHouse, Google PageSpeed, … permettono di analizzare nel dettaglio questa elaborazione. Inoltre Google, raccogliendo in modo anonimo i dati dei Chrome settati in modo da consentirlo, ha creato un bellissimo report che si chiama Chrome UX in cui si  possono consultare questi tempi di ogni sito web (dati medi mensili).

Tale rilevazione può essere fatta anche con qualsiasi tipo di browser: lo screenshot che segue è stato fatto con Chrome, aprendo l’inspector e andando su Network > TimingTempo di Download di una pagina

Per una spiegazione più dettagliata si può fare riferimento a queste risorse online:

  • Timing breakdown phases: https://developers.google.com/web/tools/chrome-devtools/network/reference#timing-explanation
  • Tempi del Chrome UX Report: https://developers.google.com/web/tools/chrome-user-experience-report#metrics (ttfb, first paint, first contentful paint, DOMContentLoad, onload)

Conclusioni

Mi auguro di aver chiarito il ciclo di vita di una pagina web. La cosa fondamentale da capire è la distinzione del tempo di creazione della pagina (programmazione server side, db, fonti dati esterne, …) rispetto ai tempi di rendering (js, script statistiche, …).

Loading Facebook Comments ...

2 pensieri su “Server Client e Tempi di Risposta

  1. Pingback: ScreamingFrog 12 è arrivato!!! - Merlinox's Blog

  2. Pingback: Sorgente vs DOM - Merlinox's Blog

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *