Performance bei Bildgrößen

Druckbare Version

11.04.2017, 18:55
wanst

Performance bei Bildgrößen

Ich wollte das Bildgrößen-Tool in Contao nutzen, hab mir jetzt dazu auch die Anleitung von RockSolid durchgelesen und steige jetzt auch langsam durch. ;)

In der Anleitung ist (ganz am Ende, vorm Fazit) davon die Rede, das man mit der Performance bei kleinen Hosting-Paketen aufpassen muss und nicht zu viele Bildvarianten erstellen lassen soll. Also hab ich das mal ein bisschen getestet, und meine Seite stieg schon mit drei Bildern pro Seite aus – zwei gingen noch. Dann wird komplett gar nichts mehr angezeigt – leere Seite.

Die Einstellungen waren am Anfang recht übersichtlich: 640px breit und 0.5x,1x,2x,4x als Varianten. Die Originalbilder sind alle 2560px breit.

Also weiter probiert, woran es liegen könnte. Weniger Varianten, andere Verhältnisse etc. – es hängt offensichtlich mit der Bildgröße zusammen, die berechnet werden soll. Bei etwa 2500px und mehr als zwei Bildern ist Schluss.

Hat jemand ne Idee, wo diese Grenze herkommt (und natürlich, wie man damit umgeht)? Oder ist es einfach nur die PHP-Speicherbegrenzung, und daraus resultieren dann die Maße/Mengen?
11.04.2017, 19:06
Spooky

Zitat:

Zitat von wanst

Die Einstellungen waren am Anfang recht übersichtlich: 640px breit und 0.5x,1x,2x,4x als Varianten.

Das sind ja schon sehr viele Varianten ;). Pro Bild, wo du diese Bildeinstellung auswählst, werden dann 4 Bilder erzeugt.

Zitat:

Zitat von wanst

Also weiter probiert, woran es liegen könnte.

Was meinst du damit? Finde zuerst mal heraus wo das Problem liegt (über Logs bzw. Server Logs). Wenn du da sehr viele Bilder ausgeben lässt - und dann eben die vorhin erwähnte Bildeinstellung verwendest, dauert das erzeugen dieser Unmengen an Bilder vielleicht einfach zu lang und du kommst über die max_execution_time hinaus. Das Server Log wird dir dazu mehr Aufschluss geben können.
12.04.2017, 10:21
wanst

Zitat:

Zitat von Spooky

Das sind ja schon sehr viele Varianten ;). Pro Bild, wo du diese Bildeinstellung auswählst, werden dann 4 Bilder erzeugt.

Das stimmt schon, im weiteren Verlauf hab ich dann nur noch zwei oder drei Varianten erzeugen lassen. Aber klar, da kommen schon ein paar zusammen – aber was ist denn der Vorteil, ggü. selbst im Photopop erzeugten Bildern?

Zitat:

Was meinst du damit?

Naja, wie gesagt, ich hab versucht, mich ranzutasten, mit verschiedenen Werten für Breite und Skalierung gespielt.

Zitat:

Finde zuerst mal heraus wo das Problem liegt (über Logs bzw. Server Logs). Wenn du da sehr viele Bilder ausgeben lässt - und dann eben die vorhin erwähnte Bildeinstellung verwendest, dauert das erzeugen dieser Unmengen an Bilder vielleicht einfach zu lang und du kommst über die max_execution_time hinaus. Das Server Log wird dir dazu mehr Aufschluss geben können.

Ist Server-Log = /system/logs/error.log ?

Da gibts nur Archive, also error.log.1, error.log.2 etc. und da steht ein Fehler drin. Bei aktivierter $GLOBALS['TL_CONFIG']['displayErrors'] = true; bekomme ich als Fehler:

Code:

Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 17479681 bytes) in /.../system/modules/core/library/Contao/GdImage.php on line 112

zu wenig Speicher, wie vermutet? Aber 17479681 (try to allocate) ist doch kleiner als 67108864 (allowed) ... ich steh aufm Schlauch.
12.04.2017, 10:41
Spooky

Zitat:

Zitat von wanst

aber was ist denn der Vorteil, ggü. selbst im Photopop erzeugten Bildern?

Was meinst du damit? Vielleicht verstehst du Responsive Images falsch.

Wenn du zB eine 1x und 2x Source von einem Bild hast, das eine Ausgangsgröße von 300x200 hat, dann wird auf einem Device, das eine höhere Pixeldichte als DPPX = 1 hat das 2x Bild genommen - welches ja dann 600x400 groß ist (es wird aber trotzdem in 300x200 CSS Pixel dargestellt).

Zitat:

Zitat von wanst

Code:

Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 17479681 bytes) in /.../system/modules/core/library/Contao/GdImage.php on line 112

zu wenig Speicher, wie vermutet?

