JTL-Shop langsam: Liegt es am Server, an der Datenbank, am Template oder an Plugins?

Wann ein JTL-Shop tatsächlich zu langsam ist

Das subjektive Gefühl eines langsamen Shops ist ein wichtiges Warnsignal, reicht für die technische Einordnung aber nicht aus.

Performanceprobleme können sich unterschiedlich zeigen:

• Die erste Seite benötigt lange, bevor überhaupt Inhalte erscheinen.
• Nur Kategorien mit vielen Artikeln laden langsam.
• Filter oder Suche reagieren verzögert.
• Produktseiten mit vielen Varianten sind auffällig langsam.
• Warenkorb oder Checkout benötigen mehrere Sekunden.
• Der Shop ist zu bestimmten Tageszeiten langsamer.
• Einzelne Aufrufe liefern Fehler 500 oder 503.
• Das Backend ist langsam, während das Frontend normal reagiert.
• Die mobile Darstellung lädt deutlich langsamer als am Desktop.

Diese Unterschiede sind für die Analyse entscheidend. Eine langsame Serverantwort benötigt andere Maßnahmen als ein schnell ausgeliefertes HTML-Dokument, das anschließend durch Bilder und JavaScript lange blockiert wird.

Die wichtigsten Ebenen der JTL-Shop-Performance

Ein JTL-Shop besteht aus mehreren technischen Schichten. Jede davon kann die Ladezeit beeinflussen.

Zuerst das Problem reproduzierbar machen

Bevor Änderungen vorgenommen werden, muss feststehen, wann und wo der Shop langsam ist.

Hilfreiche Angaben sind:

• betroffene URL
• genauer Zeitpunkt
• verwendetes Gerät und Browser
• angemeldeter oder nicht angemeldeter Benutzer
• betroffene Sprache oder Kundengruppe
• Häufigkeit des Problems
• vorherige Updates oder Änderungen
• gleichzeitig auftretende Fehlermeldungen

Eine Aussage wie „Der Shop ist langsam“ lässt viele Ursachen offen. Die Beschreibung „Kategorieseiten mit aktivierten Filtern benötigen abends regelmäßig acht Sekunden, Produktseiten laden normal“ grenzt das Problem bereits deutlich ein.

Serverantwort und sichtbare Ladezeit unterscheiden

Ein Shop kann serverseitig schnell antworten und trotzdem im Browser langsam wirken.

Vereinfacht lassen sich zwei Bereiche unterscheiden:

• Serverseitige Zeit: PHP, Datenbank, Plugins und Shoplogik erzeugen die Antwort.
• Browserseitige Zeit: Bilder, CSS, JavaScript, Schriftarten und externe Ressourcen werden geladen und dargestellt.

Beginnt die Übertragung erst nach mehreren Sekunden, liegt die Ursache häufig serverseitig. Wird das Dokument schnell geliefert, aber die Seite bleibt lange unvollständig, müssen Frontend, Bilder und externe Ressourcen geprüft werden.

Ursache 1: Zu geringe oder überlastete Serverressourcen

Das Hosting bildet die Grundlage für jede Shopanfrage.

Typische Engpässe sind:

• dauerhaft hohe CPU-Auslastung
• zu wenig Arbeitsspeicher
• langsame Datenträger
• begrenzte PHP-FPM-Prozesse
• zu viele gleichzeitig aktive Anfragen
• zu wenig freier Speicherplatz
• weitere stark ausgelastete Projekte auf demselben Server
• unzureichende Datenbankressourcen

Bei Shared Hosting können verfügbare Ressourcen zusätzlich von anderen Kunden beeinflusst werden. Ein eigener Server löst das Problem jedoch nicht automatisch, wenn PHP, Datenbank und Webserver ungeeignet konfiguriert sind.

Wie sich ein Serverengpass bemerkbar macht

