Google Lighthouse Audit für PrestaShop: Jede Bewertung richtig interpretieren

Was Google Lighthouse misst

Google Lighthouse ist ein automatisiertes Audit-Tool, das in die Chrome DevTools integriert ist und Webseiten in vier Hauptkategorien bewertet: Performance, Barrierefreiheit, Best Practices und SEO. Jede Kategorie erzeugt eine Bewertung von 0 bis 100, und jede Bewertung wird aus spezifischen Metriken und Prüfungen berechnet, die unterschiedliche Gewichtungen haben. Zu verstehen, was diese Bewertungen tatsächlich für einen PrestaShop-Shop bedeuten und welche realistischen Ziele erreichbar sind, ist wesentlich, bevor Sie Zeit in die Optimierung investieren.

Lighthouse läuft in zwei Umgebungen. Labordaten stammen aus einer simulierten Umgebung mit kontrollierter Netzwerkdrosselung und CPU-Verlangsamung. Felddaten stammen von echten Benutzern über den Chrome User Experience Report (CrUX). Die Bewertungen, die Sie beim Ausführen von Lighthouse in den Chrome DevTools sehen, sind Labordaten. Die Bewertungen, die Google für Ranking-Zwecke verwendet (Core Web Vitals), stammen aus Felddaten. Diese Unterscheidung ist wichtig, da Labor- und Feldergebnisse oft erheblich voneinander abweichen und die Optimierung für das eine nicht immer das andere verbessert.

Für PrestaShop-Shops ist Lighthouse besonders aufschlussreich, da die Standardkonfiguration von PrestaShop und die meisten Themes nicht für moderne Performance-Standards optimiert sind. Ein typischer nicht optimierter PrestaShop-Shop erzielt zwischen 15 und 40 bei der Performance, 60 bis 80 bei der Barrierefreiheit, 70 bis 85 bei Best Practices und 75 bis 90 bei SEO. Diese Ausgangswerte zeigen Ihnen, wo die größten Verbesserungsmöglichkeiten liegen.

Performance-Bewertung: Die komplexeste Kategorie

Die Performance-Bewertung ist ein gewichtetes Gesamtergebnis aus sechs Metriken. Jede Metrik erfasst einen anderen Aspekt davon, wie schnell die Seite lädt und interaktiv wird. Das Verständnis der einzelnen Metriken ist weitaus nützlicher als die Fokussierung auf die Gesamtzahl.

Largest Contentful Paint (LCP)

LCP misst, wann das größte sichtbare Inhaltselement fertig gerendert ist. Auf einer PrestaShop-Produktseite ist dies normalerweise das Hauptproduktbild. Auf einer Kategorieseite könnte es das erste Produktbild oder ein Kategorie-Banner sein. Google betrachtet LCP als gut, wenn er unter 2,5 Sekunden liegt, als verbesserungswürdig zwischen 2,5 und 4 Sekunden und als schlecht über 4 Sekunden.

PrestaShop-spezifische LCP-Probleme umfassen übergroße Produktbilder, die ohne ordnungsgemäße responsive Größenanpassung ausgeliefert werden, render-blockierendes CSS von Modulen, die auf jeder Seite laden, Server-Antwortzeiten, die durch nicht optimierte Datenbankabfragen verlangsamt werden (besonders auf Kategorieseiten mit vielen Produkten), und JavaScript von Drittanbieter-Modulen, das die Rendering-Pipeline verzögert.

Um den LCP in PrestaShop zu verbessern, beginnen Sie mit der Bildoptimierung. Stellen Sie sicher, dass Produktbilder für jeden Kontext richtig dimensioniert sind (liefern Sie kein 2000x2000-Bild, wenn der Anzeigebereich 400x400 ist). Aktivieren Sie Lazy Loading für Bilder unterhalb des sichtbaren Bereichs, aber stellen Sie sicher, dass das LCP-Bild NICHT lazy geladen wird, da dies sein Rendering verzögert. Implementieren Sie Preload-Hinweise für das LCP-Bild mit einem <link rel="preload">-Tag im Seitenkopf. Serverseitig aktivieren Sie OPcache, konfigurieren Sie MySQL-Query-Caching und stellen Sie sicher, dass Ihr Hosting über ausreichende Ressourcen verfügt.

