CSS, JS und Schriften in PrestaShop optimieren, ohne den Shop zu beschädigen

Öffnen Sie die Produktseite eines PrestaShop-Shops mit vierzig Modulen und zählen Sie die CSS- und JS-Dateien, die geladen werden. Mehr als fünfzig sind schnell erreicht. Darunter das CSS des Kontaktformulars, das JS des Bewertungsmoduls, das nur auf einer anderen Seite erscheint, und eine Schrift mit sechs Schnitten, von denen das Theme zwei verwendet.

Keine dieser Dateien macht für sich allein etwas kaputt. Zusammen führen sie dazu, dass der Browser viel mehr herunterlädt, analysiert und ausführt, als er braucht, bevor er die Seite darstellt. Das belastet LCP und INP, die Core-Web-Vitals-Werte, die Shops am meisten Mühe machen.

Woher die vielen Dateien kommen

In PrestaShop registriert jedes Modul seine Ressourcen im Front-Hook. Die meisten tun das auf allen Seiten, aus Bequemlichkeit: Der Entwickler weiß nicht, wo Sie seinen Block platzieren, also lädt er ihn immer. Dazu kommen das Theme, sein Eltern-Theme bei einem Child-Theme, die mitgelieferten Bibliotheken und die Skripte von Drittanbietern (Analyse, Chat, Pixel, externe Bewertungen).

Deshalb bedeutet Optimieren nicht nur „komprimieren“. Es gibt vier verschiedene Hebel, und man sollte sie nicht vermischen.

1. Zusammenfassen und minifizieren

PrestaShop bringt unter Erweiterte Einstellungen > Leistung standardmäßig den intelligenten Cache für CSS und JavaScript mit: Er fasst die Dateien zu einer oder wenigen zusammen und minifiziert sie. Das sollte man als Erstes aktivieren, und es funktioniert fast immer.

• Vorteil: weniger Anfragen und weniger Bytes.
• Grenze: Es wird weiterhin alles auf allen Seiten geladen, nur gebündelt. Wenn 40 % des CSS auf der Produktseite nicht genutzt werden, bleiben sie ungenutzt, jetzt in einer größeren Datei.
• Risiko: Schlecht geschriebenes JS, das von der Reihenfolge oder einer globalen Variable abhing, kann nach dem Zusammenfassen versagen. Man merkt es daran, dass ein Button nicht mehr reagiert; in der Browserkonsole erscheint der Fehler.

Leeren Sie nach dem Aktivieren den Cache und testen Sie den kompletten Ablauf: Liste, Produktseite, Warenkorb, Checkout und Zahlung.

2. Entfernen, was auf einer Seite nicht gebraucht wird

Das bringt am meisten und wird am seltensten gemacht. Wenn das CSS des Formularmoduls nur auf der Kontaktseite gebraucht wird, ist es sinnlos, es auf der Produktseite zu laden. Für die Entscheidung brauchen Sie eine Bestandsaufnahme: welche Ressource jeder Seitentyp lädt, wie groß sie ist und aus welchem Modul sie stammt.

Mit dieser Übersicht sind die Regeln einfach: „dieses CSS nicht auf der Produktseite“, „dieses JS nur im Checkout“. Das Risiko besteht darin, etwas zu entfernen, das an einer Stelle doch genutzt wurde, die Sie nicht angesehen haben. Deshalb wird jede Regel auf den betroffenen Seiten getestet, bevor sie aktiv bleibt.

3. Defer, async und Verzögern bis zur Interaktion

Ein normales Skript im <head> hält das Parsen der Seite an, bis es heruntergeladen und ausgeführt ist. Es gibt drei Wege, das zu vermeiden:

Das Verzögern bis zur Interaktion wirkt sehr gut bei Drittanbieter-Skripten, die meist das Schwerste sind. Es hat aber zwei Fallstricke:

• Analyse und Einwilligung. Wenn Sie das Analyse-Tag verzögern, werden Besuche, die ohne Interaktion abspringen, nicht gemessen. Das kann je nach Bedarf akzeptabel sein oder nicht. Und das Einwilligungsskript wird nie verzögert: Es muss vor allem anderen stehen.
• Abhängigkeiten. Definiert ein verzögertes Skript etwas, das ein anderes beim Laden benutzt, schlägt das zweite fehl. Verzögerte Skripte müssen in Dokumentreihenfolge und mit einer Höchstwartezeit ausgeführt werden, damit sie nicht ewig warten.

4. Google Fonts vom eigenen Server

Viele Themes laden die Schriften von den Servern von Google. Das kostet zweifach:

• Leistung: Verbindungen zu einer anderen Domain und oft mehr Schnitte und Zeichensätze, als Sie verwenden.
• Datenschutz: Der Browser des Besuchers sendet beim Abruf der Schrift seine IP an Google, bevor er irgendetwas akzeptiert hat. Ein deutsches Gericht hat deswegen bereits eine Website verurteilt, und es ist eine häufige Abmahnung.

Die Lösung: die woff2-Dateien herunterladen und von Ihrer Domain ausliefern, nur mit den Schnitten und Teilmengen, die Sie verwenden (für Deutsch meist latin und latin-ext). Außerdem:

• Laden Sie nur die Schrift des zuerst sichtbaren Textes vor, nicht alle.
• Verwenden Sie font-display: swap, damit der Text in der Systemschrift erscheint, während Ihre noch lädt.
• Prüfen Sie, dass kein Verweis auf Google im Eltern-Theme, in den Modulen oder in dem von ihnen erzeugten CSS übrig bleibt.

Messen, ohne sich etwas vorzumachen

1. Messen Sie vorher. PageSpeed Insights liefert Felddaten (echte Nutzer, wenn Ihr Shop genug Traffic hat) und Labordaten.
2. Ändern Sie jeweils nur eine Sache.
3. Vergleichen Sie dieselbe Seite mit und ohne die Änderung, auf dem Smartphone.
4. Gehen Sie den Checkout durch und machen Sie eine Testbestellung.
5. Sehen Sie in die Browserkonsole: Ein neuer Fehler ist eine kaputte Funktion, die Sie noch nicht gefunden haben.

Die Version zählt

Shops auf PrestaShop 1.6 oder den frühen 1.7-Versionen schleppen Themes mit altem jQuery und Bibliotheken mit, die sich nicht verzögern lassen, ohne etwas zu beschädigen. In PrestaShop 8 und 9, mit aktuellem PHP und Themes wie Hummingbird, ist der Ausgangspunkt sauberer, und jede Optimierung bringt mehr. Liegt Ihr Shop weit zurück, ist das Update Teil der Optimierung und kein separater Schritt.

So lösen Sie es in PrestaShop

RKR OptiMatters erstellt eine Bestandsaufnahme der CSS- und JS-Dateien, die jeder Seitentyp lädt, mit Größe und Herkunftsmodul, und lässt Sie Regeln anlegen, um Dateien zu entfernen, defer oder async anzuwenden, sie bis zur ersten Interaktion zu verzögern, nach dem Laden nachzuladen oder das Laden zu erzwingen, eingegrenzt nach Seite, Controller, Kategorie, Gerät oder URL. Es lädt die Google Fonts Ihres Shops herunter und liefert sie von Ihrem Server aus, nur mit den nötigen Schnitten und Teilmengen, und bietet einen Testmodus, um jede Seite mit und ohne Optimierer zu vergleichen. Für den Server ergänzt All In One Cache einen Full-Page-Cache, einen Abfrage-Cache in Redis (PrestaShop 8 oder höher) und die Verwaltung von OPcache, mit optionaler Minifizierung von HTML sowie Inline-CSS und -JS.