Ja, viel zu wenig Speicher. Dein memory_limit liegt bei nur 64 MiB - das reicht für Bildoperationen auf großen Bildern ganz sicher nicht aus.
12.04.2017, 11:29
wanst

Ach ja, noch was – kann man den Bildeintrag eigentlich noch nachträglich beeinflussen? Das größte Bild ist bei mir zum Beispiel immer das Original – das müsste ja gar nicht neu berechnet werden. Aber das weiß Contao natürlich nicht. Dazu muss ich am Template rumpfuschen, gell?
12.04.2017, 11:50
wanst

Zitat:

Zitat von Spooky

Was meinst du damit? Vielleicht verstehst du Responsive Images falsch.

Ja, nein, also doch – schon verstanden. Du hast natürlich recht – das lässt sich ja nicht anders umsetzen. Ich meinte, der Vorteil gegenüber den drei erzeugten Bildvarianten im Photoshop. Aber deshalb habe ich die ja noch lange nicht im HTML eingebunden –*klar.

Zitat:

Ja, viel zu wenig Speicher. Dein memory_limit liegt bei nur 64 MiB - das reicht für Bildoperationen auf großen Bildern ganz sicher nicht aus.

Ich hab das jetzt mal bei unserem Provider auf 192 hochgesetzt. Das geht schon besser. Es bleibt die Angst, das es auf dem Webspace der Kunden dann wieder Probleme damit gibt. Dieser Speicher steht ja dann fürs Script zur Verfügung (also ggf. 20 Bilder x 3 Auflösungen), oder? Das bedeutet, wenn es ein Kunde mal übertreibt, steigt PHP wieder ohne Vorwarnung einfach aus? Hm...
12.04.2017, 12:10
Spooky

Genau. Du kannst dem aber mit der Einstellung Maxime GD Bildbreite/höhe entgegen wirken. Das könntest du auf einen Wert setzen, der niedrig genug ist, damit es bei zu großen Bildern nicht zu einem memory overflow kommt. Das bedeutet aber auch, dass bei diesen Bildern keine Varianten ausgegeben werden, sondern nur immer das Original.
12.04.2017, 15:16
wanst

Das würde dem eigentlichen Zweck ja aber diametral gegenüber stehen ;)

Das lässt sich auch nicht errechnen, oder? Nur abschätzen.

Aber wenn das Bild einmal berechnet und gecachet ist, dann gehts. Das heißt, sollte es wieder mal nicht reichen, lege ich das Bild auf eine leere Seite, rufe die einmal auf und verschiebe dann das Bildelement in den Artikel, in dem ich es brauche? So, als Workaround. Läuft sowas?
12.04.2017, 15:21
tab

Vielleicht? Aber wie auch immer, das bessert ja dein Problem nicht, dass der Kunde es jedenfalls nicht so machen wird. Und wenn der Cache mal geleert wird, darfst du alle deine großen Bilder wieder auf diese Art und Weise neu in den Cache bringen.
12.04.2017, 15:22
Spooky

Zitat:

Zitat von wanst

Das lässt sich auch nicht errechnen, oder? Nur abschätzen.

Ja, lässt sich nur abschätzen. Ich würde mal sagen bei bspw. 6 Megapixel brauchst du mindestens 256 MiB.

Zitat:

Zitat von wanst

Aber wenn das Bild einmal berechnet und gecachet ist, dann gehts. Das heißt, sollte es wieder mal nicht reichen, lege ich das Bild auf eine leere Seite, rufe die einmal auf und verschiebe dann das Bildelement in den Artikel, in dem ich es brauche? So, als Workaround. Läuft sowas?

Nein, nicht unbedingt. Das Problem ist, dass ein einzelnes Bild schon zu groß sein könnte.
12.04.2017, 22:47
mlweb

Nur mal so am Rand - auch Bilder mit eine Kantenlänge von 2500px, kann man vorher fürs Web optimieren (z.B. kostenfreies Webtool TinyPNG). Dann klappt das u.U. schon deutlich besser, bei den Berechnungen.
12.04.2017, 22:56
tab

Sollte eigentlich nichts bringen, da das notwendige RAM für das Bild nur von der Bildgröße in Pixel abhängt, egal ob das JPG 10KB oder 10MB groß ist.
13.04.2017, 00:04
mlweb

Danke, wieder was dazu gelernt.
13.04.2017, 00:15
wanst

Zitat:

Zitat von Spooky

Ja, lässt sich nur abschätzen. Ich würde mal sagen bei bspw. 6 Megapixel brauchst du mindestens 256 MiB.

Ah, OK –*das ist doch schonmal was. Also bisher haben meine Bilder so um die 3 Megapixel. Dann sollte ich doch mit meinen 192 MB/MiB recht locker hinkommen.

Zitat:

Nein, nicht unbedingt. Das Problem ist, dass ein einzelnes Bild schon zu groß sein könnte.