Cumulative Layout Shift (CLS)

CLS misst die visuelle Stabilität. Jedes Mal, wenn ein sichtbares Element seine Position nach dem ersten Rendern ändert, trägt es zur CLS-Bewertung bei. Google betrachtet CLS als gut, wenn er unter 0,1 liegt, als verbesserungswürdig zwischen 0,1 und 0,25 und als schlecht über 0,25.

PrestaShop-Shops leiden häufig unter CLS, verursacht durch Bilder, die ohne definierte Abmessungen laden (der Browser weiß nicht, wie viel Platz reserviert werden soll, sodass der Inhalt springt, wenn das Bild lädt), Web-Schriftarten, die laden und Text zum Neuanordnen bringen (FOUT, Flash of Unstyled Text), dynamisch eingefügte Banner oder Benachrichtigungsleisten von Modulen, Cookie-Consent-Banner, die den Seiteninhalt nach unten drücken, und lazy-geladene Produktbilder in Rastern, die umliegende Produkte verschieben, wenn sie erscheinen.

Die Behebung von CLS in PrestaShop erfordert das Setzen expliziter Breiten- und Höhenattribute auf allen Bildern (oder die Verwendung von CSS aspect-ratio), das Vorladen kritischer Web-Schriftarten mit font-display: swap oder font-display: optional, das Reservieren von Platz für dynamische Elemente wie Cookie-Banner mittels CSS min-height und das Sicherstellen, dass Werbe- oder Promotions-Module Inhalte einfügen, ohne bestehende Elemente zu verschieben.

First Contentful Paint (FCP)

FCP misst, wann das erste Inhaltselement auf dem Bildschirm erscheint. Dies kann Text, ein Bild, ein SVG oder ein Canvas-Element sein. Bei PrestaShop wird FCP stark von der Serverantwortzeit (Time to First Byte) und der Menge an render-blockierenden Ressourcen (CSS und JavaScript) beeinflusst, die heruntergeladen werden müssen, bevor der Browser etwas anzeigen kann.

Die Standardkonfiguration von PrestaShop lädt eine erhebliche Menge an CSS und JavaScript synchron im Head jeder Seite. Jedes installierte Modul kann eigene CSS- und JavaScript-Dateien hinzufügen. Ein Shop mit 30 Modulen könnte 15 bis 25 separate CSS-Dateien und 20 bis 30 JavaScript-Dateien laden, bevor irgendein Inhalt erscheint. Dies erhöht direkt den FCP.

Total Blocking Time (TBT)

TBT misst die Gesamtzeit zwischen FCP und Time to Interactive, in der der Haupt-Thread lang genug blockiert war, um die Eingabereaktion zu verhindern. Jede Aufgabe, die länger als 50 Millisekunden dauert, zählt mit ihrer überschüssigen Zeit zum TBT. Beispielsweise trägt eine 200-Millisekunden-Aufgabe 150 Millisekunden zum TBT bei.

PrestaShop-Shops sind berüchtigt für hohe TBT-Werte. Häufige Verursacher sind jQuery und seine Plugins, die synchron ausgeführt werden, Modul-JavaScript, das beim Seitenladen schwere DOM-Manipulationen durchführt, Analytics- und Tracking-Code von mehreren Modulen, Produktseiten-Scripte, die gleichzeitig Slider, Zoom-Funktionalität und Kombinationsselektoren initialisieren, sowie Chat-Widgets und Social-Media-Einbettungen.

Die Reduzierung von TBT erfordert das Verschieben nicht-kritischen JavaScripts, das Aufteilen langer Aufgaben in kleinere asynchrone Blöcke, das Entfernen ungenutzten Modul-JavaScripts und das Laden von Drittanbieter-Widgets nach dem Zeitpunkt, an dem die Seite interaktiv wird.

