Lifecycle von HTML

HTML Nativer Lebenszyklus (Lifecycle) bezieht sich typischerweise auf die Ereignisse und Phasen, die ein Browser beim Laden und Verarbeiten einer Webseite durchläuft. Obwohl HTML selbst eine Auszeichnungssprache ist und keine Lifecycle-Hooks wie JavaScript besitzt, werden HTML-Lifecycle-Ereignisse tatsächlich durch JavaScript-Interaktionen mit dem DOM (Document Object Model) verwaltet.

HTML-Parsing

Wenn der Browser eine Webseite lädt, empfängt er eine HTML-Datei vom Server und beginnt mit dem Parsen. Während dieser Phase erstellt der Browser einen DOM-Baum (Document Object Model) und wandelt das HTML in manipulierbare DOM-Objekte um.

Genau genommen ist das HTML-Parsing eine wesentliche Phase im Seitenladeprozess, fällt aber nicht in die Kategorie der "Lifecycle-Ereignisse" im herkömmlichen Sinne, da es nicht direkt über JavaScript erfasst oder abgehört werden kann. Aus einer breiteren Perspektive ist das HTML-Parsing jedoch ein unverzichtbarer Bestandteil des gesamten Seiten-Lifecycles und somit eine kritische Komponente in Diskussionen über den HTML-Lifecycle.

Dieser Prozess ist browserintern, daher können Entwickler diese Phase nicht direkt abhören. Sie können jedoch die Parsing-Geschwindigkeit verbessern, indem sie die HTML-Struktur optimieren und blockierende Ressourcen (wie JavaScript-Dateien) minimieren.

Laden externer Ressourcen

Während der Browser HTML parst, trifft er auf externe Ressourcen. Abhängig vom Ressourcentyp, der Lademethode (synchron oder asynchron) und der Priorität entscheidet der Browser, wie er das Laden und Rendern der Seite fortsetzt. Dieses Verhalten beeinflusst direkt die Rendering-Reihenfolge der Seite und die Ladezeit der für Benutzer sichtbaren Inhalte.

Verschiedene Ressourcentypen haben unterschiedliche Ladeverhalten, die das Parsen und Rendern der Seite beeinflussen:

1. CSS-Laden: Wenn der Browser auf ein <link>-Tag trifft, pausiert er das Seitenrendering, bis die CSS-Datei vollständig geladen und geparst ist. CSS wird als renderblockierende Ressource betrachtet, da Seitenlayout und -stile ohne die CSS-Datei nicht korrekt gerendert werden können.

2. JavaScript-Laden: Standardmäßig stoppt der Browser das HTML-Parsing, wenn er auf ein <script>-Tag trifft, bis die JavaScript-Datei geladen und ausgeführt wurde. Dies wird als synchrones Laden bezeichnet. Synchron geladenes JavaScript blockiert das HTML-Parsing und beeinflusst das Timing der DOMContentLoaded- und load-Ereignisse.

Insgesamt ist das Laden externer Ressourcen eng mit dem Seiten-Lifecycle verbunden, da das Laden externer Ressourcen das Parsen, Rendern und das Auslösen kritischer Lifecycle-Ereignisse wie DOMContentLoaded und load beeinflusst. Je kürzer die Ladezeit externer Ressourcen ist, desto schneller werden Lifecycle-Ereignisse ausgelöst.

readyState & readystatechange

readyState und readystatechange sind zwei wichtige Browserattribute und -ereignisse, die verwendet werden, um den Status von Dokumenten und Netzwerkanforderungen (wie AJAX-Anforderungen) zu verfolgen. Sie helfen Entwicklern, verschiedene Phasen des Ladevorgangs von Webseiten zu verstehen und entsprechende Operationen während dieser Phasen auszuführen. Sie werden hauptsächlich im Kontext des Dokumentenladens und von Netzwerkanforderungen (z. B. XMLHttpRequest) verwendet.

document.readyState

Die Eigenschaft document.readyState repräsentiert den aktuellen Status des Dokuments und hat drei mögliche Werte, die verschiedenen Dokumentenladestufen entsprechen:

1. loading: Das Dokument wird noch geladen und das HTML wird noch geparst. Der DOM-Baum wurde noch nicht vollständig aufgebaut. Externe Ressourcen (wie Bilder und Stylesheets) wurden möglicherweise noch nicht geladen oder verarbeitet.
2. interactive: Das HTML des Dokuments wurde vollständig geladen und geparst, und der DOM-Baum wurde aufgebaut. Stylesheets, Bilder und andere Ressourcen sind jedoch möglicherweise noch nicht vollständig geladen.
3. complete: Alle Ressourcen auf der Seite, einschließlich HTML, CSS, JavaScript, Bilder und Subframes, wurden vollständig geladen und verarbeitet. Die Seite ist vollständig bereit.

Mit document.readyState können Entwickler den Ladestatus des Dokuments überprüfen und entsprechende Aktionen basierend auf verschiedenen Status ausführen. Zum Beispiel:

if (document.readyState === 'complete') {
  // Die Seite ist vollständig geladen; Führen Sie Seitenoperationen aus
}

readystatechange Event

Das readystatechange-Ereignis wird ausgelöst, wenn sich der readyState des Dokuments ändert. Entwickler können das readystatechange-Ereignis abhören, um bestimmte Logiken in verschiedenen Ladestufen auszuführen. Zum Beispiel:

document.addEventListener('readystatechange', function () {
  if (document.readyState === 'interactive') {
    // Der DOM-Baum wurde vollständig aufgebaut; DOM-Manipulation ist jetzt möglich
    console.log('DOM is fully parsed');
  } else if (document.readyState === 'complete') {
    // Die gesamte Seite, einschließlich aller Ressourcen, ist vollständig geladen
    console.log('Page and resources are fully loaded');
  }
});

Unten ist ein HTML-Beispiel, das die Verwendung von document.readyState und readystatechange zur Verfolgung verschiedener Dokumentenladestufen veranschaulicht. Die Seite enthält grundlegende HTML-Elemente und zeigt entsprechende Inhalte oder Informationen in verschiedenen readyState-Stufen an:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Document ReadyState Example</title>
    <style>
      body {
        font-family: Arial, sans-serif;
        padding: 20px;
      }
      .status {
        font-size: 1.2em;
        color: #333;
        margin: 20px 0;
      }
      img {
        max-width: 100%;
        height: auto;
      }
    </style>
  </head>
  <body>
    <h1>Hello World</h1>
    <script>
      function updateStatus() {
        console.log(document.readyState);

        switch (document.readyState) {
          case 'loading':
            console.log('loading');
            break;
          case 'interactive':
            console.log('interactive');
            break;
          case 'complete':
            console.log('complete');
            break;
        }
      }

      updateStatus();

      document.addEventListener('readystatechange', updateStatus);
    </script>
  </body>
</html>

Die Ausgabe des obigen Codes:

loading
interactive
complete

DOMContentLoaded Event

Das DOMContentLoaded-Ereignis ist ein wichtiges Ereignis, das vom Browser während des Ladevorgangs des HTML-Dokuments ausgelöst wird. Es bedeutet, dass alle Elemente im HTML-Dokument vollständig geparst wurden und der DOM-Baum aufgebaut wurde. Externe Ressourcen wie Bilder, Stylesheets und Videos sind jedoch möglicherweise noch nicht vollständig geladen. Dies ist der Hauptunterschied zwischen DOMContentLoaded und dem load-Ereignis.

Das DOMContentLoaded-Ereignis tritt auf dem document-Objekt auf und muss mit addEventListener erfasst werden:

document.addEventListener('DOMContentLoaded', () => {});

Das DOMContentLoaded-Ereignis wird ausgelöst, wenn der Browser das Parsen des HTML-Dokuments abgeschlossen und alle DOM-Knoten generiert hat. Es erfordert jedoch nicht, dass externe Ressourcen (z. B. Bilder, Videos, Stylesheets oder Schriftartdateien) vollständig geladen sind.

Wenn die Seite beispielsweise ein großes Bild enthält, wird das DOMContentLoaded-Ereignis ausgelöst, bevor das Bild vollständig geladen ist. Zu diesem Zeitpunkt ist der DOM-Baum vollständig aufgebaut, und Entwickler können die DOM-Elemente auf der Seite bearbeiten und darauf zugreifen. Hier ist ein Beispiel:

<script type="text/javascript">
  function ready() {
    console.log('DOM is ready.');

    const img = document.querySelector('#img');

    // At this point, the image might not be fully loaded (unless it is cached),
    // so its size will be 0x0.
    console.log(`Image size: ${img.offsetWidth}x${img.offsetHeight}`);
  }

  document.addEventListener('DOMContentLoaded', ready);
</script>

<img
  id="img"
  src="https://www.google.com/images/branding/googlelogo/2x/googlelogo_color_272x92dp.png"
/>

Die Ausgabe dieses Codes sieht wie folgt aus, wobei das DOM vollständig geparst wird, bevor das Bild geladen wird:

DOM is ready.
Image size: 0x0

Wenn sich synchrone JavaScript-Dateien auf der Seite befinden (d. h. Skripte ohne die Attribute async oder defer), pausiert der Browser das HTML-Parsing, wenn er auf ein <script>-Tag trifft, wartet, bis das Skript ausgeführt wurde, und fährt dann mit dem Parsen fort. Dies verzögert das Auslösen des DOMContentLoaded-Ereignisses.

<script type="text/javascript">
  document.addEventListener('DOMContentLoaded', () => {
    console.log('DOM ready!');
  });
</script>

<script src="https://cdnjs.cloudflare.com/ajax/libs/lodash.js/4.3.0/lodash.js"></script>

<script type="text/javascript">
  console.log('Library loaded, inline script executed');
</script>

Ausgabe Reihenfolge:

1. Library loaded...
2. DOM ready!

Skripte, die das DOMContentLoaded-Ereignis nicht blockieren, sind:

• Skripte mit dem Attribut async
• Skripte, die der Webseite dynamisch mit document.createElement('script') hinzugefügt werden

window.onload Event

Das load-Ereignis wird auf dem window-Objekt ausgelöst, wenn die gesamte Seite, einschließlich Styles, Bilder und anderer Ressourcen, vollständig geladen ist. Dieses Ereignis kann mit der Eigenschaft onload erfasst werden.

Hier ist ein Beispiel, in dem die Größe des Bildes korrekt angezeigt wird, da window.onload wartet, bis alle Bilder vollständig geladen sind:

<script type="text/javascript">
  window.onload = function () {
    console.log('Page loaded');

    // At this point, the image is fully loaded
    console.log(`Image size: ${img.offsetWidth}x${img.offsetHeight}`);
  };
</script>

<img
  id="img"
  src="https://www.google.com/images/branding/googlelogo/2x/googlelogo_color_272x92dp.png"
/>

Die Ausgabe dieses Codes unterscheidet sich vom vorherigen Beispiel, da onload wartet, bis alle Ressourcen vollständig geladen sind:

Page loaded
Image size: 544x184

window.onbeforeunload Event

Das beforeunload-Ereignis wird ausgelöst, kurz bevor die Seite entladen wird (z. B. wenn der Benutzer zu einer anderen Seite navigiert, den Tab schließt oder die Seite aktualisiert). Dieses Ereignis ermöglicht es Entwicklern, den Benutzer aufzufordern, zu bestätigen, ob er die Seite wirklich verlassen möchte. Es wird typischerweise verwendet, um Benutzer daran zu erinnern, nicht gespeicherte Daten zu speichern oder sie vor potenziellem Datenverlust zu warnen.

Browser erlauben die Anzeige einer kurzen Nachricht während dieses Ereignisses, in der Benutzer gefragt werden, ob sie die Seite wirklich verlassen möchten. Wenn Benutzer beispielsweise Inhalte in ein nicht gespeichertes Formular eingegeben haben, können Entwickler beforeunload verwenden, um versehentliches Schließen oder Aktualisieren der Seite zu verhindern.

Moderne Browser zeigen keine benutzerdefinierten Eingabeaufforderungen an. Stattdessen wird eine standardisierte Warnmeldung angezeigt. Hier ist ein Beispiel:

window.onbeforeunload = function () {
  return false;
};

Wenn Benutzer versuchen, die Seite zu verlassen, löst dieses Ereignis einen Bestätigungsdialog aus, in dem sie gefragt werden, ob sie die Seite verlassen oder auf der Seite bleiben möchten.