Aber dann könnte ich ja reagieren und das Bild nicht verwenden oder von vornherein mit kleineren Abmessungen nochmal hochladen. Davon würde ja der Besucher nichts sehen. Ist 'ne Krücke, ist klar. Aber für den Fall der Fälle besser als nix.

@mlweb: das erschließt sich mir auch nicht so ganz. Die Speichermenge, die ein Rechner braucht, um ein Bild zu berechnen, hängt doch nicht von der Dateigröße ab, die das Bild in gespeichertem, komprimierten Zustand auf einem Datenträger braucht, sondern hauptsächlich von den Abmessungen (und der Farbtiefe und drei mehr). Das gute alte Photopop nennt das schon immer, glaube ich, Arbeitsgröße – im Gegensatz zur Dateigröße. [edit: warste schneller ;)]
13.04.2017, 00:21
wanst

Den hätte ich ja fast übersehen.

Zitat:

Zitat von tab

Vielleicht? Aber wie auch immer, das bessert ja dein Problem nicht, dass der Kunde es jedenfalls nicht so machen wird. Und wenn der Cache mal geleert wird, darfst du alle deine großen Bilder wieder auf diese Art und Weise neu in den Cache bringen.

Richtig, aber 1. nur als Notbehelf und 2. ich lass doch keinen Kunden den Cache leeren – HALLO! ;)
13.04.2017, 00:51
tab

Vielleicht habe ich ja deine Bedenken falsch verstanden. Meinst du das so, dass der Kunde zuviele Bilder mit zu vielen Auflösungen haben will und du das dann notfalls mit deinem Workaround einbaust? Ich bin halt davon ausgegangen, dass es so gemeint war, dass der Kunde da selbst Bilder/Bildgrößen definiert. Jedenfalls musst du aufpassen, da Contao zwar selten, aber regelmäßig den Bildercache leert.

Zitat:

Es bleibt die Angst, das es auf dem Webspace der Kunden dann wieder Probleme damit gibt. Dieser Speicher steht ja dann fürs Script zur Verfügung (also ggf. 20 Bilder x 3 Auflösungen), oder? Das bedeutet, wenn es ein Kunde mal übertreibt, steigt PHP wieder ohne Vorwarnung einfach aus? Hm...
13.04.2017, 02:08
wanst

Zitat:

Vielleicht habe ich ja deine Bedenken falsch verstanden. Meinst du das so, dass der Kunde zuviele Bilder mit zu vielen Auflösungen haben will und du das dann notfalls mit deinem Workaround einbaust? Ich bin halt davon ausgegangen, dass es so gemeint war, dass der Kunde da selbst Bilder/Bildgrößen definiert.

Die Anzahl der Bilder wird schon vom Kunden bestimmt, die Auflösung von mir. Es muss ja irgendwie passen, auf Smartphones und 27" Retina iMacs. Ungeachtet dessen gibt es zwar ein konkretes Projekt, aber eigentlich will das Thema prinzipiell mal durchdringen.

Zitat:

Jedenfalls musst du aufpassen, da Contao zwar selten, aber regelmäßig den Bildercache leert.

Oh. Also das ist aber blöd jetzt. Dann ist die einzige Option ein fetter Server?

Nochmal zurück zu einem der ersten Posts: kann ich den Eintrag noch weiter beeinflussen? Wenn ich im Moment mein Originalbild auch verwenden will, dann muss ich das irgendwie auf die Größe mit anlegen (also bspw. bei orig. 2560px Breite, mit 640px und 4x oder 512px und 5x), und dann wird es brav mitberechnet – also neu berechnet. Kann ich dem Eintrag nicht irgendwie mitgeben, dass er diese Größe nicht berechnen soll, sondern das Original verwenden? Nur übers Template, oder?
13.04.2017, 06:22
tab

Hmm, also ich habe eine Installation, bei der das große Originalbild automatisch direkt ausgeliefert wird ohne Berechnung. Das ist allerdings nur die einfache Variante mit "srcset=..." ohne <picture>.
13.04.2017, 14:53
wanst

Zitat:

Zitat von tab

Hmm, also ich habe eine Installation, bei der das große Originalbild automatisch direkt ausgeliefert wird ohne Berechnung. Das ist allerdings nur die einfache Variante mit "srcset=..." ohne <picture>.

Zusammen mit anderen Bildgrößen?

Benutzt du dafür die Bildgrößen-Eingabe von Contao? Was hast du da eingestellt oder hast du dann doch das Template bearbeitet, und wie sieht das dann aus?
13.04.2017, 14:55
Spooky

Zitat:

Zitat von wanst

Nochmal zurück zu einem der ersten Posts: kann ich den Eintrag noch weiter beeinflussen? Wenn ich im Moment mein Originalbild auch verwenden will, dann muss ich das irgendwie auf die Größe mit anlegen (also bspw. bei orig. 2560px Breite, mit 640px und 4x oder 512px und 5x), und dann wird es brav mitberechnet – also neu berechnet.

