PrestaShop Modul-Audit: Prüfen, was jedes Modul auf jeder Seite lädt

Warum Modul-Bloat der stille Killer der PrestaShop-Performance ist

Jeder PrestaShop-Shop startet schnell. Dann installiert man fünf Module, zehn Module, dreißig Module, und plötzlich braucht die Startseite vier Sekunden zum Laden. Der Übeltäter ist selten ein einziges massives Modul. Stattdessen sind es Dutzende kleiner Module, die jeweils ihre eigene CSS-Datei, ihre eigene JavaScript-Datei und ihre eigenen Datenbankabfragen bei jedem einzelnen Seitenaufruf hinzufügen. Dieses kumulative Gewicht ist das, was wir Modul-Bloat nennen, und es ist der Hauptgrund, warum PrestaShop-Shops mit der Zeit langsam werden.

Das Problem ist, dass die meisten Shopbetreiber nie überprüfen, was ihre Module tatsächlich laden. Sie installieren ein Modul für Produktlabels, ein weiteres für Social-Sharing-Buttons, ein weiteres für ein Newsletter-Popup, ein weiteres für Analytics, und jedes einzelne registriert sich stillschweigend auf Hooks wie displayHeader und actionFrontControllerSetMedia. Selbst wenn ein Modul nur Inhalte auf Produktseiten anzeigt, lädt es möglicherweise seine CSS- und JavaScript-Dateien auf der Startseite, auf Kategorieseiten, der Warenkorbseite und im Checkout. Das bedeutet, dass Ihre Kunden Assets herunterladen, die sie auf der jeweiligen Seite nie verwenden werden.

Ein ordnungsgemäßes Modul-Audit zeigt genau auf, was jedes Modul zum Seitengewicht beiträgt. Es verrät Ihnen, welche Module die schlimmsten Übeltäter sind, welche Assets unnötig laden und welche Sie optimieren oder gänzlich entfernen können. Dieser Artikel führt Sie durch den vollständigen Prozess der Überprüfung Ihrer PrestaShop-Module auf Leistung, unter Verwendung von Browser-DevTools, dem PrestaShop-Debug-Modus und systematischer Analyse.

Schritt 1: PrestaShop-Debug-Modus und Performance-Profiling aktivieren

Bevor Sie Ihre Browser-Tools öffnen, müssen Sie die integrierten Profiling-Funktionen von PrestaShop aktivieren. PrestaShop verfügt über einen Debug-Modus, der detaillierte Informationen über Hook-Ausführung, Modul-Ladezeiten und Datenbankabfragen offenlegt. Um ihn zu aktivieren, müssen Sie zwei Einstellungen ändern.

Gehen Sie zunächst zu Erweiterte Einstellungen, dann Leistung in Ihrem Back-Office. Setzen Sie den Debug-Modus auf Ja. Dies aktiviert die Fehlerberichterstattung und zusätzliche Protokollierung, die hilft, problematische Module zu identifizieren. Die wahre Stärke liegt jedoch in der Profiling-Funktion.

Um das vollständige Profiling zu aktivieren, müssen Sie die Datei defines.inc.php im Konfigurationsverzeichnis Ihres PrestaShop bearbeiten. Suchen Sie die Zeile, die _PS_DEBUG_PROFILING_ definiert, und setzen Sie sie auf true. In PrestaShop 1.7 und 8.x steuert diese Konstante, ob die Profiling-Leiste am unteren Rand jeder Front-Office-Seite erscheint. Nach der Aktivierung laden Sie eine beliebige Seite Ihres Shops neu und Sie werden ein detailliertes Profiling-Panel sehen, das Ausführungszeiten für jeden Hook, jedes Modul und jede SQL-Abfrage anzeigt.

Das Profiling-Panel ist in mehrere Abschnitte unterteilt. Der Hook-Bereich zeigt Ihnen jeden Hook, der auf der aktuellen Seite ausgeführt wurde, welche Module an jedem Hook angeschlossen sind und wie lange jedes Modul für die Ausführung benötigt hat. Der SQL-Bereich zeigt jede Datenbankabfrage, ihre Ausführungszeit und welches Modul oder welche Kernfunktion sie ausgelöst hat. Der Modul-Bereich gibt Ihnen eine Zusammenfassung der gesamten Ausführungszeit pro Modul über alle Hooks hinweg.