Speed Index

Der Speed Index misst, wie schnell der sichtbare Bereich der Seite gefüllt wird. Er erfasst den gesamten visuellen Fortschritt des Seitenladens. Eine Seite, auf der Header, Navigation und erste Produktreihe schnell erscheinen, aber der Rest schrittweise lädt, hat einen besseren Speed Index als eine Seite, auf der alles auf einmal nach einer langen Verzögerung erscheint.

Für PrestaShop verbessert sich der Speed Index, wenn Sie das Rendering von Above-the-Fold-Inhalten priorisieren. Das bedeutet, kritisches CSS inline einzufügen (das CSS, das zum Rendern des sichtbaren Bereichs der Seite ohne Scrollen benötigt wird), Below-the-Fold-Bilder zu verschieben und JavaScript zu vermeiden, das das Rendering sichtbarer Inhalte blockiert.

Interaction to Next Paint (INP)

INP hat First Input Delay (FID) im März 2024 als Core Web Vital abgelöst. Es misst die Reaktionsfähigkeit einer Seite über ihren gesamten Lebenszyklus, nicht nur die erste Interaktion. Jeder Klick, jedes Tippen und jeder Tastendruck wird gemessen, und die schlechteste Interaktionslatenz (ungefähr) wird zum INP-Wert. Google betrachtet INP als gut unter 200 Millisekunden.

PrestaShop-Shops haben oft schlechte INP-Werte auf Produktseiten, wo das Klicken auf ein Kombinationsattribut eine synchrone AJAX-Anfrage auslöst, die die Benutzeroberfläche blockiert, auf Kategorieseiten, wo Klicks auf Facetten-Filter schwere JavaScript-Verarbeitung verursachen, und auf jeder Seite, auf der Modul-JavaScript während der Benutzerinteraktion den Haupt-Thread monopolisiert.

Barrierefreiheits-Bewertung

Die Barrierefreiheits-Bewertung bewertet, ob Ihre Seite von Menschen mit Behinderungen genutzt werden kann, einschließlich derer, die Screenreader, Tastaturnavigation oder andere Hilfstechnologien verwenden. Lighthouse prüft auf spezifische WCAG 2.1-Konformitätselemente und weist jedem eine Gewichtung basierend auf der Benutzerauswirkung zu.

Häufige PrestaShop-Barrierefreiheitsfehler

Fehlender Alt-Text bei Bildern ist das häufigste Problem. PrestaShop-Shops mit Tausenden von Produkten haben oft Produkte, die ohne Alt-Text-Beschreibungen hochgeladen wurden. Lighthouse markiert jedes Bild ohne Alt-Attribut. Die Lösung besteht darin, allen Produktbildern über das Back Office aussagekräftigen Alt-Text hinzuzufügen, was auch der SEO zugutekommt.

Unzureichender Farbkontrast ist in PrestaShop-Themes extrem verbreitet. Der Theme-Designer hat möglicherweise Farben gewählt, die visuell ansprechend aussehen, aber nicht das WCAG-Mindest-Kontrastverhältnis von 4,5:1 für normalen Text und 3:1 für großen Text erfüllen. Typische Probleme sind hellgrauer Text auf weißem Hintergrund (oft für Produktpreise, Beschreibungen oder Footer-Links verwendet), weißer Text auf farbigen Buttons, deren Farbe nicht dunkel genug ist, und Platzhaltertext in Suchfeldern.

Fehlende Formularbeschriftungen betreffen PrestaShops Suchformulare, Newsletter-Anmeldeformulare und Kontaktformulare. Viele Themes verwenden Platzhaltertext als einzigen Hinweis darauf, wofür ein Eingabefeld gedacht ist, aber Platzhalter sind keine barrierefreien Beschriftungen. Jedes Eingabefeld muss ein zugehöriges <label>-Element haben.