Sicher? Zeige mal die Einstellungen und einen Link zur Seite wo man das sieht.
13.04.2017, 15:03
wanst

So langsam hab ich Blut geleckt. Jetzt will ich aber auch die, in dem RockSolidThemes erwähnten, Repsonsive Bilder mit »Art Direction« –*also Bildausschnitts-»Vergrößerung« ausprobieren.

Aber bedeutet das nicht, dass für jeden Eintrag, den ich da tätige und der sich dann im Picture-Element als <source...-Eintrag wiederfindet, NOCH ein zusätzliches Bild berechnet werden muss? Perfomancemäßig ist das doch mittlerer Wahn, oder?
13.04.2017, 15:07
Spooky

Ja, oder sogar mehrere pro <source> Einträge ;)
13.04.2017, 15:19
wanst

Liste der Anhänge anzeigen (Anzahl: 1)

Zitat:

Zitat von Spooky

Sicher? Zeige mal die Einstellungen und einen Link zur Seite wo man das sieht.

Nee, nicht sicher. Aber vermutlich schon, denn:
1. das Bild für 2560w im Quelltext ist ein neu Angelegtes im Cache mit einem Namenszusatz (bspw. Dateiname-cf909a77.jpg).
2. die Performance-Probleme hingen immer an dieser Bildgröße. Wenn ich die weggelassen habe, lief alles.

Link geht im Moment leider nicht, weil ich gerade wild am Testen bin und das ständig anders aussieht. Vielleicht setze ich vor Ostern noch einen Test auf, den ich dann hier verlinken kann.

Die Einstellungen:
Anhang 19199
13.04.2017, 15:21
wanst

Zitat:

Zitat von Spooky

Ja, oder sogar mehrere pro <source> Einträge ;)

Zack – und schon wieder gestorben...

Schade, Mann! :(
13.04.2017, 16:23
lucina

Zitat:

Zitat von wanst

Aber wenn das Bild einmal berechnet und gecachet ist, dann gehts. Das heißt, sollte es wieder mal nicht reichen, lege ich das Bild auf eine leere Seite, rufe die einmal auf und verschiebe dann das Bildelement in den Artikel, in dem ich es brauche? So, als Workaround. Läuft sowas?

Das läuft genau einen Monat lang. Danach räumt Contao den Bildercache auf.

Du solltest ernsthaft die Hostingoptionen prüfen. Auch die des Kunden - wobei ich mir ohnehin nicht vorstellen kann, dass jemand vierstellige Summen für Webseiten ausgibt um dann am Hosting zu sparen ... ;-)
13.04.2017, 16:53
mlweb

Zitat:

Zitat von lucina

wobei ich mir ohnehin nicht vorstellen kann, dass jemand vierstellige Summen für Webseiten ausgibt um dann am Hosting zu sparen ... ;-)

Ist aber gelegentlich leider die Realität. Häufig geht es aber dabei nicht vorrangig nur um den Preis. Man scheut sich aus den verschiedensten, nicht immer nachvollziehbaren Gründen vor einem Umzug.
In letzter Zeit einige Male untergekommen ist mir Dienstleister A hat Hoster X in den höchsten Tönen gelobt und dem Kunden empfohlen. Der Kunde ist gerade dahin umgezogen bzw. hat den Vertrag gerade neu abgeschlossen. Dann rede ich mir mit meiner Empfehlung den Mund fusslig, entweder weil der Kunde den Aufwand nicht noch einmal haben will, Vertragslaufzeiten einzuhalten sind (keine Doppelzahlung) oder weil der Dienstleister sein Gesicht nicht verlieren will.
Anderes mehr oder weniger häufiges Szenario Dienstleister B hostet als Reseller selbst, möchte auf seine Kunden nicht verzichten und/oder arbeitet für so etwas mit äußerst knappen Ressourcen.
13.04.2017, 18:06
wanst

Ok, hab doch schnell einen Test aufgesetzt:
test.larxperimente.de

Die Bilder werden neu berechnet. Das mit dem blauen Fernrohr hat original 355 kB, das im Cache 426 kB. Wahrscheinlich war das Original stärker komprimiert. Also, noml die Frage: wie bring ich dem Dingen bei, dass es das originale Bild mitbenutzen soll?

@lucina & mlweb: Womit wir bei der Frage nach dem besten Hosting-Provider wären.
13.04.2017, 18:30
mlweb

Zitat:

Zitat von wanst

@lucina & mlweb: Womit wir bei der Frage nach dem besten Hosting-Provider wären.

