WebP per impostazione predefinita in attesa per 6.1 dopo nuove obiezioni da parte degli sviluppatori principali di WordPress

La scorsa settimana i collaboratori del team Performance stavano lavorando al perfezionamento delle patch di follow-up per la funzione multi-mime/WebP, dopo che il lavoro principale per essa è stato unito al core per 6.1 alla fine di luglio. Ciò include elementi correlati più piccoli come lo shim per i browser non supportati e l'aggiunta del supporto PDF, che vengono gestiti in ticket separati.

La proposta di generare immagini WebP per impostazione predefinita per il caricamento di nuove immagini JPEG è stata controversa sin dall'inizio. Mentre i contributori sponsorizzati da Google che guidano il progetto hanno apportato alcune revisioni dopo un giro iniziale di feedback critici significativi, altri hanno continuato a esprimere preoccupazioni che, secondo loro, non sarebbero state prese in considerazione. Diversi contributori hanno segnalato problemi con la funzione e hanno suggerito che dovrebbe iniziare con l'accettazione, un'idea che è stata sommariamente respinta prima che il lavoro principale fosse impegnato.

La scorsa settimana, lo sviluppatore principale di WordPress Andrew Ozz ha valutato il biglietto con nuove obiezioni:

Come @MatthiasReinholz, @eatingrules e altri, penso che forse questo approccio manchi. Perché ci sarebbero il doppio dei file di immagine che occupano molto spazio extra quando la metà di essi non verrà mai utilizzata da nessuna parte?

IMHO un approccio migliore sarebbe quello di rendere WEBP tutte le sottodimensioni dell'immagine. Se i file JPEG sono effettivamente necessari, questi possono essere generati al volo secondo necessità. Non ha senso intasare la memoria dei server web con tutti questi file inutili.

D'altra parte, se le dimensioni del file WEBP sono effettivamente maggiori dei JPEG, ciò significherebbe probabilmente che sono necessari strumenti migliori e questa patch è prematura.

Sei settimane fa, in risposta a una lamentela secondo cui "le risorse per la conversione sarebbero enormi", il principale committente sponsorizzato da Google Adam Silverstein ha confermato che le risorse per generare le immagini durante il caricamento sarebbero "aumentate notevolmente".

"Tuttavia, le risorse per servire un'immagine saranno ridotte", ha affermato Silverstein. "Dato che il caricamento di immagini è molto raro rispetto alla pubblicazione di immagini, lo sforzo extra per comprimere e archiviare le immagini dovrebbe valerne la pena".

Questo è un altro problema citato da Ozz nella sua obiezione a questo approccio.

"In realtà quel drammatico aumento dell'utilizzo delle risorse durante il caricamento di un'immagine è un pessimo effetto collaterale qui", ha affermato Ozz. “Significa che molti caricamenti falliranno e lasceranno gli utenti bloccati. Aumenterà inoltre notevolmente le richieste di supporto sia per WordPress che per le società di hosting. Non pensare che questo sia accettabile. Per questo motivo, anche se in WordPress è necessario il supporto multi-mime delle immagini, l'approccio attuale non sembra una buona soluzione".

Circa 24 ore dopo, il collaboratore sponsorizzato da Google Felix Arntz ha commentato per avvisare che il meccanismo di fallback WebP su JPEG per i browser più vecchi era pronto per il commit e che aveva pianificato di eseguirlo in pochi giorni.

"Per favore, non impegnare altro codice qui a meno che non sia per affrontare il drammatico aumento delle risorse necessarie per creare sottodimensioni dell'immagine dopo il caricamento", ha affermato Ozz. “Come ho detto sopra, tale aumento è inaccettabile.

"Ci sono dati su quante più risorse (memoria, tempo di elaborazione, ecc.) sono necessarie per caricare immagini di dimensioni diverse? Qualche stima su quanti siti potrebbero essere interessati da ciò? Qualche suggerimento su come affrontarlo? Sai cosa succede quando la post-elaborazione di un'immagine caricata non riesce?

"Francamente per ora sembra che questa patch dovrà essere ripristinata e refactoring per affrontare questo problema."

Adam Silverstein ha risposto alle sue preoccupazioni con chiarimenti sul motivo per cui hanno scelto l'approccio attuale, in previsione di alcuni casi limite e alla fine aggiungendo il supporto per formati come AVIF una volta che sarà più ampiamente supportato:

Tendo ad essere d'accordo con la tua valutazione sul fatto che tutte le sottodimensioni dovrebbero essere generate solo come WebP, questa era la forma della proposta originale. Per la stragrande maggioranza dei casi d'uso/utenti questo funzionerà al meglio. Sarei aperto a considerare questo per l'impostazione predefinita (con alcune mitigazioni, vedi sotto).

Il motivo per cui abbiamo deciso di generare entrambi i formati era per considerazioni di compatibilità con le versioni precedenti per i pochi casi limite che abbiamo identificato in cui le immagini WebP potrebbero non funzionare: vale a dire immagini inviate tramite e-mail (alcuni client Outlook/Windows precedenti), tag Open Graph (alcuni servizi non supportano WebP) e browser Safari precedenti. Una possibilità che abbiamo considerato sarebbe quella di mantenere solo il JPEG a grandezza naturale in modo che sia sempre disponibile per quei casi limite.

