WebP domyślnie wstrzymane dla wersji 6.1 po nowych zastrzeżeniach wiodących programistów WordPressa

W zeszłym tygodniu współtwórcy zespołu Performance pracowali nad dopracowaniem kolejnych poprawek do funkcji multi-mime/WebP, po tym, jak główne prace nad nią zostały włączone do rdzenia wersji 6.1 pod koniec lipca. Obejmuje to mniejsze powiązane elementy, takie jak podkładka dla nieobsługujących przeglądarek i dodanie obsługi plików PDF, które są obsługiwane w osobnych zgłoszeniach.

Propozycja domyślnego generowania obrazów WebP dla nowych przesyłanych obrazów JPEG od początku budziła kontrowersje. Podczas gdy współtwórcy sponsorowani przez Google kierujący projektem wprowadzili pewne poprawki po wstępnej rundzie istotnych krytycznych opinii, inni współtwórcy nadal zgłaszali obawy, które według nich nie są brane pod uwagę. Kilku współtwórców zgłosiło problemy z funkcją i zasugerowało, że należy zacząć od wyrażenia zgody, co zostało natychmiast odrzucone przed wykonaniem głównej pracy.

W zeszłym tygodniu główny programista WordPress, Andrew Ozz, zgłosił nowe zastrzeżenia:

Podobnie jak @MatthiasReinholz, @eatingrules i inni, myślę, że być może brakuje tego podejścia. Dlaczego miałoby być dwa razy więcej plików graficznych zajmujących dużo dodatkowej przestrzeni, skoro połowa z nich nigdy nie będzie nigdzie używana?

IMHO lepszym podejściem byłoby po prostu zrobienie wszystkich podrozmiarów obrazów WEBP. Jeśli pliki JPEG są rzeczywiście potrzebne, można je wygenerować w locie w razie potrzeby. Nie ma sensu zapychać pamięci serwerów WWW tymi wszystkimi bezużytecznymi plikami.

Z drugiej strony, jeśli rozmiary plików WEBP są rzeczywiście większe niż pliki JPEG, prawdopodobnie oznaczałoby to, że potrzebne są lepsze narzędzia, a ta poprawka jest przedwczesna.

Sześć tygodni temu, w odpowiedzi na jedną skargę, że „zasoby do konwersji będą ogromne”, sponsorowany przez Google główny koordynator, Adam Silverstein, potwierdził, że zasoby do generowania obrazów podczas przesyłania „drastycznie wzrosną”.

„Jednak zasoby do obsługi obrazu zostaną zmniejszone” – powiedział Silverstein. „Ponieważ przesyłanie obrazów jest bardzo rzadkie w porównaniu z udostępnianiem obrazów, dodatkowy wysiłek w zakresie kompresji i przechowywania obrazów powinien być tego wart”.

To kolejny problem, który Ozz przytoczył w swoim sprzeciwie wobec takiego podejścia.

„Właściwie ten dramatyczny wzrost zużycia zasobów podczas przesyłania obrazu jest tutaj bardzo złym efektem ubocznym” – powiedział Ozz. „Oznacza to, że wiele operacji przesyłania zakończy się niepowodzeniem i pozostawi użytkowników na pastwę losu. Znacznie zwiększy również liczbę żądań wsparcia zarówno dla WordPressa, jak i firm hostingowych. Nie myśl, że to jest do przyjęcia. Z tego powodu, nawet jeśli w WordPressie potrzebna jest obsługa multimime obrazu, obecne podejście nie wydaje się dobrym rozwiązaniem”.

Około 24 godziny później, współpracownik sponsorowany przez Google, Felix Arntz, skomentował, że doradzał, że mechanizm WebP do zmiany formatu JPEG dla starszych przeglądarek jest gotowy do zatwierdzenia i że planuje zatwierdzić go w ciągu kilku dni.

„Proszę nie wprowadzać tutaj więcej kodu, chyba że ma to na celu zaradzenie dramatycznemu wzrostowi zasobów potrzebnych do tworzenia podrozmiarów obrazu po przesłaniu” – powiedział Ozz. „Jak powiedziałem powyżej, taki wzrost jest niedopuszczalny.

„Czy są jakieś dane o tym, o ile więcej zasobów (pamięć, czas przetwarzania itp.) jest potrzebnych podczas przesyłania obrazów o różnych rozmiarach? Jakieś szacunki dotyczące tego, ile witryn może to dotyczyć? Jakieś sugestie, jak sobie z tym poradzić? Czy wiesz, co się dzieje, gdy przetwarzanie końcowe przesłanego obrazu nie powiedzie się?

„Szczerze na razie wydaje się, że ta łatka będzie musiała zostać cofnięta i zrefaktorowana, aby rozwiązać ten problem”.

Adam Silverstein odpowiedział na jego obawy, wyjaśniając, dlaczego wybrali obecne podejście, w oczekiwaniu na pewne przypadki brzegowe i ostatecznie dodając obsługę formatów takich jak AVIF, gdy jest to szerzej obsługiwane:

Zgadzam się z Twoją oceną, że wszystkie podrozmiary powinny być generowane tylko jako WebP, taki był kształt oryginalnej propozycji. W przypadku zdecydowanej większości przypadków użycia/użytkowników to zadziała najlepiej. Byłbym otwarty na rozważenie tego jako domyślnego (z pewnymi środkami łagodzącymi, patrz poniżej).

Powodem, dla którego zdecydowaliśmy się wygenerować oba formaty, były względy kompatybilności wstecznej w kilku przypadkach brzegowych, które zidentyfikowaliśmy, w których obrazy WebP mogą nie działać: obrazy wysłane pocztą e-mail (niektóre starsze klienty Outlook/Windows), tagi Open Graph (niektóre usługi nie obsługują WebP) i starsze przeglądarki Safari. Jedną z możliwości, które rozważaliśmy, byłoby zachowanie tylko pełnowymiarowego pliku JPEG, aby był zawsze dostępny dla tych skrajnych przypadków.

