JTL-Shop 5 Performance: Ladezeit optimieren für KMU

Zur Einordnung: Ich bin Stanislav Tonkich, Webentwickler aus Pocking bei Passau, und arbeite als Einzelperson, nicht als Agentur. Dieses Blog gehört zu meinem persönlichen Portfolio. Daneben bin ich Gründer und Geschäftsführer der DigMa Systems UG (digma-systems.de).

Warum Ladezeit im JTL-Shop zählt

Google bewertet die Nutzererfahrung einer Seite unter anderem mit den Core Web Vitals. Laut web.dev gelten diese Werte als „gut“:

Google empfiehlt, das 75. Perzentil der Seitenaufrufe zu betrachten, getrennt nach Mobilgerät und Desktop. Für einen Shop heißt das: Nicht der schnellste Aufruf im Büro-WLAN zählt, sondern die Erfahrung der Mehrheit Ihrer echten Besucher, oft auf dem Smartphone.

Für Shops ist das besonders relevant, weil Kategorieseiten, Artikeldetailseiten und der Warenkorb sehr unterschiedlich aufgebaut sind. Eine schnelle Startseite sagt wenig über eine Kategorie mit vielen Artikelbildern und Filtern aus.

Ausgangslage messen

Bevor Sie etwas ändern, halten Sie den Ist-Zustand fest. Drei Werkzeuge reichen für den Anfang:

• PageSpeed Insights zeigt zwei Arten von Daten. Die Labordaten aus Lighthouse entstehen in einer kontrollierten Umgebung und eignen sich zur Fehlersuche. Die Felddaten stammen aus dem Chrome User Experience Report (CrUX) und bilden echte Besuche der vorangegangenen 28 Tage ab.
• Der Core Web Vitals-Bericht in der Google Search Console nutzt ebenfalls CrUX-Daten. Er fasst URLs mit ähnlicher Nutzererfahrung zu Gruppen zusammen und trennt Mobilgerät und Desktop. So sehen Sie, ob etwa alle Artikelseiten betroffen sind oder nur einzelne.
• Lighthouse in den Chrome-Entwicklertools hilft, einzelne Ursachen nachzuvollziehen, zum Beispiel welches Element das LCP-Element ist oder welche Skripte die Seite blockieren.

Wichtig ist die Unterscheidung: Labordaten ändern sich sofort nach einer Anpassung, Felddaten erst, wenn genügend neue Besuche erfasst sind. Wählen Sie für die Messung je eine typische Startseite, Kategorieseite und Artikelseite und dokumentieren Sie die Werte. Bei Shops mit wenig Verkehr liegen unter Umständen keine Felddaten vor. Dann bleiben die Labordaten Ihre Orientierung.

Hosting und PHP-Version

Laut JTL-Guide setzt JTL-Shop 5 ab Version 5.2 mindestens PHP 8.1 voraus, ab Version 5.2.3 empfiehlt JTL PHP 8.2. Prüfen Sie für Ihre installierte Shop-Version die Systemvoraussetzungen und Versionshinweise im JTL-Guide, denn die Freigaben ändern sich mit neuen Releases.

Achten Sie zusätzlich auf den Support-Status der PHP-Version selbst. Laut PHP.net endet der Sicherheitssupport für PHP 8.2 am 31. Dezember 2026. Vor einem Wechsel der PHP-Version sollten Sie klären, ob alle eingesetzten Plugins und das Template damit kompatibel sind. Der JTL-Guide weist ausdrücklich darauf hin, dass die gewählte Version zu Shop und Plugins passen muss. Testen Sie den Wechsel daher zuerst in einer Kopie des Shops.

Beim Hosting selbst zählt vor allem die Serverantwortzeit (Time to First Byte, TTFB). web.dev beschreibt, dass eine hohe TTFB es schwer oder unmöglich machen kann, einen LCP von 2,5 Sekunden zu erreichen. Ein Shop auf einem stark ausgelasteten Shared-Hosting-Tarif stößt hier schneller an Grenzen als auf einem Server mit zugesicherten Ressourcen. Fragen Sie Ihren Hoster, welche PHP-Erweiterungen verfügbar sind und ob Redis oder Memcached angeboten wird.

Caching: Objektcache und OPcache

JTL-Shop 5 bringt einen eigenen Objektcache mit. Laut JTL-Guide ist er standardmäßig deaktiviert. Sie finden ihn im Backend unter System > Cache. Im Reiter „Einstellungen“ aktivieren Sie den Objektcache und wählen die Methode, im Reiter „Verwaltung“ können Sie das Caching für einzelne Objekttypen abschalten.

Einige Hinweise aus der Dokumentation:

• Die meisten Methoden setzen eine passende PHP-Erweiterung auf dem Server voraus. Methoden wie Redis oder Memcached benötigen zusätzlich Host und Port, die Sie unter „Erweiterte Einstellungen anzeigen“ eintragen.
• Den Wechsel der Methode sollten Sie mit Ihrem Serveradministrator abstimmen.
• Der Reiter „Benchmark“ vergleicht Methoden. JTL weist darauf hin, dass dies nur grobe Werte sind und eine Methode mit schlechterem Benchmark in der Praxis trotzdem besser laufen kann.

Auf Serverebene sollte OPcache aktiv sein. Laut PHP-Handbuch speichert OPcache den vorkompilierten Bytecode im Arbeitsspeicher, sodass Skripte nicht bei jedem Aufruf neu geladen und geparst werden müssen. Bei vielen Hostern ist OPcache bereits eingeschaltet. Ein kurzer Blick in die PHP-Konfiguration oder eine Rückfrage beim Hoster klärt das.

Template und Smarty

JTL empfiehlt, ein eigenes Design als Child-Template anzulegen und dabei vom Standard-Template NOVA abzuleiten. Das mitgelieferte Template bleibt dabei unverändert und damit updatefähig. Im Child-Template liegen nur die Dateien, die Sie tatsächlich anpassen.

Für die Performance hat das zwei Vorteile. Erstens profitieren Sie von Verbesserungen, die mit NOVA-Updates kommen. Zweitens bleibt der Umfang Ihrer Anpassungen überschaubar. Wer ganze Template-Dateien ersetzt, verliert laut Entwicklerdokumentation diesen Vorteil und muss Änderungen aus Updates von Hand übernehmen.

Prüfen Sie außerdem:

• Zusätzliche Skripte im Template: Die Entwicklerdokumentation empfiehlt, eigene Skripte bei NOVA über den Block layout-footer-js in der footer.tpl und asynchron zu laden, damit sie den Seitenaufbau nicht bremsen.
• Boxen und Widgets: Jede eingeblendete Box (zum Beispiel Bestseller, zuletzt angesehen, Hersteller) erzeugt Abfragen und Markup. Was niemand nutzt, sollten Sie deaktivieren.
• Alte Templates: Ein Shop, der noch auf einem stark angepassten älteren Template läuft, ist oft der aufwendigste Teil der Optimierung. Hier lohnt die Frage, ob eine saubere Ableitung von NOVA langfristig einfacher ist.

Bilder

Bei Shops ist das LCP-Element häufig ein Bild: das Bannerbild auf der Startseite oder das Hauptbild auf der Artikelseite. web.dev nennt dazu klare Regeln:

• Moderne Formate: Komprimieren Sie Bilder und nutzen Sie, wo möglich, effizientere Formate wie AVIF oder WebP.
• Passende Größen: Liefern Sie Bilder nicht größer aus, als sie dargestellt werden. Ein Produktfoto in Druckauflösung als Vorschaubild kostet unnötig Ladezeit.
• Lazy Loading nur außerhalb des sichtbaren Bereichs: Bilder unterhalb des ersten Bildschirms können mit loading="lazy" verzögert geladen werden. Das LCP-Bild sollten Sie laut web.dev nie lazy laden, weil das den Ladevorgang immer unnötig verzögert.
• Priorität setzen: Mit fetchpriority="high" am voraussichtlichen LCP-Bild lädt der Browser es früher. web.dev rät, dies nur bei einem oder zwei Bildern zu verwenden, sonst verliert der Hinweis seine Wirkung.
• Im HTML auffindbar: Das LCP-Bild sollte direkt im HTML stehen und nicht erst per CSS oder JavaScript nachgeladen werden. Ist das nicht möglich, hilft ein Preload.
• Breite und Höhe angeben: Setzen Sie width und height an Bildern. Der Browser reserviert dann den Platz vorab, und der Inhalt springt nicht (CLS).

Prüfen Sie bei Bannern und Slidern besonders genau, ob das erste Bild im Template als lazy markiert ist. Das ist ein häufiger und leicht zu behebender Befund.

JavaScript, CSS und Drittanbieter

Tracking, Chat-Widgets, Bewertungssiegel, Karten und Social-Media-Einbindungen laden fremden Code. Jedes dieser Skripte kann Ladezeit und Reaktionsfähigkeit (INP) verschlechtern.

