Thema: Optimale Nutzung des picture-Tags

p3e · **am:** 10. April 2022, 16:59:59

In einem anderen Thema habe ich mit Markus über eine optimierte Nutzung des picture-Tags zur Darstellung der Produktbilder diskutiert. Wir kamen zu dem Schluss, dass ich für den Dev. Shop ein Beispiel poste.

Die Vorgeschichte: Der pictue-Tag ermöglicht es dem Browser auszusuchen, welches Bild auf dem Bildschirm angezeigt wird. Innerhalb des picture-Tags kann man dazu dem Browser u.a. verschieden große Bilder anbieten. Dieser sucht dann selbstständig eine Bildgröße aus. Neben der Bildschirmgröße kann die Entscheidung des Browsers ggf. auch von der Verbindungsgeschwindigkeit abhängen.
Damit der Browser optimal entscheiden kann, gibt man ihm zu jedem Bild die Breite (in Pixeln) und geplante Darstellungsbreite in Prozent an. Letztere variiert, da bei den meistens Templates je nach Bildschirmbreite die Spaltenanzahl der Produktdarstellung sowie weitere Dinge verändert werden.

Der Shop weiß, welche Maximalwerte bei den Bildern eingestellt sind und der Templateersteller weiß, wann wie viele Spalten zur Darstellung genutzt werden. Aus diesen Daten kann theoretisch per Code der picture-Tag optimiert werden.

Ich habe das mal als Beispiel manuell für den Dev. Shop in den Standarteinstellungen mit dem voreingestellten eingestellten Template (tpl_modified_responsive) gemacht:

Das Template folgt in der Darstellung diesen Vorgaben:

Bildschirmbreite ist kleiner 370px ---- Vorschaubild nimmt 100% der Breite ein
Bildschirmbreite ist mindestens 370px ---- Vorschaubild nimmt 50% der Breite ein
Bildschirmbreite ist mindestens 690px ---- Vorschaubild nimmt 33,33% der Breite ein
Bildschirmbreite ist mindestens 920px ---- Vorschaubild nimmt 25% der Breite ein
Bildschirmbreite ist mindestens 985px ---- linke Leiste erscheint (265px breit), Vorschaubild nimmt 33,33% der übrigen Breite ein

Als Bildgrößen stehen in den Standarteinstellungen (Maximalwerte) folgende zur Verfügung:

mini_images: 80px breit
midi_images: 160px breit
thumbnail_images: 240px breit
info_images: 520px breit
popup_images: 800px breit

Aus diesen Angaben ergibt sich meiner Meinung nach folgender optimaler picture-Tag den ich hiermit gerne zur Diskussion stelle (mini und popup habe ich weggelassen, mini wäre ggf. bei ganz schlechter Internetverbindung interessant). Lazyload etc. habe ich auch raus gelassen, weil es mir erst nur einmal darum geht, welcher picture-Tag unter den oben genannten Bedingungen, ideal wäre. Vielleicht findet sich eine bessere oder kürzere Lösung:

Code: PHP [Auswählen]

Linkback: https://www.modified-shop.org/forum/index.php?topic=42330.0

Markus · **Antwort #1 am:** 10. April 2022, 18:25:14

Hallo p3e,

erstmal danke dass du dir die Mühe gemacht hast.

Nichtsdestotrotz ... was wird dadurch anders werden mal davon abgesehen dass die ganzen Sache dadurch noch komplexer wird? Wir geben aktuell dem Browser vor welches Bild er nehmen soll. Das ganze ist einstellbar und macht auch genau das was es soll.

In deiner Variante passiert letztenendlich genau das gleiche mit dem einzigen Unterscheid dass sich der Broser dann noch zusätzlich das passende Bild heraussuchen darf. Von dem Quellcode den das ganze dann fabriziert will ich jetzt mal nicht sprechen.

Ich bin davon nicht überzeugt es komplizierter zu machen als es letztendlich ist.
Ich weiss den Viewport und ich weiss wieviele Bilder ich in einer Reihe anzeigen will.
Also gebe ich dem Browser vor was bitte er zu laden hat.
Mir erschließt sich hier kein Grund warum wir das ändern sollten und welche Vorteile das bringen soll.

Markus

... und was ich auch noch gesehen habe ...

Code: PHP [Auswählen]

sizes="(100vw - 265px)/3" />

Ich weiss wovür das ist ... aber sowas ist natürlich immer "interessant" wenn man das in einer config-Datei hinterlegen will damit es auch richtig und vor allem automatsich funktioniert. Aber das nur am Rande ... das ist ja erstmal nicht von Bedeutung.

p3e · **Antwort #2 am:** 10. April 2022, 19:32:00

Vor der Kalkulation fehlt der calc() Befehl. Damit wird das dann automatisch kalkuliert.

Dir ist das zu viel Quellcode? Im Dev. Shop sieht Dein endgültiger picture Quellcode von Dir so aus:

Code: PHP [Auswählen]

Okay, teilweiser wird der durch JS erzeugt aber das geht bei meiner Variante auch.
Ist aber vor allem traurig, wenn ich am Retina Display ab 985px nur noch 160px Breite statt 240px oder gar 520px sehe.
Mit den zwei Bildgrößen, die Du damit dem Browser fest vorgibst, bleibst Du weit hinter den Möglichkeiten, die picture bietet.

Markus · **Antwort #3 am:** 11. April 2022, 08:21:27

Hi p3e,

ganz so dramatisch sehe ich das nicht.
Im Prinzip geht es dir um die Bildgrößen bzw. Darstellung für Retina-Displays.
Das picture-Tag so wie es aktuell eingebunden ist, ist weder fehlerhaft noch falsch eingebunden und vor allem berücksichtigt es auch unterschiedliche Bildformate. Du darfst nicht davon ausgehen dass jeder Shopbetreiber immer für jedes Bild das gleiche Seitenverhältnis hat.

Um es auf den Punkt zu bringen ... das einzige was dir fehlt wäre die Darstellung für Retina-Displays.

Was ich jetzt der ganzen Sache noch nicht getestet habe ist das Verhalten vom Browser wenn eben jemand in seinem Shop keine einheitlichen Bilder hat. Bedeutet ... es kommen Hoch- und Querformate für das Thumbnail.

Als Beispiel:

In den Bildoptionen ist für das Thumbnail 240 x 240 Pixel eingestellt.
Das Original-Bild wird aufgrund dieser Werte auf 100 x 240 Pixel gerechnet.
Im picture-Tag wird aber ein w für die Breite angegeben. Demzufolge also eine Breite von "240w". Das Bild hat aber keine Breite von 240px

Ich werde mir das auch nochmal anschauen ob und wie man auf einem einfacheren Weg Retina Images abbilden kann.
Vielleicht hat ja noch wer eine zündenede Idee

Markus

p3e · **Antwort #4 am:** 11. April 2022, 08:34:11

Ich habe das Gefühl, wir reden aneinander vorbei. Dem Server ist sehr wohl bekannt, wie groß die jeweiligen Bilder sind (getimagesize), immerhin liegen die auf dem selben Server.

Markus · **Antwort #5 am:** 11. April 2022, 08:47:40

Hi p3e,

das ist mir schon klar dass es dem Server bekannt ist aber darum geht es nicht.

Es geht um diese Angabe hier (verkürzt dargestellt) ...

srcset=".....modified-shop.org/images/product_images/info_images/24_0.jpg 520w, ......

Die 520w würden in dem Fall nicht stimmen da das Bild eben nicht 520px sondern nur 260px breit ist.
Ich hab das noch nicht getestet was dann passiert. Und um überhaupt über die Möglichkeit der Integration nachzudenken muss das dann trotzdem sauber funktionieren.

Markus

p3e · **Antwort #6 am:** 11. April 2022, 11:05:49

Die 520w sind nur ein Beispiel. In den Fall steht da dann natürlich dank getimagesize 260w (oder wie auch immer die Bildbreite jeweils ist).

Markus · **Antwort #7 am:** 11. April 2022, 11:31:08

Hi p3e,

du willst mir damit sagen, dass du in einem Listing mit sagen wir mal 20 Artikel pro Seite für alle Bildgrößen mit getimagesize die Bildgrößen holen willst? Das ist jetzt nicht dein Ernst.

Markus

p3e · **Antwort #8 am:** 11. April 2022, 14:32:09

Du brauchst das nur für das jeweils kleine midi Bild auslesen und dann entsprechend hochrechnen. Bei kleinen Bilddateien geht das sehr schnell. Habe ich schon gemacht. Theoretisch kann man die Werte auch schon beim Anlegen in der Datenbank speichern, aber das wäre natürlich komplex. Im Internet gibt es auch Beispiele wie Du nur die ersten Bytes der Files auslesen kannst, da hier schon die Größe hinterlegt ist. Bei kleinen Bilddateien ist das aber kein Geschwindigkeitsvorteil.

Markus · **Antwort #9 am:** 11. April 2022, 15:12:23

Hi p3e,

wir optimieren die Software an allen Ecken und Enden und versuchen unnötige oder doppelt ausgeführte SQLs und Funktionen auszumerzen und dann willst du mit getimagesize Bildgrößen abfragen und damit es ein wenig schneller geht auch noch hoch rechnen? Sorry .. aber das ist in meinen Augen nicht der richtige Weg.
Und nur mal am Rande erwähnt haben wir noch nichtmal von Kategorie-, Banner- oder Slider-Bilder gesprochen.

Markus

p3e · **Antwort #10 am:** 11. April 2022, 15:42:16

War auch nur ein Vorschlag.
Auch wenn Du das hier alles ins lächerliche ziehst, hat der picture-Tag schon seinen Sinn. Man muss den ja nicht nutzen. So wie es im Dev. Shop gelöst ist, ist jedenfalls weit davon entfernt (für zwei Bildgrößen werden 7 source-Tags verwendet).

