Grafikformat webp: Delay bei Anzeige trotz hoher Datenersparnis

  • Firefox-Version
    90
    Betriebssystem
    Windows 10

    Hallo zusammen,

    u.a. Google empfiehlt, bei Bildern das "next generation format" WEBP statt z.B. GIF, JPG oder PNG zu verwenden. Tatsächlich verringert das Format die Dateigröße meiner Erfahrung nach je nach Motiv um 20-80%, und mit bloßem Auge sind die geringfügigen Unterschiede bei verlustbehafteter Komprimierung kaum zu sehen.

    Da noch nicht alle Browser WEBP unterstützen, ist man darauf angewiesen, ein altes Format (GIF, JPG oder PNG) als Fallback vorzuhalten. Dazu gibt es das HTML-Tag <picture> sowie in CSS image-set.

    Probleme:

    1. WEBP-Bilder werden trotz Caching zumindest im Firefox im Vergleich zu den anderen Formaten mit leichter zeitlicher Verzögerung dargestellt, was auch mit bloßem Auge auffällt, wenn z.B. auf einer Seite verschiedene Formate zusammen auftreten. Die GIFs, JPGs und PNGs erscheinen immer alle zeitgleich, bevor dann kurz darauf die WEBPs folgen. Das ist schade, weil das WEBP in meinem Fall 80% der Dateigröße einspart, aber trotzdem im Vergleich zu den anderen (deutlich größeren) Formaten verzögert angezeigt wird. Ist das WEBP-Rendering derzeit ggf. noch nicht ganz optimal und wird noch genauso schnell wie bei GIF, JPG und PNG?

    Edit: In Microsoft Edge tritt die kleine Verzögerung bei der Anzeige von WEBPs übrigens so nicht auf. Allerdings werden die WEBPs dort seltsamerweise nicht gecacht (im Firefox dagegen schon), obwohl vom Webserver alle vier Formate dafür vorgesehen sind.

    2. <picture> funktioniert einwandfrei, aber image-set in CSS (z.B. für Hintergrundbilder benötigt) unterstützt in den gängigen Browsern tatsächlich das type-Attribut noch nicht, obwohl es bereits dokumentiert ist: https://developer.mozilla.org/en-US/docs/Web/CSS/image/image-set()

    Sobald man im image-set eine url mit type ergänzt, wird das ganze image-set nicht mehr berücksichtigt, und der Fallback auf das vorangestellte "background-image: url" ohne image-set greift. Ist hier schon etwas dokumentiert, was tatsächlich im Browser noch nicht funktioniert?

    Einmal editiert, zuletzt von dark_rider (15. Juli 2021 um 11:29)

  • Zur hilfreichsten Antwort springen
  • Hallo,

    bitte zeige ein konkretes Beispiel, wo das Problem nachvollzogen werden kann. Nach Implementierung von WebP via picture-Element und srcset auf mindestens 50 verschiedenen Websites habe ich noch kein Performance-Problem mit WebP gesehen. Als WebP-Decoder in Firefox kommt übrigens libwebp zum Einsatz, also der gleiche, der auch in Chrome und darauf basierenden Browsern wie Edge verwendet wird.

    Da noch nicht alle Browser WEBP unterstützen

    Das noch kann gestrichen werden. Jeder halbwegs aktuelle Browser unterstützt WebP. Die Browser, die zu diesem Zeitpunkt kein WebP unterstützen, werden es auch nie unterstützen. Das sind in erster Linie der Internet Explorer und Safari auf Betriebssystemen älter als Big Sur.

    2. <picture> funktioniert einwandfrei, aber image-set in CSS (z.B. für Hintergrundbilder benötigt) unterstützt in den gängigen Browsern tatsächlich das type-Attribut noch nicht, obwohl es bereits dokumentiert ist: https://developer.mozilla.org/en-US/docs/Web/CSS/image/image-set()

    Sobald man im image-set eine url mit type ergänzt, wird das ganze image-set nicht mehr berücksichtigt, und der Fallback auf das vorangestellte "background-image: url" ohne image-set greift. Ist hier schon etwas dokumentiert, was tatsächlich im Browser noch nicht funktioniert?

    Ich habe https://codepen.io/team/css-tricks/pen/GRWbOWz in Firefox 90 getestet und das funktioniert.

  • Das Performance-Problem ließ sich zwischenzeitlich mit einer serverseitigen Änderung der Caching-Vorgaben lösen.

    Auch FF 90 ignoriert image-set allerdings, sobald man dabei das type-Attribut verwendet. Code-Beispiel:

    Code
    <table><tr>
         <td style="background-image:url(bgpic_fallback1.png); background-image:image-set(url(bgpic.webp) type(image/webp), url(bgpic_fallback2.png) type(image/png));">
    </tr></table>

    Hier wird leider stets bgpic_fallback1.png verwendet.

    Ohne type lässt sich für per CSS eingebundene background-images allerdings kein Fallback realisieren.

    • Hilfreichste Antwort

    Auch FF 90 ignoriert image-set allerdings, sobald man dabei das type-Attribut verwendet. Code-Beispiel:

    Hast du dir das von mir verlinkte Beispiel angesehen? Dort siehst du nämlich die korrekte Syntax. Du hast die Anführungszeichen innerhalb von type() vergessen. Mit Anführungszeichen klappt auch dein Beispiel. Auch in den Beispielen im MDN sind übrigens die Anführungszeichen zu sehen.

  • Tatsächlich, die Anführungszeichen machen den Unterschied. Auch wenn die Argumente in CSS anderswo auch ohne sie funktionieren, funktioniert type() innerhalb von image-set nur mit Anführungszeichen (egal ob ein- oder zweistrichig) zwischen den Klammern. Dankeschön!

    Jetzt bleibt zu hoffen, dass Chrome, Edge usw. das type()-Argument in image-set auch bald berücksichtigen, am besten auch ohne das Präfix -webkit-.

  • Das kann noch dauern. Das Ganze ist noch ein Entwurf, es gibt noch keine finale Spezifikation. Vor allem wird man auf Apple warten müssen, ehe man von einer flächendeckenden Verfügbarkeit sprechen kann. Andererseits macht background-image gewisse Anwendungsfälle einfacher, man könnte das meiste aber auch über Bilder im HTML und dann einer darüber positionierten Inhaltsfläche lösen. Das müsste man im Einzelfall betrachten, ob und wie das sinnvoll umsetzbar ist. Da sieht, wenn das eine Option ist, die Kompatibilität jedenfalls besser aus und es hat auch a11y-Vorteile, da man ein alt-Attribut setzen kann.

  • Das Performance-Problem ließ sich zwischenzeitlich mit einer serverseitigen Änderung der Caching-Vorgaben lösen.

    Ganz konkret war in punkto Caching übrigens zumindest beim hier verwendeten Hoster der Knackpunkt, dass Apache 2.4 den MimeType "image/webp" standardmäßig noch nicht kannte, so dass man ihn vor einem etwaigen Expires-Kommando z.B. im .htaccess erst selbst ergänzen muss:

    Code
    AddType image/webp .webp
    ExpiresByType image/webp "access plus 1 week"