I'm pretty Splitt in that
Martin Splitt – SEO Summit 2025
Martin hat gebeten, seine Aussage zum Thema JavaScript nicht einfach so aus dem Zusammenhang zu reißen, daher reiße ich dieses Zitat aus dem Zusammenhang (außerdem habe ich mir zwar aufgeschrieben, dass er es gesagt hat, aber vergessen zu notieren, in welchem Kontext der Satz genau gefallen war ¯\_(ツ)_/¯ ).
Abgesehen davon hat Martin Splitt von Google auf dem Tech SEO-Summit viele schlaue Dinge über JavaScript-Performance-Optimierung gesagt.
Merkwürdigerweise hat er dabei nicht die krassen JavaScript-SEO-Hacks vorgestellt, sondern wirklich über Performance-Optimierung geredet.
Fast so, als würde Google wollen, dass wir einfach performante Webseiten mit guter UX bauen und darauf dann guten Content darstellen, der die Fragen der Nutzer beantwortet.
Zu Anfang gab es einen kurzen Rant darüber, dass HTML und CSS inzwischen viel mehr können und man nicht mehr für alles JavaScript braucht – und man jQuery, React und Co. nicht einfach nur einbauen soll, weil es gerade alle coolen Kids tun, sondern nur, wenn man JavaScript für die Funktionalität braucht. Dann folgte schicker Deep Dive in ein paar JavaScript-Performance-Untiefen (the_Splitti kennt sich mit dem Tauchen ja auch gut aus).
Neben der einleitenden Tautologie habe ich noch ein paar Punkte notiert, die Dir vielleicht helfen, wenn Du das nächste Mal versuchst, herauszufinden, warum Deine Seite so langsam geworden ist.
Not All Bytes Are Equal
JavaScript braucht die CPU, um kompiliert und ausgeführt zu werden.
Bilder sind zwar häufig größer als JavaScript, aber belasten den Main Thread des Browsers kaum.
Byte für Byte verglichen, hat daher JavaScript einen wesentlich größeren Einfluss auf Ladezeiten als Bilder.
Das bedeutet nicht, dass Du aufhören kannst, Dir über Bildkompression Gedanken zu machen, sondern dass Du bei JavaScript-Code auf mehr gucken musst als nur die Größe der JS-Dateien.
Insbesondere schlecht geschriebenes JavaScript kann – im Zweifel in wenigen Zeilen Code – Deine Website unheimlich verlangsamen. Martin hat das in einigen Beispielen eindrücklich erörtert.
Wenn Deine Website hauptsächlich Text und Bilder darstellt, sollte ein halbwegs modernes Endgerät mit guter Internetverbindung eigentlich kein Problem beim Rendering haben. Wenn Dein Blog auf einem hochgetunten Gaming-PC mit Glasfaserinternet beim Scrollen ruckelt, dann läuft da etwas falsch.
async und defer
Gut, das ist jetzt keine Weltneuheit, aber es kommt doch immer mal wieder vor, dass JavaScripte unnötig das Rendering blockieren.
Nutze für script-Elemente das async- oder das defer-Attribut, um zu verhindern, dass JavaScript das Rendering unnötig blockiert.
Faustregel: Wenn ein Skript im Rendering wichtig wird, async, damit es asynchron geladen und ausgeführt wird, sobald es verfügbar ist. Alternativ defer, um das Skript erst auszuführen, wenn die Seite fertig geladen und gerendert ist. Letzteres ist in der Regel für Tracking-Skripte und einen großen Teil der Nutzerinteraktionen völlig ausreichend.
Es gibt nur seeeehr wenige Ausnahmen, wo ein Skript ohne async oder defer ausgeführt werden sollte. Und ich vermute, in 99,976 % dieser Fälle sollte so ein Skript serverseitig gerendert werden.
Minify und Komprimieren
Es sollte auch 2025 eigentlich selbstverständlich sein, dass darauf geachtet wird, dass Code komprimiert übertragen wird.
Zum Thema Minify weist Martin darauf hin, dass minified JavaScript nicht nur Bytes spart, sondern in der Regel auch die Ausführung beschleunigt. ABER: nicht immer – es gibt Fälle, in denen das Kompilieren und Ausführen des minifizierten JavaScript langsamer ist. Daher: Benchmark your execution times!
Layout Thrashing
Vereinfacht gesagt: Wenn Du Read- und Write-Operationen mischst und voneinander abhängig machst, dann kann der Browser das Layout nicht im Batch verarbeiten, sondern muss jeden Schritt einzeln rendern (und das ist langsam).
Weniger vereinfacht ist Layout Thrashing auf web.dev beschrieben.
Ich bin ehrlich: Ich hab vorher noch nie davon gehört, aber ich bin kein JavaScript-Entwickler.
Ich kann mir aber gut vorstellen, wie das im Entwicklungsprozess mal bei der QS durch die Lappen geht.
Wenn Deine Seite langsam rendert, obwohl eigentlich alle Ressourcen fluffig geladen werden, liegt hier vielleicht der Hase im Pfeffer.
Nächste Woche geht es weiter
Das war schon eine ganze Menge JavaScript für Deine Newsletter-Aufmerksamkeitsspanne. Aber noch lange nicht alles, was Martin auf dem Tech Summit schlaues gesagt hat. Daher habe ich den Bericht aufgesplittet.
Im zweiten Teil, der nächste Woche erscheint, geht’s weiter mit Martins Deep Dive und ich erzähle Dir von Code Splitting, Loadable Components, Web Workern und ihren SEO-Fallstricken