Achten Sie besonders auf die Spalte der gesamten Ausführungszeit. Ein gut optimiertes Modul sollte weniger als 10 Millisekunden zu einem Seitenaufruf beitragen. Wenn Sie sehen, dass ein Modul 50, 100 oder sogar 500 Millisekunden benötigt, ist das ein ernstes Leistungsproblem, das untersucht werden muss.

Schritt 2: Browser-DevTools verwenden, um Modul-Assets zu kartieren

Das integrierte Profiling von PrestaShop zeigt Ihnen die serverseitige Leistung, aber es zeigt nicht das vollständige Bild dessen, was im Browser passiert. Dafür benötigen Sie die Entwicklertools Ihres Browsers. Öffnen Sie Chrome oder Firefox, drücken Sie F12 und navigieren Sie zum Netzwerk-Tab.

Laden Sie Ihre Startseite mit geöffnetem Netzwerk-Tab neu. Sie werden jede Anfrage sehen, die der Browser stellt: HTML, CSS-Dateien, JavaScript-Dateien, Bilder, Schriftarten und AJAX-Aufrufe. Das Ziel ist es, festzustellen, welche dieser Anfragen von Modulen stammen.

In PrestaShop folgen Modul-Assets einem vorhersehbaren URL-Muster. CSS-Dateien von Modulen werden typischerweise von Pfaden wie /modules/modulname/views/css/dateiname.css oder /modules/modulname/css/dateiname.css ausgeliefert. JavaScript-Dateien folgen dem gleichen Muster mit js statt css. Verwenden Sie die Filterleiste im Netzwerk-Tab, um nach "modules/" zu filtern, und Sie sehen sofort jedes Asset, das von Ihren installierten Modulen geladen wird.

Notieren Sie für jedes gefundene Modul-Asset folgende Informationen: den Dateinamen, seine Größe (sowohl übertragen als auch unkomprimiert) und ob es auf dem aktuellen Seitentyp geladen wird. Sie möchten eine Tabelle oder einfache Liste erstellen, die jedes Modul seinen Assets zuordnet. Ein typisches Audit könnte beispielsweise Folgendes offenbaren: Modul A lädt zwei CSS-Dateien mit insgesamt 45 KB und eine JavaScript-Datei von 120 KB auf jeder Seite, zeigt aber nur Inhalte auf Produktseiten an. Das bedeutet, dass Kategorieseiten, die Startseite und der Warenkorb alle 165 KB unnötiger Assets laden.

Der Netzwerk-Tab zeigt Ihnen auch die Wasserfall-Ansicht, die offenlegt, wann jedes Asset zu laden beginnt und wie lange es dauert. Assets, die das Rendering blockieren (render-blockierendes CSS und synchrones JavaScript), sind besonders schädlich, weil sie den Browser daran hindern, irgendeinen Inhalt anzuzeigen, bis sie fertig geladen sind. Achten Sie auf JavaScript-Dateien von Modulen, die im Head ohne async- oder defer-Attribute geladen werden, da diese die schlimmsten Übeltäter für die wahrgenommene Ladezeit sind.

Schritt 3: Analyse des Netzwerk-Wasserfalls pro Modul

Die Wasserfall-Ansicht in den DevTools verdient ihren eigenen Abschnitt, weil sie Leistungsprobleme aufdeckt, die reine Dateigrößen nicht zeigen. Wenn Sie den Wasserfall betrachten, möchten Sie drei Arten von Problemen identifizieren.

Erstens suchen Sie nach render-blockierenden Ressourcen von Modulen. Diese erscheinen als Balken, die früh im Wasserfall beginnen und das First-Paint-Ereignis verzögern (die vertikale grüne oder blaue Linie). In PrestaShop sind CSS-Dateien, die über den displayHeader-Hook oder durch addCSS in setMedia hinzugefügt werden, typischerweise render-blockierend. Wenn ein Modul eine große CSS-Datei hinzufügt, die nur auf bestimmten Seiten benötigt wird, blockiert sie das Rendering auf jeder Seite ohne Grund.

Zweitens suchen Sie nach sequenziellen Ladeketten. Manche Module laden eine JavaScript-Datei, die dann das Laden weiterer Ressourcen auslöst: weitere JavaScript-Dateien, CSS-Dateien, Web-Fonts oder externe API-Aufrufe. Jedes Glied in dieser Kette fügt Latenz hinzu. Ein Modul, das jQuery UI lädt, dann ein jQuery UI Theme-CSS, dann ein benutzerdefiniertes Widget-Skript, dann das CSS des Widgets, erstellt eine Kette von vier sequenziellen Anfragen, die selbst bei einer schnellen Verbindung 200 bis 400 Millisekunden dauern können.

