Geschwindigkeit in PrestaShop ohne etwas zu beschädigen
Dieses Skill fasst zusammen, was an echten PrestaShop-Shops gemessen und angewendet wurde: was wirklich verbessert, in welcher Reihenfolge es sinnvoll ist und wo die Stolperfallen liegen. Alles ist anonymisiert.
Die Regeln, die nicht gebrochen werden
- Backup vor jeder Änderung. Von jeder Datei, die bearbeitet wird, von den geänderten Konfigurationszeilen und von der Serverkonfiguration. Und ein
volver.sh, das diese spezifische Änderung rückgängig macht. Details inreferenzen/01-metodo-seguro.md. - Messen vorher und nachher mit derselben Methode. Ohne eine Ausgangsmessung kann man nicht sagen, dass sich etwas verbessert hat. Die Methode steht in
referenzen/02-medir.mdund das Tool inscripts/medir.py. - Eine Änderung nach der anderen und testen durch Ein- und Ausschalten. Um zu wissen, ob eine Option hilft, wird mit und ohne gemessen, im Wechsel (A, B, A, B) und mit mehreren Ladevorgängen. Wenn es nicht besser wird, wird die Änderung rückgängig gemacht.
- Nichts in der Produktion ohne die Erlaubnis des Shopbetreibers, vorher sagen, was geändert werden soll. Wenn es eine Kopie des Shops gibt, zuerst dort testen.
- Nicht nur den Anfang prüfen, sondern auch das Ende. Dieselben HTTP-Statuscodes wie zuvor auf den wichtigsten Seiten, null neue JavaScript-Fehler (vorhandene Fehler zählen nicht, werden aber notiert), Bilder laden korrekt, und Warenkorb und Checkout funktionieren.
- Jede Änderung melden: was geändert wurde, wo das Backup ist, wie es rückgängig gemacht wird und was gemessen wurde.
Arbeitsreihenfolge, von der rentabelsten zur geringsten
| Schritt | Was | Referenz |
|---|---|---|
| 1 | Ausgangssituation messen (Mobil 4G, erster und zweiter Besuch) | referenzen/02-medir.md |
| 2 | Bilder: WebP bei Produktfotos, im Template und bei Bannern/CMS | referenzen/03-imagenes-webp.md |
| 3 | Rendert-blockierende Ressourcen: Schriftarten, Icons, jQuery, reCAPTCHA, CCC | referenzen/04-bloqueos.md |
| 4 | Browser-Cache für statische Ressourcen | referenzen/05-cache-navegador.md |
| 5 | Server: OPcache, MariaDB, PHP-FPM, Sessions, DNS, CPU | referenzen/06-servidor.md |
| 6 | Drittanbieter-Module, die nach außen rufen oder blockieren | referenzen/07-modulos-terceros.md |
| — | Bereits gemachte Fehler (vorher lesen) | referenzen/08-trampas.md |
Am meisten wiegen fast immer die Bilder: Banner im PNG-Format mit 2 bis 5 MB sind üblich. In einem Shop sank die Startseite von 26,5 MB auf 4,8 MB allein durch WebP bei den Bannern, ohne ein einziges Originalbild zu verändern.
Werkzeuge
| Skript | Wofür |
|---|---|
scripts/medir.py | Echter Browser (Playwright) auf dem Handy mit langsamen 4G und CPU ×4: FCP, LCP, Ladezeit, KB, Anfragen, rendert-blockierende Ressourcen, die schwersten Elemente und JavaScript-Fehler beim ersten und zweiten Besuch. |
scripts/revisar_cache.py | Wie lange der Browser CSS, JS, Bilder und Schriftarten einer Website speichert und ob die Seiten und das JSON nicht gespeichert werden. Nur lesend. |
scripts/webp_al_lado.py | Erstellt image.png.webp neben jedem Bild eines Ordners (ohne das Original zu verändern), nur wenn es mindestens 10 % kleiner ist. Hinterlässt ein Protokoll zur Rückgängigmachung. |
Vorlagen zur Konfiguration, die in plantillas/ fertig zur Anpassung sind: WebP-Aushandlung für nginx und Apache, sicherer Browser-Cache-Block für .htaccess, das Smarty-Partial, das WebP nur anfordert, wenn es existiert, und eine Mustervorlage zur Benachrichtigung eines Modulentwicklers.
Abschlussbericht
- Was geändert wurde, Shop für Shop, mit den Zahlen vorher und nachher.
- Wo das Backup liegt und der genaue Befehl, um die Änderung rückgängig zu machen.
- Was noch offen ist und welche Entscheidung der Shopbetreiber treffen muss.
- Was nebenbei gesehen und nicht geändert wurde (bereits vorhandene Fehler, verdächtige Module).