Serverprobleme treten häufig nicht auf jeder Seite und zu jedem Zeitpunkt gleich auf.

Mögliche Hinweise sind:

• Der Shop wird bei mehreren gleichzeitigen Besuchern deutlich langsamer.
• Fehler 503 treten sporadisch auf.
• PHP-Prozesse erreichen regelmäßig ihre Obergrenze.
• Der Shop ist nachts schneller als tagsüber.
• Backups oder Cronjobs verursachen erkennbare Lastspitzen.
• Das Backend und das Frontend sind gleichzeitig betroffen.

In solchen Fällen sollten nicht nur durchschnittliche Werte betrachtet werden. Kurze Lastspitzen können entscheidend sein, obwohl die mittlere Serverauslastung unauffällig erscheint.

PHP-FPM und begrenzte Prozesse

PHP-FPM verarbeitet die dynamischen PHP-Anfragen des Shops. Ist die Zahl verfügbarer Prozesse zu niedrig, müssen weitere Anfragen warten.

Hinweise auf ein zu niedriges Prozesslimit können sein:

• Meldungen über erreichte Prozessgrenzen
• lange Warteschlangen bei mehreren gleichzeitigen Aufrufen
• sporadische 502- oder 503-Fehler
• starke Verzögerungen während Bots oder Crawler viele Seiten aufrufen

Der Wert darf jedoch nicht beliebig erhöht werden. Jeder zusätzliche PHP-Prozess benötigt Arbeitsspeicher. Eine ungeeignete Einstellung kann den Server dadurch vollständig überlasten.

Ursache 2: Langsame oder überlastete Datenbank

Fast jede dynamische Shopseite benötigt Informationen aus der Datenbank.

Performanceprobleme können entstehen durch:

• sehr große Tabellen
• langsame oder häufig wiederholte Abfragen
• unzureichenden Datenbankcache
• gleichzeitige Schreib- und Lesevorgänge
• umfangreiche Besucher- oder Protokolldaten
• Plugins mit ineffizienten Abfragen
• zu wenig Arbeitsspeicher für die Datenbank
• langsamen Datenträger

Besonders Kategorien, Filter, Suche und personalisierte Inhalte können viele Datenbankabfragen auslösen. Der sichtbare Fehler erscheint dann im Frontend, obwohl das eigentliche Problem in der Datenverarbeitung liegt.

Große Tabellen und stetig wachsende Daten

Manche Tabellen wachsen dauerhaft, obwohl ihr Inhalt im Tagesgeschäft kaum sichtbar ist.

Dazu können gehören:

• Besucherarchive
• Suchprotokolle
• Sessions
• Fehlerprotokolle
• Pluginhistorien
• temporäre Daten

Bevor Daten gelöscht oder Tabellen bereinigt werden, muss geklärt werden, welche Funktionen darauf zugreifen und ob eine offizielle Bereinigungsmöglichkeit besteht. Direkte Löschungen ohne Sicherung und Verständnis der Datenstruktur können den Shop beschädigen.

Langsame Datenbankabfragen identifizieren

Wenn nur bestimmte Seiten langsam sind, sollten die dort ausgelösten Abfragen genauer betrachtet werden.

Typische Kandidaten sind:

• Kategorien mit sehr vielen Artikeln
• umfangreiche Filterkombinationen
• interne Suchanfragen
• Cross-Selling-Berechnungen
• kundengruppenspezifische Preise
• Plugins mit dynamischen Auswertungen
• individuelle SQL-Abfragen

Eine professionelle Analyse kann prüfen, welche Abfragen besonders lange laufen und ob sie durch Konfiguration, Indexierung, Pluginanpassung oder eine geänderte Datenlogik verbessert werden können.

Ursache 3: Cache funktioniert nicht richtig

Caches reduzieren wiederholte Berechnungen und Datenbankzugriffe.

Probleme können entstehen, wenn:

• der Cache dauerhaft deaktiviert ist
• Cachedateien nicht geschrieben werden können
• Speicherpfade oder Berechtigungen fehlerhaft sind
• der Cache nach Änderungen ständig geleert wird
• Plugins den Cache häufig invalidieren
• unterschiedliche Cacheebenen widersprüchlich arbeiten

Ein Cache sollte nicht als pauschale Fehlerquelle betrachtet werden. Das regelmäßige vollständige Leeren kann den Shop vorübergehend sogar langsamer machen, weil Inhalte anschließend neu aufgebaut werden müssen.

Ursache 4: Zu viele oder ungeeignete Plugins

Plugins können bei jedem Seitenaufruf zusätzliche Logik ausführen.

Ein Plugin kann Performance beeinflussen durch:

• zusätzliche Datenbankabfragen
• externe API-Aufrufe
• umfangreiche JavaScript-Dateien
• zusätzliche CSS-Dateien
• dynamische Berechnungen
• ungecachte Inhalte
• Verarbeitung auf Seiten, auf denen die Funktion gar nicht benötigt wird

Nicht die Anzahl allein ist entscheidend. Ein einzelnes schlecht optimiertes Plugin kann mehr Last erzeugen als mehrere kleine und sauber entwickelte Erweiterungen.

Der Beitrag JTL-Shop-Plugins sinnvoll einsetzen zeigt, wie Erweiterungen nach Nutzen, Risiko und Wartungsaufwand bewertet werden sollten.

Plugins kontrolliert testen

Plugins sollten nicht wahllos im produktiven Shop deaktiviert werden.

Ein sinnvoller Test benötigt:

• eine Sicherung
• Kenntnis der betroffenen Funktion
• einen reproduzierbaren Testfall
• möglichst eine Testumgebung
• eine Messung vor und nach der Änderung
• Kontrolle von Daten und Frontend

Manche Plugins speichern Inhalte oder verändern Prozesse. Ihre Deaktivierung kann daher mehr Auswirkungen haben als nur eine fehlende Darstellung.

Ursache 5: Aufwendiges Template und zu viel JavaScript

Das Template bestimmt, wie Inhalte im Browser aufgebaut und dargestellt werden.

Performanceprobleme können entstehen durch:

• große gebündelte JavaScript-Dateien
• viele Slider und Animationen
• mehrfach eingebundene Bibliotheken
• blockierende Skripte im Kopfbereich
• umfangreiche DOM-Strukturen
• unnötige Komponenten auf jeder Seite
• nicht optimierte CSS-Dateien
• individuelle Templateänderungen mit aufwendiger Logik

Ein optisch aufwendiges Design ist nicht automatisch langsam. Entscheidend ist, wie Komponenten technisch umgesetzt und auf welchen Seiten sie geladen werden.

Startseite und Produktseiten getrennt bewerten

Die Startseite enthält häufig Slider, große Bilder und zusätzliche Inhalte. Produktseiten besitzen dagegen Varianten, Empfehlungen und dynamische Daten.

Deshalb sollten mindestens getrennt gemessen werden:

• Startseite
• große Kategorie
• kleine Kategorie
• Produktseite ohne Varianten
• Produktseite mit vielen Varianten
• Suchergebnis
• Warenkorb
• Checkout

Ein einziger Messwert für die Startseite beschreibt nicht die Performance des gesamten Shops.

Ursache 6: Zu große oder ungeeignete Bilder

Produkt- und Inhaltsbilder gehören häufig zu den größten Dateien einer Shopseite.

Typische Probleme sind:

• Originalbilder werden in voller Größe ausgeliefert.
• Dateien sind deutlich größer als ihre sichtbare Darstellung.
• ungeeignete Dateiformate werden verwendet.
• viele Bilder laden gleichzeitig.
• Lazy Loading fehlt oder funktioniert nicht.
• mobile Geräte erhalten dieselben großen Dateien wie Desktopgeräte.
• Bildabmessungen sind nicht reserviert und verursachen Layoutsprünge.