Den besten gibt es m.E. nicht. Ist ja auch ein Unterschied ob ich einen Shop betreibe oder eine Präsenzseite für ein kleines lokal arbeitendes Unternehmen. Gute Hoster werden hier ja immer wieder genannt z.B. Allinkl, Webgo, früher auch domainfactory, Uber. Schau mal im Hosterbereich des Forums. Da gibt es einige Threads zu auch mit Vor- und Nachteilen bzw. Besonderheiten.
13.04.2017, 19:10
lucina

Zitat:

Zitat von mlweb

Ist aber gelegentlich leider die Realität. Häufig geht es aber dabei nicht vorrangig nur um den Preis. Man scheut sich aus den verschiedensten, nicht immer nachvollziehbaren Gründen vor einem Umzug.
In letzter Zeit einige Male untergekommen ist mir Dienstleister A hat Hoster X in den höchsten Tönen gelobt und dem Kunden empfohlen. Der Kunde ist gerade dahin umgezogen bzw. hat den Vertrag gerade neu abgeschlossen. Dann rede ich mir mit meiner Empfehlung den Mund fusslig, entweder weil der Kunde den Aufwand nicht noch einmal haben will, Vertragslaufzeiten einzuhalten sind (keine Doppelzahlung) oder weil der Dienstleister sein Gesicht nicht verlieren will.
Anderes mehr oder weniger häufiges Szenario Dienstleister B hostet als Reseller selbst, möchte auf seine Kunden nicht verzichten und/oder arbeitet für so etwas mit äußerst knappen Ressourcen.

Ja, das gibt es. Ich hatte im letzten Jahr auch so einen Fall - der Kunde sass mit an meinem Schreibtisch und verstand erst dann, was parasitäre Geschäftsmodelle sind, nachdem wir mal dreieinhalb bezahlte Stunden von mir auf einen Hoster zwecks Anlage einer Subdomain (im automatisierten Verfahren!) gewartet haben und danach noch einmal zwei Stunden auf die Anlage einer weiteren Datenbank. Der brauchte das regelrecht, dass hinterher mehr als ein halber Tagessatz auf der Uhr war. Das fand er erst dann heftig, als ich - während diese Aktion lief - seine neue CMS-Installation dreimal innerhalb von 20 Minuten auf eines meiner Hostings bei einem anderen Anbieter deployed hatte, mal aus Neugier über Twitter einen Supportfall initiiert haben und innert derselben 20 Minuten befriedigende Antwort hatten.

Das war deutlich, und so relativieren sich dann auch Kosten für frisch bezahlte Jahresverträge.

Zitat:

Zitat von wanst

@lucina & mlweb: Womit wir bei der Frage nach dem besten Hosting-Provider wären.

Den gibt es nicht - es gibt nur Hosting, dass den Aufgabenstellungen angemessen ist oder eben auch nicht. Dabei kann es dann durchaus auch unterschiedliche Ergebnisse geben.

Beispielsweise sind Hostings mit viel RAM (und da meine ich > 1GB) sehr fein zum Entwickeln. Darunter bis minimal 256 MB finde ich es geeignet für bildlastige Seiten, bei denen ich mir Klimmzüge beim Deployment und bei Updates ersparen möchte. Darunter, mit minimaler Ausstattung von 128 MB, finde ich Hostings, die sich für Seiten eignen, die einfach nur laufen und keine grossartigen Funktionen mitbringen. Bei Installationen mit vielen Einzeldateien kann es auch beachtenswert sein, wieviele Dateien das (virtualisierte) Dateisystem des Hosters verkraftet - 100 GB Plattenplatz mit einem Limit von 500'000 Dateien kann schneller als gedacht voll sein.

Weiterhin sollte man berücksichtigen, wie schnell ein Hosting an den nächsten Knoten angebunden ist, wie schnell man auf die Datenbanken zugreifen kann - wobei ich auch schon Angebote gesehen habe, die mit SSD langsamer waren als die Konkurrenz ohne. Aus Sicherheitsgründen fallen dann alle Hostings raus, die keinen Zugriffe über SSH bieten, und wenn ich dann noch die Firmen rausrechne, die aktiv das Leben mit Let's Encrypt schwer machen und ihre Produkte nur als Bundles mit 'Inklusivleistungen' von Domains bis hin zu SEO-Coachings anbieten, dann bleibt eine recht überschaubare Anzahl vorwiegend kleinerer und mittlerer Firmen übrig.

Merksatz sollte weiterhin sein: Wer Fernsehwerbung macht und dabei komplexe Sachverhalte hinter Wortwolken versteckt, der ist IMHO nicht seriös.
13.04.2017, 20:20
tab

Zitat:

Zitat von wanst

Ok, hab doch schnell einen Test aufgesetzt:
test.larxperimente.de

Die Bilder werden neu berechnet. Das mit dem blauen Fernrohr hat original 355 kB, das im Cache 426 kB. Wahrscheinlich war das Original stärker komprimiert. Also, noml die Frage: wie bring ich dem Dingen bei, dass es das originale Bild mitbenutzen soll?

