„Der Shop ist langsam." Darauf folgt fast immer dieselbe Reihenfolge: ein größerer Server, ein Caching-Plugin, ein Bildoptimierer. Manchmal hilft es. Oft nicht – weil niemand vorher gemessen hat, wo die Zeit eigentlich verloren geht. Dieser Beitrag zeigt, wie man das in fünf Minuten herausfindet, und beschreibt vier Ursachen, die uns in der Praxis am häufigsten begegnen.
Zuerst messen: Server oder Seite?
Die wichtigste Unterscheidung ist einfach. Entweder braucht der Server lange, bis er anfängt zu antworten – dann liegt es an PHP, der Datenbank oder einem Plugin. Oder er antwortet sofort, und die Seite lädt trotzdem ewig – dann liegt es an dem, was sie nachlädt: Bilder, Schriften, Skripte, Videos.
Beides trennt ein einziger Befehl auf der Kommandozeile:
curl -s -o /dev/null -w "Antwort: %{time_starttransfer}s | gesamt: %{time_total}s\n" https://ihr-shop.de/
Der erste Wert ist die Zeit bis zum ersten Byte. Liegt er unter 0,5 Sekunden, ist der Server in Ordnung – dann sparen Sie sich das Server-Upgrade und sehen sich die Seite an. Liegt er über zwei Sekunden, brauchen Sie an den Bildern gar nicht erst zu schrauben.

1. Die Startseite wiegt zu viel
Der häufigste Fall. Eine Startseite mit Hero-Video, Slider und großen Produktbildern kommt schnell auf zweistellige Megabyte – ein einzelnes unkomprimiertes Video macht leicht 13 MB aus. Der Server antwortet dabei in Millisekunden; der Besucher wartet trotzdem.
Eine Falle dabei: preload="metadata" am Video nützt nichts, wenn gleichzeitig autoplay gesetzt ist – ein automatisch startendes Video lädt der Browser sofort vollständig. Entweder das Video deutlich kleiner rechnen (3 bis 5 MB reichen für eine Kopfzeile), oder es erst auf Klick starten und bis dahin ein Standbild zeigen. Fehlt dieses Standbild, sieht der Besucher übrigens gar nichts, bis die ersten Videodaten da sind.
Produktbilder im Format PNG sind der zweite Posten: Vier Bilder zu je 300 KB sind zusammen mehr als eine ganze Textseite. Als WebP in der tatsächlich angezeigten Größe bleibt oft ein Zehntel übrig.
2. Der Großteil Ihrer Besucher ist gar keiner
In der Besucherstatistik eines von uns betreuten Shops standen an einem Tag 1.174 Seitenaufrufe. Davon entfielen 963 auf Bots – über 80 Prozent. An anderen Tagen waren es 84 Prozent. Echte Besucher: rund 85 am Tag.
Das hat zwei Folgen. Erstens rechnet man mit falschen Zahlen: Wer seine Kaufquote gegen die Gesamtzugriffe rechnet, hält seinen Shop für schlechter, als er ist. Zweitens kosten Bots echte Rechenzeit – jeder Aufruf erzeugt PHP-Last, Datenbankabfragen und belegt einen Arbeitsprozess, der dann für einen Kunden fehlt.
Prüfen Sie, ob Ihre Statistik Bots ausweist. Tut sie es nicht, sind alle Ihre Besucherzahlen zu hoch. Auffällige Sammler erkennt man an einem Muster: zwölf, dreizehn Seiten in wenigen Sekunden, immer zur selben Minute, keine Bilder nachgeladen.
3. Gelöschte Weiterleitungen machen den Shop langsamer, nicht schneller
Ein Fall aus dem September, der uns selbst überrascht hat. Ein Shop hatte über 23.000 Einträge unter „Weiterleitungen" in der Suchmaschinenoptimierung. Der Betreiber hat sie in bester Absicht gelöscht – aufräumen schadet ja nie. Danach lief der Shop in den Timeout.
Der Grund: Eine Weiterleitung ist billig. Der Shop antwortet mit einem 301 und ist fertig. Ohne sie liefert dieselbe Adresse eine 404-Seite – und die ist im JTL-Shop eine vollständig gerenderte Seite mit Template, Datenbankabfragen und allen Plugins. Die Bots, die diese 23.000 Adressen bis dahin abgeklappert hatten, taten das weiter. Nur kostete jeder Aufruf jetzt ein Vielfaches.
Wer Weiterleitungen aufräumt, sollte deshalb zuerst das automatische Anlegen für nicht gefundene Seiten abschalten und die auffälligen Bots aussperren – sonst ist der Zustand in zwei Wochen zurück, nur schlimmer.
4. Wenn gar nichts mehr antwortet: ein Test, der alles verrät
Steht der Shop komplett, hilft ein einziger Aufruf beim Eingrenzen – und zwar auf eine Datei, die weder PHP noch Datenbank braucht:
curl -s -o /dev/null -w "%{http_code} in %{time_total}s\n" https://ihr-shop.de/robots.txt
Antwortet die Datei sofort, läuft der Webserver und das Problem liegt in PHP, in der Datenbank oder in einem Plugin. Antwortet sie nicht, hängt die Schicht darunter: Dann sind alle Arbeitsprozesse belegt, und auch eine einfache Textdatei kommt nicht mehr durch. In dem oben beschriebenen Fall war genau das so – die Datenbank hatte dabei nicht eine einzige laufende Abfrage.
Nützlich ist außerdem ein Blick auf die Prozessliste der Datenbank (SHOW FULL PROCESSLIST) und auf den freien Platz – volle Inodes (df -i) sehen exakt aus wie ein überlasteter Server, sind aber in einer Minute behoben.
Die Reihenfolge, die sich bewährt hat
- Zeit bis zum ersten Byte messen – Server oder Seite?
- Gewicht der Startseite prüfen, Video und Bilder zuerst
- Bot-Anteil in der Statistik ansehen, bevor man Kennzahlen bewertet
- 404-Seiten und Weiterleitungen prüfen, besonders nach einem Relaunch
- Erst dann über einen größeren Server nachdenken
In den meisten Fällen ist der Server nicht das Problem. Das ist die gute Nachricht: Die vier Punkte oben kosten nichts außer einer Stunde Zeit.
Lieber messen lassen?
Wir betreuen JTL-Shops seit Jahren und sehen diese Muster täglich. Wenn Sie den Verdacht haben, dass bei Ihnen etwas im Argen liegt, schreiben Sie uns über das Support-Formular – wir sehen uns die Zahlen an und sagen Ihnen, woran es liegt. Auch dann, wenn die Antwort lautet: Ihr Shop ist in Ordnung.