Fehlerhafte Überschriftenhierarchie ist häufig, wenn Themes Überschriftenebenen überspringen (von <h1> auf <h3> springen) oder wenn Module Inhalte mit Überschriftenebenen einfügen, die die Dokumentgliederung der Seite durchbrechen.

Fehlende ARIA-Attribute bei interaktiven Elementen wie Dropdown-Menüs, modalen Dialogen und Tab-Interfaces bedeuten, dass Screenreader den Zweck und Zustand dieser Elemente nicht an die Benutzer vermitteln können.

Realistische Barrierefreiheitsziele

Die meisten PrestaShop-Themes können mit Aufwand 85 bis 95 erreichen. Eine perfekte 100 ist erreichbar, erfordert aber Theme-Template-Modifikationen, die bei Updates überschrieben werden können. Konzentrieren Sie sich zuerst auf die Elemente mit der größten Wirkung: Bild-Alt-Text, Farbkontrast, Formularbeschriftungen und Tastaturnavigation für die wichtigsten Benutzerabläufe (Stöbern, In den Warenkorb legen, Checkout).

Best-Practices-Bewertung

Die Kategorie Best Practices umfasst allgemeine Signale für die Qualität der Webentwicklung: HTTPS-Nutzung, Vermeidung veralteter APIs, Fehlerfreiheit in der Konsole und Sicherheits-Header.

Häufige PrestaShop Best-Practices-Fehler

Browser-Konsolenfehler werden von Lighthouse markiert. PrestaShop-Shops haben häufig JavaScript-Fehler durch Modulkonflikte, veraltete jQuery-Funktionsaufrufe oder fehlgeschlagene AJAX-Anfragen. Jeder Konsolenfehler reduziert die Best-Practices-Bewertung. Überprüfen Sie Ihre Browser-Konsole auf jedem Seitentyp (Startseite, Kategorie, Produkt, Warenkorb, Checkout) und beheben oder unterdrücken Sie die Fehler.

Fehlende Sicherheits-Header reduzieren die Bewertung. PrestaShop setzt standardmäßig keine Header wie Content-Security-Policy, X-Content-Type-Options, Permissions-Policy oder Referrer-Policy. Das Hinzufügen dieser über Ihre .htaccess oder Webserver-Konfiguration verbessert die Best-Practices-Bewertung und die Sicherheitslage Ihrer Website.

Veraltete APIs lösen Warnungen aus, wenn ältere PrestaShop-Themes oder -Module JavaScript-APIs verwenden, die Browser als veraltet eingestuft haben. Häufige Beispiele sind document.write(), synchrone XMLHttpRequest und der unload-Event-Listener. Diese finden sich typischerweise in älteren Modulen, die nicht für moderne Browser-Standards aktualisiert wurden.

Mixed Content (Laden von HTTP-Ressourcen auf einer HTTPS-Seite) wird schwerwiegend markiert. Dies passiert, wenn Modul-Assets, externe Schriftarten oder Tracking-Pixel HTTP-URLs verwenden. Stellen Sie sicher, dass alle Ressourcen über HTTPS geladen werden.

Bilder ohne explizite Breite und Höhe (was auch CLS unter Performance beeinflusst) werden hier ebenfalls markiert. PrestaShop-Themes, die CSS-only-Dimensionierung für Bilder verwenden, ohne HTML-Attribute zu setzen, lösen diese Prüfung aus.

Realistische Best-Practices-Ziele

Ein gut gewarteter PrestaShop-Shop sollte 90 bis 100 anstreben. Die meisten Best-Practices-Probleme sind unkompliziert über Serverkonfiguration und Modul-Bereinigung zu beheben.

SEO-Bewertung

Das SEO-Audit prüft grundlegende technische SEO-Anforderungen. Dies ist die einfachste Kategorie, um gut abzuschneiden, da die Prüfungen unkompliziert sind und PrestaShop viele davon standardmäßig erfüllt.

Was Lighthouse bei SEO prüft

