{"id":15761,"date":"2026-11-11T13:15:00","date_gmt":"2026-11-11T12:15:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=15761"},"modified":"2026-10-26T12:52:43","modified_gmt":"2026-10-26T11:52:43","slug":"blockierende-skripte-was-zwanzig-html-antworten-zeigen","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/web-entwicklung\/tutorials-de-web-entwicklung\/blockierende-skripte-was-zwanzig-html-antworten-zeigen\/","title":{"rendered":"Blockierende Skripte: Was zwanzig HTML-Antworten zeigen"},"content":{"rendered":"

Die Position eines Skripts im HTML hilft bei der Suche nach Abh\u00e4ngigkeiten. Daraus entstehen jedoch weder eine Zeitmessung noch ein sicherer Nachweis vorhandener Seitenelemente. Eine historische Stichprobe von zwanzig Antworten zeigt Nutzen und Grenzen der statischen Analyse.<\/p>\n

\"745
745 erkannte Tags, 660 klassifizierte Datens\u00e4tze; keine Zeitmessung.<\/figcaption><\/figure>\n

745 Tags gefunden, 660 klassifiziert<\/h2>\n

Die gespeicherte Messung vom 6. September 2026 um 14:26:11 +02:00 enth\u00e4lt 745 erkannte Skript-Tags, im Mittel 37,25 je Antwort. Eine detaillierte Einstufung erhielten nur 660: 283 blockierend, 230 Daten, 70 async, 52 defer und 25 module.<\/p>\n

Die Differenz entsteht durch eine Grenze des Pr\u00fcfers: Pro Dokument bleiben h\u00f6chstens 120 Skript-Datens\u00e4tze erhalten. Bei ZEIT wurden 205 Tags erkannt; 85 fehlen deshalb in der Detailz\u00e4hlung. Auch die gemeldete letzte blockierende Position gilt dort nur f\u00fcr die ersten 120 Datens\u00e4tze.<\/p>\n

Antworten sind nicht immer Startseiten<\/h2>\n

Stack Overflow lieferte Status 429, Allegro Status 403. Das eine beziehungsweise die zwei erkannten Tags geh\u00f6ren zu diesen Antwortdokumenten, nicht zu best\u00e4tigten normalen Startseiten. Die historische Auswahl ist kein aktueller Leistungsvergleich.<\/p>\n

Die GitHub-Antwort enthielt acht Modulskripte und sechs Datenbl\u00f6cke ohne blockierende Einstufung. Daraus folgen weder unterbrechungsfreies Parsen noch fertiges Layout oder geringe JavaScript-Kosten. In sechzehn Antworten lag eine blockierende Einstufung vor dem erkannten schlie\u00dfenden head-Tag. Das beschreibt einen Ort, keine gemessene Verz\u00f6gerung der ersten Anzeige.<\/p>\n

Laderegeln gelten unter Bedingungen<\/h2>\n

Ein vom Parser eingef\u00fcgtes klassisches externes Skript ohne async oder defer unterbricht normalerweise das Parsen bis nach Laden und Ausf\u00fchren. defer verschiebt die Ausf\u00fchrung hinter das Parsen. async vermeidet die Wartezeit beim Laden, kann bei der Ausf\u00fchrung aber weiterhin den Hauptthread belegen. Beide Attribute \u00e4ndern die Ausf\u00fchrungszeit eines eingebetteten klassischen Skripts nicht.<\/p>\n

Module laufen standardm\u00e4\u00dfig nach dem Parsen, auch eingebettete Module; async gilt ebenfalls f\u00fcr Module. Datenbl\u00f6cke, Import Maps und Speculation Rules sind eigene F\u00e4lle. nomodule, Content Security Policy (CSP), Abruffehler und die Art des Einf\u00fcgens k\u00f6nnen die Ausf\u00fchrung verhindern oder ver\u00e4ndern. F\u00fcnf Pr\u00fcferklassen bilden daher nicht das gesamte Browserverhalten ab.<\/p>\n

Byteposition ist keine DOM-Vollst\u00e4ndigkeit<\/h2>\n

Dreizehn gespeicherte Positionen runden auf 95 bis 100 Prozent. Drei statt vier liegen unter 50 Prozent; der Bund-Wert betr\u00e4gt 55 Prozent. Der ZEIT-Wert von 42 Prozent unterliegt der Grenze von 120 Datens\u00e4tzen. Bei Heise steht Position 6.016 innerhalb von 943.607 Bytes, mit 937.591 Bytes ab dem \u00f6ffnenden Skript-Tag.<\/p>\n

Dieser Rest enth\u00e4lt das Skript selbst. Das Document Object Model (DOM) ist die vom Browser aufgebaute Struktur der Seitenelemente. Die verbleibende Bytezahl zeigt nicht genau, welche dieser Elemente bei der Skriptausf\u00fchrung noch fehlen. Vorheriger Code kann Knoten erg\u00e4nzen oder entfernen; die HTML-Verarbeitung kann Strukturen umordnen. Sp\u00e4tere R\u00fcckrufe laufen zu anderen Zeitpunkten. Ein spekulativer Scanner kann au\u00dferdem Ressourcen hinter dem angehaltenen Hauptparser vorab laden.<\/p>\n

Netzwerkkosten ben\u00f6tigen eine Browseraufzeichnung<\/h2>\n

Sieben Antworten enthalten eine blockierende Einstufung mit abweichendem normalisiertem Hostnamen. Der Vergleich entfernt www und ignoriert Schema sowie Port. Das erkennt weder jeden anderen Origin noch fremdes Eigentum. Bei drei Antworten fehlt jeder erkannte preconnect-Hinweis; die \u00fcbrigen wurden damit nicht auf passende Zielhosts gepr\u00fcft.<\/p>\n

Im gespeicherten LukasWojcik-Ergebnis steht stub.js bei 96 Prozent, mit 3.082 Bytes ab dem Tag. Eine Wartezeit wurde nicht gemessen. Cachetreffer, vorhandene Verbindungen und vorgezogene Abrufe k\u00f6nnen neuen Verbindungsaufbau vermeiden. Ein eingebetteter Stub spart den eigenen Dateiabruf, f\u00fchrt aber weiterhin Code aus und muss zur geltenden CSP passen.<\/p>\n

Was der Pr\u00fcfer tats\u00e4chlich feststellt<\/h2>\n

Die verlinkte Analyse untersucht bis zu 3 MiB abgerufenes HTML ohne Ausf\u00fchrung. Elf lokale Gegenproben zeigen Grenzen: Skripttext in Kommentaren oder Templates wird mitgez\u00e4hlt; nomodule landet weiterhin unter blockierend, eingebettetes async-module unter module. Ein leeres integrity-Attribut gilt als vorhanden.<\/p>\n

Der document.write-Befund ist eine Textsuche in eingebettetem Inhalt, kein Aufrufnachweis. Je nach Kontext f\u00fcgt die API Inhalt in den Parserstrom ein, bleibt wirkungslos oder ersetzt ein Dokument. Auch Subresource Integrity (SRI) ben\u00f6tigt verwertbare Integrit\u00e4tsdaten und passende herkunfts\u00fcbergreifende Zugriffsregeln; der Attributname allein reicht nicht.<\/p>\n

Skript-Ladeanalyse<\/a><\/p>\n

\n

Fragen und Antworten<\/h2>\n

Wie l\u00e4sst sich eine ge\u00e4nderte Ladereihenfolge pr\u00fcfen?<\/h3>\n

Eine Browser-Leistungsaufzeichnung vor und nach der \u00c4nderung unter vergleichbaren Cache- und Netzbedingungen zeigt Ressourcenzeiten, Arbeit im Hauptthread und Darstellung. Anschlie\u00dfend geh\u00f6ren abh\u00e4ngiger Code und Einwilligungsverhalten zur Funktionspr\u00fcfung. Statische Z\u00e4hlungen liefern Pr\u00fcfkandidaten; die Aufzeichnung misst die Wirkung.<\/p>\n

Darf ein Einwilligungs-Stub einfach defer oder async erhalten?<\/h3>\n

Ein Einwilligungs-Stub ist ein kleines Platzhalterskript. Es sammelt Aufrufe in einer Warteschlange, bis die vollst\u00e4ndige Einwilligungssoftware geladen ist. Eine \u00c4nderung der Ladereihenfolge erfordert die Pr\u00fcfung aller Abh\u00e4ngigkeiten. Die Warteschlange muss vor dem zugreifenden Code verf\u00fcgbar sein; eine andere Ausf\u00fchrungszeit kann diese Voraussetzung verletzen. Eine eingebettete Kopie braucht au\u00dferdem einen gepflegten Aktualisierungsprozess. preconnect und preload k\u00f6nnen Wartezeit reduzieren, garantieren aber weder eine feste Ersparnis noch kostenlose Ausf\u00fchrung.<\/p>\n<\/div>\n

\n

Quellen<\/h2>\n