WebP în mod implicit în așteptare pentru 6.1 după noi obiecții din partea dezvoltatorilor principali WordPress

Săptămâna trecută, colaboratorii echipei de performanță lucrau la perfecționarea corecțiilor ulterioare pentru caracteristica multi-mime/WebP, după ce munca principală pentru aceasta a fost îmbinată în core pentru 6.1 la sfârșitul lunii iulie. Aceasta include articole mai mici, cum ar fi shim-ul pentru browsere care nu acceptă și adăugarea de suport pentru PDF, care sunt gestionate în bilete separate.

Propunerea de a genera imagini WebP în mod implicit pentru încărcările noi de imagini JPEG a fost controversată de la început. În timp ce colaboratorii sponsorizați de Google care conduc proiectul au făcut unele revizuiri după o rundă inițială de feedback critic semnificativ, alți contribuitori au continuat să-și exprime preocupările despre care au spus că nu au fost luate în considerare. Mai mulți contribuitori au raportat probleme cu caracteristica și au sugerat că ar trebui să înceapă prin a fi opt-in, o idee care a fost respinsă sumar înainte ca munca principală să fie angajată.

Săptămâna trecută, dezvoltatorul principal WordPress, Andrew Ozz, a analizat biletul cu noi obiecții:

La fel ca @MatthiasReinholz, @eatingrules și alții, cred că această abordare poate lipsi. De ce ar fi de două ori mai multe fișiere de imagine care ocupă mult spațiu suplimentar, când jumătate dintre ele nu vor fi niciodată folosite nicăieri?

IMHO, o abordare mai bună ar fi să faceți doar toate subdimensiunile de imagine WEBP. Dacă sunt într-adevăr necesare JPEG, acestea pot fi generate din mers, după cum este necesar. Nu are rost să înfundați stocarea serverelor web cu toate aceste fișiere inutile.

Pe de altă parte, dacă dimensiunile fișierelor WEBP sunt de fapt mai mari decât JPEG, asta ar însemna probabil că sunt necesare instrumente mai bune, iar acest patch este prematur.

Cu șase săptămâni în urmă, ca răspuns la o plângere conform căreia „resursele pentru conversie ar fi extraordinare”, Adam Silverstein, comisarul principal sponsorizat de Google, a confirmat că resursele pentru generarea imaginilor la încărcare vor „crește dramatic”.

„Cu toate acestea, resursele pentru a servi o imagine vor fi reduse”, a spus Silverstein. „Deoarece încărcarea imaginilor este foarte rară în comparație cu difuzarea imaginilor, efortul suplimentar de comprimare și stocare a imaginilor ar trebui să merite.”

Aceasta este o altă problemă pe care Ozz a citat-o ​​în obiecția sa față de această abordare.

„De fapt, această creștere dramatică a utilizării resurselor la încărcarea unei imagini este un efect secundar foarte rău aici”, a spus Ozz. „Înseamnă că multe încărcări vor eșua și vor lăsa utilizatorii blocați. De asemenea, va crește în mod dramatic solicitările de asistență atât pentru WordPress, cât și pentru companiile de găzduire. Nu credeți că acest lucru este acceptabil. Din această cauză, chiar dacă este nevoie de suport pentru imagini multi-mime în WordPress, abordarea actuală nu pare a fi o soluție bună.”

Aproximativ 24 de ore mai târziu, contribuitorul sponsorizat de Google, Felix Arntz, a comentat că mecanismul de rezervă WebP la JPEG pentru browserele mai vechi era gata pentru comite și că plănuia să îl comite în câteva zile.

„Vă rugăm să nu mai scrieți cod aici decât dacă este pentru a aborda creșterea dramatică a resurselor necesare pentru a crea sub-dimensiuni de imagine după încărcare”, a spus Ozz. „Așa cum am spus mai sus, o astfel de creștere este inacceptabilă.

„Există date despre cât de mult mai multe resurse (memorie, timp de procesare etc.) sunt necesare atunci când încărcați imagini de diferite dimensiuni? O estimare despre câte site-uri pot fi afectate de asta? Ceva sugestii despre cum să o faceți? Știți ce se întâmplă atunci când eșuează postprocesarea unei imagini încărcate?

„Sincer deocamdată, se pare că acest patch va trebui să fie reluat și refactorizat pentru a rezolva acest lucru.”

Adam Silverstein a răspuns preocupărilor sale cu clarificări despre motivul pentru care au ales abordarea actuală, în așteptarea anumitor cazuri marginale și, în cele din urmă, adăugând suport pentru formate precum AVIF, odată ce acesta este susținut pe scară largă:

Tind să fiu de acord cu evaluarea dvs. conform căreia toate subdimensiunile ar trebui generate numai ca WebP, aceasta a fost forma propunerii inițiale. Pentru marea majoritate a cazurilor de utilizare/utilizatori, acest lucru va funcționa cel mai bine. Aș fi deschis să iau în considerare acest lucru pentru implicit (cu unele atenuări, vezi mai jos).

Motivul pentru care am decis să generăm ambele formate a fost din considerente de compatibilitate inversă pentru puținele cazuri marginale pe care le-am identificat în care imaginile WebP ar putea să nu funcționeze: și anume imagini trimise prin e-mail (unii clienți Outlook/Windows mai vechi), etichete Open Graph (unele servicii nu acceptă WebP) și browsere Safari mai vechi. O posibilitate pe care am luat-o în considerare ar fi să păstrăm doar formatul JPEG de dimensiune completă, astfel încât să fie întotdeauna disponibil pentru acele cazuri de margine.

