Bilder per img srcset oder lieber automatisch skaliert ausliefern?

  • Derzeit zeige ich ja Bildchen in responsive Layouts an, indem ich die per CSS und einer Klasse an die Breite anpasse:

    Code
    img.scale-2-grid{max-width:100%;height:auto;}

    Jetzt gibt es ja auch die Möglichkeit, mir gleich für das richtige Monitorformat, bzw. dem grade verwendeten Responsive-Layout das passende Bildchen zu verwenden.

    Code
    <img srcset="  /bild1.jpg,  /bild2.jpg,  /bild3.jpg,  /bild4.jpg " src="/bild-fallback.jpg" >

    Die richtige Bildgröße automatisch zu generieren ist ja kein Problem, auch das srcset in den Quelltext reinzuwürgen nicht.

    Aber wie ist das dann mit dem google-Bilderbot?
    Welches Bild nimmt der dann? Hat der eine bevorzugte Größe in px?
    Oder indexiert der dann einfach mal alle Bilder aus dem srcset? Oder keines? Oder einfach irgendeines?

    Wer zuerst "Datenschutz" sagt, hat verloren.

  • ja

    weiss jetzt nicht wo die grenze ist, aber das ist denke mal noch im Rahmen. Hab ich auch oft, bei Stockfotos wird auch immer das grösste genommen in der Bildersuche von Google.

    Biete dann halt auch mehrere Versionen an ( per Klick dann das grösste ).

    zB guck mal hier was er da nimmt:

    https://bilder.rocks

    wenn etwas möglich erscheint mach ich das, wenn das nicht klappt gehts ans unmögliche und ansonsten das undenkbare.

    - nun stolz rauchfrei - Ich denke also Bing ich!

    Support 24h Bereitschaft 0173 6107465 - NUR Für Kunden von SEO NW!

  • Alex hat in dem Fall recht, auch wenn nur bedingt. Der normale Google-Bot nimmt erst mal alle URLs, die da sind. Wenn der merkt, dass es ein Bild ist, dann übergibt er es dem Bilder-Bot. Der holt sich dann die Bilder. Und ja, der nimmt dann das größte in den Index auf, aber das bedeutet nicht, dass das das erste ist. Kommt drauf an, ob es das "größte" schon kannte oder nicht.

    Die Frage ist nur, was Google dann in der Bildersuche selbst anzeigt, also als Vorschaubild in der schwarzen Box. Wenn ein Bild zu groß ist, dann nimmt er dennoch ein kleineres und zeigt es dort dann gezoomt an. Merkt man dann, wenn es für paar Sekunden unschaft oder verpixelt ist, bis dann das große nachgeladen wurde. Keine Ahnung, wo die Grenze genau ist, aber ich hatte mal was von 7000px im Kopf.

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

  • OK. Hm... und wie ist das denn, wenn ich jetzt z.B. Wert drauf legen würde, wenn mein Logo auf jedem Bild - also auch auf der kleinsten Bildversion, das per img srcset ausgeliefert wird - gut lesbar ist?

    Wenn das kleinste Bild z.B. nur 340px Breite hat, dann muß mein Schriftzug unten im Bild halt mind 150px breit sein, damit man das noch entziffern kann.
    Ist das Bild aber 1900px breit, dann genügt mir aber ebenfalls ein Schriftzug mit 150px Breite.

    Und das sind doch dann theoretisch andere Bilder? Oder? Oder ist der Bildbot so schlau und kapiert, das das dasselbe Bild ist?

    Denn sonst könnte ich ja auch per img srcset gleich ganz andere Bilder ausliefern:
    Z.B. für Billig-SmartPhone-Besucher kontrastreichere Bilder, weil deren Displays scheisse sind.

    Wer zuerst "Datenschutz" sagt, hat verloren.

  • Das wirste im Zweifel testen müssen, ob das der Bot erkennt. Ich hatte so was mal früher auf meiner Bilderseite. Unten rechts immer den Domain-Namen und ja, immer in der gleichen Größe, egal wie groß das Bild war. Google hat es mal gerafft und mal nicht, kommt wohl drauf an, wie viel unterschied es letztendlich ist.

    Aber ja, ganz andere Bilder ausliefern würde natürlich auch gehen. Fraglich nur, ob der Bot das dann unterscheidet oder nicht einfach doch das größte nimmt. Man kann ja auch andere Formate ausliefern, also mal quer, mal hochkannt. Im Grunde wären das auch andere Bilder.

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

  • Also... ich wollte das img srcset jetzt auch mal im Shop machen und da gehts schon wieder los... Damit wird der der String "bild.jpg" aus der DB geholt und nach dem Muster "/bilder/bild.jpg" ins document geschrieben:

    echo tep_image(DIR_WS_IMAGES . $product_info['products_image']);

    Wenn ich jetzt aber ein img srcset machen will, bei dem ich ein Bild als .jpg und dasselbe als .webp ausliefern will, dann muss ich irgendwie das "jpg" nach dem Dateinamen wegkriegen.
    Da ich das icht am lebenden Kadaver testen will... wäre das so möglich?

    Code
    $file_array = explode(".", $product_info['products_image']);

    $file_array[0] wäre dann der Dateiname ohne Endung.

    Oder bin ich wieder mal - dank meiner überlegenen PHP-Kenntnisse - ganz auf dem Holzweg?

    Wollen will ich am Schluss dann sowas:

    Code
    <picture>
    	<source srcset="/bilder/bild.webp" type="image/webp">
    	<img src="/bilder/bild.jpg">
    </picture>

    Wer zuerst "Datenschutz" sagt, hat verloren.

  • Wenn Du sicherstellen kannst, dass im $product_info['products_image'] der komplette Name ist, also auch mit Dateiendung und die nicht zufälligerweise erst mit der Funktion tep_image() gesetzt wird, dann sollte das so eigentlich gehen.

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

  • Bin ich dann auch mal gespannt. Mit webp hatte ich mal gearbeitet aber dann wieder direkt ignoriert, denn die Dinger waren größer als die normalen jpg oder wenn es es eine Einsparung gab, dann war das weniger als 2%, also den Aufwand nicht wert. Oder anders gesagt, teils war dann der Quelltext so viel größer, dass dort mehr Daten gesendet werden mussten, als das webp eingespart hätte und das wäre dann vor allem im Cache, der Quelltext nicht.

    Mit was hast Du die webp denn erzeugt?

    PS. Echoe das ganze doch einfach erst mal als HTML-Kommentar mit dazu, dann kannst im Quelltext doch nachsehen, ob es passt, ohne dass es Dir eventuell gleich die Webseite zerreißt.

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

  • Mit IrfanView. Die waren auch gleich um 1/3 bis 2/3 kleiner gegenüber jpg, die ich vorher durch JPEGMini laufen lassen habe.
    Meine Formatgrössen sind 500x331px und 290×192px.

    Aber ich kam da eben bei suchen auf ne andere Idee:

    Apache Configuration
    RewriteEngine On
        RewriteCond %{HTTP_ACCEPT} image/webp
        RewriteCond %{DOCUMENT_ROOT}/$1.webp -f
        RewriteRule ^(wp-content/uploads.+)\.(jpe?g|png)$ $1.webp [T=image/webp,E=accept:1]
        Header append Vary Accept env=REDIRECT_accept
    AddType image/webp .webp

    Wer zuerst "Datenschutz" sagt, hat verloren.

  • Kann man so machen, finde ich aber weniger schön, wenn man für die Bildersuche optimiert. Dann steht da zwar ein .jpg im Quelltext, ausgeliefert wird aber ein .webp und da auch noch ohne 301.

    Wobei der Code ehrlich gesagt seltsam ist, oder fehlt da was?

    Ok, JEGMini, hatte ich noch nicht so oft. Meine Bilder werden ja mit PHP erzeugt und da habe ich Qualität 80 eingestellt. Aus denen wird webp nicht wirklich kleiner. Eigene Bilder, also nicht die von Kunden, die das System erzeugt, sondern die von mir kommen, die jage ich durch https://tinyjpg.com/ und da wird webp auch nicht wirklich kleiner.

    Dachte Du hast da ein Tool für den Server, kann ja schlecht über 300.000 Bilder per irfan machen, zumal das ja alles von den Kunden kommt ;)

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

  • Keine Ahnung was der Kot im Detail macht :)
    Ich bin da nur grade drauf gestossen und dachte mir, ob das nicht auch ne Möglichkeit wäre, mir das php-gecode zu ersparen. Bin ja faul und so...

    Also tinyjpg.com ist im Grunde dasselbe wie JPEGmini - nur ist das eine halt webbasiert und das eine haste auf dem Rechner.

    Ein Serverdingens gibts von google: https://developers.google.com/speed/webp/docs/precompiled


    btw:
    Ich habe vormittags mal nen Test gemacht mir 3.000 jpg in einem Ordner.
    IrfanView hat die in knapp 20 Minuten durchgelutscht und zu webp gemacht.

    Photoshop kackte irgendwann nach 700 Bildern ab und brauchte dafür über 2 1/2h.

    Wer zuerst "Datenschutz" sagt, hat verloren.

  • Der Code macht nix anderes als zu sagen, wenn Du webp kannst, dann schreibe ich jpg/png auf webp um. Aber ohne Weiterleitung. Und das REDIRECT_accept ist gar nicht definiert, also sehr seltsam.

    Das Ding von Google kenne ich. Ich bräuchte aber was, das das mit PHP macht. Per Script was ändern kann ich, aber das muss halt automatisiert gehen, wenn ein Kunde in 30 Sekunden ein neues Bild hoch lädt. Habe das eben mit PHP versucht, kann das in den neuen Versionen ja auch. Was soll ich sagen, die Bilder von webp sind nicht kleiner oder nur marginal als JPG mit 80% Qualität.

    Irfan ist einfach nur sau schnell. Was meinst Du, wie oft mir mein Photoshop schon nach 30 Min Wartezeit meinte "keine Rückmeldung", aber alle 16 Cores mit fast 90% belegte ;)

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

  • Kann man da nich so ne serverseitige Batch schreiben?
    Ala "Wenn

    1 Bild in Ordner /kundenbilder neu hinzukommt

    dann

    werfe googles cwebp-script mit folgenden Parameter an

    checke das alle 10 Minuten nach"

    Wer zuerst "Datenschutz" sagt, hat verloren.

  • Im Prinzip ja, aber dafür müsste man exec-Command zulassen und das ist bei mir aus Sicherheitsgründen nicht erlaubt. Ist es auch per Default nicht, bei keiner Distribution. PHP kann ja so an sich nur auf seine eigenen Funktionen/Module zugreifen, aber nicht auf System-Programme.

    Man könnte es auch per node.js machen, aber dann muss man sich erst mal extra dafür einen Node-Server aufsetzen (Hat Alex für das Cookie-Script). Zu aufwendig und fehleranfällig für den doch geringen Nutzen.

    Beides ist nicht meins, wenn ich da SIcherheitsfunktionen umgehen muss oder mögliche neue Schwachstellen installiere, nur damit ein Host von 30, dann Bilder als webp speichern kann.

    Ahso, Batch, jetzt erst verstanden, also als Cron. Nee, nicht sinnvoll. Machbar ja, aber nicht sinnvoll. Erstens meckern dann die Kunden sofort rum, weil die ein hochgeladenes Bild nicht sofort sehen und wittern einen Fehler, zweitens ist das Overhead ohne Ende. Der Cron müsste dann in dem Fall alle 10 Minuten an die 24.000 Ordner und 300.000 Dateien vergleichen, nur um zu sehen, ob da vielleicht was neu ist. Zudem gäbe es Kollisionen bei der Löschung. PHP kann nur löschen, was ihm bekannt ist und auch da ist. Wenn das aber gerade eine Löschung macht, der Cron aber ein Bild erzeugt, dann ist das Bild für immer als Leiche da.


    Wenn schon muss das in Echtzeit gehen und das ist eben entweder node oder exec. Wie gesagt, PHP kann das in Echtzeit, aber da kommt nicht wirklich was sonderbar gutes bei raus, das das rechtfertigt.

    Auf welcher Domain nutzt Du das webp denn nun oder versuchst es? Würde gerne einen Vergleich sehen.

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(