Besonders auf mobilen Verbindungen wirken sich große Bilddateien deutlich aus. Optimierung bedeutet jedoch nicht, Bilder so stark zu komprimieren, dass Produktdetails verloren gehen.

Ursache 7: Externe Dienste blockieren den Seitenaufbau

Ein JTL-Shop lädt häufig Ressourcen von Drittanbietern.

Dazu können gehören:

• Analyse- und Trackingdienste
• Werbenetzwerke
• Bewertungssiegel
• Chat- und Supportwidgets
• externe Schriftarten
• Videos
• Zahlungsanbieter
• Social-Media-Inhalte
• Consent-Dienste

Reagiert ein Drittanbieter langsam, kann die sichtbare Seite verzögert werden. Externe Skripte sollten deshalb nur eingebunden werden, wenn sie einen konkreten Nutzen besitzen und technisch möglichst nicht blockierend geladen werden.

Consent-Lösung und Performance

Der Consent-Banner ist häufig eines der ersten sichtbaren Elemente und steuert weitere Skripte.

Probleme können entstehen, wenn:

• zu viele Dienste bereits vor einer Entscheidung geladen werden
• Skripte mehrfach eingebunden sind
• blockierte Ressourcen regelmäßig erneut angefordert werden
• das Consent-Skript selbst sehr groß ist
• Konfigurationen verschiedener Systeme miteinander kollidieren

Die technische Prüfung muss Datenschutzanforderungen und Performance gemeinsam berücksichtigen. Ein schneller Shop darf nicht durch unzulässiges Vorladen von Diensten erreicht werden.

Ursache 8: Bots, Crawler und unerwünschter Traffic

Nicht jeder Seitenaufruf stammt von einem potenziellen Kunden.

Hohe Last kann entstehen durch:

• Suchmaschinen-Crawler
• Preisvergleichsdienste
• SEO-Werkzeuge
• Scraper
• automatisierte Angriffsmuster
• fehlerhaft konfigurierte eigene Überwachung

Besonders problematisch sind Bots, die Filterkombinationen, interne Suchergebnisse oder sehr viele Produktseiten in kurzer Zeit aufrufen. Solche Anfragen können aufwendige Datenbankprozesse auslösen.

Serverprotokolle helfen dabei, auffällige Zugriffsmuster zu erkennen. Eine Sperrung sollte jedoch gezielt erfolgen, damit wichtige Suchmaschinen und legitime Dienste nicht blockiert werden.

Filter und facettierte Navigation als Lastfaktor

Filter verbessern die Produktauswahl, können aber sehr viele unterschiedliche URL- und Abfragekombinationen erzeugen.

Kritisch können sein:

• viele gleichzeitig kombinierbare Merkmale
• sehr große Kategorien
• umfangreiche Mehrfachauswahl
• nicht begrenzte Bot-Zugriffe auf Filter-URLs
• Filterwerte mit hoher Datenmenge
• unzureichende Cachewirkung

Filter müssen deshalb aus Sicht von Bedienung, Datenbank und Indexierung gemeinsam geplant werden. Der Beitrag JTL-Shop Varianten, Filter und Merkmale behandelt diese Zusammenhänge ausführlicher.

Ursache 9: Interne Suche und große Sortimente

Die interne Suche muss häufig große Mengen an Artikeln, Begriffen und Eigenschaften verarbeiten.

Sie kann langsamer werden durch:

• sehr große Sortimente
• lange oder uneinheitliche Produkttexte
• viele Suchfelder und Merkmale
• aufwendige Vorschlagsfunktionen
• fehlende oder ungeeignete Indizierung
• Suchanfragen automatisierter Bots

Bei einer langsamen Suche muss deshalb geprüft werden, ob das Problem nur einzelne Suchbegriffe, die Vorschlagsfunktion oder die gesamte Ergebnisseite betrifft.