Wie groß ist das Original (in Pixel)? Es wird genau dann benutzt, wenn eines der berechneten Bilder exakt die gleiche Größe in Pixel hätte. Wäre das Original also z.B. 2560*1707 Pixel groß, dann würde es auch benutzt.
13.04.2017, 20:36
wanst

Zitat:

Zitat von tab

Wie groß ist das Original (in Pixel)? Es wird genau dann benutzt, wenn eines der berechneten Bilder exakt die gleiche Größe in Pixel hätte. Wäre das Original also z.B. 2560*1707 Pixel groß, dann würde es auch benutzt.

Das Original IST genau 2560*1707 px groß und das Original wird nicht benutzt. Ich hab die letzte Größe ja extra so angelegt, dass exakt das Maß dabei rauskommt.

Damit du das vergleichen kannst, habe ich Großansicht/Neues Fenster eingestellt.
13.04.2017, 20:49
tab

Komisch, bei mir sieht es auf einer privaten Seite z.B. für das Headerbild in voller Breite so aus:

HTML-Code:

<img src="files/themes/theme_sf59/Ausfluege-Header.jpg" srcset="files/themes/theme_sf59/Ausfluege-Header.jpg 2560w, assets/images/1/Ausfluege-Header-562864a1.jpg 1280w, assets/images/3/Ausfluege-Header-428888c3.jpg 640w" sizes="100vw" alt="">

Hier wird ganz klar das Original hergenommen.
13.04.2017, 22:17
wanst

stimmt, ganz klar. Hm, erstaunlich! Einmal so, einmal anders. Kann es an der Reihenfolge liegen?

Ich probier mal was...
13.04.2017, 22:25
wanst

Aaaah!

Ich hab jetzt mal den Bildercache geleert und siehe da:

Zitat:

Kaum macht man's richtig, schon gehts!

Irgendwann hat er wohl mal ein 2560px-Bild erzeugt und in den Cache gelegt und daraufhin immer das verwendet, anstelle des Originals. Aber warum wurde es überhaupt erst angelegt?
13.04.2017, 22:29
wanst

Ach so, »ich probier mal was...« war, eine weitere Bildgröße anzulegen, mit der Ausgangsgröße 2560px und den Skalierungen in umgekehrter Reihenfolge, analog zu deinem Quellcode:
test.larxperimente.de/bildgroessen-gross-zu-klein.html
13.04.2017, 22:36
wanst

Mist, zu früh gefreut. Nach dem Neuladen oder nach dem Aufruf über das zweite Bildformat hatter doch wieder Cache-Bilder für die 2560px angelegt. Jetzt weiß ich auch nicht mehr weiter.
13.04.2017, 23:44
Znrl

Also, wenn ich das ganze so eingebe wie du, komme ich auf das selbe Ergebnis.

Ein paar test (unvollständig):

Lösche ich jetzt aber die Höhe raus.
Steht also in der Bildgröße nur noch 640 breit, Höhe ist leer.

Dann bekomme das original Bild im srcset.

Es scheint hier andersrum nicht zu funktionieren, nur eine Höhe liefert auch keine Originaldatei,
außer ich geben dort die 1707 ein.

Breite und Höhe als 2560 und 1707 funktioniert auch.

Also hat das mit den Einstellungen für Höhe und Breite zu tun.

edit:
Und wenn ich das jetzt richtig seh liegt das an der Image Klasse Image.php
(3.5.25) ab Zeile 418.
Da sowohl Breite als auch Höhe angegeben sind aber nicht mit der orginalen Größe übereinstimmen ist Contao der Meinung, dass hier die Größe geändert werden muss.

Sprich:
Eines der Felder MUSS leer sein oder der Breite/Höhe des Originals entsprechen.
(Und kein Zoom.)
14.04.2017, 06:55
Spooky

Könnte man als Bug melden.
14.04.2017, 15:37
Znrl

Habs mal eingetragen:

https://github.com/contao/core/issues/8700
14.04.2017, 17:00
wanst

Noch eine Verständnisfrage

Welchen Wert lege ich als Basis bspw. bei Breite in den Bildgrößen-Einstellungen fest und wie wirkt sich das aus?

Sagen wir, ich habe ein Bild, das wie in meinen Beispielen immer fast in voller Breite dargestellt werden soll. Und angenommen, ich will vier Größen, auf die der Browser zurückgreifen kann: 320, 640, 1280, 2560 Pixel.

Das kann ich ja einmal so definieren, dass ich als Basisbreite 640px angebe und als Pixeldichten 0.5x,1x,2x,4x
oder
320px + 1x,2x,4x,8x
oder in umgekehrter Richtung
2560px + 0.125x,0.25x,.0.5x,1x.

