English
DeutschBlockierende Skripte: Was zwanzig HTML-Antworten zeigen
Management Summary
Website-Skripte ermöglichen interaktive Funktionen, Analyse und Einwilligungsverwaltung, können den Browser beim Seitenaufbau aber auch aufhalten. Ein anderer Ausführungszeitpunkt kann das Laden verbessern, sofern Abhängigkeiten erhalten bleiben. Eine historische Prüfung von zwanzig Antworten zeigt mögliche Verzögerungsquellen, misst jedoch keine tatsächlichen Wartezeiten. Entscheidend sind deshalb Geschwindigkeit und korrektes Verhalten zugleich: Verschobene Skripte können Wartezeit sparen, aber auch zeitlich abhängige Funktionen stören.
Inhalt
Die Position eines Skripts im HTML hilft bei der Suche nach Abhängigkeiten. 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.
745 Tags gefunden, 660 klassifiziert
Die gespeicherte Messung vom 6. September 2026 um 14:26:11 +02:00 enthält 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.
Die Differenz entsteht durch eine Grenze des Prüfers: Pro Dokument bleiben höchstens 120 Skript-Datensätze erhalten. Bei ZEIT wurden 205 Tags erkannt; 85 fehlen deshalb in der Detailzählung. Auch die gemeldete letzte blockierende Position gilt dort nur für die ersten 120 Datensätze.
Antworten sind nicht immer Startseiten
Stack Overflow lieferte Status 429, Allegro Status 403. Das eine beziehungsweise die zwei erkannten Tags gehören zu diesen Antwortdokumenten, nicht zu bestätigten normalen Startseiten. Die historische Auswahl ist kein aktueller Leistungsvergleich.
Die GitHub-Antwort enthielt acht Modulskripte und sechs Datenblöcke 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ßenden head-Tag. Das beschreibt einen Ort, keine gemessene Verzögerung der ersten Anzeige.
Laderegeln gelten unter Bedingungen
Ein vom Parser eingefügtes klassisches externes Skript ohne async oder defer unterbricht normalerweise das Parsen bis nach Laden und Ausführen. defer verschiebt die Ausführung hinter das Parsen. async vermeidet die Wartezeit beim Laden, kann bei der Ausführung aber weiterhin den Hauptthread belegen. Beide Attribute ändern die Ausführungszeit eines eingebetteten klassischen Skripts nicht.
Module laufen standardmäßig nach dem Parsen, auch eingebettete Module; async gilt ebenfalls für Module. Datenblöcke, Import Maps und Speculation Rules sind eigene Fälle. nomodule, Content Security Policy (CSP), Abruffehler und die Art des Einfügens können die Ausführung verhindern oder verändern. Fünf Prüferklassen bilden daher nicht das gesamte Browserverhalten ab.
Byteposition ist keine DOM-Vollständigkeit
Dreizehn gespeicherte Positionen runden auf 95 bis 100 Prozent. Drei statt vier liegen unter 50 Prozent; der Bund-Wert beträgt 55 Prozent. Der ZEIT-Wert von 42 Prozent unterliegt der Grenze von 120 Datensätzen. Bei Heise steht Position 6.016 innerhalb von 943.607 Bytes, mit 937.591 Bytes ab dem öffnenden Skript-Tag.
Dieser Rest enthält 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ührung noch fehlen. Vorheriger Code kann Knoten ergänzen oder entfernen; die HTML-Verarbeitung kann Strukturen umordnen. Spätere Rückrufe laufen zu anderen Zeitpunkten. Ein spekulativer Scanner kann außerdem Ressourcen hinter dem angehaltenen Hauptparser vorab laden.
Netzwerkkosten benötigen eine Browseraufzeichnung
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 übrigen wurden damit nicht auf passende Zielhosts geprüft.
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önnen neuen Verbindungsaufbau vermeiden. Ein eingebetteter Stub spart den eigenen Dateiabruf, führt aber weiterhin Code aus und muss zur geltenden CSP passen.
Was der Prüfer tatsächlich feststellt
Die verlinkte Analyse untersucht bis zu 3 MiB abgerufenes HTML ohne Ausführung. Elf lokale Gegenproben zeigen Grenzen: Skripttext in Kommentaren oder Templates wird mitgezählt; nomodule landet weiterhin unter blockierend, eingebettetes async-module unter module. Ein leeres integrity-Attribut gilt als vorhanden.
Der document.write-Befund ist eine Textsuche in eingebettetem Inhalt, kein Aufrufnachweis. Je nach Kontext fügt die API Inhalt in den Parserstrom ein, bleibt wirkungslos oder ersetzt ein Dokument. Auch Subresource Integrity (SRI) benötigt verwertbare Integritätsdaten und passende herkunftsübergreifende Zugriffsregeln; der Attributname allein reicht nicht.
Fragen und Antworten
Wie lässt sich eine geänderte Ladereihenfolge prüfen?
Eine Browser-Leistungsaufzeichnung vor und nach der Änderung unter vergleichbaren Cache- und Netzbedingungen zeigt Ressourcenzeiten, Arbeit im Hauptthread und Darstellung. Anschließend gehören abhängiger Code und Einwilligungsverhalten zur Funktionsprüfung. Statische Zählungen liefern Prüfkandidaten; die Aufzeichnung misst die Wirkung.
Darf ein Einwilligungs-Stub einfach defer oder async erhalten?
Ein Einwilligungs-Stub ist ein kleines Platzhalterskript. Es sammelt Aufrufe in einer Warteschlange, bis die vollständige Einwilligungssoftware geladen ist. Eine Änderung der Ladereihenfolge erfordert die Prüfung aller Abhängigkeiten. Die Warteschlange muss vor dem zugreifenden Code verfügbar sein; eine andere Ausführungszeit kann diese Voraussetzung verletzen. Eine eingebettete Kopie braucht außerdem einen gepflegten Aktualisierungsprozess. preconnect und preload können Wartezeit reduzieren, garantieren aber weder eine feste Ersparnis noch kostenlose Ausführung.
Passend dazu
