Der Ladezeittest zeigt Grün, die Seite ist in unter einer Sekunde da, und beim Scrollen hakt es trotzdem. Das Bild bleibt kurz stehen und springt dann nach. Der erste Reflex ist ein Cache-Plugin. Der greift in diesem Fall ins Leere.
Wenn eine Website beim Scrollen ruckelt, obwohl sie schnell lädt, liegt das fast nie am Laden. Ladezeit misst, wie lange der Aufbau dauert, einmal. Laufzeit misst, was der Browser danach pro Bild rechnet, etwa sechzig Mal in der Sekunde. Ruckeln entsteht in der zweiten Größe, und die verbessert kein Cache.
Warum sagt die Ladezeit nichts über das Scrollgefühl?
Der Browser hat für jedes Bild rund 16 Millisekunden Zeit. In dieses Fenster muss alles passen: Stilberechnung, Layout, Zeichnen, Zusammensetzen. Wer darüber liegt, verliert ein Bild, und das nimmt das Auge sofort als Hängen wahr. Ob die Seite vorher in 700 Millisekunden oder in drei Sekunden geladen hat, spielt dafür keine Rolle.
Deshalb sind die beiden Fälle auch unterschiedlich zu behandeln. Eine langsam ladende Seite gewinnt durch Caching, kleinere Bilder und weniger Dateien. Eine ruckelnde Seite gewinnt dadurch nichts, weil ihr Engpass erst nach dem Laden entsteht.
Wie sehen die Messwerte in so einem Fall aus?
Wir messen das regelmäßig an WordPress-Installationen mit gekauftem Theme. Ein typischer Befund einer Seite, über die sich Besucher beschweren, obwohl der Test gut aussieht:
| Messwert | Ergebnis | Einordnung |
|---|---|---|
| Seite vollständig geladen | 745 ms | gut |
| DOM aufgebaut | 699 ms | gut |
| JavaScript | 35 Dateien, 395 kB | unauffällig |
| CSS | 26 Dateien, 152 kB | unauffällig |
| Elemente im Dokument | 1050 | niedrig |
Nach diesen Zahlen gibt es kein Problem. Genau das ist der Grund, warum an dieser Stelle so viele Optimierungsversuche verpuffen: sie verbessern eine Kennzahl, die schon in Ordnung war.
Ursache eins: Smooth Scrolling in JavaScript
Viele Themes bringen eine Bibliothek für weiches Scrollen mit, häufig Lenis oder Locomotive Scroll. Diese Bibliotheken schalten das native Scrollen des Browsers ab und berechnen die Position selbst, Bild für Bild, in JavaScript.
Auf einer leeren Demoseite sieht das geschmeidig aus. Auf einer echten Seite mit Inhalt kommt die Rechnung zu allem hinzu, was ohnehin pro Bild passiert. Der Browser kann natives Scrollen auf einem eigenen Thread verarbeiten, die nachgebaute Variante nicht. Sie konkurriert mit jeder anderen Berechnung um dieselben 16 Millisekunden.
Ein praktischer Hinweis zum Abschalten: die Instanz ist oft nicht über window erreichbar, weil sie im Theme-Skript als lokale Konstante angelegt wird. Man kommt also nicht an das laufende Objekt heran, um es zu stoppen. Der Weg ohne Eingriff ins gekaufte Theme führt über den Konstruktor: eine Attrappe, die dieselben Methoden anbietet und nichts tut, und deren scrollTo auf das native scrollIntoView zeigt.
Ursache zwei: zu viele gleichzeitige Animationen
Die zweite große Quelle sind Scroll-Animationen. Themes dieser Preisklasse arbeiten fast durchgehend mit GSAP und ScrollTrigger. Auf einer gut gefüllten Startseite kommen dabei schnell über hundert gleichzeitig laufende Einzelanimationen zusammen.
Ein Teil davon ist Absicht. Ein Teil ist Ballast, und zwar aus einem Grund, den man kennen muss: Wird das Theme-Skript zweimal gestartet, was bei Elementor regelmäßig passiert, animiert die Bibliothek anschließend auch Elemente weiter, die längst nicht mehr im Dokument stehen. Sie rechnet, sie schreibt Werte, und sichtbar ist davon nichts. Diese verwaisten Animationen lassen sich gezielt finden und beenden, indem man prüft, ob ihr Ziel überhaupt noch über document.contains() auffindbar ist.
Woran erkenne ich, welcher der beiden Fälle vorliegt?
Öffne deine Seite, drücke F12, geh in die Konsole und füge das hier ein:
const n = performance.getEntriesByType('navigation')[0];
console.log('Serverantwort ', Math.round(n.responseStart), 'ms');
console.log('DOM fertig ', Math.round(n.domContentLoadedEventEnd), 'ms');
console.log('Seite geladen ', Math.round(n.loadEventEnd), 'ms');
console.log('Dateien ', performance.getEntriesByType('resource').length);
console.log('DOM-Elemente ', document.querySelectorAll('*').length);Die Auswertung ist kurz:
- Serverantwort über 600 ms: Serverseite. Caching und ein besseres Hosting wirken sofort.
- Seite geladen über 2500 ms: Ladeproblem. Bilder, Dateianzahl und Caching angehen.
- Alles unauffällig und es ruckelt trotzdem: Laufzeit. Dann geht es um Animationen und Scroll-Skripte, nicht um Dateigrößen.
Eine Warnung zur Messung der Bildrate
Der naheliegende nächste Schritt wäre, die Bildrate vorher und nachher zu messen. Das führt in die Irre. Wer die Bildrate über requestAnimationFrame in einem Hintergrundtab misst, misst gar nichts: der Browser drosselt die Funktion dort bis auf null Aufrufe. Auch Werkzeuge, die im Hintergrund laufen, liefern deshalb unbrauchbare Zahlen.
Belastbar sind die Ladewerte und die Anzahl laufender Animationen. Ob sich Scrollen gut anfühlt, entscheidet ein Mensch an einem echten Gerät. Wer eine Bildratenzahl in ein Angebot schreibt, hat sie in aller Regel nicht sauber gemessen.
Wann ein Cache-Plugin trotzdem das Richtige ist
Damit kein falscher Eindruck entsteht: Caching ist nicht überflüssig, es ist nur die Antwort auf eine andere Frage. Liegt die Serverantwort über einer halben Sekunde, ist ein Cache das wirksamste Einzelmittel überhaupt, und zwar deutlich vor jeder Bildoptimierung. Nur eben nicht gegen Ruckeln.
Genauso ehrlich: Wenn deine Seite gut lädt, flüssig scrollt und nur im Test nicht die volle Punktzahl erreicht, dann lass sie in Ruhe. Die letzten Punkte in einem Laborwert kosten mehr, als sie an Besuchern zurückbringen.
Wie wir das angehen
Wir messen vor jedem Eingriff und danach erneut, weil sonst die Gefahr groß ist, die falsche Hälfte zu reparieren. Der erste Schritt ist immer eine Bestandsaufnahme im Browser, nicht der Einbau eines Plugins. Wie wir dabei vorgehen und was wir sonst an Websites machen, steht auf der Seite zur Webentwicklung und technischen Überarbeitung von Websites.
Hilft ein Cache-Plugin gegen Ruckeln beim Scrollen?
In der Regel nicht. Ein Cache verkürzt die Zeit bis zum fertigen Seitenaufbau. Ruckeln entsteht danach, durch Berechnungen pro Bild. Nur wenn gleichzeitig die Serverantwort über 600 Millisekunden liegt, bringt ein Cache spürbar etwas.
Was ist der Unterschied zwischen Ladezeit und Laufzeit?
Ladezeit ist die Dauer bis zur fertig aufgebauten Seite, gemessen einmal pro Aufruf. Laufzeit ist die Rechenlast pro Einzelbild danach, etwa sechzig Mal pro Sekunde. Beide Größen haben verschiedene Ursachen und verschiedene Gegenmittel.
Muss ich Smooth Scrolling komplett abschalten?
Nicht zwingend. Auf kurzen Seiten mit wenig Bewegung fällt es kaum auf. Auf langen Seiten mit vielen Scroll-Animationen summiert sich die Rechenlast, und dort ist natives Scrollen fast immer die bessere Wahl.
Wie viele Animationen sind zu viele?
Eine feste Grenze gibt es nicht, weil die Kosten je Animation stark schwanken. Auffällig wird es meist jenseits von hundert gleichzeitig laufenden Einzelanimationen, besonders wenn Elemente animiert werden, die gar nicht mehr sichtbar sind.