Das Audit überprüft, ob die Seite ein gültiges <title>-Tag hat, eine Meta-Beschreibung, ein gültiges Viewport-Meta-Tag, ob Links beschreibenden Text haben (nicht nur "hier klicken"), ob die Seite nicht von der Indexierung blockiert ist, ob Bilder Alt-Attribute haben, ob das Dokument ein gültiges hreflang-Attribut hat, wenn es mehrere Sprachen bedient, ob die Schriftgröße auf Mobilgeräten lesbar ist und ob Tap-Targets (Buttons, Links) ausreichend groß und beabstandet sind.

Häufige PrestaShop-SEO-Fehler

Fehlende oder doppelte Meta-Beschreibungen sind häufig bei Kategorieseiten, besonders bei automatisch generierten. PrestaShop ermöglicht es Ihnen, Meta-Beschreibungen pro Kategorie und pro Produkt festzulegen, aber viele Shopbetreiber lassen diese Felder während des Massenimports von Produkten leer.

Nicht-beschreibender Linktext erscheint, wenn Themes generischen Text wie "Mehr lesen" oder "Details" für Produktlinks verwenden, ohne zusätzlichen Kontext. Screenreader und Lighthouse markieren diese gleichermaßen.

Kleine Tap-Targets betreffen mobile Benutzer. PrestaShop-Themes mit kompakten Produktrastern auf Mobilgeräten können Links und Buttons haben, die zu nah beieinander oder zu klein sind. Google empfiehlt ein minimales Touch-Target von 48x48 CSS-Pixeln mit mindestens 8 Pixeln Abstand zwischen benachbarten Zielen.

Blockierte Ressourcen können dazu führen, dass Lighthouse meldet, dass JavaScript- oder CSS-Dateien nicht zugänglich sind. Dies passiert, wenn robots.txt den Zugriff auf Asset-Verzeichnisse blockiert. PrestaShops Standard-robots.txt blockiert manchmal Verzeichnisse, die CSS- oder JavaScript-Dateien enthalten, die für das Rendering durch Suchmaschinen benötigt werden.

Realistische SEO-Ziele

Ein PrestaShop-Shop sollte 90 bis 100 beim SEO-Audit anstreben. Die meisten Punkte sind einfache Konfigurationsanpassungen. Die eine anhaltende Herausforderung ist Bild-Alt-Text bei Shops mit großen Katalogen und historischen Importen, bei denen Alt-Text übersprungen wurde.

Labordaten vs. Felddaten

Das Verständnis des Unterschieds zwischen Labor- und Felddaten ist entscheidend für die korrekte Interpretation von Lighthouse-Ergebnissen und die Priorisierung Ihrer Optimierungsarbeit.

Labordaten (Lighthouse)

Wenn Sie Lighthouse aus den Chrome DevTools oder der Kommandozeile ausführen, erstellt es eine simulierte Umgebung. Es drosselt die Netzwerkverbindung (typischerweise auf eine langsame 4G-Geschwindigkeit von etwa 1,6 Mbit/s mit 150 ms Latenz) und verlangsamt die CPU (typischerweise 4-fache Verlangsamung). Diese simulierte Umgebung liefert konsistente, reproduzierbare Ergebnisse, spiegelt aber nicht die Erfahrung eines bestimmten realen Benutzers wider.

Labordaten sind nützlich zum Debuggen spezifischer Probleme, zum Vergleichen von Vor- und Nach-Optimierungsänderungen und zur Identifizierung spezifischer Engpässe im Ladeprozess. Die Bewertungen sollten jedoch nicht als repräsentativ für die reale Benutzererfahrung betrachtet werden.

Felddaten (CrUX)

Der Chrome User Experience Report (CrUX) sammelt echte Performance-Daten von Chrome-Benutzern, die dem Teilen von Nutzungsstatistiken zugestimmt haben. Diese Daten werden am 75. Perzentil aggregiert, was bedeutet, dass der gemeldete Wert die Erfahrung von 75 Prozent Ihrer Benutzer repräsentiert, die bei oder besser als diesem Schwellenwert liegen.