Und ich habe das Sizes-Attribut:
(min-width:1280px) 90vw, (min-width:1650px) 85vw, 100vw.

Was ist der Unterschied zwischen den Varianten bei den Pixeldichten? Wann wird die Basisbreite verwendet?

In Erklärungen habe ich gelesen, der Browser entscheidet, welche Größe verwendet wird – aber anhand welcher Kriterien? Fließt da CSS mit ein? Falls nicht, muss ich für jede vorkommende Bildgröße im Layout diese im CSS und hier in den Bildgrößen angeben?
14.04.2017, 17:54
Znrl

Zuerst nocha als nachtrag, dass das mit der Breite oben nicht funktioniert liegt daran, dass man mit den 640px als Einstellung natürlich nicht auf die native Bildauflösung kommt.
Hätte man hier einen Wert, bei dem man mit einem Skalierungsfaktor auf die 1707 kommt, verhält sich das genau wie die Breite.

Zusammenfassend:
Man sollte vtl. vermeiden Breite und Höhe anzugeben außer die Abmessungen/Seitenverhältnisse sind in der Regel gleich.
Gegebenenfalls dafür zwei Bildgrößen anlegen, eine für Hochkant und eine für Querformat.

Dann hast du auf der Seite gerade eine srcset Angabe bei der nur "w" steht ohne Zahl... schau dir mal die Einstellungen an?

Was genommen wird entscheidet dann der Browser anhand der Angaben, die Reihenfolge sollte dabei keine Rolle spielen.
Das sizes wird zur Berechnung gebraucht.

Vereinfacht wohl so:
Wenn das Browserfenster 1000px breit ist, du aber sagst das bild wird nur auf 50vw (quasi 50%) Angezeigt nimmt er nur das Bild für 500px Breite.

http://pmueller.de/blog/responsive-b...eberblick.html
https://blog.kulturbanause.de/2014/0...izes-adaptive/
14.04.2017, 18:40
Spooky

Zitat:

Zitat von wanst

Und ich habe das Sizes-Attribut:
(min-width:1280px) 90vw, (min-width:1650px) 85vw, 100vw.

Wie schon vorher erwähnt: du willst wahrscheinlich max-width verwenden, nicht min-width.
14.04.2017, 19:15
wanst

Zitat:

Zitat von Znrl

Zuerst nocha als nachtrag, dass das mit der Breite oben nicht funktioniert liegt daran, dass man mit den 640px als Einstellung natürlich nicht auf die native Bildauflösung kommt.
Hätte man hier einen Wert, bei dem man mit einem Skalierungsfaktor auf die 1707 kommt, verhält sich das genau wie die Breite.

ich war der Ansicht (soll heißen, ich hab gelesen), dass die jeweils längere Seite den Ausschlag gibt. Die Höhe sollte demnach also keine Auswirkung haben. Allerdings brauche ich die auch gar nicht, hab das nur ausgefüllt, weil ich nicht wusste, dass man es auch leer lassen kann. Dann aber selber schon mal ausprobiert – darum hatte es wohl zwischendrin mal funktioniert.

Zitat:

Dann hast du auf der Seite gerade eine srcset Angabe bei der nur "w" steht ohne Zahl... schau dir mal die Einstellungen an?

Das finde ich auch merkwürdig, aber darauf habe ich doch gar keinen Einfluss. Das ist, was Contao daraus macht.

Zitat:

Was genommen wird entscheidet dann der Browser anhand der Angaben, die Reihenfolge sollte dabei keine Rolle spielen.
Das sizes wird zur Berechnung gebraucht.

Vereinfacht wohl so:
Wenn das Browserfenster 1000px breit ist, du aber sagst das bild wird nur auf 50vw (quasi 50%) Angezeigt nimmt er nur das Bild für 500px Breite.

http://pmueller.de/blog/responsive-b...eberblick.html
https://blog.kulturbanause.de/2014/0...izes-adaptive/

schau ich mir grade an. Danke.
14.04.2017, 19:18
wanst

Zitat:

Zitat von Spooky

Wie schon vorher erwähnt: du willst wahrscheinlich max-width verwenden, nicht min-width.

Wann wurde das erwähnt? Aber nein, ich will das eigentlich genauso – dachte ich zumindest, analog zur CSS-Definition und Mobile First und so.
14.04.2017, 19:43
Znrl

Zitat:

Zitat von wanst

ich war der Ansicht (soll heißen, ich hab gelesen), dass die jeweils längere Seite den Ausschlag gibt. Die Höhe sollte demnach also keine Auswirkung haben. Allerdings brauche ich die auch gar nicht, hab das nur ausgefüllt, weil ich nicht wusste, dass man es auch leer lassen kann. Dann aber selber schon mal ausprobiert – darum hatte es wohl zwischendrin mal funktioniert.