• Bestandsaufnahme: Listen Sie alle externen Dienste auf und fragen Sie bei jedem, ob er noch gebraucht wird.
• Consent-Reihenfolge: Dienste, die eine Einwilligung erfordern, sollten erst nach der Einwilligung geladen werden. Das ist datenschutzrechtlich geboten und entlastet zugleich den ersten Seitenaufbau.
• Cookie-Banner: web.dev empfiehlt, für nachträglich eingeblendete Inhalte wie Banner vorab ausreichend Platz zu reservieren oder sie weiter unten zu platzieren, damit kein Layout-Shift entsteht.
• Schriften lokal hosten: Werden Webfonts von einem externen Anbieter geladen, überträgt der Browser dabei die IP-Adresse des Besuchers an diesen Anbieter. Lokal gehostete Schriften vermeiden diese Übertragung und eine zusätzliche Verbindung. Für die Darstellung empfiehlt web.dev, die Größenunterschiede zwischen Ersatzschrift und Webfont gering zu halten; font-display: optional kann ein erneutes Layout vermeiden.
• Weniger Schriftschnitte: Jeder zusätzliche Schnitt ist eine weitere Datei. Prüfen Sie, welche Schnitte das Design tatsächlich verwendet.

Plugins und Wawi-Abgleich

Plugins erweitern den Shop, bringen aber eigene Abfragen, Skripte und Stylesheets mit. Gehen Sie die Liste im Plugin-Manager durch:

• Deaktivieren und entfernen Sie Plugins, die nicht mehr genutzt werden.
• Prüfen Sie, ob ein Plugin Funktionen doppelt anbietet, die NOVA oder ein anderes Plugin bereits abdeckt.
• Testen Sie bei Verdacht gezielt: Plugin in einer Testkopie deaktivieren, dieselbe Seite erneut messen, Werte vergleichen.

Auch der Abgleich zwischen JTL-Wawi und Shop erzeugt Last auf Datenbank und Webserver. Wenn Sie größere Datenmengen übertragen, etwa nach umfangreichen Artikel- oder Preisänderungen, ist ein Zeitpunkt mit wenig Besucherverkehr sinnvoll. Beobachten Sie, ob Ladezeiten gerade während des Abgleichs auffällig steigen. Das ist ein Hinweis darauf, dass die Serverressourcen knapp bemessen sind.

Datenbank

Mit wachsendem Sortiment werden Datenbankabfragen zum Faktor, besonders bei Kategorien mit vielen Artikeln, Filtern und der Shopsuche.

• Langsame Abfragen finden: MySQL und MariaDB können langsame Abfragen protokollieren (Slow Query Log). Das zeigt, welche Abfragen tatsächlich Zeit kosten.
• Indexe prüfen: Häufig betroffen sind zusätzliche Tabellen von Plugins, denen ein passender Index fehlt. Änderungen an Indexen sollten nur mit Backup und in Abstimmung mit dem Plugin-Anbieter erfolgen.
• Suchlast im Blick behalten: Die Shopsuche und Filter erzeugen bei vielen Artikeln aufwendige Abfragen. Wenn die Suchseite deutlich langsamer ist als der Rest, lohnt hier ein genauerer Blick.
• Datenbankversion: Prüfen Sie, ob die eingesetzte MySQL- oder MariaDB-Version laut JTL-Guide für Ihre Shop-Version freigegeben ist.

Checkliste: Reihenfolge und Aufwand

Ändern Sie möglichst einen Bereich nach dem anderen und messen Sie dazwischen. Nur so lässt sich sagen, welche Maßnahme welchen Effekt hatte.

Wann Hilfe sinnvoll ist

Viele Schritte, etwa das Aktivieren des Objektcaches oder das Korrigieren des LCP-Bildes, lassen sich mit etwas Sorgfalt selbst erledigen. Externe Unterstützung ist eher dann sinnvoll, wenn ein PHP-Wechsel an inkompatiblen Plugins scheitert, ein stark angepasstes Template auf NOVA umgestellt werden soll oder die Ursache in langsamen Datenbankabfragen liegt. In diesen Fällen hilft eine Testumgebung, in der Änderungen ohne Risiko für den laufenden Verkauf geprüft werden.

Quellen

1. web.dev: Web Vitals
2. web.dev: Largest Contentful Paint optimieren
3. web.dev: Browser-level image lazy loading
4. web.dev: Fetch Priority API
5. web.dev: Cumulative Layout Shift optimieren
6. Google for Developers: Über PageSpeed Insights
7. Google Search Console-Hilfe: Bericht zu Core Web Vitals
8. JTL-Guide: Neuinstallation von JTL-Shop auf eigenem Webserver (Systemvoraussetzungen) (englisch)
9. JTL-Guide: Cache einstellen (englisch)
10. JTL-Guide: Shop-Update FAQ Hosting (englisch)
11. JTL-Entwicklerdokumentation: Eigenes Template (englisch)
12. PHP.net: Unterstützte Versionen
13. PHP-Handbuch: OPcache

Stanislav Tonkich

Webentwickler, SEO und KI-Automation

Seit 1995 in der IT, seit 2018 Webentwickler, seit 2023 im eCommerce. Ich baue Individuallösungen, automatisiere Abläufe mit KI und arbeite an der Sichtbarkeit in Google und in KI-Suchen.

Mehr über Stanislav Tonkich →