Drittens suchen Sie nach externen Anfragen. Manche Module senden Anfragen an externe Server für Analytics, Tracking, Schriftarten-Laden, Social-Media-Widgets oder API-Daten. Diese Anfragen sind besonders gefährlich, weil Sie keine Kontrolle über die Antwortzeit des externen Servers haben. Ein Social-Sharing-Modul, das auf jeder Seite Facebook-, Twitter- und Pinterest-APIs aufruft, kann 500 Millisekunden oder mehr Latenz hinzufügen, und wenn einer dieser Server langsam oder nicht erreichbar ist, kann es das vollständige Laden Ihrer gesamten Seite blockieren.

Um die Auswirkung pro Modul zu quantifizieren, verwenden Sie die Blockierungsfunktion der Chrome DevTools. Klicken Sie mit der rechten Maustaste auf eine Anfrage eines bestimmten Moduls und wählen Sie "Anfrage-Domain blockieren" oder "Anfrage-URL blockieren". Laden Sie dann die Seite neu und vergleichen Sie die Ladezeit. Dies gibt Ihnen eine direkte Messung, wie viel die Assets dieses Moduls zu Ihrer gesamten Seitenladezeit beitragen. Wiederholen Sie dies für jedes Modul, um eine Rangliste von den schwersten bis zu den leichtesten zu erstellen.

Schritt 4: Hook-Ausführungsanalyse

Zu verstehen, welche Hooks jedes Modul verwendet, ist entscheidend für die Identifizierung unnötigen Ladens. PrestaShops Hook-System ist der Mechanismus, über den Module ihre Inhalte, Assets und Logik in Seiten einschleusen. Die leistungsrelevantesten Hooks für Front-Office-Seiten sind displayHeader, actionFrontControllerSetMedia, displayTop, displayHome, displayFooter, displayProductAdditionalInfo und displayProductListFunctionalButtons.

Der displayHeader-Hook ist der am häufigsten missbrauchte Hook im PrestaShop-Ökosystem. Module registrieren sich auf diesem Hook, um ihre CSS- und JavaScript-Dateien zum Seiten-Head hinzuzufügen. Das Problem ist, dass displayHeader auf jeder einzelnen Front-Office-Seite ausgelöst wird. Wenn ein Modul sich bei displayHeader registriert, ohne zu prüfen, welche Seite der Kunde gerade betrachtet, lädt es seine Assets überall.

Um zu sehen, welche Module bei jedem Hook registriert sind, gehen Sie zu Design, dann Positionen in Ihrem Back-Office. Diese Seite zeigt jeden Hook und jedes daran angehängte Modul. Schauen Sie sich speziell displayHeader und actionFrontControllerSetMedia an. Zählen Sie, wie viele Module dort registriert sind. In einem typischen Shop mit 30 oder mehr installierten Modulen finden Sie möglicherweise 15 bis 20 Module allein auf displayHeader. Jedes einzelne fügt mindestens eine CSS- oder JavaScript-Datei zu jeder Seite hinzu.

Vergleichen Sie dies nun mit Ihren DevTools-Erkenntnissen. Prüfen Sie für jedes Modul auf displayHeader, ob dieses Modul tatsächlich auf der aktuellen Seite laden muss. Ein Produktbewertungsmodul benötigt seine Assets nur auf Produktseiten. Ein Wunschlistenmodul benötigt seine Assets nur auf Produkt- und Kontoseiten. Ein Größentabellenmodul benötigt seine Assets nur auf Produktseiten. Dennoch laden alle auf Ihrer Startseite, Ihren Kategorieseiten, Ihren CMS-Seiten und Ihrem Checkout.

Die Profiling-Daten aus Schritt 1 fügen dieser Analyse eine weitere Dimension hinzu. Manche Module laden nicht nur unnötige Assets, sondern führen auch aufwendigen PHP-Code bei jedem Hook-Aufruf aus. Ein Modul, das in seiner hookDisplayHeader-Methode Datenbankabfragen ausführt, um Konfigurationswerte zu prüfen oder Daten abzurufen, verschwendet Serverressourcen auf jeder Seite, selbst wenn seine Ausgabe nicht benötigt wird.

