Ich habe in der Einkaufswelt die Zeilen und Spalten derart eingestellt, dass das Bild eines einzelnen Artikels bei mir ca. von der Dimension 150x230 px ist. Die Default-Thumbnails sind ja 200x200, 600x600 und 1280x1280. Entsprechend wählt er als Bilder die 600x600, was aber natürlich viel zu groß ist. Also habe ich nun eine neue Thumbnailgröße eingerichtet: 230x230 und sämtliche Thumbnails aller Bilder generieren lassen. Trotzdem benutzt er für die Einkaufswelt immernoch die 600x600 und verschwendet damit viel. Man muss ich tun, damit in der Einkaufswelt die bestgeeignetsten Thumbnails benutzt werden? Also in diesem Fall die 230x230? Danke sehr!
Schliesse mich der Frage an: Element [Banner] 290x185 [Desktop] Dementsprechend hochgeladenes Bild 290x185 Von der Logik her müsste - warum auch immer das Original nicht verwendet wird - 600x600 benutzt werden. Gucke ich im Chrome nach, ist das Element auf dem Desktop auch wirklich 290x185 groß, verwendet wird aber - laut Endung - 1280x1280. Öffne ich das Bild 1280x1280 im extra Tab, ist es dennoch nur 290x185 groß. a) werden Thumbnails bei kleineren Bilder nicht hochgerechnet, nur größere runter? b) wenn schon nicht das Original verwendet wird, warum dann nicht das nächst passende, sondern in dem Fall 1280x1280? Wenn ich mir vorstelle, ich würde für jeden Banner 1600x1600 hochladen, SW5 dann 1280x1280 verwenden, und ich hätte 10 Banner auf der seite, dann würde Google zurecht die Ladezeiten der Seite kritisieren. Mir esrchließt sich die “Thumbnail”-Logik von SW5 noch garnicht.
Dürfte einfach ein Bug sein, gibts noch so einige von.
Ich dachte erst, SW5 nimmt einfach von „oben“ kommend das passende, was bei kleinen Bildern mit 1280x1280 ja hätte sein können. Nun Habe ich einfach mal ein 290x185er Bild auf 2000x1276 hochskaliert und als Banner bei 290x185 genommen. Auch hier nimmt SW5 im Desktop runter bis zum wechsel zum „Tablet“ das 1280x1280 - welches real dann 1280x817 groß ist. Für eine max Darstellung [nicht Retina] von 290x185 ist das ein absolut schlechter Scherz! Das hochgeladene Bild hatte übrigens eine Größe von 232kb - das kleine von SW5 ausgelieferte [höher eingestellte Qualität] hat eine Größe von 471kb. Da fehlen mir echt die Worte - 471kb für eine Darstellung von 290x185!
[quote]Ich dachte erst, SW5 nimmt einfach von “oben” kommend das passende, was bei kleinen Bildern mit 1280x1280 ja hätte sein können.[/quote] Das hatte ich zunächst gehofft, wäre ja auch das sinnigste (vermutlich), daher meine beschriebenen Anpassungen oben. Aber vielleicht ist es doch kein Bug, sondern es ist nur irgendeine Einstellung nötig, mit der man Shopware sagt, welche Bilder Thumbnails für die jeweilige Einkaufswelt benutzt werden sollen. Bin gespannt, ob jemand mehr weiß. Viele Grüße
Das Problem betrifft allerdings, soweit ich das sehe, ausschließlich die Einkaufswelten bei neu angelegten Thumbnails. Bei den Listings der Artikel wird korrekt der nächstgrößere Thumbnail benutzt. Bei der Einkaufswelt mit eingebundenen Artikeln ist dies nicht der Fall. Vermutlich gibt es eine einfache Lösung, wie man dies auch dort aktiviert.
Hallo Ihr Lieben, aktuell werden in Shopware 5 folgende Thumbnail-Größen für den Artikel Ordner erstellt: 200x200, 600x600, 1280x1280 Die Ausgabe der Größen wird über das Picture HTML Element gesteuert, welches mehrere Source-Sets für verschiedene Viewports definiert. Da wir nicht wissen können wie der Kunde seine Einkaufswelt gestaltet, gehen wir grundsätzlich von der maximalen Breite des Containers aus (Element verwendet volle Spaltenanzahl). Bei der Artikel-Box gebe ich zu, dass diese natürlich in vielen Fällen als kleinere Box verwendet wird und daher vielleicht auch ein kleineres Bild ausreichen würde. Ihr könnt die Ausgabe der Produktbilder in den Boxen Eurer Einkaufswelt optimal auf Euer Template abstimmen, indem ihr einfach das Template der Produkt-Box anpasst. Hier gibt es ein eigenes Template speziell für die Einkaufswelten: frontend/listing/product-box/box-emotion.tpl Dort könnt Ihr über den Block frontend_listing_box_article_image_picture_element einfach Eure eigenen Source-Sets definieren. Ihr könntet dann auch noch weitere eigene Thumbnail-Größen hinzufügen. Sonnige Grüße, Phil
Hi, danke für die Antwort. Verstehe ich das also richtig: Es wird nicht das jeweils kleinstmögliche Vorschaubild gewählt, außer diese neue Thumbbildgröße wird vorher in frontend/listing/product-box/box-emotion.tpl registriert? Das wäre ja kein Problem. Danke, viele Grüße
Hallo, da wir von der maximalen Breite ausgehen müssen werden die bestehenden Größen wie folgt als Source-Set definiert: 200x200 - Mobile 600x600 - Tablet 1280x1280 - Desktop Entsprechend in doppelter Auflösung bei Retina Display. Dieses Source-Set kannst Du ganz einfach an der beschriebenen Stelle Deinen eigenen Bedürfnissen anpassen. Zum Beispiel neue Größen hinzufügen oder bestimmen, ab welchem Viewport eine bestimmte Größe geladen werden soll. Grüße, Phil
Verständlich und auch nicht 
Im script werden ja die einzelnen Zellen zusammengesetzt und die Elementbreite festgelegt. Genau hier ist also sehr wohl die Größe der Einkaufswelt, bzw die größe der Elementzelle bekannt [siehe “Bug” zur letzten Zelle einer Zeile]. Damit könnte ich dann schon - zumindest beim Banner / Slider(da hab ich das Verhalten noch nicht getestet) [also nicht Artikel!] - vorab festlegen, welches Thumbnail zur Darstellung genommen wird. O.K. - dass müsste man dann relative leicht durch Umbasteln im eigenen Theme nachrüsten können - wenn es auch eher in den core gehört 
Vorschlag: Für Banner/Slider im Designer ein Dropdown mit “default, thumbnail-a bis thumbnail-x” für die Darstellung einbauen, und gut ist
Ok, ich habe jetzt testweise die Datei mal umgeschrieben in: [code]{block name=‚frontend_listing_box_article_image_picture_element‘}
<img srcset="{$sArticle.image.thumbnails[0].sourceSet}" alt="{$sArticle.articleName|escape}">
</source></source></picture>{/block}[/code] Entsprechend wurden genau die 200x200 Bilder geladen, funktioniert also. Gehe ich recht der Annahme, dass die neu zu generierenden Thumbnails also dann 3,4,5 usw. fortlaufend nummeriert werden und mit der Nummer im Fnester "Thumbnail" übereinstimmen? Dann wäre es für mich soweit gelöst.Prinzipiell ließe sich das aber auch automatisieren: 1. Prüfe, welche Maße das maximale Bild in einer Artikelbox einer Einkaufswelt einnimmt. 2. Lade für diese EInkaufswelt entsprechend die minimalen verügbaren Thumbnails. Idealerweise sogar noch für jedes Bild einzeln (wobei dies wohl große Änderungen notwendig machte). Es würde also genügen, diesen Schritt, den ich jetzt von Hand gemacht habe, zu automatisieren, und dann entsprechend der Einkaufswelt die richtige Thumbnailgröße zu wählen. Als Maßstab darf dann eben nicht die ganze Breite der Artikelbox gewählt werden, sondern nur die maximale Breite/Höhe, die auf der Einkaufsseite auch tatsächlich vorkommt. Vielleicht etwas für die Zukunft.
Hallo, ja die IDs sind fortlaufend so wie sie im Media-Manager angelegt wurden. Bzgl. der Auswahl der Bilder haben wir uns für das Picture Element entschieden, da es in zukünftigen Browsern zum Standard gehören wird. Das Element arbeitet in den Source-Sets mit Media Queries, so dass sich um alles Weitere der Browser kümmert. Der Vorschlag von Carsten, die Auslieferung an der Zellengröße festzumachen, funktioniert leider nicht, da wir in einem fluiden Layout nicht von der Zellengröße auf die Screensize schließen können. Liebe Grüße, Phil
[quote=“Philipp Schuch”]Hallo, Der Vorschlag von Carsten, die Auslieferung an der Zellengröße festzumachen, funktioniert leider nicht, da wir in einem fluiden Layout nicht von der Zellengröße auf die Screensize schließen können. Liebe Grüße, Phil[/quote] Da sollten sich die Designer von Shopware aber noch einmal ins stille Kämmerlein zurückziehen, und über eine Lösung nachdenken. Denn folge ich Euren “Empfehlungen”, am besten alles in 1600x1600 hochzuladen, “explodiert” bei einer Einkaufswelt mit vielen Bannern förmlich das Datenvolumen, und zwar locker auf das 20-Fache vom eigentlich benötigtem.
[quote]Da sollten sich die Designer von Shopware aber noch einmal ins stille Kämmerlein zurückziehen, und über eine Lösung nachdenken. Denn folge ich Euren „Empfehlungen“, am besten alles in 1600x1600 hochzuladen, „explodiert“ bei einer Einkaufswelt mit vielen Bannern förmlich das Datenvolumen, und zwar locker auf das 20-Fache vom eigentlich benötigtem.[/quote] Lies Dir doch bitte nochmal die Lösung aus dem vorherigen Beitrag genau durch. Hier nochmal der Link: http://forum.shopware.com/post119206.html#p119206 Liebe Grüße, Phil PS: Stille Kämmerlein haben wir hier bei Shopware nicht
Phillipp, wenn ich mir eine Software für 5kEUR zulegen möchte, bastel ich nicht am Kleinkram rum, ich war übrigens grad im stillem Kämmerlein [o.k. - Ihr habt Eure Kuschelsackecke *fg*], und muss sagen: Wer sagt, es gäbe keine Lösung, hat sich zur Entwicklung von SW5 wirklich keine Gedanken gemacht *duck - renn weg* Und nun möchte ich mein *bashing* mal begründen: Trennen wir die Problematik zunächst auf. a) Artikel-Thumbnails b) Banner / Slider Mein Problem sind derzeit die Banner im Resize. Für Artikelthumbs müsste man den Ansatz weiter entwickeln. Richtig: Ich kenne nicht die exakte Größe der Darstellung, die brauche ich aber auch nicht. Die letztlich richtige Größe holt sich das Pictureelement. Allerdings habe ich aber alle notwendigen Informationen, dem Pictureelement die nach „oben“ nächst passende Größe zu übergeben. : Max Elementbreite zwischen den Breakpoints, Thumbnailsgrößen, Picturelement Die Basis ist der Designer - hier werden Höhe und Abtand in Pixel vorgegeben, die Breite im Desktop beträgt 1160px - lassen wir den Sonderfall „Vollbild“ als Option unberücksichtigt. Alle „Pixel-Angaben“ findet man dann 1:1 im Desktop wieder - also „Normgröße“ Wie an andere Stelle [Bug] ja schon erkannt, lässt sich die Breite im Desktop vereinfacht durch Breite/Spalten-Abstand errechnen. Dieser Wert ist dann bekannt, und somit auch die maximale Breite, die ein Element im Desktop haben kann - es wird zwischen den Breakpoints schlicht nicht größer! [Analog zusammengesetzte Zellen]. Meine Thumbnailgrößen sind ebenso bekannt => hier kan ich ganz simpel für den Desktop das kleinste passende Picture-Bild aussuchen. Weiter gehts nach „unten“ - es wird linear runterskaliert, bis ich zum ersten Breakpoint komme. *Bischen Mathe* BreiteDesktop / BreiteTablet = BreiteElementDesktop / BreiteElementTablet ==> BreiteElementTablet = BreiteElementDesktop * BreiteTablet / BreiteDesktop [size=70][color=red]da kürzen sich ja sogar die Einheiten weg - also egal ob PX,REM oder EM - es bleibt die Breite in px[/color][/size] *schwups* habe ich die MAXIMALE Breite für das Bild im Tablet => Auswahl für Picture Das ganze geht runter bis zum Handy. Alle Breakpoints, Maximale Breiten etc. sind bekannt. Das ist so simpel - da sollte ich ala Apfel gleich ein Patent drauf anmelden Die gleiche Basis könnte man auch erweitern für Artikel-Thumbs. Für meine Banner brauche ich eigentlich auch gar kein Theme-hack - ich lade einfach in der Max. Breite vom Desktopelement hoch, und gut ist. Ist aber keine tolle Lösung 
Man sollte bedenken, das auch gerade auf dem Land die meisten eben kein VDSL50+, Kabel oder volles LTE haben… [Edit] Nachtrag: Natürlich muss man auch die Höhe entsprechend analog berechnen und berücksichtigen. Also das Thumbnail was für Breite UND Höhe passt…
Hallo Carsten, ich habe mir jetzt noch einmal die Zeit genommen und versucht aus Deinem Text die wichtigsten Infos herauszufiltern. Deine Anregungen habe ich in einem Ticket, in dem es um die Optimierung der Responsive Images geht, hinzugefügt. Solltest Du in Zukunft noch weitere Ideen haben, freuen wir uns über detaillierte Feature Vorschläge in unserem Issue-Tracker: http://jira.shopware.de/ Bzgl. des Support hier im Forum möchte ich noch hinzufügen: Der Ton macht die Musik. Das gesamte Team möchten hier jedem so gut es geht helfen um mit Shopware 5 erfolgreich durchzustarten. Umso ausführlicher und strukturierter Eure Fragen formuliert sind, desto besser können wir helfen. Dabei sollte die Diskussion möglichst immer auf einer sachlichen Ebene bleiben. Vielen Dank und sonnige Grüße, Phil
1 „Gefällt mir“
Hallo, gibt es denn zwischenzeitlich eine automatisierte Lösung? Ich bin erst gestern auf diesen thread gestoßen weil mir jemand gesagt hat, dass meine Startseite grottig lädt und hat mir diesen Link gegeben: https://developers.google.com/speed/pag … tab=mobile . Wenn die paar Artikelbildchen im Slider alle mit 1280x1280 geladen werden, wundert mich das Ergebnis natürlich nicht. Jetzt habe ich einen tollen Shopware 5.1 mit Responsive am Laufen und bekomme ein solches Ergebnis 
Das ist jetzt aber nicht im Sinnes des Erfinders, oder? Mit den „Anleitungen“ hier kann ich ehrlich gesagt nicht viel anfangen. Die Datei „frontend/listing/product-box/box-emotion.tpl“ habe ich zwar im Bare gefunden, aber dort gibt es keinen Block „frontend_listing_box_article_image_picture_element“ geschweige denn ein Source-Set. Wie genau ich mir dort eigene Thumbnail-Größen anlegen soll erschließt sich mir schlicht nicht. Die gegebenen Auflösungen des Source-Sets habe ich nur in der php-Datei hier gefunden: files/update/update-assets/migrations/450-add-high-dpi-album-settings.php. Dort sollte man aber wohl eher nichts ausprobieren. Und was meint das insight tool bitte mit „JavaScript- und CSS-Ressourcen, die das Rendering blockieren, in Inhalten „above the fold“ (ohne Scrollen sichtbar) beseitigen“ Was soll ich da bitte wie beseitigen??? Zu Hülfe! … und was wollen die mir sagen mit „Sichtbare Inhalte priorisieren“? Habe ich da ggf. selbst was verbockt? Ich habe doch das System nur ganz normal installiert und lege brav gerade meine Artikel an. Ähm … . Sollte ich hier einen neuen thread aufmachen? Der Post steht ja aug [GELÖST]. Für mich ist aber irgendwie gar nichts gelöst. Vielleicht kann mir da jemand weiterhelfen. Lieben Dank!
Hallo, das Google PageSpeed Tool ist grundsätzlich mit viel Vorsicht zu genießen. Die Warnung zu “above the fold” kannst Du z.B. ignorieren. Hier geht es dem Tool darum, dass die CSS und JavaScript Datei zu groß ist. Dies entsteht dadurch, dass alle Dateien zu einer einzigen Datei zusammengeführt werden. Diese Vorgehensweise ist allerdings besonders wichtig, denn dadurch werden unnötige Requests an den Server minimiert. Diese werden außerdem nach dem ersten Request vom Browser gecached. Die Thematik wird durch die Einführung von HTTP2 irgendwann eh komplett hinfällig. Bzgl. der Thumbnail-Größen scheint es hier noch ein Problem in der Einkaufswelt mit dem “Resize” Modus zu geben. Die Bilder der nachgeladenen Produkte scheinen passendere Größen zu verwenden. Ich habe das Problem mal mit in die Planung aufgenommen. Ich werde mal schauen ob ich das Problem reproduzieren kann. Vielleicht versuchst Du mal den Slider im “Masonry” Modus zu verwenden. Im “Resize” werden die Produkt-Boxen auf Mobile eh sehr klein. Sonst kannst Du natürlich auch gerne die Box im Slider bearbeiten, bzw. auch eine eigene verwenden. Die box-emotion.tpl ist schon ein guter Ansatz. Du kannst auch eine eigene Box anlegen und diese von einer bestehenden Box ableiten. Das Template vom Slider findest Du unter widgets/emotion/components/component_article_slider.tpl. Sonnige Grüße, Phil
ist da was im sourcecode geändert worden?
ich finde unter bare\frontend\listing\product-box\box-emotion.tpl
keinen block mehr mit dem inhalt:
{block name='frontend\_listing\_box\_article\_image\_picture\_element'} <picture>
<source srcset="{$sArticle.image.thumbnails[0].sourceSet}" media="(min-width: 78em)">
<source srcset="{$sArticle.image.thumbnails[0].sourceSet}" media="(min-width: 48em)">
<img srcset="{$sArticle.image.thumbnails[0].sourceSet}" alt="{$sArticle.articleName|escape}">
</source></source></picture> {/block}