In unserem Newsletter von letzter Woche habe ich schon angefangen, über Martins Vortrag auf dem Tech SEO Summit 2025 zu erzählen. Was bei async und defer, Minify und Komprimieren zu beachten ist und was zur Hölle Layout Thrashing ist, hatte ich Dir schon zusammengefasst.
Jetzt geht es weiter mit dem JavaScript Deep Dive:
Code Splitting & Loadable Components
Es macht Sinn, den Code sinnvoll aufzuteilen. Seit HTTP/2 müssen wir nicht mehr die Zahl der Requests klein halten. Ein großes Code-Bundle ist nicht mehr sinnvoll.
Das JavaScript für die Animation im Footer muss nicht zusammen mit allem anderen übertragen werden. Und irgendein Skript-Schnipsel, das nur für das Tabellenelement auf der Dankeseite der Newsletteranmeldung gebraucht wird, schon gar nicht.
Schneide lieber den Code in funktionelle Bestandteile und lade das, was gebraucht wird, dort, wo es gebraucht wird.
Moderne Frameworks bieten dafür auch sinnvolle Lösungen. Für React gibt es beispielsweise Loadable Components.
Wenn ein Relaunch ansteht, sollte das von Grund auf mitgedacht werden.
Denn: Wenn das nicht von Anfang an mitgedacht wurde, ist das ein ganz schönes Brett, das nachzuziehen. Vielleicht reicht schon das gezielte Auslagern bestimmter Komponenten für eine 80/20-Lösung.
Animations
Das ist jetzt genau genommen kein reines JavaScript-Thema, sondern gilt auch für CSS-Animationen.
Die Kurzfassung ist: Wenn man Elemente verschiebt und jedes Frame einen Paint auslöst, ist das unpraktisch. Es gibt Varianten, Animationen zu bauen, die das nicht tun – die wesentlich performanter sind.
Für die längere Fassung verweise ich Dich wieder auf Dokumentationen. Beispielsweise den Animations Guide von web.dev oder diesen Guide zu CSS- und JS-Animations und Performance in den MDN Web Docs.
Debouncing, Long Tasks, Web Workers und Co.
Ein großes Performance-Problem ist der Main Thread. Standardmäßig arbeiten Browser nur in einem Thread mit der CPU. Und solange der Main Thread voll ist, kann der Browser auf nichts anderes reagieren. Das kann beim Rendern dazu führen, dass Frames droppen. Dann sieht die Seite ruckelig aus. Noch schlimmer: Währenddessen kann der Browser nicht auf Nutzerinteraktionen reagieren.
Damit das nicht passiert, sollte man lange, teure Operationen vermeiden.
Nicht alle Reaktionen auf Nutzerinteraktionen sollten immer ausgeführt werden. Wenn viele Nutzerinteraktionen hintereinander kommen und aufwändig zu verarbeiten sind, sollte vielleicht nicht jedes Mal das ganze Feuerwerk losgehen.
Als Beispiel wählte Martin Suggests bei Suchen. Nicht bei jedem getippten Buchstaben sollte Deine Suche neue Suggests abholen. Suggests sind ein relativ teurer Prozess, und es reicht vermutlich – oder ist besser –, ein paar Millisekunden zu warten, bis ein Nutzer das erste Wort fertig getippt hat. Die Zauberworte hierbei heißen Debouncing und Throttling. FreeCodeCamp hat, finde ich, die Idee von Debouncing gut dargestellt.
Außerdem gibt es noch die Möglichkeit, Prozesse, die nicht synchron stattfinden müssen, auszulagern. Web Worker ist hier das Zauberwort.
Martin hat dabei noch auf die WebGL-API hingewiesen, mit der sogar die GPU mit einbezogen werden kann.
Dann hat Martin noch das Fass mit scheduler: yield() aufgemacht. Das wirkte für mich eher nach schwarzer Magie als nach JavaScript – aber es gibt bestimmt die ein oder andere Stelle, wo das sinnvoll eingesetzt werden kann.
Im Nebensatz zu den Web Workern gab es dann aber noch ein kleines SEO-Nugget. Sinngemäß war die Aussage zu Web Workern:
Do not use [Web Worker] to fetch content without user interaction; the rendering service does funny things.
Das hat mich aufhorchen lassen.
Klar. Googlebot führt keine Nutzerinteraktionen aus, insofern ist Inhalt, der erst auf Nutzerinteraktion in den DOM-Tree kommt, für Google unsichtbar.
Solange der Inhalt ohne Nutzerinteraktion nachgeladen wird, kann Google das normalerweise rendern. Und auch mit Lazy Loading kommt Google klar. John Mu hat klargestellt, dass Google dafür schlicht einen seeehr langen Viewport verwendet.
Wenn Google die Inhalte trotzdem nicht sieht, ist häufig das entsprechende Third-Party-Skript für Googlebot via robots.txt gesperrt (bei Taboola, Outbrain und Co. zum Beispiel geschieht das sehr bewusst).
Aber wenn Deine Inhalte nicht sauber gerendert werden und Du beim Debugging alles Offensichtliche abgeklopft hast, dann guck doch mal, ob das Lazy Loading vielleicht in einen Web Worker ausgelagert wurde.
Fazit:
Das war ein schöner Vortrag mit Live Coding, bei dem nicht nur SEOs, sondern auch Frontend-Entwickler eine ganze Menge lernen konnten.
Die kurze Zusammenfassung ist:
Nutze JavaScript nur dann, wenn Du es auch wirklich brauchst – und dann nutze es weise.
Und sonst:
Don’t use JavaScript.