Server-Timing: i millisecondi del backend (non è Lighthouse)
Data Pubblicazione: 02/10/2026 | | Performance

Server-Timing: i millisecondi del backend (non è Lighthouse)

Server-Timing è un header di risposta. Il server ci scrive i millisecondi del backend. Non è Lighthouse. Non è CrUX. Si vede in Network.

Lighthouse non scrive l’header Server-Timing. È un header di risposta: il server ci mette i millisecondi del backend (database, CPU, disco) e il browser li mostra in Network, o li espone all’interfaccia PerformanceServerTiming. Non è il punteggio Performance. Non è CrUX. Non è la cache.

In breve: response header. Una metrica ha un nome; può avere dur e desc. Più metriche, separate da virgola. Può esporre dettagli di infrastruttura: si decide cosa mandare, e a chi. Cross-origin: senza Timing-Allow-Origin i valori in JS diventano zero. Trailer dopo il body: solo DevTools, non la Fetch API. Verifica del 2 ottobre 2026 su MDN (header, ultima modifica 28 luglio 2026). Baseline high.

Cosa trovi in questo articolo

  1. Cosa è Server-Timing (e cosa non è Lighthouse)

  2. Name, dur, desc: tre pezzi, una riga

  3. JS, Timing-Allow-Origin, trailer

  4. Errori da evitare

  5. In sintesi

Cosa è Server-Timing (e cosa non è Lighthouse)

MDN, sulla pagina dell’header Server-Timing: comunica una o più metriche di performance del ciclo richiesta-risposta. Serve a far vedere i tempi del backend (lettura/scrittura database, CPU, file system) negli strumenti di sviluppo del browser, o nell’interfaccia PerformanceServerTiming. Tipo: response header.

Non è Lighthouse contro CrUX. Lighthouse è una run nel browser. CrUX è il campo. Server-Timing è quello che il server dichiara su quella risposta. Non è Cache-Control: la cache dice se si può riusare la risposta, questo header dice quanto ci ha messo il backend a costruirla. Non è il grafico di un database lento visto da un APM: è la riga HTTP. Il cluster è Performance.

MDN, in testa: Baseline high. Disponibile nei browser da marzo 2023 (low), high dal 27 settembre 2025. Asterisco: alcune parti hanno supporto variabile. Data di modifica della pagina: 28 luglio 2026. Rilettura: 2 ottobre 2026. Si verifica in Network, sulla risposta, non nel report HTML di Lighthouse.

Name, dur, desc: tre pezzi, una riga

MDN, sintassi. Una metrica, o una lista separata da virgole. Ogni metrica ha un nome (token, senza spazi). Opzionale: dur= seguito da un numero. Opzionale: desc= seguito da un token o da una stringa quotata. Esempi in pagina:

Esempio MDNCosa c’è
Server-Timing: missedCachesolo il nome
Server-Timing: cpu;dur=2.4nome e durata
Server-Timing: cache;desc="Cache Read";dur=23.2nome, descrizione, durata
Server-Timing: db;dur=53, app;dur=47.2due metriche, una riga

MDN: nomi e descrizioni vanno tenuti corti, per non gonfiare l’header. Lo stesso paragrafo avverte: l’header può esporre informazioni sensibili su applicazione e infrastruttura. Si decide quali metriche mandare, quando, e a chi. Esempio in pagina: solo agli utenti autenticati, niente sulle risposte pubbliche. Non è un punteggio da pubblicare in home.

JS, Timing-Allow-Origin, trailer

Oltre a DevTools, MDN descrive PerformanceServerTiming: gli strumenti possono raccogliere le metriche da JavaScript. L’interfaccia è ristretta alla same origin. Per altri domini serve l’header Timing-Allow-Origin: senza, le API di Resource Timing riportano zero. In alcuni browser l’interfaccia è solo in contesto sicuro (HTTPS). Mapping MDN: name → PerformanceServerTiming.name, dur → duration, desc → description.

MDN, trailer. Si può annunciare Trailer: Server-Timing e mandare la riga dopo il body, quando la durata è nota solo alla fine. Warning in pagina: solo i DevTools del browser usano quel trailer (scheda Network → Timings). La Fetch API non legge gli HTTP trailer. Un fetch() che cerca la metrica nel trailer non la trova, anche se in Network c’è. Non è un bug del sito: è il limite documentato.

Esempio MDN in testa al paragrafo JS: Server-Timing: custom-metric;dur=123.45;desc="My custom metric". Si guarda la risposta. Non il faro verde di Lighthouse. Non il RUM di campo. Per il sito lento resta la checklist di performance e, se il collo è il negozio, l’e-commerce lento.

Errori da evitare

  • Scambiarlo per un header di richiesta: MDN, response header.

  • Usarlo come sostituto del punteggio Lighthouse o di CrUX.

  • Mandare su risposte pubbliche i nomi delle query o dei host interni: MDN, può essere sensibile.

  • Leggere i millisecondi da JS su un dominio diverso senza Timing-Allow-Origin: diventano zero.

  • Aspettarsi che fetch() veda un Server-Timing in trailer: MDN, solo DevTools.

  • Mettere spazi nel nome della metrica: MDN, è un token.

In sintesi

Server-Timing è un header di risposta. Il server ci scrive name, dur, desc. Si vede in Network. In JS, same-origin, o con Timing-Allow-Origin. Il trailer dopo il body è per DevTools, non per Fetch. Non è Lighthouse. Può parlare troppo dell’infrastruttura. MDN, 2 ottobre 2026.

Domande frequenti

MDN: un response header. Comunica una o più metriche di performance del ciclo richiesta-risposta, per esempio tempi di database, CPU, file system. Si vede in DevTools o via PerformanceServerTiming. Non è Lighthouse, non è CrUX, non è Cache-Control.
MDN: un nome (token), opzionale dur=numero, opzionale desc=token o stringa quotata. Più metriche, separate da virgola. Esempio in pagina: Server-Timing: db;dur=53, app;dur=47.2
Non di default. MDN: PerformanceServerTiming è ristretta alla same origin. Per altri origini serve Timing-Allow-Origin, altrimenti le API di Resource Timing riportano zero. In alcuni browser l’interfaccia è solo in HTTPS.
No. MDN: solo i DevTools del browser usano Server-Timing come HTTP trailer (scheda Network → Timings). La Fetch API non accede agli HTTP trailer.
MDN, 2 ottobre 2026: Baseline high. Low dal 27 marzo 2023, high dal 27 settembre 2025. Asterisco: alcune parti hanno supporto variabile. Ultima modifica della pagina header: 28 luglio 2026.

Potrebbe interessarti anche...