Latenza di un'API: da dove arrivano i millisecondi

La latenza di un'API si misura in quattro pezzi separati, non in un solo numero: DNS, connessione TCP, handshake TLS e tempo del server. Su venti richieste consecutive a https://ui.eneawork.it/api/stats la mediana è 100 ms, e solo 36 ms sono del server: il resto lo spendono rete e handshake.

La scomposizione di una richiesta

Somma delle quattro fasi: 100 ms, coerente con la mediana di time_total. La connessione riusa lo stesso socket per tutte le richieste della serie? No: ogni invocazione di curl apre una connessione nuova, quindi l'handshake si paga ogni volta. È lo scenario peggiore, ed è quello che vede un client che chiama l'API una volta sola.

Il comando

for i in $(seq 1 20); do
  curl -s -o /dev/null -w "%{time_namelookup} %{time_connect} %{time_appconnect} %{time_starttransfer} %{size_download}\n" \
    https://example.com/api/stats
done

Il comando richiede bash, curl e una connessione. Sostituisci l'URL con il tuo endpoint. time_appconnect è zero sulle connessioni in chiaro, quindi su HTTP la fase TLS sparisce e il confronto con HTTPS non è onesto.

Dove finisce il tempo quando la risposta cresce

L'endpoint leggero risponde in 102 byte; quello dei tag in 22.866 byte, 224 volte tanto, e passa da 100 a 421 ms. La differenza non si spiega con i byte: a 1 Mbps 22 KB viaggiano in meno di 200 ms. Il resto è lavoro del server, che aggrega i tag prima di rispondere. La domanda giusta non è "come comprimo meglio", è "perché questa risposta si costruisce a ogni richiesta".

Il limite da dichiarare

I numeri vengono da una sola rete e da un solo momento: la latenza verso il server cambia con la posizione del client, e una CDN davanti all'API sposta la fase DNS e TLS su un edge. In più, una raffica di richieste ha restituito 429: quando c'è un rate limiter, la latenza include anche la sua decisione, e va misurata con la stessa frequenza che usa il client vero.

Dove continuare

Il catalogo EneUI indicizza 111.985 componenti, 1.556 blocchi e l'icona brand speedtest, utile per dare un volto al pannello di latenza. Per la metrica che contiene questa, leggi TTFB: cosa misura, per togliere l'handshake iniziale preconnect e dns-prefetch, per il peso dei byte Brotli contro gzip, e per il confronto tra architetture framework frontend a confronto.