Start · Sprachen · JavaScript · Referenz · PerformanceResourceTiming.workerStart

PerformanceResourceTiming.workerStart

Eigenschaft

Liefert einen <code>DOMHighResTimeStamp</code> unmittelbar vor dem Auslösen des <code>FetchEvent</code> im Service Worker bzw. vor dem Start des Worker-Threads. Ohne Service Worker ist der Wert <code>0</code>.

seit JavaScript Baseline: Chrome 44+, Edge 17+, Firefox 58+, Safar Kategorie: webapi

Signatur

PerformanceResourceTiming.workerStart

Beschreibung

Die schreibgeschützte Eigenschaft workerStart der Schnittstelle PerformanceResourceTiming gibt einen hochauflösenden Zeitstempel zurück, der misst, wann ein Service Worker an einer Ressourcenanfrage beteiligt wird. Läuft der Service-Worker-Thread schon, ist das der Zeitpunkt direkt vor dem Auslösen des FetchEvent. Muss der Worker erst gestartet werden, ist es der Zeitpunkt direkt vor dem Start des Threads.

Wird die Ressource von keinem Service Worker abgefangen, ist der Wert 0. Deshalb eignet sich workerStart gut, um festzustellen, ob eine Anfrage über einen Service Worker gelaufen ist und wie viel Zeit er gekostet hat. Typische Messungen sind:

  • fetchStart - workerStart: Zeit für den Worker-Start bzw. für die Verarbeitung im fetch-Handler, bis die eigentliche Abrufphase beginnt.
  • responseEnd - workerStart: gesamte Dauer ab Beteiligung des Service Workers bis die Antwort vollständig da ist.

Der Wert ist relativ zu performance.timeOrigin und steht über performance.getEntriesByType("resource"), PerformanceObserver und bei Navigationen über PerformanceNavigationTiming (erbt von PerformanceResourceTiming) zur Verfügung.

Rückgabewert

Typ
DOMHighResTimeStamp (number)
Beschreibung
Zeitstempel in Millisekunden relativ zu performance.timeOrigin. 0, wenn kein Service Worker beteiligt war oder die Zeitangaben wegen fehlender CORS-Freigabe nicht verfügbar sind.

Beispiele

Service-Worker-Dauer pro Ressource ermitteln

const entries = performance.getEntriesByType('resource');

for (const entry of entries) {
  if (entry.workerStart > 0) {
    const swDauer = entry.fetchStart - entry.workerStart;
    console.log(`${entry.name}: Service Worker ${swDauer.toFixed(1)} ms`);
  }
}
https://example.com/app.js: Service Worker 3.4 ms

Neue Ressourcen mit PerformanceObserver beobachten

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    const ueberSW = entry.workerStart > 0;
    console.log(entry.name, ueberSW ? 'über Service Worker' : 'direkt');
  }
});

observer.observe({ type: 'resource', buffered: true });
https://example.com/style.css über Service Worker

Service-Worker-Startzeit der Navigation messen

const [nav] = performance.getEntriesByType('navigation');

if (nav && nav.workerStart > 0) {
  const startkosten = nav.fetchStart - nav.workerStart;
  const gesamt = nav.responseEnd - nav.workerStart;
  console.log({ startkosten: Math.round(startkosten), gesamt: Math.round(gesamt) });
} else {
  console.log('Seite wurde nicht von einem Service Worker ausgeliefert');
}
{ startkosten: 42, gesamt: 118 }

// Wichtig · Fallstricke

  • Wert 0 kann zweierlei heißen: Entweder hat kein Service Worker die Anfrage abgefangen, oder die Ressource kommt von einem fremden Ursprung ohne Timing-Allow-Origin-Header. Vor Rechnungen immer auf > 0 prüfen, sonst entstehen unsinnig große Differenzen.
  • Bei einem „kalten“ Worker (Thread muss erst starten) ist die Differenz zu fetchStart deutlich größer als bei einem laufenden Worker. Für aussagekräftige Messwerte sollte man beide Fälle getrennt auswerten. Chrome bietet dafür ergänzend Navigation Preload an.
  • Der Ressourcen-Puffer ist standardmäßig begrenzt (meist 250 Einträge). Mit performance.setResourceTimingBufferSize() lässt er sich vergrößern, oder man nutzt PerformanceObserver.
  • Browser-Kompatibilität: in allen modernen Browsern verfügbar. Genauigkeit und Rundung der Zeitstempel können wegen Schutzmaßnahmen gegen Timing-Angriffe (z. B. Spectre) eingeschränkt sein.