Rolf B: „Nachlade-Effekt“ bei durch JavaScript generierten Elementen

Beitrag lesen

Hallo Raketenwilli,

Freilich ist das synchrones JS und widerspricht damit derzeitigen Moden.

Da der Browser erst dann was anzeigt, wenn das HTML komplett geparsed ist (oder irre ich mich da?), kann der relevante Script-Block auch am Ende des Body stehen. Wenn er nicht zu viel tut, ist das nicht schlimm.

The DOMContentLoaded event fires when the initial HTML document has been completely loaded and parsed, without waiting for stylesheets, images, and subframes to finish loading.

Ja. Schon. Aber es gibt noch einen anderen Einfluss: script-blocking elements. Das sind <link rel="stylesheet"> oder auch <style> Elemente, die im Dokument stehen und erstmal fertig geladen und in das CSSOM übertragen werden müssen, bevor JavaScript auch nur eine Zeile Code ausführt. Guck mal hier. Es gilt nicht für Stylesheets, die von einem Script hinzugefügt wurden, wenn ich die Spec richtig lese.

Es kann also bei umfangreichem CSS sein, dass man ein inline Script-Element hat, das einen DOMContentLoaded Handler registrieren will, aber dieses Script erstmal auf die CSS Dateien wartet. Und der DOM Parser wartet auf das Script.

Der Browser liest DOM und CSSOM parallel ein. Er rendert nicht, bevor das CSSOM bereitsteht. Er führt auch keine Scripte aus, bevor das CSSOM bereitsteht. Ein Scriptblock mit defer-Attribut oder der am DOM Ende steht, wird also kurz vor dem Beginn des ersten Renderings ausgeführt. Wenn er nichts weiter tut als 2-3 Eventhandler zu registrieren und Elemente im DOM sichtbar zu schalten, sollte das unkritisch sein.

Umfangreiche Scripte, bei denen der JavaScript Parser und JIT viel zu tun haben, sollte man vorn im head laden, aber mit defer oder async-Attribut, so dass sie übersetzt sind, wenn das DOM bereitsteht.

Wenn man das optimal gestalten will, ist das keine kleine Nummer.

Rolf

--
sumpsi - posui - obstruxi