Obsługa „multi-mime” jest tutaj stworzona do generowania wielu formatów, dzięki czemu witryny mogą zapewnić format podstawowy i zastępczy z czymś w rodzaju elementu picture . Jest to mniej ważne dla WebP, ponieważ jest tak szeroko obsługiwane, ale byłoby pomocne przy przyjmowaniu nowszych formatów, takich jak AVIF, za pomocą wtyczek lub rdzenia.

Silverstein powiedział również, że opcja generowania obrazów w locie była czymś, co muszą rozgryźć, ale „wyszła poza zakres tego wysiłku”.

W odpowiedzi na skargę dotyczącą dramatycznego wzrostu zasobów do przesyłania obrazów Silverstein powiedział, że polega na mechanizmie „ponownej próby”, aby złagodzić ten problem.

„Ta zmiana podwaja również liczbę ponownych prób regeneracji obrazu przez WordPress, więc chociaż czas przetwarzania wydłuży się, nie sądzę, abyśmy koniecznie zauważyli skok liczby niepowodzeń” – powiedział. „Wiem, że w przeszłości mieliśmy problemy z dodawaniem nowych rozmiarów, ale było to przed dodaniem mechanizmu ponawiania prób”.

Zespół odpowiedzialny za projekt WebP domyślnie jest bardziej skoncentrowany na obsłudze mniejszych rozmiarów obrazów na interfejsie użytkownika i uważa, że ​​dodatkowe wykorzystanie zasobów podczas przesyłania jest konieczną ofiarą dla użytkowników WordPressa.

„Dodatkowe zasoby w czasie przesyłania należy porównać ze zmniejszonymi zasobami związanymi z obsługą mniejszego obrazu WebP, zwłaszcza że udostępnianie zwykle odbywa się o kilka rzędów wielkości częściej niż przesyłanie” — powiedział Silverstein.

„Jeśli przesyłanie nie powiedzie się po wszystkich ponownych próbach, użytkownik ma takie same wrażenia jak obecnie: zostaje z uszkodzonym, bezużytecznym obrazem. Można to prawdopodobnie naprawić, chociaż nie sądzę, aby ta zmiana zwiększyła odsetek niepowodzeń”.

Główny programista WordPress, Dion Hulse, skomentował również zgłoszenie dotyczące problemów z konwersjami WebP w WordPress Photo Directory:

Zaznaczam tutaj, że te dodatkowe konwersje webp wydają się być główną przyczyną niepowodzeń przesyłania do katalogu zdjęć WordPress w ostatnich tygodniach. Zobacz #meta6142 i bilety zamknięte jako duplikat.

Błędy były generalnie podobne do Allowed memory size of 256M bytes exhausted (tried to allocate 90M bytes (oczywiście z wartościami bajtów) podczas próby wykonania początkowej pełnowymiarowej oryginalnej konwersji jpeg -> webp.

Nie wpłynęło to na każde przesyłanie , tylko na niektóre obrazy. Potencjalnie powiązany z wartością $quality przekazywaną dla żądań webp (IIRC domyślna wartość 82 została zoptymalizowana dla jpeg?).

Hulse wyłączył konwersję JPEG do WebP w wyniku tych błędów, ponieważ katalog zdjęć nie używa obecnie WebP, ale zauważył, że „może to oznaczać, że warto rozważyć generowanie webp tylko dla obrazów o zmienionym rozmiarze, a nie dla oryginalny plik też.”

Silverstein powiedział, że bada problemy zgłoszone przez Hulse, ponieważ mogło ujawnić błąd.

Ozz zawrócił, aby zalecić, że tworzenie podrozmiarów na żądanie byłoby lepszym podejściem, które zapewnia szybsze przetwarzanie przesłanych obrazów i mniejsze wymagania dotyczące miejsca, ponieważ dodatkowe obrazy JPEG nie byłyby generowane, chyba że są potrzebne. Zauważył również, że „ponowna próba” przetwarzania obrazu „nie działa tak dobrze, jak oczekiwano”.

„Zła wiadomość jest taka, że ​​jeśli przetwarzanie końcowe się nie powiedzie, istnieje szansa, że ​​pierwotnie przesłany plik pozostanie” – powiedział Ozz. „Wtedy będzie używany wszędzie, ponieważ większość kodu w WP wraca do dostępnych rozmiarów, a jedynym rozmiarem będzie oryginał. Oznacza to, że będziemy obsługiwać ogromne (średnio 4 MB – 8 MB) obrazy. Poważna wada.”

Silverstein odpowiedział na sugestie Ozza, zgadzając się z wieloma i zaproponował dwie potencjalne ścieżki rozwoju projektu:

1. Zachowaj obecną infrastrukturę multi-mime, ale zmień ustawienia domyślne, aby generowane były tylko pliki WebP, prawdopodobnie do rozmiaru progowego, powyżej którego generowane byłyby tylko pliki JPEG. Większość istniejących prac byłaby kontynuowana; filtrowanie treści może zostać usunięte.
2. Przywróć infrastrukturę multi-mime i przełącz się z powrotem na podejście pojedynczego mime, używając WebP dla obrazów o maksymalnym rozmiarze progowym i dostosowując warstwę zgodności tak, aby używała przechowywanych przez nas plików JPEG.

Zespół ds. wydajności przeprowadza więcej badań i tymczasowo wstrzymał dokonywanie jakichkolwiek innych czynności, dopóki nie otrzyma informacji zwrotnej na temat następnego kierunku projektu.