Muss unbedingt WebP haben, weil Google das empfiehlt

  • WebP ist ein Bilderformat, also so was wie JPG, PNG oder GIF, von dem Google behauptet(e) es sei sooooo viel besser, was Bilder-Optimierungen für das Web anbelangt. Also "verkleinern" des Speicher- und Ladebedarfs von Bilder im Internet. Ist ja schließlich eine Entwicklung aus dem Hause G. Muss besser sein.


    Eh klar, dass dann aus diversen (Teils-Pseudo-)SEO-Ecken nach WEBP-Unterstützung geblöckt wird.


    Also begab ich mich mal in die Herde:


    Nach 3 Tagen testen unter realen Joomla-Verhältnissen mit einem meiner Joomla-Plugins, das auch für Bildoptimierung zuständig ist, sehe ich die pauschal versprochenen Effekte (25-30% Bildgrößenreduzierung im Vergleich zu z.B. JPG) NICHT.


    Es ergaben sich WEBP-Bilder (aus einem großen JPG-, PNG-, GIF-Mischmasch einer Live-Seite),

    - die sind etwas kleiner,

    - andere sind größer,

    - andere sind gleich

    (bezogen auf die Speichergröße in kB).


    Generell: Sehr große Bilder (> 1200px), kaum positive Effekte.


    Einziges Format, wo ich sage "generell OK" sind PNG-Bilder im Fireworks-Format, die mir aber sowieso nur versehentlich auf den Server gelangen. Die habe ich aber auch nicht verglichen mit Umwandlungen nach JPG.


    Dabei habe ich von allen Bildern 5 verschiedene Größen generieren lassen, jeweils im Originalformat sowie im WEBP-Format.


    Nicht konstant der Fall, aber einige WEBP-Bilder sind erheblich verpixelter als die Pendants selber Größe. Umgekehrt ist das aber nicht der Fall.


    Im Durchschnitt, bezogen auf Gesamtlade-Volumen einer Joomla-Blog-Seite mit vielen Einleitungsbildern, kann man nur milde lächeln über den dollen Effekt.


    Einschränkend muss man (vielleicht) dazu sagen, dass ich natürlich bei meinen Versuchen bei einem 0815-Provider auf PHP-Bibliotheken angewiesen bin, die auf dem Server installiert sind. Also ein Versuch "unter realen Joomla-Verhältnissen" eines normalen Benutzers.


    Es blieb nur GD, da IMAGEMAGICK bei dem Provider keine WEBP-Unterstützung bietet. Weiß aber auch nicht, ob das unterm Strich Unterschiede macht.


    Als "ausführende Instanz" habe ich die PHP-Bibliothek http://image.intervention.io/getting_started/formats verwendet. Ein Hoch übrigens auf diese Bibliothek, nur nebenbei gesagt. Man lobt ja zu selten...


    Weiteres Kriterium: Da nicht alle Browser WEBP unterstützen (derzeit z.B. Safari), muss man natürlich Fallbacks auf z.B. JPG-Bilder anbieten:

    1) Ca. doppelter Speicherbedarf im Webspace für optimierte Bilder.

    2) Mehr HTML-Code der ausgelieferten Webseite, da ja jedes Bild für den Fallback mehr davon braucht.

    3) WEBP ist ein Format, das meine (zugegeben altertümlichen) Bilder-Anschau-und-Durchblätter-Programme nicht unterstützen.


    Kurz: Der innere Zwang, dass man jetzt unbedingt WEBP-Bilder verwenden muss, weil Google was verspricht, ist bei der einen oder anderen Seite vielleicht angebracht, ein generelles Allheilmittel ist das aber nicht und man sollte Leuten misstrauen, die das bspw. im Zusammenhang mit SEO blind bejubeln.


    Trotzdem lasse ich das jetzt in meinem Plugin drinnen, allerdings mit einem Häkchenfeld zum Deaktivieren ;) Bis dann irgendwann mal MozJPEG (libjpeg-turbo) unter PHP zu neuen Tests einlädt ;)

  • Ich habe eine Zeit lang mit WebP Bildern gearbeitet und habe einen wesentlichen Geschwindigleitsvorteil feststellen können. Ich hatte einige Galerien mit Wep Bilder laufen. Googles Pagespeed-Tool hat da locker 10% Punkte mehr angezeigt, also statt 90% fast 100% bzw. 99%.


    Im Laufe de Zeit stellte ich aber einen Rückgang der Pageviews fest und immer mal kamen auch Hinweise von Besuchen, dass Bilder anscheinend nicht zu sehen waren.


    Mit WebP habe ich mir alle Apple-User die den Safari einsetzen ausgeschlossen, denn diese konnten keine WebP-Bilder sehen. War auf meiner Webseite, die von Bildern lebt natürlich fatal. Ich habe nicht an einen Fallback gedacht und mir ist das auch einfach zu aufwändig.


    Apple weigert sich vehement Google-Standards anzuerkennen bzw. zu nutzen.

    Also lieber ein bisschen langsamere Seite, dafür aber für alle nutzbar.

  • Danke! Super Hinweis, das mit dem PageSpeed. Frage ist, ob man tatsächlich weiß, dass es da um Geschwindigkeit bzgl. Seitenladung geht oder, ob das nicht ein "Hast-du-brav-gemacht-kleiner-Racker"-Bonus-Punkt ist. Manchmal habe ich bei dem PageSpeed-Tool den Eindruck, dass es nicht immer wirklich um "echten" Speed-Gewinn gehen könnte, aber große ??????


    Ja, das Fallbackgebastel ist nervtötend, selbst, wenn man es dann final dynamisch aus JLayouts oder so lädt. Noch dazu, wenn man ja schon fertig war mit seiner "genialen" Plugin-Logik, die nie mit je 2 Bildern gerechnet hat ;) Jedenfalls ekelhaftes HTML, was rauskommt...

  • das mit dem PageSpeed. Frage ist, ob man tatsächlich weiß, dass es da um Geschwindigkeit bzgl. Seitenladung geht oder, ob das nicht ein "Hast-du-brav-gemacht-kleiner-Racker"-Bonus-Punkt ist

    Man müsste es mit "unabhängigen" Pagespeed-Tools vergleichen.
    Google Pagespeed misst auch wann die ersten Inhalte geladen werden und in welcher Zeit wie viel Inhalt (Screenhsots). Wenn anfangs schon Bilder im oberen Bereich der Seite sind, hat das sicher Auswirkungen. Kleine Datei schnelle Ladezeit. Wenn dann noch mit Lasyload gearbeitet wird, sieht das Ganze schon sehr gut aus.


    Mein letzter Stand ist, dass Google zwar auf den Pagespeed achtet, der Rankinfaktor aber überbewertet wird. (Referenz im Netzt finde ich gerade nicht mehr).

  • Glücklicherweise habe ich das vor dem Online-Gang noch mal auf vielen Browsern getestet.


    Firefox zeigt ausnahmslos alle webp korrekt an, die in srcsets responsiv und mit loading=lazy hinterlegt sind.


    Safari brav das Fallback-Bild.


    Schrägerweise: Alle auf Chromium basierenden Browser (Vivaldi, Chrome, Edge, Opera) haben konstant Probleme und zeigen viele Bilder nicht an.


    Selbst Bilder aus der selben Quelldatei in verschiedene webp-Größen konvertiert, werden teils angezeigt, teils nicht. Bei anderen Quelldateien werden dann wieder alle Größen angezeigt. Für mich ist keine Logik zu erkennen.


    Kurz: Außer mit Firefox pure Lotterie.


    Schade um 50% der damit verbrachten Zeit.

    Trotzdem lasse ich das jetzt in meinem Plugin drinnen, allerdings mit einem Häkchenfeld zum Deaktivieren

    Häkchen geklickt und good-bye....