PrestaShop-Bilder: Formate, Beschriftungen, Lazy Loading und Reparatur
PrestaShop: Formate und GD-Unterstützung prüfen, Alt-Texte korrigieren, Vorschaubilder neu erzeugen, fehlende Bilder reparieren und Lazy Loading prüfen.
Verwenden Sie passend dimensionierte Dateien, hilfreiche Bildbeschreibungen und ein für das jeweilige Bild geeignetes Ladeverhalten. Prüfen Sie erzeugte Dateien und ausgegebenes HTML, bevor Sie Leistung oder Ergebnisse der Bildersuche beurteilen.
So würden wir vorgehen
Wir würden eine langsame Seite messen, bevor wir einen Konverter auswählen oder jeden Bildtyp ändern. Der passende Weg hängt von Ihrer installierten PrestaShop-Version, dem PHP-Build, Theme, vorhandenen Bild- und Cache-Modulen, CDN, Katalogoriginalen und Importintegrationen ab. Prüfen Sie, welche Sprachen und Märkte Beschreibungen benötigen und wer diese bei Produktänderungen pflegt.
Nutzen Sie für Änderungen an Erzeugung oder Templates eine Staging-Kopie mit eigenen Bilddateien und isolierten Live-Integrationen. Erproben Sie die Änderung an repräsentativen Produkten, einschließlich Zoom, Kombinationen und mobilen Layouts. Halten Sie bisherige Templates, Einstellungen und erzeugte Dateien bereit. Planen Sie anschließend die Umstellung im Live-Shop mit einer benannten Person zur Ausgabekontrolle und einem getesteten Rückweg. Eine Kopie, die den Bildspeicher mit dem Live-Shop teilt, eignet sich nicht für sichere Lösch- oder Neuerzeugungstests.
Wenn Sie den Engpass untersuchen lassen möchten, liefert das PrestaShop Speed & Core Web Vitals Audit einen auf Messungen basierenden, priorisierten Maßnahmenplan. Die Umsetzung wird separat vereinbart.
Die erste Korrektur anhand der Befunde wählen
| Ihr Befund | Hier beginnen | Nachweis vor weiteren Änderungen |
|---|---|---|
| Der Browser lädt für eine kleine Listenkarte eine große Datei herunter. | Ausgewählten Bildtyp oder responsive Quellenauswahl korrigieren. | Die gewählte Datei passt zu Anzeigebereich und Pixeldichte, ohne sichtbare Details zu verlieren. |
| Das Hauptfoto wird erst spät heruntergeladen. | Auffindbarkeit, loading-Attribut und mögliche Slider-Skripte prüfen. | Die anfängliche Bild-URL ist früh verfügbar, ohne auf Scrollen oder die Initialisierung der Galerie zu warten. |
| Ein Format ist aktiviert, aber der Browser erhält weiterhin die alte Datei. | Erzeugung, Template-URLs und Auslieferung aus dem Cache getrennt verfolgen. | Erzeugtes Muster und tatsächliche Antwort stimmen beim ausgelieferten Format überein. |
| Fotos erscheinen, aber ihre Beschreibungen wiederholen sich oder beschreiben die falsche Variante. | Bildbeschriftungen, Katalogdaten und Ausgabe des aktiven Themes prüfen. | Der ausgegebene Text beschreibt das Bild in der gewählten Sprache. |
| Bilder fehlen nach einem Umzug. | Vor Format- oder Qualitätsänderungen die folgenden Reparaturprüfungen durchführen. | Originale, URLs, Rewrites und Zugriffe sind vor der Neuerzeugung korrekt. |
Bildtypen und tatsächliche Downloads prüfen
Öffnen Sie Design > Bildeinstellungen. Ältere PrestaShop-1.6-Installationen verwenden Voreinstellungen > Bilder. Bildtypen definieren erzeugte Größen für Themes und Module; ihre Namen garantieren keine identischen Abmessungen in verschiedenen Shops.
Öffnen Sie eine Startseite, eine umfangreiche Kategorie und eine Produktgalerie im Browser. Ermitteln Sie die größten Downloads, tatsächliche Anzeigegröße, intrinsische Abmessungen, ausgewählte Quelle und das wahrscheinliche LCP-Bild. Bilder können eine Seite dominieren; setzen Sie aber keinen festen Anteil am Übertragungsvolumen voraus.
Ein 1200 px breites Bild in einem 300 px breiten CSS-Bereich hat die vierfache Breite, nicht zwingend die vierfache Bytezahl. Bei gleichem Seitenverhältnis hat es die sechzehnfache Pixelfläche. Auch das Gerätepixelverhältnis zählt: Ein Bereich mit 300 CSS-Pixeln auf einem 2x-Display kann etwa 600 Quellpixel nutzen. Vergleichen Sie codierte Dateigrößen und sichtbare Qualität.
- Bewahren Sie Originale groß genug für die größte Galerie- oder Zoomansicht auf, ohne unnötige Megapixel.
- Prüfen Sie Warenkorb-, Listen-, Galerie-, Kategorie- und Bannertypen anhand ihrer tatsächlichen Anzeigebereiche.
- Erzeugen Sie einen echten größeren Typ, wenn Zoom oder hochauflösende Displays ihn benötigen.
- Bewahren Sie vor destruktiver Neuerzeugung oder Größenänderung eine Originalsicherung auf.
Komprimieren und kontrollieren Sie Fotos und transparente Grafiken getrennt visuell. Werkzeuge wie Squoosh helfen beim Ergebnisvergleich, aber kein fester Qualitätswert passt zu jedem Bild. Komprimieren Sie das einzige Original nicht wiederholt neu.
Beispiel: zu große Bilder in mobilen Listen
Angenommen, eine Produktkarte für eine Brieftasche belegt auf einem 2x-Display 300 CSS-Pixel, die Netzwerkwerkzeuge zeigen aber eine Quelle mit 1200 px. Vergleichen Sie eine echte 600-px-Kopie mit der aktuellen Datei bei gleichem Zuschnitt. Sieht diese Kopie gut aus, ergänzen Sie sie als Quellkandidaten und prüfen Sie die ausgewählte Quelle nach einem erneuten Seitenaufruf. Wählt der Browser weiterhin die größere Datei, vergleichen Sie sizes mit dem tatsächlichen Kartenlayout, bevor Sie die Komprimierungsqualität senken. Prüfen Sie Desktop und Zoom getrennt, damit die Listenkorrektur keine Galeriedetails reduziert.
Formatunterstützung und Auslieferung prüfen
PrestaShop 1.7.8 bietet nicht den aktuellen nativen Ablauf zur WebP-/AVIF-Erzeugung. PrestaShop 8.0 ergänzte WebP-Erzeugung. PrestaShop 8.1 führte AVIF und Mehrformaterzeugung experimentell ein; AVIF wurde nicht erst mit PrestaShop 9 eingeführt. Siehe die Ankündigung von 8.1.
Prüfen Sie bei unterstützten Versionen Erzeugungsformate und Qualität unter Bildeinstellungen. Die native Codierung in ImageManager von PrestaShop 9.1 ruft GDs imagewebp() und imageavif() auf. Imagick-Unterstützung allein erfüllt diesen Codepfad nicht. Prüfen Sie die PHP-Laufzeit, die die tatsächliche Neuerzeugung ausführt:
php -r '$gd = extension_loaded("gd") ? gd_info() : [];
var_export([
"gd" => extension_loaded("gd"),
"webp" => function_exists("imagewebp")
&& !empty($gd["WebP Support"]),
"avif" => function_exists("imageavif")
&& !empty($gd["AVIF Support"])
]); echo PHP_EOL;'
Prüfen Sie neben den Encoderfunktionen auch die GD-Formatunterstützung und erzeugen und kontrollieren Sie dann ein echtes Muster. CLI und Web/FPM können unterschiedliche Konfigurationen verwenden. Prüfen Sie beide, wenn Uploads im Browser und Neuerzeugung per CLI laufen.
- Aktivieren Sie die von Ihrer genauen Version und Ihrem GD-Build unterstützten Formate.
- Erzeugen Sie eine kleine repräsentative Stichprobe und prüfen Sie Transparenz, Farbe und Details.
- Prüfen Sie ausgegebene Bild-URLs oder picture-Quellen, Antwort-Inhaltstypen und tatsächlich heruntergeladene Dateien.
- Testen Sie das Fallback-Verhalten mit dem verwendeten Auslieferungssystem.
- Erzeugen Sie vorhandene Vorschaubilder neu und leeren Sie betroffene HTML-/Bild-Cache-Ebenen.
Gehen Sie nicht davon aus, dass alle nativen Abläufe eine Formataushandlung anhand des Accept-Headers verwenden. Eine Vorlage kann ein bestimmtes Format anfordern oder picture verwenden; ein Server oder Modul kann eine andere Antwort aushandeln. Wenn Antworten nach Accept variieren, konfigurieren Sie die Cache-Variation korrekt, damit ein geteilter Cache keine falsche Darstellung ausliefert.
Performance Revolution bietet Bildkonvertierung, wenn die Encoderanforderungen erfüllt sind. Siehe die Hilfe zu Performance Revolution. Prüfen Sie erzeugte Dateien, Cache-Verhalten, Zoom, Slider und CDN-Auslieferung. Fest codierte Annahmen zu .jpg können zu fehlenden Dateien führen.
Korrekte Bildbeschriftungen und Alt-Texte schreiben
Produktbildbeschriftungen werden je Bild und Sprache in image_lang.legend gespeichert. Bearbeiten Sie sie im Bilderbereich des Produkts. Der native Presenter kann bei fehlender Beschriftung auf Produktname oder Meta-Titel zurückgreifen, und das Theme entscheidet, wie daraus ein alt-Attribut wird.
Eine leere Beschriftung bedeutet daher nicht automatisch leeren Alt-Text. Prüfen Sie das ausgegebene HTML. Allgemeine wiederholte Produktnamen lassen sich verbessern, sind aber etwas anderes als fehlende Attribute.
| Schwacher Text | Hilfreichere Beschreibung |
|---|---|
IMG_0421 | Marineblaue Lederbrieftasche, Vorderansicht mit sichtbaren Kartenfächern. |
wallet auf jedem Foto | Marineblaue Brieftasche, flach geöffnet, mit sichtbarem Geldscheinfach und Futter. |
| Keyword-Liste | Brieftasche in ihrer Geschenkbox mit Magnetverschluss. |
Beschreiben Sie, was das Bild tatsächlich zeigt und warum dies im jeweiligen Zusammenhang relevant ist. Unterscheiden Sie Ansichten, wo es hilft, lokalisieren Sie den Text und erfinden Sie keine Materialien oder Eigenschaften. Lassen Sie Beschreibungen dekorativer Bilder angemessen leer, statt jedes Bild mit Werbetext zu versehen.
Bildbeschreibungen auch in großen Katalogen hilfreich halten
Nutzen Sie Katalogdaten als Grundlage und verbessern Sie dann die Beschreibungen wichtiger Produktbilder, wenn das Foto Informationen ergänzt, die der Produktname nicht vermittelt. Ein Muster kann eine geöffnete Brieftasche nur dann zuverlässig von ihrer Geschenkbox unterscheiden, wenn die verwendeten Daten diese Information enthalten. Prüfen Sie ein Produkt mit mehreren Ansichten, ein kombinationsspezifisches Foto und jede Verkaufssprache, bevor Sie eine allgemeine Regel anwenden. Legen Sie Zuständigkeiten für importierte und neu hochgeladene Bilder fest, damit dieselben Lücken nicht erneut entstehen.
Automatic SEO Images Alt Tags erzeugt Texte bei der Darstellung aus Katalogdaten. Siehe die Hilfe zu Automatic SEO Images Alt Tags. Das standardmäßige Verhalten, nur leere Werte zu füllen, kann bereits vom Core gesetzte Ersatzbeschriftungen unverändert lassen. Prüfen Sie die tatsächliche Ausgabe, bevor Sie entscheiden, ob deren Ersatz eine Verbesserung wäre, und bewahren Sie bessere manuelle Beschreibungen.
Echte responsive Dateien ausgeben und ihren Platz reservieren
Beginnen Sie in Classic mit catalog/_partials/product-cover-thumbnails.tpl für die Galerie und catalog/_partials/miniatures/product.tpl für Listenkarten. Prüfen Sie vor Änderungen Includes und Daten des aktiven Themes. Pflegen Sie Änderungen in einem Child-Theme oder einer unterstützten Erweiterung.
Verwenden Sie unterschiedliche erzeugte Dateien und deren tatsächliche intrinsische Breiten in srcset. Führen Sie niemals dieselbe große Datei sowohl mit 600w als auch mit 1200w auf. Dieses Beispiel verwendet Presenter-Abmessungen, statt die Bedeutung der Bildtypnamen vorauszusetzen:
<img
src="{$product.default_image.bySize.large_default.url|escape:'htmlall':'UTF-8'}"
srcset="{$product.default_image.bySize.medium_default.url|escape:'htmlall':'UTF-8'} {$product.default_image.bySize.medium_default.width|intval}w,
{$product.default_image.bySize.large_default.url|escape:'htmlall':'UTF-8'} {$product.default_image.bySize.large_default.width|intval}w"
sizes="(max-width: 768px) 100vw, 600px"
width="{$product.default_image.bySize.large_default.width|intval}"
height="{$product.default_image.bySize.large_default.height|intval}"
alt="{$product.default_image.legend|escape:'htmlall':'UTF-8'}"
loading="eager"
fetchpriority="high">
Dieses Galeriebeispiel verwendet product.default_image; Listenkarten verwenden normalerweise product.cover. Nutzen Sie es nur, wenn diese beiden Typen existieren, unterschiedlich breit sind und kompatible Zuschnitte darstellen. Ersetzen Sie die beispielhaften sizes-Werte durch das tatsächliche Bereichslayout. Ergänzen Sie für eine größere Quelle einen echten erzeugten Typ mit eigener URL und Breite.
Breite und Höhe lassen den Browser ein Seitenverhältnis reservieren. Responsives CSS kann weiterhin max-width: 100% und height: auto verwenden. Ein bewusst reserviertes Seitenverhältnis ist eine weitere Möglichkeit. Prüfen Sie gezielte Bildzuschnitte und Container, damit die reservierte Form der Anzeige entspricht.
fetchpriority="high" kann die relative Abrufpriorität eines Bilds erhöhen. Es garantiert keinen Download vor jedem Stylesheet oder Skript. Reservieren Sie es für das wahrscheinlich kritische Bild, statt eine ganze Liste hoch zu priorisieren. Siehe die Referenz zum Bildelement.
Lazy Loading nach Sichtbarkeit einsetzen
Das native loading="lazy" an einem Bild erlaubt dem Browser, eine Ressource außerhalb des sichtbaren Bereichs später zu laden. Den Abstandsschwellenwert legt der Browser fest. Es funktioniert mit responsiven Bildern und dynamisch eingefügten img-Elementen, wenn Attribut und Quelle vorhanden sind. Eine JavaScript-Bibliothek kann für eingefügte Inhalte eine eigene Initialisierung benötigen.
- Laden Sie den anfangs sichtbaren Hero, das Logo und sichtbare Produktbilder sofort.
- Laden Sie bei Bedarf Listen-, ähnliche Produkt- und Inhaltsbilder außerhalb des sichtbaren Bereichs verzögert.
- Bestimmen Sie die sichtbare Reihe anhand des tatsächlichen Viewports und Layouts; es gibt keine für jeden Bildschirm gültige feste Anzahl.
- Erhalten Sie Bildabmessungen und eine nutzbare Quell-URL.
Das LCP-Bild sollte früh auffindbar sein. Lazy Loading kann hier sichtbare Inhalte verzögern. Weniger gleichzeitige Bilddownloads garantieren keinen besseren INP: Auch Decodierung, Darstellung und JavaScript-Arbeit müssen gemessen werden.
| Ressource | Verfügbarer Ansatz |
|---|---|
| Bilder einschließlich picture/srcset und eingefügter Bilder | Natives loading-Attribut am img-Element. |
| Iframes | Natives Lazy Loading, soweit unterstützt. Bild- und iframe-Unterstützung haben unterschiedliche Entwicklungsgeschichten. |
| CSS-Hintergründe | Kein loading-Attribut eines img-Elements; erwägen Sie ein echtes Bildelement oder eine getestete IntersectionObserver-Umsetzung. |
| Unscharfe Vorschau, Skelett- oder Farbplatzhalter | Zusätzliche Darstellungsarbeit, keine Voraussetzung für natives Lazy Loading. |
| Video und Audio | Native loading-Unterstützung ist dokumentiert, bleibt aber eingeschränkt/experimentell; prüfen Sie Browserunterstützung und bieten Sie einen Fallback. |
| Drittanbieter-Widgets | Anbieterspezifischer Aufschub, Einwilligung oder eigene Integration. |
Lazy Loading für Bilder und iframes wird je nach Browser seit unterschiedlichen Versionen unterstützt. Firefox 121 ergänzte iframe-Lazy-Loading. Prüfen Sie aktuelle Kompatibilitätstabellen für Ihre Zielbrowser; siehe die Firefox-Versionshinweise und die Browserunterstützung für das verzögerte Laden von Medien.
Beobachten Sie bei Hintergründen Elemente nahe am Viewport, setzen Sie bei Bedarf eine vertrauenswürdige Bildquelle und beenden Sie danach die Beobachtung des geladenen Elements. Verzögern Sie bei Video-Fallbacks das Anfügen der Quellen bis zum Bedarf, rufen Sie die passende Medienlademethode auf und erhalten Sie Nutzersteuerungen. Verzögern Sie keine sichtbaren Hero-Medien. Dies sind Implementierungsentscheidungen, keine Gründe für eine automatische Modulinstallation.
Gespeichertes CMS- oder Beschreibungs-HTML kann manuell eingefügte loading-Attribute enthalten, sofern der Editor diese erhält. Auch ein Editor, Inhaltsfilter oder Modul kann sie pflegen. Automatic SEO Images Lazy Tags ergänzt Produktbilddaten und filtert unterstützte HTML-Inhalte, mit einer optionalen Einstellung decoding="async". Produkttemplates müssen die bereitgestellten Schlüssel auswerten. Decodierung und Abrufzeitpunkt sind getrennt, daher ersetzt diese Einstellung keine Regel für sofortiges oder verzögertes Laden. Sie erkennt nicht automatisch jede notwendige Ausnahme für Hero-Bilder. Siehe die Hilfe zu Automatic SEO Images Lazy Tags. Prüfen Sie Attribute nach der Ausgabe und dem Leeren des Caches, bevor Sie eine Änderung der Seite durch das Modul feststellen.
Prüfen Sie vor einer weiteren Regel, ob Theme, Slider oder ein anderes Optimierungsmodul das Laden von Bildern bereits verändern. Untersuchen Sie nach Filterung, Seitenwechsel oder Variantenwechsel die neu ausgegebenen Bildattribute und beobachten Sie die angeforderten Dateien. Eine korrekte Ausgangsseite beweist nicht, dass nachgeladene Inhalte funktionieren. Prüfen Sie auch Schnellansicht und Galerievergrößerung: Ein sichtbares Vorschaubild kann eine fehlende Quelle in voller Größe verdecken.
Vorschaubilder mit einem versionsgerechten Befehl neu erzeugen
Erzeugen Sie Vorschaubilder nach Änderungen an Bildtypabmessungen, Formaten oder Theme-Anforderungen oder bei fehlenden Vorschaubildern neu. Sie benötigen intakte Originale; die Neuerzeugung kann ein nie kopiertes Original nicht wiederherstellen.
- Sichern Sie Originalbilder und relevante Einstellungen.
- Bestätigen Sie freien Speicher, PHP-/GD-Unterstützung, Dateieigentümer und ausgewählten Shop/Typ.
- Nutzen Sie Design > Bildeinstellungen > Vorschaubilder neu generieren für einen kontrollierten Test.
- Wählen Sie den benötigten Bildbereich und die Typen. Verstehen Sie die Löschoptionen, bevor Sie alte Vorschaubilder entfernen.
- Prüfen Sie neue Dateien und Shop-URLs und verarbeiten Sie dann die übrigen Bilder.
Planen Sie die Neuerzeugung im Browser nach Bildanzahl, Quellabmessungen, Formaten, Speicher und Zeitlimits. CLI vermeidet das HTTP-Anfragezeitlimit, hat aber eigene Speicher-, Rechte- und Laufzeitgrenzen.
Der Konsolenbefehl von PrestaShop 9.1 benötigt ein Argument für den Bildbereich. Aus dem Shop-Root:
php bin/console prestashop:thumbnails:regenerate --help
php bin/console prestashop:thumbnails:regenerate products
# For every supported image domain:
php bin/console prestashop:thumbnails:regenerate all
Führen Sie ihn mit der vorgesehenen PHP-Version und einem Nutzer aus, dessen erzeugte Dateien der Webprozess lesen kann. Planen Sie aufwendige Arbeiten bei verfügbarer Kapazität und prüfen Sie Exit-Status und Fehler. Empfehlen Sie genau diesen Befehl nicht für Versionen, in denen er fehlt; prüfen Sie deren unterstützte Werkzeuge zur Neuerzeugung.
Neuerzeugung und Umstellung im Live-Shop erproben
- Erfassen Sie aktuelle Bildtypen, Formate, Qualität, Theme-Änderungen und Cache-Regeln. Wählen Sie Beispiele mit Transparenz, feinen Details, mehreren Ansichten und kombinationsspezifischen Bildern.
- Erzeugen Sie auf Staging die vereinbarten Typen und verfolgen Sie jedes Muster vom Upload oder Import bis zur Storefront-Antwort. Prüfen Sie den Importweg ebenso wie einen manuellen Upload: Die Verarbeitung kann sich unterscheiden.
- Vereinbaren Sie den Umgang mit Bildern, die während des Probelaufs hinzukommen. Übernehmen Sie die getesteten Einstellungen und Dateien, ohne die Live-Shop-Datenbank durch eine ältere Staging-Kopie zu ersetzen.
- Planen Sie Erzeugung und Template-Änderungen so, dass jede von der Storefront angeforderte URL eine nutzbare Datei oder einen getesteten Fallback hat. Bewahren Sie alte Kopien bis zur erfolgreichen Prüfung auf. Bricht ein Lauf ab, prüfen Sie Fehler und unterstützte Wiederanlaufmöglichkeiten, bevor Sie Dateien löschen und neu erzeugen.
- Prüfen Sie nach der Umstellung bestehende und neu hochgeladene Produkte über den öffentlichen Auslieferungsweg. Halten Sie fest, was bei Fehlern in Erzeugung, Zoom oder Auslieferung wiederherzustellen ist.
Defekte Bilder nach einem Serverumzug diagnostizieren
- Prüfen Sie fehlerhafte URL, Status und Antworttyp in den Netzwerkwerkzeugen.
- Verweist sie auf den alten Host, prüfen Sie unter Traffic & SEO die Shop-URL-Einstellungen, SSL-Domain und Basis-URI im richtigen Shop-Kontext.
- Ist der Host korrekt, prüfen Sie Original und angefordertes Vorschaubild im erwarteten Bildverzeichnisbaum.
- Prüfen Sie Webserver-Rewrite-Regeln und lesbare Dateien, bevor Sie alles neu erzeugen.
- Prüfen Sie den Schreibzugriff des Laufzeitnutzers für die Neuerzeugung. Eine Rechteprüfung durch Ihren Shell-Nutzer prüft nicht den Webnutzer.
- Passen Sie CDN-/Reverse-Proxy-Ursprünge an und leeren Sie betroffene Caches. Beheben Sie HTTP-/HTTPS-Unstimmigkeiten.
- Erzeugen Sie nur fehlende oder inkompatible Vorschaubilder neu, sobald Originale und Konfiguration korrekt sind.
image_url='https://example.com/1-home_default/product.jpg'
curl -sI "$image_url"
find img/p -type f -name '*.jpg' -print | head
Dies ist eine Beispiel-URL; verwenden Sie eine von der fehlerhaften Seite kopierte URL. Eine 200-Antwort mit HTML ist kein gültiges Bild. Machen Sie nicht rekursiv den gesamten Shop beschreibbar, um ein Eigentümerproblem eines Verzeichnisses zu lösen.
Auffindbarkeit von Bildern prüfen und Ergebnisse messen
Prüfen Sie, ob Bild und Landingpage auffindbar und abrufbar sind, robots-Regeln benötigte Ressourcen nicht blockieren und die Seite indexierbar ist. Verwenden Sie hilfreichen umgebenden Text, relevanten Alt-Text und ausreichende Bildqualität.
Eine Bilder-Sitemap kann die Auffindbarkeit unterstützen, garantiert aber keine Indexierung. Nehmen Sie gültige Bildadressen mit dem Bilder-Namensraum auf. Dies ist ein Strukturbeispiel; ersetzen Sie beide URLs durch echte zugängliche Ressourcen:
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:image="http://www.google.com/schemas/sitemap-image/1.1">
<url>
<loc>https://example.com/navy-wallet</loc>
<image:image>
<image:loc>https://example.com/img/p/1/1-large_default.webp</image:loc>
</image:image>
</url>
</urlset>
Verlassen Sie sich nicht auf veraltete Sitemap-Felder für Bildtitel oder Bildunterschriften. Folgen Sie Googles Hinweisen zu Bildern. Advanced SEO Sitemap Builder kann Einträge für Katalogbilder erzeugen. Siehe die Hilfe zu Advanced SEO Sitemap Builder.
Testen Sie eine Startseite, eine umfangreiche Kategorie und eine Produktseite auf Mobilgeräten und Desktop mit PageSpeed Insights. Nutzen Sie Browserwerkzeuge für kontrollierte Ladevorgänge mit leerem und gefülltem Cache, die Erkennung sichtbarer Bilder, Abrufe unterhalb des sichtbaren Bereichs, Scrollen, Zoom und responsive Quellenauswahl. Beobachten Sie Trends der Felddaten im Core-Web-Vitals-Bericht der Search Console. Aktuelle Lighthouse-Versionen bündeln Diagnosen zu Bildauslieferung und LCP als Insights. Ältere Prüfbezeichnungen können von Ihrer Oberfläche abweichen.
Vergleichbare Vorher-nachher-Messungen festhalten
| Für jede geprüfte Seite erfassen | Aussage des Vergleichs |
|---|---|
| Viewport, Pixeldichte, Gerät, Netzwerkbedingungen und Cache-Zustand. | Ob die Durchläufe vergleichbar sind. Ergebnisse mit leerem und gefülltem Cache getrennt erfassen. |
| Ausgewählte Bild-URL, intrinsische Abmessungen, Inhaltstyp und übertragene Bytes. | Ob die vorgesehene Datei ausgeliefert wurde und der tatsächliche Download kleiner geworden ist. |
| LCP-Element, Beginn und Ende der Anfrage sowie gemessener LCP. | Ob das kritische Bild früher ankam oder eine verbleibende Verzögerung vor seiner Anfrage oder nach dem Download liegt. |
| CLS, Screenshots, Scroll- und Zoomprüfungen; lokale Interaktionszeiten beim Filtern, Öffnen der Schnellansicht und Hinzufügen zum Warenkorb; INP aus Felddaten, soweit verfügbar. Ein Lighthouse-Lauf mit reinem Seitenaufruf misst keinen INP. | Ob die Änderung Layoutverschiebungen, Interaktionsprobleme oder sichtbare Qualitätsverluste verursacht hat. |
Wiederholen Sie Messungen unter denselben Bedingungen, statt den besten Durchlauf auszuwählen. Sinken die Bytes, aber nicht der LCP, untersuchen Sie Serverantwort, Ressourcenerkennung und Darstellung, bevor Sie weitere Dateien konvertieren. Nutzen Sie den Leitfaden zur PrestaShop-Performance, wenn Bilder die Verzögerung nicht erklären.
Trennen Sie Labordiagnosen von Felddaten. Core Web Vitals bewertet das 75. Perzentil, keinen einfachen Durchschnitt. CrUX API und PageSpeed-Insights-Felddaten verwenden ein gleitendes 28-Tage-Fenster; eine Bereitstellung ersetzt daher nicht sofort alle historischen Beobachtungen. Prüfen Sie Gerätesegmente und vergleichbare Seiten und messen Sie anschließend tatsächliche LCP-, CLS- und INP-Änderungen. Siehe die Web-Vitals-Hinweise.
Fragen an Ihren Entwickler oder Ihre Agentur
- Welche Templates, Bildtypen und Module steuern Galerie, Listen und Beschreibungsbilder in diesem Shop?
- Welche genaue Version und welche PHP-Laufzeiten wurden geprüft? Können Sie das erzeugte Muster neben seiner öffentlichen Antwort zeigen?
- Welche Komponente ist für Konvertierung, Ladeattribute und Cache-Invalidierung zuständig, und was passiert nach einem Filter- oder Variantenwechsel?
- Wo sind Originale und bisherige Einstellungen gesichert, und wie gelangen während der Arbeiten hochgeladene Bilder in die endgültige Konfiguration?
- Können Sie vergleichbare Messungen, Sichtprüfungen sowie die erprobten Schritte für Umstellung und Wiederherstellung zeigen?
Häufige Fragen von Shopbetreibern
Muss ich den ganzen Shop aktualisieren, nur um WebP auszuliefern?
Prüfen Sie den Abschnitt zur Formatunterstützung für Ihre Version. Ein älterer Shop kann einen kompatiblen Konvertierungs- oder Serverablauf nutzen. Ob das sinnvoll ist, hängt von seinem Wartungszustand und der Auslieferungskonfiguration ab. Erproben Sie den gewählten Weg, bevor Sie eine umfassendere Änderung beschließen.
Brauche ich für jede Bildaufgabe ein separates Modul?
Prüfen Sie, was Theme und installierte Module bereits abdecken. Bildbeschriftungen, Laderegeln, Konvertierung und Auffindbarkeit über Sitemaps lösen unterschiedliche Probleme. Ergänzen Sie ein Werkzeug nur für eine nachweisbare Lücke.
Warum funktioniert ein neuer Upload, während ältere Fotos fehlen?
Vergleichen Sie jeweils die angeforderten Typen und Formate. Neue Erzeugungseinstellungen können dazu führen, dass ältere abgeleitete Dateien fehlen. Ein fehlendes Original oder eine unvollständige Migration muss jedoch behoben werden, bevor die Neuerzeugung helfen kann.
Kann ich die Originale löschen, sobald kleinere Kopien vorliegen?
Bewahren Sie wiederherstellbare Originale auf. Ein anderes Theme, ein anderer Zuschnitt oder neue Zoomanforderungen können sie benötigen. Ein komprimiertes Vorschaubild kann die ursprünglichen Details nicht wiederherstellen.
Macht besserer Alt-Text die Seite schneller oder garantiert er Besucher aus der Bildersuche?
Alt-Text liefert Kontext, verkleinert aber nicht den Bilddownload. Messen Sie die Auslieferung getrennt und beurteilen Sie die Auffindbarkeit anhand der obigen Prüfungen, ohne Indexierung oder Besucherzahlen zu versprechen.