WebP wird standardmäßig für 6.1 nach neuen Einwänden von führenden WordPress-Entwicklern auf Eis gelegt

Letzte Woche arbeiteten die Mitarbeiter des Performance-Teams an der Verfeinerung ihrer Nachfolge-Patches für die Multi-Mime/WebP-Funktion, nachdem die Hauptarbeit dafür Ende Juli in Core für 6.1 zusammengeführt wurde. Dazu gehören kleinere verwandte Elemente wie der Shim für nicht unterstützende Browser und das Hinzufügen von PDF-Unterstützung, die in separaten Tickets behandelt werden.

Der Vorschlag, standardmäßig WebP-Bilder für neue JPEG-Bild-Uploads zu generieren, war von Anfang an umstritten. Während die von Google gesponserten Mitwirkenden, die das Projekt vorantreiben, einige Überarbeitungen nach einer ersten Runde erheblichen kritischen Feedbacks vorgenommen haben, haben andere Mitwirkende weiterhin Bedenken geäußert, dass sie sagten, dass sie nicht berücksichtigt würden. Mehrere Mitwirkende berichteten von Problemen mit dem Feature und schlugen vor, dass es mit einer Opt-in-Funktion beginnen sollte, eine Idee, die kurzerhand verworfen wurde, bevor die Hauptarbeit festgeschrieben wurde.

Letzte Woche hat der führende WordPress-Entwickler Andrew Ozz das Ticket mit neuen Einwänden beschwert:

Wie @MatthiasReinholz, @eatingrules und andere denke ich, dass dieser Ansatz vielleicht fehlt. Warum sollten doppelt so viele Bilddateien viel zusätzlichen Speicherplatz beanspruchen, wenn die Hälfte davon niemals irgendwo verwendet wird?

IMHO wäre ein besserer Ansatz, einfach alle Bilduntergrößen WEBP zu machen. Wenn tatsächlich JPEGs benötigt werden, können diese bei Bedarf on-the-fly generiert werden. Es hat keinen Sinn, den Speicher des Webservers mit all diesen nutzlosen Dateien zu verstopfen.

Wenn andererseits die WEBP-Dateien tatsächlich größer sind als die JPEGs, würde das wahrscheinlich bedeuten, dass bessere Tools benötigt werden, und dieser Patch ist verfrüht.

Vor sechs Wochen bestätigte der von Google gesponserte Core Committer Adam Silverstein als Antwort auf eine Beschwerde, dass die „Ressourcen für die Konvertierung enorm sein würden“, dass die Ressourcen für die Generierung der hochgeladenen Bilder „drastisch ansteigen würden“.

„Allerdings werden die Ressourcen zur Bereitstellung eines Images verringert“, sagte Silverstein. „Da das Hochladen von Bildern im Vergleich zum Bereitstellen von Bildern sehr selten ist, sollte sich der zusätzliche Aufwand zum Komprimieren und Speichern von Bildern lohnen.“

Dies ist ein weiteres Problem, das Ozz in seinem Einwand gegen diesen Ansatz anführt.

„Eigentlich ist dieser dramatische Anstieg der Ressourcennutzung beim Hochladen eines Bildes hier ein sehr schlechter Nebeneffekt“, sagte Ozz. „Das bedeutet, dass viele Uploads fehlschlagen und die Benutzer gestrandet bleiben. Es wird auch die Supportanfragen sowohl für WordPress als auch für die Hosting-Unternehmen dramatisch erhöhen. Halte das nicht für akzeptabel. Aus diesem Grund scheint der aktuelle Ansatz keine gute Lösung zu sein, selbst wenn in WordPress Multi-Mime-Unterstützung für Bilder benötigt wird.“

Ungefähr 24 Stunden später kommentierte der von Google gesponserte Mitarbeiter Felix Arntz, um darauf hinzuweisen, dass der WebP-Fallback-Mechanismus auf JPEG für ältere Browser zum Commit bereit sei und er plane, ihn in ein paar Tagen zu committen.

