Leitfäden

Render-blockierende Ressourcen: was wirklich blockiert, und warum async nicht die Lösung ist

vuetelemetry
Leitfäden
8 Min. Lesezeit

Lighthouse benennt das Audit und listet die Dateien. Es erklärt nicht, dass ein Skript ohne Attribut den Parser sofort anhält, dass async beim Ausführen weiterhin das Rendern blockiert, und dass CSS aus einem ganz anderen Grund blockiert.

„Render-blockierende Ressourcen entfernen" ist das häufigste Audit in einem Lighthouse-Bericht und das am wenigsten erklärte. Es nennt die Dateien und hört dort auf. Hinter dieser einen Zeile stecken zwei verschiedene Mechanismen, und sie brauchen verschiedene Lösungen.

Skripte: was jedes Attribut wirklich tut

Menschen, die von oben gesehen an einem Bordstein anstehen, daneben Fahrbahnmarkierungen. Ein render-blockierendes Skript macht dasselbe mit dem Parser: Alles dahinter wartet der Reihe nach, bis das vorderste fertig ist.

**Ein klassisches Skript ohne Attribut hält den Parser an.** MDN sagt es unumwunden: Skripte ohne `async`, `defer` oder `type="module"` werden *„sofort geladen und ausgeführt, bevor der Browser mit dem Parsen der Seite fortfährt"*. Der Browser baut Ihr Dokument, trifft auf das Tag und hält an: laden, ausführen, dann weiter. Alles darunter wartet.

**`defer` ist meistens die Antwort.** Das Attribut zeigt an, dass das Skript *„ausgeführt werden soll, nachdem das Dokument geparst wurde, aber bevor DOMContentLoaded ausgelöst wird"*. Das Parsen läuft ununterbrochen weiter, und aufgeschobene Skripte *„werden in der Reihenfolge ausgeführt, in der sie im Dokument stehen"* - ein Skript, das von einem anderen abhängt, bekommt es also weiterhin.

**`async` ist das, was falsch eingesetzt wird.** Es wird *„parallel zum Parsen geladen und ausgewertet, sobald es verfügbar ist"*, was strikt besser klingt. Weggelassen wird der Satz direkt danach: *„sobald der Download abgeschlossen ist, wird das Skript ausgeführt, was das Rendern der Seite blockiert"*.

async beseitigt also die Blockade beim **Laden**, nicht bei der **Ausführung**. Ein großes async geladenes Skript kommt an, wann es ankommt, mitten im Parsen, und blockiert dann das Rendern. Und weil die Ausführungsreihenfolge der Ankunftsreihenfolge folgt, warnt MDN, es gebe *„keine Garantie, dass Skripte in einer bestimmten Reihenfolge laufen"* - was alles mit Abhängigkeiten zerlegt.

Die kurze Regel: **defer für eigene Skripte, async nur für wirklich unabhängige Dritte**, etwa ein Analytics-Beacon, das mit niemandem spricht.

CSS blockiert aus einem anderen Grund

**CSS blockiert aus einem anderen Grund, und die Lösung ist kein Attribut.** Ein Stylesheet hält den HTML-Parser nicht an, aber der Browser zeichnet nicht, bevor er das benötigte CSS hat, denn erst zeichnen und danach umstylen würde ungestylte Inhalte aufblitzen lassen. Das ist eine Render-Blockade, keine Parse-Blockade.

Ohne Attribut: sofort geladen und ausgeführt, das Parsen hält an
defer: führt nach dem Parsen aus, in Dokumentreihenfolge, vor DOMContentLoaded
async: keine Blockade beim Laden, die Ausführung blockiert aber das Rendern, und die Reihenfolge ist nicht garantiert
CSS: blockiert nicht das Parsen, sondern das Zeichnen - Geltungsbereich per media einschränken
Drittanbieter-Tags machen meist den größten Teil des Audits aus

Der Hebel ist hier der Geltungsbereich, nicht der Zeitpunkt. Ein Stylesheet, das nur für einen Kontext gilt, kann ein `media`-Attribut tragen, und der Browser lädt es, ohne es den ersten Paint blockieren zu lassen - `media="print"` ist der bekannte Fall. Übrig bleibt das CSS, das der erste Bildschirm wirklich braucht, und genau das lohnt sich klein zu halten.

- vuetelemetry

Wo das Gewicht liegt, und wie man es bestätigt

**Drittanbieter-Tags sind meist das eigentliche Gewicht.** Ihr eigenes Bundle liegt vor Ihnen und wird optimiert; der Tag-Manager, das Chat-Widget und das Consent-Banner kommen als Skripte, die Sie nicht geschrieben haben und die oft weitere Skripte nachladen. Zu prüfen, was sie wirklich kosten - und ob jedes es wert ist -, bewegt die Zahl weit mehr als Kilobytes am eigenen Code zu sparen.

**Und dann messen Sie im Feld, nicht im Bericht.** Lighthouse sagt Ihnen, dass eine Ressource render-blockierend war; es sagt Ihnen nicht, ob ihr Entfernen für Ihre Besucher etwas geändert hat. Dieser Unterschied zwischen Laboraudit und echten Nutzern ist [ein eigenes Thema](/de/articles/felddaten-vs-labordaten), und er entscheidet, ob die Arbeit sich gelohnt hat.

FAQ

Was bedeutet „render-blockierende Ressourcen entfernen"?

Es ist ein Lighthouse-Audit, das Skripte und Stylesheets auflistet, die den ersten Paint verzögern. Dahinter stecken zwei verschiedene Mechanismen: Ein klassisches Skript ohne Attribut hält den HTML-Parser vollständig an, während ein Stylesheet das Parsen weiterlaufen lässt, aber das Zeichnen bis zum Laden verhindert. Sie brauchen unterschiedliche Lösungen, weshalb das Audit allein nicht genügt.

Sollte ich async oder defer verwenden?

defer für eigene Skripte, async nur für wirklich unabhängige Dritte. defer führt nach dem Parsen aus, in Dokumentreihenfolge, sodass Abhängigkeiten weiter funktionieren. async führt aus, sobald der Download fertig ist, was in diesem Moment das Rendern blockiert, und MDN warnt, dass es keine Garantie für die Ausführungsreihenfolge gibt.

Macht async ein Skript nicht-blockierend?

Nicht ganz, und das ist das übliche Missverständnis. async beseitigt die Blockade während des Ladens: Das Skript wird parallel zum Parsen geholt. Aber MDN hält fest, dass das Skript nach abgeschlossenem Download ausgeführt wird und diese Ausführung das Rendern der Seite blockiert. Ein großes async-Skript blockiert lediglich zu einem unvorhersehbaren statt zu einem vorhersehbaren Zeitpunkt.

Warum blockiert CSS das Rendern?

Weil ein Zeichnen vor Ankunft des Stylesheets ungestylte Inhalte zeigen würde, die danach neu gerendert werden müssten. Also wartet der Browser. Anders als ein Skript hält CSS nicht den HTML-Parser an, sondern den Paint. Die Lösung ist kein Attribut, sondern der Geltungsbereich - ein per media eingeschränktes Stylesheet wird geladen, ohne den ersten Paint aufzuhalten.

Woran erkenne ich, ob die Korrektur geholfen hat?

Nicht am Lighthouse-Bericht, der Ihnen nur sagt, dass eine Ressource render-blockierend war. Ob die Änderung bei Ihren Besuchern angekommen ist, zeigen die Felddaten, im 75. Perzentil über 28 Tage. Ein Laboraudit benennt den Kandidaten; nur das Feld bestätigt das Ergebnis.