Der Browser wartet — auf Dateien, die er noch nicht braucht.

Warum der Browser wartet.

Der Browser liest das HTML von oben nach unten. Stößt er auf ein Stylesheet, muss er es laden und verarbeiten, bevor er etwas zeichnen darf — sonst würde die Seite kurz unformatiert erscheinen. Stößt er auf ein Skript ohne besondere Kennzeichnung, hält er sogar das Einlesen des HTML an, weil das Skript die Seite verändern könnte.

Daraus folgt: Jede Datei im Kopfbereich ist eine potenzielle Bremse. Und zwar nicht wegen ihrer Größe, sondern wegen der Wartezeit — eine kleine Datei von einem langsamen fremden Server blockiert genauso lange wie eine große vom eigenen.

Stylesheets.

Alle Stylesheets, die der Browser findet, blockieren die Darstellung. Das ist grundsätzlich richtig, wird aber zum Problem, wenn eine Seite zwanzig davon lädt — eins vom Theme, je eins von zwölf Plugins, dazu eine Schriftbibliothek und ein Symbolsatz.

Drei Ansätze: Dateien reduzieren, nicht benötigte Stylesheets auf Seiten ausschließen, auf denen das Plugin gar nicht vorkommt, und für Teile, die nicht sofort gebraucht werden, eine nachrangige Ladeweise wählen.

Der mittlere Punkt ist bei WordPress der wirksamste: Ein Formular-Plugin lädt sein Stylesheet oft auf jeder Seite, obwohl das Formular nur auf der Kontaktseite steht. Das lässt sich gezielt abschalten (Plugin-Audit).

Skripte.

Die dritte Zeile ist in den allermeisten Fällen die richtige Wahl: Das Skript wird parallel geladen, läuft aber erst, wenn die Seite steht — und die Reihenfolge untereinander bleibt erhalten, was bei abhängigen Skripten wichtig ist.

Die zweite Zeile ist schneller, aber riskanter: Die Reihenfolge ist nicht garantiert. Für ein Skript, das auf eine Bibliothek angewiesen ist, geht das schief.

Nachrangig laden.

Die Maßnahme mit dem besten Verhältnis von Aufwand und Wirkung. In WordPress übernehmen das Optimierungs-Plugins; man kann es auch gezielt im Theme machen.

Wichtig ist, auszuprobieren statt pauschal umzustellen. Manche Skripte vertragen es nicht — typischerweise solche, die direkt im HTML etwas ausgeben, oder alte Skripte, die davon ausgehen, dass sie vor allem anderen laufen. Deshalb: umstellen, dann die wichtigsten Seiten und Funktionen durchklicken.

Die großen Gewinner sind meist Skripte, die gar nichts mit der Darstellung zu tun haben: Analyse, Marketing, Chat, Bewertungen. Die dürfen alle warten (INP).

Kritisches CSS.

Die Idee: Nur die Gestaltungsregeln, die für den ersten sichtbaren Bereich nötig sind, werden direkt in die Seite geschrieben; der Rest wird nachgeladen, ohne zu blockieren. Damit erscheint sofort etwas Fertiges.

Das ist wirksam und hat zwei Haken. Erstens muss das kritische CSS zur jeweiligen Seite passen — eine Produktseite braucht andere Regeln als die Startseite. Zweitens veraltet es: Nach jeder Gestaltungsänderung muss es neu erzeugt werden, sonst sieht der erste Moment falsch aus.

Mein Rat: erst die einfacheren Maßnahmen ausschöpfen. Kritisches CSS lohnt, wenn die Serverantwortzeit gut ist und trotzdem eine Verzögerung bis zum ersten Bild bleibt — und wenn jemand da ist, der es nach Änderungen neu erzeugt (LCP).

Reihenfolge und Abhängigkeiten.

Viele Skripte bauen aufeinander auf. Wird die Reihenfolge durcheinandergebracht, bricht etwas — und zwar oft nicht sofort sichtbar, sondern nur in einer bestimmten Funktion.

WordPress verwaltet diese Abhängigkeiten selbst, wenn Plugins sich ordentlich anmelden. Ein Optimierungs-Plugin, das Dateien zusammenfasst und umsortiert, kann das durcheinanderbringen. Deshalb nach jeder Änderung die Konsole im Browser prüfen: Fehlermeldungen dort sind der schnellste Hinweis (Skriptfehler).

Plugins als Quelle.

Bei WordPress ist die ehrlichste Antwort oft nicht „besser laden“, sondern „weniger laden“. Jedes Plugin bringt eigene Dateien mit, und viele laden sie überall.

