Start · Sprachen · JavaScript · Referenz · PerformanceTiming.requestStart

PerformanceTiming.requestStart

Eigenschaft

Veraltete, schreibgeschützte Eigenschaft: Zeitstempel in Millisekunden seit der UNIX-Epoche, zu dem der Browser die Anfrage für das Dokument gesendet hat.

seit JavaScript Veraltet (Navigation Timing Level 1) – noch in all deprecated seit ja Kategorie: webapi

Signatur

PerformanceTiming.requestStart

Beschreibung

PerformanceTiming.requestStart gibt einen Zeitstempel vom Typ unsigned long long zurück. Er gibt in Millisekunden seit der UNIX-Epoche an, wann der Browser angefangen hat, das Dokument anzufordern – beim Server, aus einem HTTP-Cache oder aus einer lokalen Ressource. Das Objekt erreichen Sie über performance.timing.

Die Eigenschaft liegt zwischen connectEnd (Verbindung steht) und responseStart (erstes Byte der Antwort kommt an). Deshalb eignet sie sich zum Messen der Wartezeit auf den Server, auch „Time to First Byte“ ab dem Absenden der Anfrage: responseStart - requestStart.

Scheitert die Übertragung und der Browser öffnet eine neue Verbindung, um die Anfrage zu wiederholen, dann gibt requestStart den Zeitpunkt der neuen Anfrage an. Für ein requestEnd gibt es kein Gegenstück.

Die gesamte PerformanceTiming-Schnittstelle gilt als veraltet. Verwenden Sie in neuem Code PerformanceNavigationTiming.requestStart aus performance.getEntriesByType("navigation"). Dort ist der Wert ein hochauflösender DOMHighResTimeStamp, der relativ zu performance.timeOrigin gemessen wird.

Rückgabewert

Typ
number
Beschreibung
Ganzzahliger Zeitstempel in Millisekunden seit der UNIX-Epoche (unsigned long long). Wird nur gelesen.

Beispiele

Zeitstempel auslesen

const { requestStart } = performance.timing;
console.log(`Anfrage gesendet: ${new Date(requestStart).toISOString()}`);
Anfrage gesendet: 2024-05-14T09:21:07.412Z

Serverwartezeit mit der alten API messen

window.addEventListener('load', () => {
  const t = performance.timing;
  const serverWartezeit = t.responseStart - t.requestStart;
  const download = t.responseEnd - t.responseStart;
  console.log(`Wartezeit auf Server: ${serverWartezeit} ms`);
  console.log(`Download der Antwort: ${download} ms`);
});
Wartezeit auf Server: 87 ms Download der Antwort: 12 ms

Moderne Alternative mit Rückfall auf die alte API

const getServerWait = () => {
  const [nav] = performance.getEntriesByType('navigation');
  if (nav) {
    // DOMHighResTimeStamp, relativ zu performance.timeOrigin
    return nav.responseStart - nav.requestStart;
  }
  // Rückfall auf die veraltete PerformanceTiming-API
  const t = performance.timing;
  return t.responseStart - t.requestStart;
};

window.addEventListener('load', () => {
  console.log(`TTFB ab Anfrage: ${getServerWait().toFixed(1)} ms`);
});
TTFB ab Anfrage: 86.4 ms

// Wichtig · Fallstricke

  • Veraltet: performance.timing ist nur noch aus Gründen der Kompatibilität vorhanden. Setzen Sie in neuem Code auf PerformanceNavigationTiming. Die Unterstützung könnte irgendwann wegfallen.
  • Geringere Genauigkeit: Die Werte sind ganze Millisekunden und hängen von der Systemuhr ab. Wird die Uhr umgestellt (z. B. per NTP), können die Werte springen. DOMHighResTimeStamp ist dagegen monoton.
  • Nicht mischen: Die absoluten Epoche-Zeitstempel dieser API sollten Sie nicht mit Werten aus performance.now() oder PerformanceNavigationTiming verrechnen. Letztere sind relativ zu timeOrigin.
  • Zum richtigen Zeitpunkt lesen: Lesen Sie die Werte erst nach dem load-Ereignis aus. Vorher sind spätere Felder wie loadEventEnd noch 0.
  • Die Eigenschaft steht nur im Fenster-Kontext zur Verfügung, nicht in Workern. Node.js stellt sie nicht bereit.