Renderblockierende Ressourcen.

Renderblockierende Ressourcen sind die Stil- und Skriptdateien, ohne deren Laden und Verarbeiten der Browser das erste Malen nicht ausführen kann.

Bevor der Browser eine Seite malt, braucht er zwei Dinge: die Struktur des Dokuments und die darauf anzuwendenden Stile. Fehlt der Stil, malt er nicht — denn das Gemalte könnte sich im nächsten Moment völlig ändern, und der Nutzer sähe ein „Aufblitzen ungestalteten Inhalts“. Stildateien sind deshalb per Definition blockierend.

Skripte blockieren aus einem anderen Grund: Ein klassisches Skript-Tag hält das Parsen des Dokuments an, denn das Skript kann das Dokument verändern. Da der Browser nicht weiß, was kommt, wartet er.

Drei Arten der Blockierung

1. Die Stildatei — immer blockierend. Mit einer Media Query eingeschränkt, blockiert sie nicht, solange die Bedingung nicht gilt.
2. Das synchrone Skript — hält das Parsen während Laden UND Ausführen an. Das teuerste.
3. Das aufgeschobene Skript — Laden parallel, Ausführen nach der Dokumentbereitschaft. Blockiert nicht und wahrt die Reihenfolge.
4. Das asynchrone Skript — Laden parallel, Ausführen im Moment der Ankunft. Blockiert nicht, garantiert aber keine Reihenfolge.
5. Das Modulskript — verhält sich standardmäßig aufgeschoben.

Die praktische Regel: Kein Skript sollte synchron sein. Die Ausnahme ist ein sehr kleines Stück Code, das das erste Malen direkt betrifft und dessen Verzögerung einen sichtbaren Sprung erzeugen würde — und selbst das lässt sich meist anders lösen.

Auf der Stilseite lässt sich die Blockierung nicht beseitigen, nur verringern. Zwei Wege: die Dateizahl senken und die Dateigröße senken.

Auf dieser Website gemessen und geschlossen

Auf dieser Website wurde die Blockierung gemessen und geschlossen; der Vorgang ist dokumentiert. Im mobilen Lighthouse-Lauf blockierten zwei getrennte Stildateien das Rendern: eine 821 Millisekunden, die andere 221. Zwei Dateien hießen zwei Anfragen.

Die erste Korrektur war das Verschmelzen: Die zwei Dateien wurden in einer gesammelt, und die Anfragenzahl fiel von zwei auf eins. Die zweite war das Entfernen — ein beachtlicher Teil der Quelldatei war Kommentar, und Kommentare sollten nicht zum Nutzer gelangen.

Das gemessene Ergebnis: 67,4 Kilobyte Quelle, 12,4 nach gzip. Ein Gewinn von 11,4 Kilobyte an der renderblockierenden Datei. Das Entfernen blieb bewusst konservativ — nur Kommentare und Einzüge; Selektoren und Werte wurden nie berührt.

Auch der Grund der Vorsicht wurde gemessen: Aggressives Entfernen brachte nur 747 Byte mehr und trug das Risiko, Nachfahren-Pseudo-Muster zu brechen. Gewinn und Risiko wurden nebeneinandergelegt und entschieden.

Für 747 Byte riskiert man keinen Selektor — der Gewinn wird gemessen, das Risiko auch.

Drittanbieter-Blocker

Nach der Optimierung der eigenen Ressourcen ist der größte verbleibende Blocker meist fremder Code. Tag-Manager, Schriftanbieter, A/B-Test-Werkzeuge und Chat-Blasen — alle werden meist synchron und am Seitenanfang eingefügt.

Diese Skripte gehen zudem an eine externe Domain, tragen also die Kosten einer zusätzlichen Namensauflösung und eines zusätzlichen Verbindungsaufbaus. Die Gesamtkosten übersteigen auf den meisten Websites die der eigenen Stildateien.

Auf dieser Website gibt es keine Drittanbieter-Skripte, und die Content-Security-Policy blockiert externe Ressourcenanfragen ohnehin. Die Entscheidung ist so sehr Datenschutz wie Performance — und die Prüfsuite misst, dass beim Seitenstart keine externe Anfrage geschieht.