Schritt 5: Die schwersten Module identifizieren

Mit Daten aus Profiling, DevTools und Hook-Analyse können Sie nun Ihre Module nach ihrer Leistungsauswirkung einordnen. Erstellen Sie eine Liste mit folgenden Spalten: Modulname, Anzahl geladener CSS-Dateien, CSS-Gesamtgröße, Anzahl geladener JavaScript-Dateien, JavaScript-Gesamtgröße, Server-Ausführungszeit aus dem Profiling, Anzahl der Datenbankabfragen und Seiten, auf denen das Modul tatsächlich Inhalte anzeigt.

Die Module, die in diesen Metriken am höchsten abschneiden, sind Ihre schlimmsten Übeltäter. Nach unserer Erfahrung aus der Überprüfung Hunderter PrestaShop-Shops sind die folgenden Modulkategorien durchgängig die schlechtesten Performer.

Page-Builder-Module gehören oft zu den schwersten. Sie laden große CSS-Frameworks, mehrere JavaScript-Bibliotheken für ihren visuellen Editor und laden manchmal sogar Editor-Assets im Front-Office. Ein Page-Builder, der 300 KB CSS und 500 KB JavaScript auf jeder Seite lädt, ist keine Seltenheit.

Social-Media-Module, die Widgets von Facebook, Instagram oder Twitter einbetten, laden externe Codes, die sowohl groß als auch unvorhersehbar in ihrer Ladezeit sind. Ein einzelnes Instagram-Feed-Widget kann 1 MB oder mehr JavaScript zu Ihrer Seite hinzufügen.

Analytics- und Tracking-Module, die mehrere Tracking-Pixel verwenden, laden Codes von externen Domains. Jedes Tracking-Pixel fügt typischerweise 20 bis 50 KB JavaScript plus zusätzliche Netzwerkanfragen für Pixel-Bilder und API-Aufrufe hinzu.

Slider- und Karussell-Module laden große JavaScript-Bibliotheken wie Slick, Owl Carousel oder Swiper zusammen mit ihrem CSS. Selbst wenn der Slider nur auf der Startseite erscheint, laden die Assets oft auf jeder Seite.

Live-Chat-Module laden umfangreiche JavaScript-Pakete für die Chat-Widget-Oberfläche, typischerweise 100 bis 300 KB, und sie stellen WebSocket-Verbindungen her, die während der gesamten Browsing-Sitzung Ressourcen verbrauchen.

Schritt 6: Leistung vor und nach der Optimierung messen

Bevor Sie anfangen, Hooks zu deaktivieren oder Module zu entfernen, erstellen Sie eine Ausgangsmessung. Verwenden Sie mehrere Tools, um ein umfassendes Bild zu erhalten.

Gehen Sie in Chrome DevTools zum Lighthouse-Tab und führen Sie ein Leistungs-Audit durch. Notieren Sie den Performance-Score, First Contentful Paint (FCP), Largest Contentful Paint (LCP), Total Blocking Time (TBT) und Cumulative Layout Shift (CLS). Führen Sie das Audit dreimal durch und bilden Sie den Durchschnitt, um Schwankungen auszugleichen.

Verwenden Sie den Performance-Tab in den DevTools, um eine Seitenlade-Aufzeichnung zu erstellen. Dies gibt Ihnen ein Flame-Chart, das genau zeigt, was der Browser in jeder Millisekunde tut. Suchen Sie nach langen Aufgaben (Blöcke länger als 50 Millisekunden) und identifizieren Sie, welche Modul-Codes sie verursachen.

Messen Sie auch Ihr Seitengewicht. Im Netzwerk-Tab sehen Sie die Gesamtzahl der Anfragen und die gesamte übertragene Größe am unteren Rand des Panels. Filtern Sie separat nach CSS und JS, um modulspezifische Summen zu erhalten.

Notieren Sie alle diese Werte, bevor Sie Änderungen vornehmen. Wenn Sie dann Module optimieren, indem Sie sie von unnötigen Hooks abmelden oder sie vollständig deaktivieren, führen Sie die gleichen Messungen erneut durch. Die Differenz sagt Ihnen genau, wie viel Leistung Sie durch jede Änderung gewonnen haben.