„Bitte übertragen Sie hier keinen weiteren Code, es sei denn, es geht um den dramatischen Anstieg der Ressourcen, die zum Erstellen von Bilduntergrößen nach dem Hochladen erforderlich sind“, sagte Ozz. „Wie ich oben sagte, ist eine solche Erhöhung inakzeptabel.

„Gibt es Daten darüber, wie viel mehr Ressourcen (Speicher, Verarbeitungszeit usw.) beim Hochladen unterschiedlicher Bildgrößen benötigt werden? Gibt es eine Schätzung darüber, wie viele Websites davon betroffen sein könnten? Irgendwelche Vorschläge, wie man damit umgeht? Wissen Sie, was passiert, wenn die Nachbearbeitung eines hochgeladenen Bildes fehlschlägt?

„Ehrlich gesagt scheint es vorerst, dass dieser Patch rückgängig gemacht und überarbeitet werden muss, um dies zu beheben.“

Adam Silverstein antwortete auf seine Bedenken mit einer Klarstellung, warum sie sich für den aktuellen Ansatz entschieden haben, in Erwartung bestimmter Randfälle, und fügte schließlich Unterstützung für Formate wie AVIF hinzu, sobald es breiter unterstützt wird:

Ich stimme Ihrer Einschätzung eher zu, dass alle Untergrößen nur als WebP generiert werden sollten, das war die Form des ursprünglichen Vorschlags. Für die überwiegende Mehrheit der Anwendungsfälle/Benutzer wird dies am besten funktionieren. Ich wäre offen dafür, dies als Standard in Betracht zu ziehen (mit einigen Abschwächungen, siehe unten).

Der Grund, warum wir uns entschieden haben, beide Formate zu generieren, waren Abwärtskompatibilitätsüberlegungen für die wenigen Randfälle, die wir identifiziert haben, in denen WebP-Bilder möglicherweise nicht funktionieren: nämlich per E-Mail gesendete Bilder (einige ältere Outlook-/Windows-Clients), Open Graph-Tags (einige Dienste unterstützen nicht WebP) und ältere Safari-Browser. Eine Möglichkeit, die wir in Betracht gezogen haben, wäre, nur das JPEG in voller Größe beizubehalten, damit es für diese Grenzfälle immer verfügbar ist.

Die „Multi-Mime“-Unterstützung hier ist darauf ausgelegt, mehrere Formate zu generieren, sodass Ihre Websites ein primäres und ein Fallback-Format mit so etwas wie dem picture bereitstellen können. Dies ist für WebP weniger wichtig, da es so weit verbreitet ist, wäre aber hilfreich, um neuere Formate wie AVIF durch Plugins oder Core zu übernehmen.

Silverstein sagte auch, dass die Option, Bilder im Handumdrehen zu generieren, etwas sei, das sie herausfinden müssten, sich aber „für diese Bemühungen außerhalb des Rahmens befanden“.

Als Antwort auf die Beschwerde bezüglich des dramatischen Anstiegs der Ressourcen für das Hochladen von Bildern sagte Silverstein, dass sie sich auf den „Wiederholungs“-Mechanismus verlassen, um dieses Problem zu entschärfen.

„Diese Änderung verdoppelt auch die Anzahl der Wiederholungsversuche von WordPress bei der Bildregeneration, sodass die Verarbeitungszeit zwar zunehmen wird, aber ich glaube nicht, dass wir unbedingt einen Anstieg der Fehler sehen werden“, sagte er. „Ich weiß, dass wir in der Vergangenheit Probleme hatten, neue Größen hinzuzufügen, aber das war, bevor wir den Wiederholungsmechanismus hinzugefügt haben.“

Das Team hinter dem WebP-by-Default-Projekt konzentriert sich mehr auf die Bereitstellung kleinerer Bildgrößen im Frontend und betrachtet die zusätzliche Ressourcennutzung beim Hochladen als notwendiges Opfer für WordPress-Benutzer.

„Die zusätzlichen Ressourcen zum Zeitpunkt des Hochladens müssen gegen die reduzierten Ressourcen für die Bereitstellung des kleineren WebP-Bildes abgewogen werden, insbesondere da die Bereitstellung in der Regel mehrere Größenordnungen häufiger erfolgt als das Hochladen“, sagte Silverstein.