Messung und Prüfung

Die renderblockierenden Ressourcen zu finden dauert wenige Minuten und braucht kein besonderes Werkzeug. Das Performance-Panel des Browsers listet die bis zum ersten Malen ladenden Ressourcen; jede Stildatei und jedes synchrone Skript auf dieser Liste ist ein Blocker.

1. Wie viele Stildateien kommen herunter — mehr als eine ist ein Verschmelzungskandidat.
2. Gibt es synchrone Skripte — lassen sie sich aufschieben oder asynchron machen?
3. Gibt es externe Domains — jede kostet zusätzliche Auflösung und Verbindung.
4. Werden Media Queries verwendet — ein Nur-Druck-Stil darf am Bildschirm nicht blockieren.
5. Ist die Kompression an — sendet der Server wirklich komprimiert?

Der vierte Punkt ist ein billiger Gewinn: Nur unter bestimmten Bedingungen nötige Stile werden, wird die Bedingung deklariert, vom Browser mit niedriger Priorität geladen und blockieren das Malen nicht. Druckstile sind das klassische Beispiel.

Der fünfte Punkt darf nicht angenommen werden. Fälle, in denen die Kompression für an gehalten wird und es nicht ist, sind häufig — besonders bei eigenen Serverkonfigurationen. Die Kontrolle geht mit einer einzeiligen Anfrage, und die Wirkung erfasst alle Textressourcen.

Auf dieser Website liegt der Stil in einer Datei, die Skripte sind aufgeschoben, externe Ressourcen gibt es nicht, und die Content-Security-Policy blockiert externe Anfragen ohnehin. Alle fünf Kontrollen sind auf Konfigurationsebene geschlossen.

Eine praktische Checkliste

Übersetzt man diese Seite in einen Prüfschritt, ist für blockierende Ressourcen Folgendes zu prüfen. Die Liste bleibt kurz, denn lange Listen werden nicht abgeschritten; sechs Punkte passen in eine Sitzung.

1. Wie viele Ressourcen kommen bis zum ersten Malen herunter?
2. Gibt es synchrone Skripte — es sollte keine geben.
3. Ist die Stildatei-Zahl eins?
4. Gibt es Anfragen an externe Domains?
5. Gibt es Stile, die sich mit Media Queries eingrenzen ließen?
6. Ist die Kompression wirklich an?

Auf dieser Website sind alle sechs Kontrollen auf Konfigurationsebene geschlossen: eine einzige Stildatei, aufgeschobene Skripte, keine externen Ressourcen und eine Content-Security-Policy, die externe Anfragen ohnehin blockiert.

Dass die Kompression an ist, wird nicht angenommen; es wird gemessen.

Ein Reihenfolgevorschlag zum Schluss: Die Renderblocker zu bereinigen sollte der erste Schritt der Performance-Arbeit sein, denn die Wirkung geht direkt ins erste Malen und die Kosten sind niedrig. Bildoptimierung und Code-Splitting sind sichtbarere Arbeiten, aber ist das erste Malen ohnehin blockiert, bleibt die Wirkung beider begrenzt.

Und eine Wartungsnotiz: Die Blockerzahl wächst mit der Zeit. Eine neue Schrift, ein neues Analytikskript, eine neue Stildatei — jedes wirkt für sich klein, und zusammen ziehen sie das erste Malen zurück. Die Checkliste sollte deshalb nicht einmal abgeschritten und fallengelassen, sondern an einen Test gebunden werden, damit das Wachstum im Deployment sichtbar wird.

Eine letzte technische Notiz: Es gibt Wege, eine Stildatei nicht-blockierend zu machen, aber alle tragen eine Abwägung. Einen Stil spät zu laden heißt, dass der damit zu gestaltende Inhalt eine Weile ungestaltet erscheint — und das Aufblitzen ungestalteten Inhalts kann mehr stören als langsames Laden. Kein Stil, der den ersten sichtbaren Bereich betrifft, sollte deshalb aufgeschoben werden; das Aufschieben ergibt nur für tief in der Seite verwendete Stile Sinn.