Ursache 10: Variantenreiche Produktseiten

Produkte mit vielen Varianten benötigen zusätzliche Daten und Logik.

Einfluss haben:

• Anzahl der Kindartikel
• mehrere Variationsdimensionen
• individuelle Bilder
• Preisunterschiede
• Bestandsabfragen
• kundengruppenspezifische Preise
• Cross-Selling und Zubehör

Werden ausschließlich solche Produktseiten langsam, sollte nicht der gesamte Server pauschal verantwortlich gemacht werden. Variantenstruktur, Template und zugehörige Plugins müssen gezielt geprüft werden.

Ursache 11: Langsamer Warenkorb oder Checkout

Performanceprobleme im Checkout besitzen eine besonders hohe wirtschaftliche Bedeutung.

Mögliche Ursachen sind:

• komplexe Versandkostenberechnung
• viele Zahlungsarten
• externe Zahlungs- oder Bonitätsdienste
• Gutschein- und Rabattlogik
• Plugins für Cross-Selling oder Zusatzangebote
• umfangreiche Steuer- und Länderregeln
• externe Adressprüfung
• langsame Sessionverarbeitung

Der Checkout sollte deshalb separat und mit unterschiedlichen Lieferländern, Warenkörben, Zahlungsarten und Kundengruppen getestet werden.

Performanceprobleme nach einem Update

Verschlechtert sich der Shop unmittelbar nach einer Änderung, sollte der zeitliche Zusammenhang dokumentiert werden.

Mögliche Auslöser sind:

• JTL-Shop-Update
• Templateupdate
• Pluginupdate
• PHP-Wechsel
• Servermigration
• neuer Trackingdienst
• neue Inhalte oder Bilder
• geänderte Cacheeinstellungen

Trotzdem sollte nicht automatisch auf die vorherige Version zurückgewechselt werden. Zuerst muss geklärt werden, ob die Änderung selbst, eine Inkompatibilität oder ein nachfolgender Cache- und Datenbankprozess verantwortlich ist.

Performance vor und nach Änderungen vergleichen

Ohne Ausgangswerte lässt sich eine Verschlechterung nur schwer objektiv bewerten.

Vor größeren Änderungen sollten deshalb dokumentiert werden:

• Serverantwort wichtiger Seiten
• Gesamtladezeit
• Dateigröße der Seite
• Anzahl geladener Ressourcen
• Serverauslastung
• Fehlerprotokolle

Dieselben Seiten und Testbedingungen sollten nach dem Update erneut verwendet werden.

Warum ein Hostingwechsel nicht immer hilft

Ein leistungsfähigeres Hosting kann sinnvoll sein, wenn die vorhandenen Ressourcen nachweislich nicht ausreichen.

Es löst jedoch nicht automatisch:

• schlecht optimierte Plugins
• zu große Bilder
• blockierende externe Skripte
• fehlerhafte Datenbankabfragen
• unnötige Filterkombinationen
• schlecht konfigurierte Caches
• unkontrollierten Bot-Traffic

Vor einem Umzug sollte feststehen, welcher konkrete Engpass durch das neue Hosting beseitigt werden soll.

Warum pauschale Performancewerte mit Vorsicht zu bewerten sind

Ein einzelner Testwert kann durch Standort, Netzwerk, Cachezustand und Testgerät beeinflusst werden.

Aussagekräftiger sind:

• mehrere Messungen zu unterschiedlichen Zeiten
• Vergleich gleicher Seiten
• Messung mit und ohne Cache
• mobile und stationäre Tests
• echte Nutzerdaten
• Serverprotokolle und Ressourcenwerte

Performance sollte nicht nur auf eine einzelne Punktzahl reduziert werden. Die tatsächliche Bedienbarkeit und Stabilität wichtiger Prozesse bleiben entscheidend.