noRiddle (revilonetz) · **Antwort #11 am:** 11. April 2022, 15:47:30

Hallo zusammen.
Vorab vielen Dank für die Bemühungen bei diesem Thema, bin ein absoluter Befürworter von Optimierungen jeglicher Art.

Zitat von: Markus am 11. April 2022, 08:21:27

...
Als Beispiel:
In den Bildoptionen ist für das Thumbnail 240 x 240 Pixel eingestellt.
Das Original-Bild wird aufgrund dieser Werte auf 100 x 240 Pixel gerechnet.
Im picture-Tag wird aber ein w für die Breite angegeben. Demzufolge also eine Breite von "240w". Das Bild hat aber keine Breite von 240px
...

Hat man in diesem Fall nicht einen Fehler gemacht, indem man ungünstige Werte im Backend eingetragen hat ?

Es ist klar, daß sich, je nach Artikelangebot, nicht immer quadratische Bilder nutzen lassen, was am einfachsten und optisch am schönsten wäre. Man sollte sich als Shop-Betreiber jedoch auf eine Breite für die Bilder festlegen, dem Template entsprechend.
Will sagen, wenn es Bilder gibt die aufgrund der Einstellung im Backend für die max. Höhe ein Bild in der Breite kleiner als die max. Breite runterskaliert müssen ist schon etwas verkehrt.
Vielleicht sollte man darüber nachdenken für den w-Wert im srcset die Konstante für die max. Breite zu nehmen und im Backend ein paar mehr Worte zur Erklärung einzubinden.

Wenn ich das richtig verstehe ist das am Ende das was p3e vorschlägt ?
Ein getimagesize() wäre nach meiner Ausführung nicht nötig.

Es ist ohnehin ein altes Thema wie mit Bildern im Shop genau verfahren werden sollte und es fehlt dazu eine Anleitung.
Ich sehe in sehr vielen Shops widersprüchliche Angaben wenn man alle drei Faktoren berücksichtigt, CSS, Konfig-Angaben, tatsächlich hochgeladene Bilder und die Bilddarstellungen im Frontend sind entsprechend schlecht. und inkonsistent. Das ist auch verständlich, da die Zusammenhänge komplex sind und sie irgendwo erklärt werden sollten.

Gruß,
noRiddle

P.S.:
Ich habe übrigens nicht den Eindruck Markus würde die Sache ins Lächerliche ziehen.
Er stellt sich vielleicht nur ein wenig steif...

Markus · **Antwort #12 am:** 12. April 2022, 07:32:03

Hallo,

@p3e
Ich ziehe das nicht ins lächerliche. ich suche eine Lösung welche für alle zu gebrauchen ist und auch möglichst mit allen Bildformaten funktioniert. Wir können leider nicht vorschreiben dass der Shop nur ein Seitenverhältniss an Bildern akzeptiert.
Das wäre Wunschdenken und funktioniert in der Praxis leider nicht.

Ich werde mir das über die Osterfeiertage mal genauer anschauen und in einem Testshop mal durchtesten.

Zitat von: noRiddle (revilonetz) am 11. April 2022, 15:47:30

Er stellt sich vielleicht nur ein wenig steif...

Aber nur ein klitzekleines bischen

Markus

Karl1 · **Antwort #13 am:** 12. April 2022, 12:38:08

Hallo Zusammen,
je mehr ich über das Thema lese, desto überzeugter bin ich vom Lösungsansatz von Markus.
Unabhängig wie aufwendig die dynamische Ermittlung des w-Wertes eines Bildes ist, findet man im Netz zahlreiche Hinweise, dass Browser sehr unterschiedlich auf die Kombination von „w-Wert“ und „sizes“ reagieren.
Der Browser sucht sich die für ihn geeignetste Grafik aus – das muss nicht die von uns gewollte sein.

Der Ansatz von Markus bietet die Möglichkeit anhand der Breite des Viewports unterschiedliche Bilder anzuzeigen.
Meine Tests mit diversen Desktop-Browsern haben ergeben, dass das zuverlässig (mit lazyload und auch mit Bildern im Cache) funktioniert.
Das will doch der Entwickler und auch der Shopbetreiber, dass der Kunde zuverlässig und schnell das Gewollte sieht.

Einziger Punkt der aus meiner Sicht noch zu überdenken wäre, sind die hochauflösenden Retina-Displays.
Leider fehlt mir, Mangels Apple-Geräten, hier das „know how“ und die Testmöglichkeit.

@p3e:
Dein Codevorschlag (ganz vorne im Thema) wird so nicht funktionieren.
Wenn ich alles richtig verstanden habe, sucht der Browser nach dem ersten zutreffenden Source-Tag.
In deinem Fall immer der erste, sobald der Viewport größer 370px ist.

Gruß Karl