1. Zählen, wie viele CSS- und JS-Dateien eine typische Seite lädt.
2. Zuordnen, welches Plugin welche Datei beisteuert.
3. Prüfen, ob das Plugin auf dieser Seite überhaupt etwas tut.
4. Gezielt ausschließen, wo es nichts tut.
5. Ersetzen oder entfernen, was viel kostet und wenig bringt.

Ein typisches Ergebnis: Von vierzig Dateien werden auf der Startseite fünfzehn gebraucht. Das allein halbiert oft die Zahl der blockierenden Anfragen (WordPress langsam).

Fremde Dateien.

Dateien von anderen Servern kosten zusätzlich Zeit für Namensauflösung und Verbindungsaufbau. Bei Schriften von einer fremden Quelle ist das besonders ärgerlich, weil sie früh gebraucht werden.

Zwei Gegenmittel: lokal ausliefern, wo es geht — das ist bei Schriften ohnehin die datenschutzfreundliche Variante — oder zumindest die Verbindung früh ankündigen, damit sie parallel aufgebaut wird (Schriften, Schriften lokal einbinden).

Zusammenfassen — ja oder nein?

Früher war es sinnvoll, alle Dateien in eine zu packen, weil jede Verbindung teuer war. Mit modernen Verbindungen gilt das nur noch eingeschränkt: Viele parallele Anfragen sind kein großes Problem mehr, und eine riesige Sammeldatei hat Nachteile — sie muss komplett neu geladen werden, wenn sich ein Teil ändert.

Praktisch: Bei sehr vielen kleinen Dateien hilft Zusammenfassen weiterhin. Bei einer Handvoll größerer eher nicht. Und es ist die Maßnahme, die am häufigsten etwas kaputt macht, weil die Reihenfolge leidet. Ich setze sie deshalb erst ein, wenn die anderen Schritte ausgeschöpft sind.

Sicher vorgehen.

1. In einer Testumgebung arbeiten, nicht live (Staging).
2. Eine Maßnahme nach der anderen, dazwischen prüfen.
3. Durchklicken: Menü, Formulare, Kasse, Konto, Suche.
4. Browserkonsole ansehen auf Fehlermeldungen.
5. Mobil gegenprüfen.
6. Erst dann live übernehmen.

Punkt zwei ist entscheidend. Wer in einem Optimierungs-Plugin zehn Schalter auf einmal umlegt und die Seite dann kaputt ist, weiß nicht, welcher es war — und schaltet entnervt alles wieder ab.

Was schiefgehen kann.

• Menü klappt nicht mehr auf — Skript zu spät oder Reihenfolge vertauscht.
• Slider zeigt alle Bilder untereinander — CSS fehlt oder kommt zu spät.
• Formular sendet nicht — Skript ausgeschlossen, das gebraucht wird.
• Kurzes unformatiertes Aufblitzen — kritisches CSS unvollständig.
• Kasse bricht ab — Shop-Skripte vertragen Zusammenfassen oft nicht (Kasse).
• Nur auf manchen Seiten kaputt — seitenweise Ausschlüsse zu grob gesetzt.

Shop-Seiten sind generell der empfindlichste Teil. Ich nehme Warenkorb, Kasse und Konto bei Optimierungsmaßnahmen grundsätzlich aus und prüfe sie danach einzeln.

Wenn du nicht weiterkommst.

Wenn das Testwerkzeug blockierende Dateien meldet und du nicht riskieren willst, dabei die Kasse zu zerschießen. Ich messe deine Seite mit echten Nutzerdaten statt mit einem einzelnen Test, sortiere die Befunde nach Wirkung und behebe die, die zählen: Ladezeit optimieren. Dauerhaft begleitet die WordPress-Wartung — damit neue Inhalte die Werte nicht wieder kaputt machen.

Orientierungswerte, keine Fixpreise — nach einem kurzen Gespräch bekommst du ein Festpreisangebot.

Wer hilft.

Ich bin Manuel Killert, Webentwickler aus Quakenbrück. Ich mache Websites schneller — und zwar messbar, nicht gefühlt. Das heißt: erst messen, dann die zwei oder drei Stellen beheben, die tatsächlich den Unterschied machen, dann noch einmal messen.

Was ich nicht mache: eine Punktzahl schönrechnen. Es gibt Tricks, mit denen ein Testwerkzeug hundert Punkte zeigt, während die Seite für echte Besucher gleich langsam bleibt. Das ist Selbstbetrug, und ich sage dir, wenn jemand dir so etwas verkauft hat.

Ich arbeite mit dem, was du hast — Theme, Plugins, Hoster. Ein Neubau ist manchmal die ehrlichere Antwort, und dann sage ich das auch, statt monatelang an einer Seite zu optimieren, die grundsätzlich falsch gebaut ist.