Ein gut durchgeführtes Modul-Audit reduziert das Seitengewicht typischerweise um 30 bis 50 Prozent und verbessert die Ladezeiten um ein bis zwei Sekunden. Bei Shops mit vielen schlecht optimierten Modulen kann die Verbesserung sogar noch dramatischer ausfallen.

Schritt 7: Unnötige Hooks deaktivieren

Sobald Sie identifiziert haben, welche Module Assets auf Seiten laden, wo sie nicht benötigt werden, haben Sie mehrere Optimierungsmöglichkeiten. Der einfachste Ansatz ist das Abmelden von Modulen von Hooks, wo sie nicht sein müssen.

Gehen Sie zu Design, dann Positionen in Ihrem Back-Office. Suchen Sie das Modul auf dem Hook, von dem Sie es entfernen möchten. Klicken Sie auf das Papierkorb-Symbol oder den Abhängen-Button, um das Modul von diesem spezifischen Hook zu entfernen. Dies verhindert, dass das Modul auf diesem Hook überhaupt ausgeführt wird.

Seien Sie jedoch vorsichtig mit diesem Ansatz. Manche Module verwenden displayHeader nicht nur zum Laden von CSS und JavaScript, sondern auch zur Durchführung wesentlicher Initialisierungsaufgaben. Das Abhängen eines solchen Moduls von displayHeader könnte seine Funktionalität auf Seiten beeinträchtigen, auf denen es tatsächlich benötigt wird. Testen Sie immer in einer Staging-Umgebung oder prüfen Sie mindestens die spezifischen Seiten, auf denen das Modul nach dem Abhängen weiterhin funktionieren sollte.

Ein besserer langfristiger Ansatz ist es, den Modulentwickler zu kontaktieren und bedingtes Asset-Laden anzufordern. Ein gut programmiertes Modul sollte den aktuellen Controller oder Seitentyp prüfen, bevor es seine Assets lädt. Zum Beispiel sollte ein Produktbewertungsmodul seine CSS- und JavaScript-Dateien nur laden, wenn der aktuelle Controller der ProductController ist. Auf diese Weise bleibt das Modul aus Kompatibilitätsgründen bei displayHeader angemeldet, lädt aber Assets nur, wenn sie tatsächlich benötigt werden.

Wenn Sie sich zutrauen, Modul-Code zu bearbeiten, können Sie selbst bedingte Prüfungen hinzufügen. Fügen Sie in der hookDisplayHeader- oder hookActionFrontControllerSetMedia-Methode des Moduls eine Prüfung des aktuellen Controller-Namens hinzu. Wenn der Controller nicht einer ist, auf dem das Modul Inhalte anzeigt, kehren Sie frühzeitig zurück, ohne Assets hinzuzufügen. Dies ist die gezielt wirksamste Optimierung, die Sie vornehmen können.

Praktische Checkliste für Ihr Modul-Audit

Um den gesamten Audit-Prozess zusammenzufassen, hier eine praktische Checkliste, der Sie folgen können. Beginnen Sie mit der Aktivierung des PrestaShop-Debug-Profilings. Öffnen Sie den DevTools-Netzwerk-Tab und laden Sie Ihre Startseite neu. Filtern Sie Anfragen nach dem Module-Pfad und listen Sie jedes Modul-Asset auf. Notieren Sie Größe und Typ jedes Assets. Prüfen Sie unter Design, dann Positionen, welche Module bei displayHeader registriert sind. Vergleichen Sie Hook-Registrierungen damit, wo Module tatsächlich Inhalte anzeigen. Verwenden Sie die DevTools-Anfragenblockierung, um die Auswirkung pro Modul zu messen. Erfassen Sie die Lighthouse-Ausgangswerte. Melden Sie Module von Hooks ab, wo sie nicht benötigt werden. Fügen Sie bedingtes Laden zu Modulen hinzu, die global laden. Messen Sie die Lighthouse-Werte nach jeder Änderung erneut. Dokumentieren Sie Ihre Erkenntnisse und Änderungen für zukünftige Referenz.

Dieser systematische Ansatz stellt sicher, dass Sie keine Leistungsmöglichkeiten verpassen, und liefert Ihnen konkrete Daten, um jede vorgenommene Änderung zu rechtfertigen. Modul-Bloat ist kein Geheimnis. Es ist ein messbares, lösbares Problem, und jeder PrestaShop-Shop profitiert von einem gründlichen Modul-Audit mindestens einmal im Jahr.