{"id":14854,"date":"2026-10-26T12:45:00","date_gmt":"2026-10-26T11:45:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=14854"},"modified":"2026-10-26T13:09:08","modified_gmt":"2026-10-26T12:09:08","slug":"klassische-skripte-und-dom-elemente-zum-richtigen-zeitpunkt-finden","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/web-entwicklung\/klassische-skripte-und-dom-elemente-zum-richtigen-zeitpunkt-finden\/","title":{"rendered":"Klassische Skripte und DOM: Elemente zum richtigen Zeitpunkt finden"},"content":{"rendered":"

Der HTML-Parser liest den Seitenquelltext und baut daraus die Struktur der Seitenelemente auf. Ein von diesem Parser verarbeitetes klassisches Skript ohne async<\/code> und ohne wirksames defer<\/code><\/strong> unterbricht den weiteren HTML-Aufbau w\u00e4hrend der Ausf\u00fchrung. Sp\u00e4ter im Quelltext stehende Elemente sind dann normalerweise noch nicht im Dokumentbaum (DOM) vorhanden. F\u00fcr Module, asynchrone oder dynamisch eingef\u00fcgte Skripte gelten andere Regeln.<\/p>\n

Das erkl\u00e4rt einen typischen Fehler beim Theme-Wechsel: Der Schalter im Seitenkopf funktioniert, aber beim ersten Laden werden die Bilder im sp\u00e4ter folgenden Artikel nicht gefunden. Die Bilddateien k\u00f6nnen vollst\u00e4ndig vorhanden sein; die Abfrage erfolgt lediglich zu fr\u00fch.<\/p>\n

\"Isolierter
Test vom 24. Oktober 2026 in Chromium: zwei Figuren nach dem Kopfskript. Die Werte beschreiben dieses Beispiel, keine historischen Seitenabrufe.<\/figcaption><\/figure>\n

Quelltextposition ist kein Laufzeitnachweis<\/h2>\n

Eine Byteposition zeigt die Reihenfolge im ausgelieferten HTML. Eine Z\u00e4hlung \u00f6ffnender Tags entspricht jedoch nicht automatisch der Zahl vorhandener DOM-Elemente: Kommentare, Skripttexte, implizit erzeugte Elemente und nachtr\u00e4gliche \u00c4nderungen k\u00f6nnen das Ergebnis ver\u00e4ndern. Auch fr\u00fcher ausgef\u00fchrte Skripte k\u00f6nnen bereits zus\u00e4tzliche Elemente angelegt haben.<\/p>\n

Ein geeigneter Nachweis erfasst deshalb document.readyState<\/code> und die tats\u00e4chlich gefundenen Elemente direkt bei der Ausf\u00fchrung. Die fr\u00fcher genannten Seitenumf\u00e4nge und Dateizahlen werden hier nicht als reproduzierte Messung fortgeschrieben. Stattdessen zeigt ein kleines isoliertes Browserbeispiel den Mechanismus.<\/p>\n

Was der Browsertest zeigt<\/h2>\n

Im Test vom 24. Oktober 2026 stehen zwei figure<\/code>-Elemente nach einem klassischen Skript im Kopf. Die fr\u00fche Abfrage findet null Figuren. Ein externes klassisches Skript mit defer<\/code> und ein normales Modul finden sp\u00e4ter beide Figuren. Ein defer<\/code>-Attribut am eingebetteten klassischen Skript \u00e4ndert die fr\u00fche Ausf\u00fchrung nicht.<\/p>\n

querySelectorAll()<\/code> liefert zudem eine statische Liste. Die fr\u00fch gespeicherte leere Liste bleibt leer, auch nachdem die beiden Figuren existieren. Nach dem HTML-Aufbau ist deshalb eine neue Abfrage erforderlich. Gepr\u00fcft wurde ein isoliertes Chromium-Beispiel, keine Browsermatrix und keine historische Netzwerkaufzeichnung der Website.<\/p>\n

Warum ein sp\u00e4terer Klick nicht gen\u00fcgt<\/h2>\n

Ein Klick nach dem Aufbau pr\u00fcft den Zustandswechsel bei bereits vorhandenen Elementen. Daraus folgt nicht, dass dieselbe Funktion beim ersten Laden funktioniert. Ein Klick kann au\u00dferdem schon w\u00e4hrend des Ladens erfolgen, sobald der Schalter angezeigt wird und eine Funktion f\u00fcr die Klickverarbeitung vorhanden ist.<\/p>\n

Eine gespeicherte helle Auswahl, ein Neuladen in dunkler Ansicht und ein Wechsel w\u00e4hrend des Ladens sind daher getrennte Testf\u00e4lle. F\u00fcr das Bildtauschen z\u00e4hlt jeweils der aktuelle Theme-Zustand. Bereits vorhandene Kopfzeilenelemente sagen nichts dar\u00fcber aus, ob die sp\u00e4ter folgenden Artikelfiguren schon existieren.<\/p>\n

Bildtausch erst nach dem HTML-Aufbau<\/h2>\n

Das folgende Integrationsbeispiel setzt eine vorhandene Funktion bilderJetztTauschen(hell)<\/code> voraus. Diese Funktion muss bei jedem Aufruf die aktuellen Bildelemente erneut abfragen und die passenden Adressen setzen. Der Ausschnitt organisiert ausschlie\u00dflich den Ausf\u00fchrungszeitpunkt.<\/p>\n

const wurzel = document.documentElement;\nlet bildtauschGeplant = false;\n\nfunction bilderTauschen(hell) {\n    if (document.readyState === 'loading') {\n        if (bildtauschGeplant) return;\n        bildtauschGeplant = true;\n        document.addEventListener('DOMContentLoaded', function () {\n            bildtauschGeplant = false;\n            bilderJetztTauschen(wurzel.getAttribute('data-theme') === 'light');\n        }, { once: true });\n        return;\n    }\n    bilderJetztTauschen(hell);\n}<\/code><\/pre>\n
Solange readyState<\/code> den Wert loading<\/code> hat, wird h\u00f6chstens ein Listener registriert. Beim sp\u00e4teren Ereignis wird die aktuelle Auswahl aus data-theme<\/code> gelesen. Nach dem HTML-Aufbau erfolgt der Aufruf sofort mit dem \u00fcbergebenen Wert. Die Auswahl muss vor dem Aufruf im Wurzelelement aktualisiert werden.<\/p>\n
Im isolierten Test f\u00fchrten drei fr\u00fche Aufrufe zu genau einem sp\u00e4teren Tausch mit der zuletzt gesetzten hellen Auswahl. Ein anschlie\u00dfender Aufruf mit dunkler Auswahl wirkte unmittelbar. Der Ausschnitt ist eine optimierte Variante; eine \u00c4nderung am produktiven Theme ist damit nicht verbunden.<\/p>\n
\n
Fragen und Antworten<\/h2>\n
Wann helfen defer und Module?<\/h3>\n
Bei externen klassischen Skripten verschiebt defer<\/code> die Ausf\u00fchrung hinter das HTML-Parsing und erh\u00e4lt die Dokumentreihenfolge. Normale Module werden ebenfalls nach dem Parsing ausgef\u00fchrt. async<\/code> bietet diese Zusage nicht; die Ausf\u00fchrung h\u00e4ngt von der Verf\u00fcgbarkeit des Skripts ab. Bei Modulen kann async<\/code> auch ohne eigenes src<\/code> relevant sein. F\u00fcr eingebettete klassische Skripte bleiben defer<\/code> und async<\/code> wirkungslos.<\/p>\n
Warum DOMContentLoaded statt load?<\/h3>\n
DOMContentLoaded<\/code> folgt auf das HTML-Parsing und die zugeh\u00f6rigen verz\u00f6gerten Skripte. Das Ereignis wartet nicht auf alle Bilder oder asynchronen Skripte; Stylesheets k\u00f6nnen indirekt \u00fcber wartende Skripte verz\u00f6gern. load<\/code> wartet zus\u00e4tzlich auf weitere Seitenressourcen, nimmt aber verz\u00f6gert geladene Bilder aus. F\u00fcr ben\u00f6tigte Webfonts ist document.fonts.ready<\/code> der gezielte Pr\u00fcfpunkt. Zum Auffinden der Figuren gen\u00fcgt der aufgebaute Dokumentbaum.<\/p>\n
Verhindert der Tausch doppelte Bild\u00fcbertragungen?<\/h3>\n
Nein. Vorablader oder der Bildlader k\u00f6nnen die urspr\u00fcngliche Adresse schon angefordert haben. Cache, Ladeabstand, Verbindung und Browser bestimmen den tats\u00e4chlichen Aufwand; loading=\"lazy\"<\/code> garantiert keine vermiedene Anfrage. Netzwerkprotokolle sind daf\u00fcr aussagekr\u00e4ftiger als die Skriptposition.<\/p>\n
<picture><\/code> mit prefers-color-scheme<\/code> kann die Systemauswahl ber\u00fccksichtigen. Eine allein in localStorage<\/code> gespeicherte Auswahl ist weder f\u00fcr CSS-Medienabfragen lesbar noch automatisch dem Server bekannt. Eine serverseitige Auswahl ben\u00f6tigt einen gesondert \u00fcbermittelten Zustand.<\/p>\n
Was gilt bei sp\u00e4ter nachgeladenen Artikeln?<\/h3>\n
DOMContentLoaded<\/code> wird f\u00fcr dasselbe Dokument nicht erneut ausgel\u00f6st. Nach einem Inhaltswechsel ohne vollst\u00e4ndige Navigation ist ein eigener Aufruf nach dem Einf\u00fcgen erforderlich. Im Test erzeugte eine sp\u00e4ter eingef\u00fcgte dritte Figur keinen automatischen weiteren Tausch.<\/p>\n<\/div>\n
\n
Quellen<\/h2>\n