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
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 MDN | Cosa c’è |
|---|---|
Server-Timing: missedCache | solo il nome |
Server-Timing: cpu;dur=2.4 | nome e durata |
Server-Timing: cache;desc="Cache Read";dur=23.2 | nome, descrizione, durata |
Server-Timing: db;dur=53, app;dur=47.2 | due 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 unServer-Timingin 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.