Core Web Vitals und JTL-Shop

Die Core Web Vitals betrachten wichtige Aspekte der wahrgenommenen Nutzung.

Dazu gehören insbesondere:

• Ladezeit des größten sichtbaren Elements
• Reaktionsfähigkeit bei Benutzerinteraktionen
• unerwartete Layoutverschiebungen

Große Hero-Bilder, verzögert geladene Schriftarten, umfangreiches JavaScript und nachträglich eingefügte Banner können diese Werte beeinflussen.

Die Seite Technische SEO beschreibt, wie Performance, Indexierung und technische Seitenqualität gemeinsam betrachtet werden.

Performance und SEO hängen zusammen

Ladezeit ist nicht der einzige Rankingfaktor, beeinflusst aber Nutzung, Crawling und Conversion.

Ein langsamer Shop kann dazu führen, dass:

• Besucher Seiten früher verlassen
• weniger Produkte angesehen werden
• der Checkout häufiger abgebrochen wird
• Crawler weniger Seiten effizient verarbeiten
• mobile Nutzer stärker beeinträchtigt werden

Performanceoptimierung sollte deshalb nicht isoliert als technische Schönheitsmaßnahme betrachtet werden.

Die richtige Reihenfolge bei einer Performanceanalyse

Eine strukturierte Vorgehensweise verhindert, dass mehrere Änderungen gleichzeitig die Ursache verdecken.

Warum nur eine Änderung gleichzeitig erfolgen sollte

Werden Hosting, Plugins, Cache und Template gleichzeitig verändert, lässt sich der tatsächliche Effekt nicht mehr zuordnen.

Eine kontrollierte Optimierung sollte deshalb:

• einen Ausgangswert besitzen
• eine konkrete Ursache testen
• nur eine zusammenhängende Änderung vornehmen
• das Ergebnis erneut messen
• Nebenwirkungen kontrollieren
• die Änderung dokumentieren

Testumgebung statt Experimente im produktiven Shop

Besonders Plugin-, Template- und Versionsänderungen sollten möglichst außerhalb des produktiven Shops geprüft werden.

Eine Testumgebung ermöglicht:

• kontrollierte Deaktivierung von Plugins
• Templatevergleiche
• PHP- und Versionswechsel
• Datenbanktests
• Messung ohne Kundenverkehr
• Prüfung des Checkouts nach Änderungen

Die Testumgebung muss der produktiven Umgebung ausreichend ähnlich sein. Ein leerer Testshop ohne reale Datenmenge bildet Performanceprobleme großer Kategorien möglicherweise nicht ab.

Schnelle Sofortmaßnahmen mit begrenzter Aussagekraft

Einige Maßnahmen können kurzfristig helfen, ersetzen aber keine Ursachenanalyse.

Dazu gehören:

• Cache kontrolliert neu aufbauen
• auffällige Cronjobs zeitlich verschieben
• sehr große Bilder ersetzen
• nicht benötigte externe Widgets entfernen
• offensichtlichen Bot-Traffic begrenzen
• freien Speicherplatz schaffen

Diese Maßnahmen sollten dokumentiert und anschließend gemessen werden. Verbessert sich der Shop nur vorübergehend, muss die eigentliche Ursache weiter untersucht werden.

Was nicht ungeprüft gemacht werden sollte

Unkoordinierte Eingriffe können neue Fehler erzeugen oder wichtige Diagnosedaten beseitigen.

• alle Plugins gleichzeitig deaktivieren
• Datenbanktabellen manuell leeren
• PHP-Version spontan wechseln
• Serverlimits beliebig erhöhen
• Cacheverzeichnisse ohne Kenntnis der Funktion löschen
• Templateänderungen direkt im Standardsystem vornehmen
• mehrere Updates gleichzeitig installieren
• Protokolle vor der Auswertung löschen

Performanceprobleme nach Priorität behandeln