Felddaten sind das, was Google tatsächlich als Ranking-Signale über die Core Web Vitals verwendet. Sie können Ihre Felddaten in der Google Search Console unter dem Core Web Vitals-Bericht einsehen, in PageSpeed Insights (das sowohl Labor- als auch Felddaten zeigt) und über die CrUX-API oder den BigQuery-Datensatz.

Warum sich die Bewertungen unterscheiden

Laborbewertungen sind typischerweise niedriger als Feldbewertungen für PrestaShop-Shops, da Lighthouse aggressive Drosselung verwendet. Ein Shop auf einem schnellen Server mit CDN könnte im Lighthouse-Labormodus 35 erzielen, aber perfekt akzeptable Feldmetriken haben, weil echte Benutzer mit ordentlichen Verbindungen den Shop viel schneller erleben als die simulierte langsame 4G-Umgebung. Umgekehrt können Shops mit Problemen, die nur unter realen Bedingungen auftreten (JavaScript-Fehler bestimmter Browser-Versionen, Verlangsamung durch Drittanbieter-Widgets oder geografische Latenz zu Benutzern weit vom Server entfernt), bessere Laborbewertungen als Feldbewertungen haben.

Was priorisieren

Für Google-Ranking-Zwecke priorisieren Sie Felddaten und Core Web Vitals (LCP, INP, CLS). Für Entwickler-Debugging und Optimierungsarbeit verwenden Sie Labordaten, da sie konsistent sind und detaillierte Diagnoseinformationen liefern. Wenn Ihre Felddaten bestandene Core Web Vitals zeigen, aber Ihre Labor-Performance-Bewertung 40 ist, geht es Ihren Benutzern gut und Google wird Sie nicht benachteiligen. Wenn Ihre Laborbewertung 90 ist, aber Felddaten fehlgeschlagene Core Web Vitals zeigen, haben Sie ein Problem, das Lab-Tests nicht erfassen.

Realistische Bewertungsziele für PrestaShop

Das Setzen realistischer Ziele verhindert verschwendeten Aufwand bei der Jagd nach abnehmendem Grenznutzen. Hier sind erreichbare Ziele für einen typischen PrestaShop 1.7 oder 8.x Shop.

Performance: 50 bis 75 (Mobil), 80 bis 95 (Desktop)

Mobile Performance-Bewertungen über 75 sind für PrestaShop-Shops mit reichhaltigen Produktseiten, mehreren Modulen und dynamischen Inhalten extrem schwierig. Die gedrosselte mobile Simulation ist streng. Eine Bewertung von 50 bis 65 auf Mobilgeräten mit bestandenen Core Web Vitals in Felddaten ist ein gutes Ergebnis. Desktop-Bewertungen von 85 bis 95 sind mit Standard-Optimierungen erreichbar.

Jagen Sie nicht einer mobilen Performance-Bewertung von 100 nach. Der Aufwand, um von 70 auf 100 auf Mobilgeräten zu kommen, erfordert typischerweise das Entfernen von Funktionen, die Ihr Shop benötigt (Produktbild-Zoom, dynamische Warenkorb-Updates, Kombinationsselektoren). Konzentrieren Sie sich stattdessen darauf, die Core Web Vitals-Schwellenwerte in Felddaten zu bestehen.

Barrierefreiheit: 85 bis 95

Dieser Bereich ist mit Theme-Template-Korrekturen und inhaltlicher Disziplin erreichbar. Der hauptsächliche laufende Aufwand besteht darin sicherzustellen, dass alle neuen Produkte Alt-Text haben und dass neue Module keine Rückschritte bei der Barrierefreiheit einführen.

Best Practices: 90 bis 100