„Wenn das Hochladen nach allen Wiederholungen fehlschlägt, hat der Benutzer die gleiche Erfahrung wie jetzt: Er bleibt mit einem kaputten, unbrauchbaren Bild zurück. Das kann wahrscheinlich behoben werden, obwohl ich nicht glaube, dass diese Änderung die Ausfallraten erhöht.“

Der führende WordPress-Entwickler Dion Hulse kommentierte auch das Ticket, um Probleme mit WebP-Konvertierungen im WordPress Photo Directory zu melden:

Ich möchte hier nur anmerken, dass diese zusätzlichen Webp-Konvertierungen in den letzten Wochen anscheinend die Hauptursache für Upload-Fehler im WordPress-Fotoverzeichnis waren. Siehe #meta6142 und geschlossene Tickets als Duplikat davon.

Die Fehler betrafen im Allgemeinen die Allowed memory size of 256M bytes exhausted (tried to allocate 90M bytes , während versucht wurde, die anfängliche Original-JPEG->-Webp-Konvertierung in voller Größe durchzuführen.

Es hat sich nicht auf jeden Upload ausgewirkt , nur auf bestimmte Bilder. Möglicherweise im Zusammenhang mit dem $quality Wert, der für Webp-Anfragen übergeben wird (IIRC, der Standardwert von 82 wurde für JPEG optimiert?).

Hulse deaktivierte die JPEG-zu-WebP-Konvertierung als Folge dieser Fehler, da das Fotoverzeichnis WebP derzeit nicht verwendet, bemerkte jedoch, dass dies „ein Zeichen dafür sein könnte, dass es sich lohnen könnte, WebPs nur für die in der Größe geänderten Bilder zu generieren, anstatt für auch die Originaldatei.“

Silverstein sagte, dass sie die von Hulse gemeldeten Probleme untersuchen, da möglicherweise ein Fehler aufgedeckt wurde.

Ozz kreiste zurück und empfahl, dass die Erstellung von Untergrößen nach Bedarf ein besserer Ansatz sei, der eine schnellere Verarbeitung hochgeladener Bilder und einen geringeren Platzbedarf habe, da die zusätzlichen JPEG-Bilder nur dann generiert würden, wenn sie benötigt würden. Er bemerkte auch, dass der „Wiederholungsversuch“ für die Bildnachbearbeitung „nicht so gut funktioniert wie erwartet“.

„Die schlechte Nachricht ist, dass die ursprünglich hochgeladene Datei wahrscheinlich erhalten bleibt, wenn die Nachbearbeitung fehlschlägt“, sagte Ozz. „Dann wird es überall verwendet, da der Großteil des Codes in WP auf verfügbare Größen zurückgreift und die einzige Größe das Original ist. Das bedeutet, dass wir riesige (durchschnittlich 4 MB – 8 MB) Bilder bereitstellen werden. Ein gravierender Nachteil.“

Silverstein reagierte auf die Vorschläge von Ozz, stimmte vielen zu und schlug zwei mögliche Wege für das Projekt vor:

1. Behalten Sie die aktuelle Multi-Mime-Infrastruktur bei, aber ändern Sie die Standardeinstellungen so, dass nur WebP-Dateien generiert werden, möglicherweise bis zu einer Schwellengröße, über der nur JPEGs generiert würden. Die meisten bestehenden Arbeiten würden fortgesetzt; Inhaltsfilterung könnte möglicherweise entfernt werden.
2. Stellen Sie die Multi-Mime-Infrastruktur wieder her und wechseln Sie zurück zu einem Single-Mime-Ansatz, indem Sie WebP für Bilder bis zu einer Schwellenwertgröße verwenden und die Kompatibilitätsebene so anpassen, dass die von uns aufbewahrten JPEGs verwendet werden.

Das Performance-Team recherchiert weiter und hat vorübergehend aufgehört, etwas anderes festzulegen, bis es Feedback zur nächsten Richtung für das Projekt erhält.