Nicht jede langsame Seite besitzt dieselbe betriebliche Auswirkung.

Eine hohe Priorität besteht insbesondere, wenn:

• der Checkout betroffen ist
• regelmäßig Fehlerseiten auftreten
• der Shop zeitweise nicht erreichbar ist
• Bestellungen oder Zahlungsprozesse abbrechen
• mobile Besucher den Shop kaum bedienen können
• die Verschlechterung plötzlich und stark aufgetreten ist

Der Beitrag JTL-Support priorisieren zeigt, wie technische Probleme nach Geschäftsauswirkung und Risiko eingeordnet werden können.

JTL-Shop regelmäßig auf Performanceveränderungen prüfen

Ein Shop wird nicht nur durch technische Updates verändert.

Auch folgende Entwicklungen können ihn schrittweise verlangsamen:

• wachsendes Sortiment
• mehr Bilder und Inhalte
• zusätzliche Plugins
• neue Trackingdienste
• mehr Filterwerte
• steigende Besucherzahlen
• wachsende Datenbanktabellen
• veränderte Bot-Zugriffe

Der Beitrag JTL-Wawi und JTL-Shop regelmäßig warten beschreibt, welche technischen und organisatorischen Kontrollen sinnvoll sind.

Ein einfaches Performance-Monitoring aufbauen

Bereits wenige wiederkehrende Messpunkte helfen dabei, schleichende Verschlechterungen zu erkennen.

Regelmäßig gemessen werden können:

• Serverantwort der Startseite
• Ladezeit einer großen Kategorie
• Ladezeit einer typischen Produktseite
• Verhalten des Warenkorbs
• Verfügbarkeit des Checkouts
• Häufigkeit von Fehler 500 und 503
• CPU-, RAM- und Datenbankauslastung
• freier Speicherplatz

Wichtig ist, nicht nur Werte zu sammeln. Für auffällige Veränderungen müssen Zuständigkeiten und Eskalationswege festgelegt sein.

Typische Fehler bei der JTL-Shop-Optimierung

Performanceprojekte scheitern häufig an fehlender Messung oder einer zu pauschalen Ursache.

Wann eine professionelle Analyse sinnvoll ist

Kleine Bild- oder Inhaltsprobleme lassen sich häufig intern beheben. Komplexere Ursachen benötigen eine Betrachtung mehrerer Systeme.

Fachliche Unterstützung ist besonders sinnvoll, wenn:

• Fehler 500, 502 oder 503 auftreten
• der Shop nur zeitweise langsam ist
• Datenbank und Server stark ausgelastet sind
• mehrere Plugins und individuelle Anpassungen bestehen
• der Checkout betroffen ist
• ein Update die Performance verändert hat
• bisherige Maßnahmen keine dauerhafte Wirkung zeigen
• ein Hostingwechsel erwogen wird

Wie Faymax Consulting einen langsamen JTL-Shop analysiert

Faymax Consulting betrachtet nicht nur die sichtbare Seite, sondern die gesamte technische Verarbeitung.

Eine Analyse kann umfassen:

• Messung wichtiger Seitentypen
• Trennung von Server- und Browserproblemen
• Prüfung von CPU, Arbeitsspeicher und Speicherplatz
• Kontrolle von PHP-FPM und Serverprotokollen
• Analyse der Datenbankauslastung
• Prüfung auffälliger Tabellen und Abfragen
• Bewertung von Plugins und Template
• Kontrolle externer Dienste
• Analyse von Bildern und Frontendressourcen
• Prüfung von Bots und ungewöhnlichem Traffic
• Priorisierung geeigneter Maßnahmen
• Funktionskontrolle nach der Umsetzung

Ziel ist nicht, möglichst viele technische Einstellungen zu verändern. Zuerst werden die tatsächlichen Engpässe identifiziert und anschließend gezielt bearbeitet.

Häufige Fragen zu langsamen JTL-Shops