Prinzipiell richtig (bei "proportional") nur an der Stelle an der Contao entscheidet das zu resizen ist noch nicht bekannt welche Seite die längere ist.

Die Reihenfolge bei srcset in <img> ist egal, weil der Browser alles anschaut und dann das passende benutzt. Es gibt hier kein Mobile First.
Anders sieht das bei picture und source etc aus, dort wird das erste passende benutzt.
14.04.2017, 19:59
Spooky

Zitat:

Zitat von wanst

Wann wurde das erwähnt?

Ah, dachte das hatte ich vorhin schon mal erwähnt, aber ist doch nicht der Fall.

Zitat:

Zitat von wanst

Aber nein, ich will das eigentlich genauso – dachte ich zumindest, analog zur CSS-Definition und Mobile First und so.

So wie du das jetzt geschrieben hast, würde bei einer Viewport Breite von zB 1920px die Größe 90vw genommen werden.
16.04.2017, 23:54
Andreas

Hast du auch schon das Video gesehen? https://www.youtube.com/watch?v=ub8yROSQyQ4&t=1300s
19.04.2017, 13:08
wanst

Zitat:

Zitat von Andreas

Hast du auch schon das Video gesehen? https://www.youtube.com/watch?v=ub8yROSQyQ4&t=1300s

Hi Andreas, danke für den Link. Ich hatte die Beiträge von Peter Müller zwar schon gelesen, das Video war trotzdem ganz nützlich.
30.04.2017, 18:43
blue12

Hallo,

gibt es denn eine Möglichkeit oder eine Erweiterung um die Bilder zum Beispiel schon beim speichern der Artikel-Elemente zu erstellen? Oder um sie Step-By-Step zu erstellen. Also das bei jedem Seitenaufruf zum Beispiel immer nur eine maximale Anzahl an Bildern gerendert wird?
Ich arbeite gerade an einem One-Pager, welcher neben normalen Contentbildern auch viele große Hintergrundbilder (mit verschiedenen Bildgrößen) hat. Und wenn dort auf einmal alle Bilder der Seite erstellt werden sollen kommt das System ganz schnell an seine Grenzen.

Oder gibt es evtl. die Möglichkeit das automatische leeren des Bilder-Caches zu deaktivieren? Somit könnte ich die Bilder in der lokalen Entwicklungsumgebung erstellen lassen und dann per FTP auf den Server legen. Wenn Contao später dann nicht den Bild-Cache löscht, sollte das erst einmal funktionieren.

Robert
30.04.2017, 19:10
Znrl

Also bei Bildern die ich sag mal zum Layout gehören etc., alles was sich nicht oft ändert und nicht von jemandem geändert werden soll, der das anders nicht hinbekommt....
Würde ich als alternative vorschlagen das ganze über ein eigenes Template oder Modul eigenes HTML zu machen und dann für alle Bildgrößen ein wirklich selbst optimiertes Bild zu nehmen.
Dann muss Contao nichts erstellen und das "kleinere" Bild ist am ende nicht größer als das orginale.
30.04.2017, 19:22
blue12

@Znrl, ja das ist auch meine derzeitige Lösung. Ich wollte nur gern wissen ob es nicht noch andere Lösungsansätze mit den Bildgrößen gibt. Denn wenn nun doch einmal eines der Hintergrundbilder geändert werden muss, kann es der Redakteur nicht einfach über das CMS machen. Sondern muss die Bilder erst wieder per Hand oder über einen andern Weg erstellen. Das finde ich sehr schade. Denn die Bildgrößen sind schon eine tolle Sache! Nur das sie eben alle auf einmal erstellt werden, wenn der Cache leer ist, ist problematisch. Und für eine kleine One-Pager Webseite brauche ich ja kein Server Paket mit 1GB oder mehr RAM.

Es wäre halt toll, wenn es eine Möglichkeit gäbe, die Bilder in mehreren Schritten erstellen zu lassen. Oder direkt beim Speichern eines Inhaltelements, oder etwas ähnliches ;)
30.04.2017, 20:00
Znrl

Ob es das schon gibt weiß ich nicht aber das Erstellen wäre vtl. über ein Callback möglich, dann müsstest du noch dafür sorgen, dass der Bilder Cache nicht gelöscht wird.
https://community.contao.org/de/show...-an-sehr-lange
01.05.2017, 15:49
Andreas

Man könnte auch einen smarteren purgeImageCache() als Cron aufsetzen als den vorhandenen https://github.com/contao/core/blob/...mator.php#L129

Dann könnte man z.B. sagen, dass er nur Bilder löschen soll, die älter als, z.B. 90 Tage sind und auch ein Limit einrichten, z.B. 200. Evtl. könnte dieser dann auch wöchentlich, anstatt monatlich laufen. Außerdem könnte man ihn noch als echten Cron ausführen, welcher dann z.B. Nachts automatisch läuft.