Il supporto "multi-mime" qui è progettato per generare più formati in modo che i siti possano fornire un formato primario e di riserva con qualcosa come l'elemento picture . Questo è meno importante per WebP poiché è così ampiamente supportato, ma sarebbe utile per l'adozione di formati più recenti come AVIF tramite plug-in o core.

Silverstein ha anche affermato che l'opzione di generare immagini al volo era qualcosa che dovevano capire, ma "sembrava fuori portata per questo sforzo".

In risposta alla denuncia relativa al drammatico aumento delle risorse per il caricamento di immagini, Silverstein ha affermato che si affidano al meccanismo di "riprova" per mitigare questo problema.

"Questa modifica raddoppia anche il numero di volte in cui WordPress ritenterà la rigenerazione dell'immagine, quindi mentre il tempo di elaborazione aumenterà, non credo che vedremo necessariamente un aumento degli errori", ha affermato. "So che abbiamo avuto problemi ad aggiungere nuove dimensioni in passato, tuttavia è stato prima che aggiungessimo il meccanismo di ripetizione".

Il team dietro il progetto WebP per impostazione predefinita è più concentrato sul servizio di immagini di dimensioni inferiori sul frontend e considera l'utilizzo aggiuntivo delle risorse durante il caricamento un sacrificio necessario per gli utenti di WordPress.

"Le risorse aggiuntive al momento del caricamento devono essere soppesate rispetto alle risorse ridotte per servire l'immagine WebP più piccola, soprattutto perché la pubblicazione avviene in genere diversi ordini di grandezza più frequentemente rispetto al caricamento", ha affermato Silverstein.

"Se il caricamento fallisce dopo tutti i tentativi, l'utente ha la stessa esperienza di oggi: viene lasciata con un'immagine rotta e inutilizzabile. Probabilmente può essere risolto, anche se non credo che questo cambiamento aumenterà i tassi di errore".

Lo sviluppatore principale di WordPress Dion Hulse ha anche commentato il ticket per segnalare problemi con le conversioni WebP nella Directory foto di WordPress:

Notando solo qui, che queste conversioni webp aggiuntive sembrano essere state la principale causa di errori di caricamento nella directory di foto di WordPress nelle ultime settimane. Vedi #meta6142 e i biglietti sono stati chiusi come duplicati.

Gli errori erano generalmente sulla Allowed memory size of 256M bytes exhausted (tried to allocate 90M bytes (ovviamente con valori di byte) durante il tentativo di eseguire la conversione jpeg -> webp originale a dimensione intera iniziale.

Non ha interessato tutti i caricamenti , solo quello di alcune immagini. Potenzialmente correlato al valore $quality passato per le richieste webp (IIRC il valore predefinito di 82 è stato ottimizzato per jpeg?).

Hulse ha disabilitato la conversione da JPEG a WebP a causa di questi errori, poiché la directory foto non utilizza attualmente WebP ma ha notato che "potrebbe essere un segno che potrebbe valere la pena considerare di generare solo webp per le immagini ridimensionate, piuttosto che per anche il file originale”.

Silverstein ha affermato che stanno indagando sui problemi segnalati da Hulse, poiché potrebbe aver esposto un bug.

Ozz è tornato per raccomandare che la creazione di sottodimensioni su richiesta sarebbe un approccio migliore con un'elaborazione più rapida delle immagini caricate e requisiti di spazio ridotti, poiché le immagini JPEG aggiuntive non verrebbero generate se non necessario. Ha anche notato che il "riprova" per la post-elaborazione delle immagini "non funziona come previsto".

"La cattiva notizia è che se la post-elaborazione fallisce, è probabile che il file originariamente caricato rimanga", ha detto Ozz. "Quindi verrà utilizzato ovunque poiché la maggior parte del codice in WP torna alle dimensioni disponibili e l'unica dimensione sarà l'originale. Ciò significa che forniremo immagini enormi (4 MB – 8 MB in media). Un grave inconveniente".

Silverstein ha risposto ai suggerimenti di Ozz, concordando con molti, e ha proposto due potenziali percorsi da seguire per il progetto:

1. Mantieni l'attuale infrastruttura multi-mime, ma modifica le impostazioni predefinite in modo che vengano generati solo i file WebP, possibilmente fino a una dimensione soglia oltre la quale verrebbero generati solo i file JPEG. La maggior parte dei lavori esistenti continuerebbe; il filtro dei contenuti potrebbe essere rimosso.
2. Ripristina l'infrastruttura multi-mime e torna a un approccio mime singolo, utilizzando WebP per immagini fino a una dimensione soglia e regolando il livello di compatibilità per utilizzare i JPEG che conserviamo.

Il team Performance sta facendo ulteriori ricerche e ha temporaneamente sospeso l'impegno di qualsiasi altra cosa fino a quando non riceve un feedback sulla direzione successiva per il progetto.