Suportul „multi-mime” aici este construit pentru a genera mai multe formate, astfel încât site-urile dvs. să vă poată oferi un format primar și alternativ cu ceva asemănător cu elementul picture . Acest lucru este mai puțin important pentru WebP, deoarece este acceptat pe scară largă, dar ar fi util pentru adoptarea de formate mai noi, cum ar fi AVIF, prin pluginuri sau core.

Silverstein a mai spus că opțiunea de a genera imagini din mers este ceva pe care trebuie să-și dea seama, dar „s-au simțit în afara acestui efort”.

Ca răspuns la reclamația privind creșterea dramatică a resurselor pentru încărcarea imaginilor, Silverstein a spus că se bazează pe mecanismul de „reîncercare” pentru a atenua această problemă.

„Această schimbare dublează, de asemenea, numărul de ori când WordPress va reîncerca regenerarea imaginii, așa că, în timp ce timpul de procesare va crește, nu cred că vom vedea neapărat o creștere a eșecurilor”, a spus el. „Știu că am avut probleme cu adăugarea de noi dimensiuni în trecut, dar asta a fost înainte de a adăuga mecanismul de reîncercare.”

Echipa din spatele proiectului WebP implicit este mai concentrată pe difuzarea imaginilor de dimensiuni mai mici pe front-end și consideră că utilizarea resurselor suplimentare la încărcare este un sacrificiu necesar pentru utilizatorii WordPress.

„Resursele suplimentare la momentul încărcării trebuie să fie cântărite cu resursele reduse de difuzare a imaginii WebP mai mici, mai ales că difuzarea are loc de obicei cu mai multe ordine de mărime mai frecvent decât încărcarea”, a spus Silverstein.

„Dacă încărcarea eșuează după toate încercările, utilizatorul are aceeași experiență ca în prezent: rămâne cu o imagine ruptă, inutilizabilă. Probabil că poate fi remediat, deși nu cred că această schimbare va crește ratele de eșec.”

Dezvoltatorul principal WordPress, Dion Hulse, a comentat, de asemenea, biletul de raportare a problemelor cu conversiile WebP în Directorul foto WordPress:

Rețineți doar că aceste conversii webp suplimentare par să fi fost cauza principală a eșecurilor de încărcare în directorul foto WordPress în ultimele săptămâni. Vedeți #meta6142 și biletele închise ca duplicat al acestuia.

Erorile au fost, în general, de-a lungul liniilor de Allowed memory size of 256M bytes exhausted (tried to allocate 90M bytes (evident cu valori de octeți) în timp ce încerca să efectueze conversia jpeg originală la dimensiune completă inițială -> webp.

Nu a afectat fiecare încărcare , doar pe cea a anumitor imagini. Potențial legat de valoarea $quality transmisă pentru cererile webp (IIRC implicit 82 a fost optimizat pentru jpeg?).

Hulse a dezactivat conversia JPEG în WebP ca urmare a acestor erori, deoarece directorul foto nu folosește în prezent WebP, dar a remarcat că „ar putea fi un semn că ar putea merita să luați în considerare doar generarea de pagini web pentru imaginile redimensionate, mai degrabă decât pentru și fișierul original.”

Silverstein a spus că investighează problemele raportate de Hulse, deoarece este posibil să fi expus o eroare.

Ozz s-a întors pentru a recomanda că realizarea de sub-dimensiuni la cerere ar fi o abordare mai bună, care are o procesare mai rapidă a imaginilor încărcate și cerințe reduse de spațiu, deoarece imaginile JPEG suplimentare nu vor fi generate decât dacă este necesar. El a remarcat, de asemenea, că „reîncercarea” pentru post-procesarea imaginii „nu funcționează așa de bine cum era de așteptat”.

„Veștile proaste sunt că, dacă procesarea ulterioară eșuează, sunt șanse ca fișierul încărcat inițial să rămână”, a spus Ozz. „Apoi va fi folosit peste tot, deoarece majoritatea codului din WP revine la dimensiunile disponibile, iar singura dimensiune va fi cea originală. Asta înseamnă că vom difuza imagini uriașe (4MB – 8MB în medie). Un dezavantaj serios.”

Silverstein a răspuns sugestiilor lui Ozz, fiind de acord cu mulți și a propus două posibile căi de urmat pentru proiect:

1. Păstrați infrastructura multi-mime actuală, dar modificați valorile implicite, astfel încât să fie generate numai fișierele WebP, posibil până la o dimensiune de prag dincolo de care ar fi generate numai fișierele JPEG. Majoritatea lucrărilor existente ar continua; filtrarea conținutului ar putea fi eliminată.
2. Reveniți la infrastructura multi-mime și reveniți la o abordare mime unică, folosind WebP pentru imagini până la o dimensiune de prag și ajustând stratul de compatibilitate pentru a folosi JPEG-urile pe care le păstrăm.

Echipa de performanță face mai multe cercetări și a întrerupt temporar orice altceva până când primește feedback cu privire la următoarea direcție a proiectului.