Start · Sprachen · JavaScript · Referenz · PerformanceTiming.domComplete

PerformanceTiming.domComplete

Eigenschaft

Schreibgeschützter Zeitstempel (ms seit UNIX-Epoche), zu dem der Parser das Hauptdokument fertig verarbeitet hat und <code>document.readyState</code> auf <code>"complete"</code> wechselt.

seit JavaScript Baseline: alle Browser (veraltet, Navigation Timin deprecated seit ja Kategorie: webapi

Signatur

PerformanceTiming.domComplete

Beschreibung

Die veraltete, schreibgeschützte Eigenschaft PerformanceTiming.domComplete liefert einen unsigned long long-Wert. Er steht für den Zeitpunkt in Millisekunden seit der UNIX-Epoche, zu dem der Parser das Hauptdokument fertig verarbeitet hat. In diesem Moment wechselt document.readyState auf "complete" und das zugehörige readystatechange-Event wird ausgelöst. Bis dahin sind auch alle Unterressourcen wie Bilder, Stylesheets und synchrone Skripte geladen.

Der Wert liegt zeitlich nach domContentLoadedEventEnd und kurz vor loadEventStart. Mit der Differenz domComplete - navigationStart misst man, wie lange die Seite vom Navigationsbeginn bis zum vollständig aufgebauten Dokument samt Ressourcen gebraucht hat. Die Differenz domComplete - domInteractive zeigt dagegen vor allem, wie lange das Nachladen der Unterressourcen dauert.

Solange das Dokument noch nicht vollständig ist, hat die Eigenschaft den Wert 0. Man liest sie deshalb erst im oder nach dem load-Event aus. Für neuen Code sollte man stattdessen PerformanceNavigationTiming.domComplete aus Navigation Timing Level 2 verwenden. Diese Eigenschaft liefert einen hochauflösenden DOMHighResTimeStamp relativ zu performance.timeOrigin.

Rückgabewert

Typ
number
Beschreibung
Ganzzahliger Zeitstempel in Millisekunden seit der UNIX-Epoche (unsigned long long). Solange das Dokument noch nicht vollständig ist, ist der Wert 0.

Beispiele

Zeit bis zum fertigen DOM messen (veraltete API)

window.addEventListener('load', () => {
  const t = performance.timing;
  const dauer = t.domComplete - t.navigationStart;
  console.log(`DOM vollständig nach ${dauer} ms`);
});
DOM vollständig nach 842 ms

Ladezeit der Unterressourcen bestimmen

window.addEventListener('load', () => {
  const { domInteractive, domComplete } = performance.timing;
  console.log(`Ressourcen-Ladephase: ${domComplete - domInteractive} ms`);
});
Ressourcen-Ladephase: 315 ms

Moderne Alternative mit Rückfall auf die alte API

const ermittleDomComplete = () => {
  const [nav] = performance.getEntriesByType('navigation');
  if (nav) {
    // relativ zu performance.timeOrigin, hochauflösend
    return nav.domComplete;
  }
  // Rückfall: veraltete PerformanceTiming-API
  const t = performance.timing;
  return t.domComplete - t.navigationStart;
};

window.addEventListener('load', () => {
  // setTimeout, damit loadEventEnd & Co. bereits gesetzt sind
  setTimeout(() => {
    console.log(`domComplete: ${ermittleDomComplete().toFixed(1)} ms`);
  }, 0);
});
domComplete: 841.7 ms

// Wichtig · Fallstricke

  • Veraltet: PerformanceTiming ist in Navigation Timing Level 2 als veraltet markiert. Browser unterstützen die Eigenschaft noch, aber für neuen Code sollte man PerformanceNavigationTiming über performance.getEntriesByType('navigation') verwenden.
  • Wert 0: Wenn man die Eigenschaft zu früh ausliest, etwa direkt im Skript im <head>, ist der Wert 0. Die Differenz zu navigationStart wird dann negativ.
  • Unterschiedliche Zeitbasis: Die alte API liefert absolute Epoche-Millisekunden als ganze Zahlen. Die neue API liefert relative Zeiten mit Nachkommastellen. Werte aus beiden APIs darf man nicht direkt miteinander vergleichen.
  • Systemuhr: Absolute Zeitstempel hängen von der Systemuhr ab und können durch Uhrzeitkorrekturen verfälscht werden. Deshalb sollte man immer Differenzen bilden.
  • Die Werte beziehen sich nur auf das Hauptdokument, nicht auf Navigationen innerhalb einer Single-Page-App.