Erreichbar mit Serverkonfiguration, Bereinigung von Konsolenfehlern und aktuell gehaltenen Modulen. Diese Bewertung tendiert dazu, im Laufe der Zeit zu sinken, wenn neue Module hinzugefügt werden, daher hilft regelmäßige Überwachung.

SEO: 90 bis 100

Am einfachsten zu erreichen und zu halten. Die meisten Punkte sind einmalige Konfigurationsanpassungen.

Handlungsorientierte Verbesserungs-Checkliste

Diese Checkliste priorisiert Optimierungen nach Wirkung, beginnend mit den Änderungen, die die größten Bewertungsverbesserungen bei geringstem Aufwand erzielen.

Hohe Wirkung, geringer Aufwand

Aktivieren Sie PrestaShops CCC-Funktion (Combine, Compress, Cache) unter den Performance-Einstellungen, um CSS- und JavaScript-Dateien zusammenzuführen und zu minifizieren. Fügen Sie Breiten- und Höhenattribute zu allen Bildern in Theme-Templates hinzu. Setzen Sie explizite Abmessungen für Produktbilder. Aktivieren Sie Browser-Caching durch ordnungsgemäße Cache-Header in Ihrer Serverkonfiguration. Komprimieren Sie Textressourcen mit Gzip oder Brotli. Entfernen oder deaktivieren Sie Module, die Sie nicht aktiv nutzen. Fügen Sie Sicherheits-Header zu Ihrer Serverkonfiguration hinzu.

Hohe Wirkung, mittlerer Aufwand

Implementieren Sie kritisches CSS-Inlining für Above-the-Fold-Inhalte. Verschieben Sie nicht-kritisches JavaScript mit dem Attribut defer oder async. Optimieren und dimensionieren Sie Produktbilder richtig (liefern Sie verschiedene Größen für verschiedene Kontexte mittels srcset). Laden Sie kritische Ressourcen vor (LCP-Bild, primäre Schriftdateien). Beheben Sie alle Browser-Konsolenfehler. Fügen Sie fehlenden Alt-Text zu allen Produkt- und Kategoriebildern hinzu.

Mittlere Wirkung, höherer Aufwand

Implementieren Sie ein CDN für statische Assets und Bilder. Wechseln Sie zu einem performance-orientierteren PrestaShop-Theme, wenn Ihr aktuelles Theme grundlegend langsam ist. Optimieren Sie die serverseitige Leistung (Datenbankindizes, OPcache, Redis für Caching). Implementieren Sie WebP-Bildauslieferung mit JPEG-Fallback. Auditieren und optimieren Sie Drittanbieter-Modul-JavaScript hinsichtlich der Blockierung des Haupt-Threads.

Überwachung über die Zeit

Ein einmaliges Lighthouse-Audit ist weniger wertvoll als regelmäßige Überwachung. Bewertungen ändern sich, wenn Sie Produkte hinzufügen, Module installieren, Themes aktualisieren und Konfigurationen ändern. Richten Sie automatisierte Lighthouse-Tests ein mit Tools wie Google PageSpeed Insights API, web.dev Measure oder selbst gehostetem Lighthouse CI. Führen Sie Tests mindestens wöchentlich und nach jeder signifikanten Shop-Änderung durch.

Verfolgen Sie sowohl die Gesamtbewertungen als auch die einzelnen Metriken. Ein Rückgang der Performance-Bewertung von 65 auf 55 ist besorgniserregend, aber zu wissen, dass er durch eine CLS-Regression eines neu installierten Banner-Moduls verursacht wurde, ist handlungsfähig. Ohne Tracking auf Metrikebene raten Sie bei den Ursachen.

Achten Sie besonders auf Core Web Vitals in der Google Search Console. Google aktualisiert diese Daten monatlich, und jede Verschlechterung von "Gut" auf "Verbesserungswürdig" oder "Schlecht" kann Ihre Suchrankings beeinflussen. Richten Sie Warnungen für Core-Web-Vitals-Änderungen ein, damit Sie reagieren können, bevor die Auswirkung in den Traffic-Daten sichtbar wird.