Web-Performance-Kennzahlen sind zum Pflichtprogramm jedes Audits geworden, und sie produzieren oft endlose Empfehlungslisten, von denen die Hälfte keinen messbaren Effekt hat. In einem PrestaShop-Shop konzentrieren fünf Baustellen das Wesentliche des verfügbaren Gewinns.
Am richtigen Ort messen
Ein Vorab-Punkt, und er ändert alles.
Audit-Tools führen einen einzelnen Test unter simulierten Bedingungen aus. Sie sind zur Diagnose nützlich, sie messen nicht, was Ihre Besucher erleben.
Die Felddaten, gesammelt auf echten Besuchen, sind die, die zählen. Sie sind im entsprechenden Bericht der Search Console zugänglich und weichen oft deutlich von den Laborergebnissen ab.
Drei Gründe für diese Abweichung: Ihre Besucher haben unterschiedliche Geräte und Verbindungen, sie landen auf anderen Seiten als der, die Sie testen, und ein Teil von ihnen surft mit bereits warmem Cache.
Die Methode: im Labor diagnostizieren, im Feld entscheiden. Ein Problem, das im Test sichtbar ist, aber in den echten Daten fehlt, hat keine Priorität.
Baustelle 1: das Hauptbild der Produktseite
Es ist fast immer das Element, das Ihre wichtigste Ladekennzahl bestimmt, und es ist die rentabelste Baustelle.
Vier Maßnahmen, nach Wirkung geordnet.
Nicht verzögert laden. Das beim Eintreffen sichtbare Bild muss sofort geladen werden. Lazy Loading, das unterschiedslos auf alle Bilder angewandt wird, verzögert genau das Bild, auf das es ankommt.
Vorladen, indem Sie dem Browser signalisieren, dass es Priorität hat. So startet es noch vor der vollständigen Analyse der Seite.
Die richtige Größe ausliefern. Ein 2000-Pixel-Bild, das mit 600 angezeigt wird, verschwendet mehrere hundert Kilobyte. Responsive Formate erledigen den Fall.
Ein modernes Format verwenden, das das Gewicht bei gleicher wahrgenommener Qualität um 30 bis 50% senkt.
Diese vier Maßnahmen sind an einem Tag erledigt und bringen in der Regel den sichtbarsten Gewinn der gesamten Performance-Arbeit.
Baustelle 2: die visuelle Stabilität
Die zweite Baustelle nach Rentabilität, weil die Ursachen wenige und leicht zu identifizieren sind.
Fünf Quellen von Layoutverschiebungen in einem Shop.
Bilder ohne deklarierte Abmessungen. Der Browser reserviert den Platz nicht, und der Inhalt springt, wenn das Bild eintrifft. Breite und Höhe zu deklarieren genügt.
Nach dem Laden eingefügte Banner: Cookies, Aktionen, Ankündigungen. Reservieren Sie ihren Platz oder zeigen Sie sie als Overlay.
Individuelle Schriften. Der Text erscheint zuerst in einer Ersatzschrift und wechselt dann, was das Layout verschiebt. Vorladen und eine passende Anzeigeeinstellung begrenzen den Effekt.
Asynchron geladene Modulblöcke: Bewertungen, ähnliche Produkte, Chat. Jeder schiebt den nachfolgenden Inhalt.
Werbung und Dritteinbindungen, deren Höhe variiert.
Diagnosemethode: Öffnen Sie eine Produktseite mit den Entwicklertools, aktivieren Sie den Layout-Shift-Indikator und laden Sie neu. Die beweglichen Zonen erscheinen sofort.
Page-Cache & Performance-Optimierung für PrestaShop 8 & 9Seiten-Cache, Critical CSS und fortgeschrittene Optimierung für PrestaShop 8 und 9.149,00€
Baustelle 3: die Reaktivität auf Interaktionen
Die neueste Kennzahl und die am schlechtesten behandelte in Shops, weil ihre Ursachen weniger offensichtlich sind.
Sie misst die Zeit zwischen einer Besucheraktion und der sichtbaren Antwort. In einem Shop konzentrieren drei Interaktionen die Probleme.
Die Facettenfilter, wenn die Verarbeitung der Auswahl den Ausführungsstrang blockiert, noch bevor die Netzwerkanfrage startet.
Der Warenkorb-Klick, wenn er mehrere synchrone Verarbeitungen auslöst, bevor das visuelle Feedback kommt.
Das Öffnen des Menüs auf Mobilgeräten, wenn das Menü erst beim Klick statt beim Laden aufgebaut wird.
Drei Korrekturen, ohne Umbau anwendbar.
Sofortiges visuelles Feedback geben, vor der Verarbeitung. Ein Button, der schon beim Klick den Zustand wechselt, verbessert die Kennzahl, auch wenn die Verarbeitung gleich lange dauert.
Lange Aufgaben aufteilen, um dem Browser zwischen zwei Schritten die Kontrolle zurückzugeben.
Den beim Klick ausgeführten Code reduzieren, insbesondere Drittskripte, die an denselben Ereignissen hängen.
Baustelle 4: die Server-Antwortzeit
Sie bedingt alle anderen Kennzahlen: Nichts kann angezeigt werden, bevor der Server geantwortet hat.
Drei Hebel, nach Wirkung auf PrestaShop geordnet.
Der vollständige Seitencache. Er verwandelt eine dynamische Generierung in das Ausliefern einer fertigen Datei. Das ist der größte Gewinn auf Kategorie- und Produktseiten.
Der Anwendungscache auf den Katalogdaten, der vermeidet, neu zu berechnen, was sich nicht geändert hat.
Die Optimierung der langsamsten Abfragen, identifiziert im Datenbanklog.
Zwei Vorsichtsmaßnahmen beim Seitencache. Er muss bei Preis- und Bestandsänderungen korrekt invalidiert werden, sonst zeigt er falsche Informationen an. Und er muss personalisierte Seiten ausschließen: Warenkorb, Konto, Checkout.
Ein oft übersehener Punkt: Der Cache bedient nur Besucher, die nach dem ersten kommen. Bei einem Katalog von zehntausend Seiten mit mäßigem Traffic bleibt ein großer Teil der Besuche ungecacht. Das Vorwärmen des Caches auf den meistbesuchten Seiten behandelt diesen Punkt.
Baustelle 5: die Drittskripte
Die undankbarste und oft rentabelste Baustelle.
Ein durchschnittlicher Shop lädt zwischen acht und zwanzig externe Skripte: Analytics, Werbung, Chat, Bewertungen, Cookies, Karten. Jedes wurde aus gutem Grund hinzugefügt, und keines wurde je entfernt.
Drei Maßnahmen.
Inventarisieren. Listen Sie die auf einer Produktseite geladenen Skripte mit Gewicht und Ausführungszeit auf. Die Entwicklertools liefern das in wenigen Minuten.
Entfernen, was nicht mehr dient. Sie finden fast immer ein aufgegebenes Analysetool oder ein Pixel einer beendeten Kampagne.
Verzögern, was bleibt. Ein Chat, ein Bewertungstool oder eine sekundäre Messung müssen nicht vor der Anzeige des Inhalts laden.
Fügen Sie einen Governance-Punkt hinzu: Machen Sie Werbeskripte von der Einwilligung abhängig, was ohnehin Pflicht ist und den Nebeneffekt hat, die Seite für Ablehnende zu erleichtern.
Was nichts bringt
Vier häufige Empfehlungen, deren Effekt in einem Shop null oder marginal ist.
HTML minifizieren. Der Gewinn zählt in Kilobyte, unsichtbar gegenüber dem Gewicht der Bilder.
Die Zahl der Requests um jeden Preis senken. Diese Empfehlung stammt aus der Zeit alter Protokolle. Bei den aktuellen Protokollen macht das Multiplexing die Request-Zahl weit weniger entscheidend.
Alle individuellen Schriften entfernen. Eine gut geladene Schrift kostet wenig und dient Ihrer Identität. Das Problem ist die Lademethode, nicht die Schrift.
Hundert von hundert anstreben in einem Audit-Tool. Der Score ist nicht das Ziel, die Feldschwellen sind es.
Reihenfolge und Rhythmus
Eine Sequenz über drei Monate.
Woche 1: Erhebung der Felddaten pro Seitentyp, um zu wissen, wo Sie wirklich stehen.
Wochen 2 und 3: Baustellen 1 und 2, Hauptbild und visuelle Stabilität. Sie sind die schnellsten und sichtbarsten.
Wochen 4 bis 6: Baustelle 4, Server-Cache, der Tests und eine sorgfältige Invalidierung verlangt.
Wochen 7 und 8: Baustelle 5, Inventar und Bereinigung der Drittskripte.
Danach: Baustelle 3, Reaktivität, die technischste, deren Effekt sich über die Zeit misst.
Ein Methodenpunkt: Die Felddaten stützen sich auf ein gleitendes Fenster von mehreren Wochen. Ziehen Sie frühestens einen Monat nach einer Änderung Schlüsse.
Das Modul Seitencache und Geschwindigkeitsoptimierung für PrestaShop deckt die vierte Baustelle auf PrestaShop 8 und 9 ab: vollständiger Seitencache mit Invalidierung bei Preis- und Bestandsänderungen, automatischer Ausschluss personalisierter Seiten, Vorwärmen der meistbesuchten Seiten und verzögertes Laden nicht kritischer Skripte.