Aufgrund von Sicherheits- und Benutzererlebnisbedenken ignorieren Browser die meisten benutzerdefinierten Nachrichten und zeigen stattdessen einen generischen Dialog an. Die übermäßige Verwendung von beforeunload kann die Benutzererfahrung beeinträchtigen, daher sollte sie nur verwendet werden, wenn dies unbedingt erforderlich ist, z. B. bei nicht gespeicherten Daten.

unload Event

Das unload-Ereignis wird ausgelöst, wenn die Seite vollständig entladen ist (z. B. wenn die Seite geschlossen, aktualisiert oder von der Seite weg navigiert wird). Im Gegensatz zu beforeunload kann das unload-Ereignis Benutzer nicht daran hindern, die Seite zu verlassen. Es wird hauptsächlich verwendet, um abschließende Bereinigungsaufgaben durchzuführen, z. B. das Löschen temporärer Daten, das Abbrechen asynchroner Anforderungen und das Freigeben von Speicher.

Das unload-Ereignis kann Benutzer nicht auffordern, im Gegensatz zu beforeunload. Stattdessen wird es für Operationen wie das Schließen von WebSocket-Verbindungen, das Speichern von Daten im lokalen Speicher oder das Löschen von Timern verwendet.

Eine spezifische Anwendung des unload-Ereignisses ist das Senden von Analysedaten, bevor die Seite entladen wird. Die Methode navigator.sendBeacon(url, data) kann verwendet werden, um Daten im Hintergrund zu senden, ohne das Entladen der Seite zu verzögern. Zum Beispiel:

const analyticsData = {
  // Object containing collected data
};

window.addEventListener('unload', function () {
  navigator.sendBeacon('/analytics', JSON.stringify(analyticsData));
});

Wenn die sendBeacon-Anforderung abgeschlossen ist, hat der Browser das Dokument möglicherweise bereits verlassen, sodass keine Serverantwort abrufbar ist (die Antwort ist für Analysezwecke oft leer).

Zusammenfassung

Das HTML-Parsing bildet die Grundlage des Seiten-Lifecycles, ist aber selbst kein JavaScript-abrufbares Lifecycle-Ereignis. Das DOMContentLoaded-Ereignis wird ausgelöst, wenn der DOM-Baum vollständig aufgebaut ist, während das load-Ereignis ausgelöst wird, nachdem alle Ressourcen auf der Seite vollständig geladen wurden. Das beforeunload-Ereignis fordert Benutzer auf, die Navigation von der Seite weg zu bestätigen, und das unload-Ereignis wird für die Ressourcenbereinigung während des Entladens der Seite verwendet. Diese Ereignisse geben Entwicklern die Kontrolle über die Seitenlade- und Entladevorgänge und tragen dazu bei, die Benutzererfahrung und die Seitenleistung zu verbessern.

---

Wir sind Leapcell, Ihre erste Wahl für das Hosten von Node.js-Projekten.

Leapcell ist die Serverless-Plattform der nächsten Generation für Webhosting, asynchrone Aufgaben und Redis:

Multi-Sprachen-Unterstützung

• Entwickeln Sie mit Node.js, Python, Go oder Rust.

Setzen Sie unbegrenzt Projekte kostenlos ein

• Zahlen Sie nur für die Nutzung - keine Anfragen, keine Gebühren.

Unschlagbare Kosteneffizienz

• Pay-as-you-go ohne Leerlaufgebühren.
• Beispiel: 25 US-Dollar unterstützen 6,94 Millionen Anfragen bei einer durchschnittlichen Antwortzeit von 60 ms.

Optimierte Entwicklererfahrung

• Intuitive Benutzeroberfläche für mühelose Einrichtung.
• Vollständig automatisierte CI/CD-Pipelines und GitOps-Integration.
• Echtzeitmetriken und -protokollierung für umsetzbare Erkenntnisse.

Mühelose Skalierbarkeit und hohe Leistung

• Automatische Skalierung zur einfachen Bewältigung hoher Parallelität.
• Null Betriebsaufwand - konzentrieren Sie sich einfach auf den Aufbau.

Erfahren Sie mehr in der Dokumentation!

Folgen Sie uns auf X: @LeapcellHQ