WebP secara Default Ditahan selama 6.1 Setelah Keberatan Baru Dari Pengembang Utama WordPress

Minggu lalu, kontributor tim Performance bekerja untuk menyempurnakan patch tindak lanjut mereka untuk fitur multi-mime/WebP, setelah pekerjaan utama untuk itu digabungkan menjadi inti untuk 6.1 pada akhir Juli. Ini termasuk item terkait yang lebih kecil seperti shim untuk browser yang tidak mendukung dan menambahkan dukungan PDF, yang ditangani dalam tiket terpisah.

Proposal untuk menghasilkan gambar WebP secara default untuk unggahan gambar JPEG baru telah kontroversial sejak awal. Sementara kontributor yang disponsori Google yang mendorong proyek telah membuat beberapa revisi setelah putaran awal umpan balik kritis yang signifikan, kontributor lain terus menyuarakan keprihatinan yang mereka katakan tidak dipertimbangkan. Beberapa kontributor melaporkan masalah dengan fitur tersebut dan menyarankan agar fitur tersebut dimulai dengan memilih ikut serta, sebuah gagasan yang dengan cepat diberhentikan sebelum pekerjaan utama dilakukan.

Minggu lalu, pengembang utama WordPress Andrew Ozz mempertimbangkan tiket dengan keberatan baru:

Seperti @MatthiasReinholz, @eatingrules, dan lainnya saya pikir pendekatan ini mungkin kurang. Mengapa ada dua kali lebih banyak file gambar yang menghabiskan banyak ruang ekstra ketika setengahnya tidak akan pernah digunakan di mana pun?

IMHO pendekatan yang lebih baik adalah dengan membuat semua gambar sub-ukuran WEBP. Jika JPEG memang diperlukan, ini dapat dibuat dengan cepat sesuai kebutuhan. Tidak ada gunanya menyumbat penyimpanan server web dengan semua file yang tidak berguna ini.

Di sisi lain, jika ukuran file WEBP sebenarnya lebih besar dari JPEG, itu mungkin berarti bahwa alat yang lebih baik diperlukan, dan tambalan ini terlalu dini.

Enam minggu lalu, sebagai tanggapan atas satu keluhan bahwa “sumber daya untuk konversi akan luar biasa”, komitter inti yang disponsori Google, Adam Silverstein, mengonfirmasi bahwa sumber daya untuk menghasilkan gambar saat diunggah akan “meningkat secara dramatis.”

"Namun sumber daya untuk melayani citra akan diturunkan," kata Silverstein. “Karena pengunggahan gambar sangat jarang dibandingkan dengan penyajian gambar, upaya ekstra untuk mengompresi dan menyimpan gambar harus sepadan.”

Ini adalah masalah lain yang disebutkan Ozz dalam keberatannya terhadap pendekatan ini.

“Sebenarnya peningkatan dramatis penggunaan sumber daya saat mengunggah gambar adalah efek samping yang sangat buruk di sini,” kata Ozz. “Itu berarti banyak unggahan akan gagal, dan membuat pengguna terdampar. Ini juga akan meningkatkan permintaan dukungan untuk WordPress dan perusahaan hosting secara dramatis. Jangan berpikir ini bisa diterima. Karena itu, bahkan jika dukungan gambar multi-mime diperlukan di WordPress, pendekatan saat ini sepertinya bukan solusi yang baik.”

Kira-kira 24 jam kemudian, kontributor yang disponsori Google Felix Arntz berkomentar untuk memberi tahu bahwa mekanisme mundur WebP ke JPEG untuk browser lama sudah siap untuk dikomit dan dia berencana untuk mengkomitnya dalam beberapa hari.

"Tolong jangan melakukan kode lagi di sini kecuali untuk mengatasi peningkatan dramatis sumber daya yang dibutuhkan untuk membuat sub-ukuran gambar setelah diunggah," kata Ozz. “Seperti yang saya katakan di atas, peningkatan seperti itu tidak dapat diterima.

“Apakah ada data tentang berapa banyak lebih banyak sumber daya (memori, waktu pemrosesan, dll.) yang diperlukan saat mengunggah ukuran gambar yang berbeda? Adakah perkiraan tentang berapa banyak situs yang mungkin terpengaruh oleh itu? Adakah saran tentang cara menghadapinya? Tahukah Anda apa yang terjadi ketika pasca-pemrosesan gambar yang diunggah gagal?

“Terus terang untuk saat ini tampaknya tambalan ini harus dikembalikan dan difaktorkan ulang untuk mengatasi ini.”

Adam Silverstein menanggapi kekhawatirannya dengan klarifikasi tentang mengapa mereka memilih pendekatan saat ini, untuk mengantisipasi kasus tepi tertentu dan akhirnya menambahkan dukungan untuk format seperti AVIF setelah didukung secara lebih luas:

Saya cenderung setuju dengan penilaian Anda bahwa semua sub-ukuran harus dibuat sebagai WebP saja, itulah bentuk proposal aslinya. Untuk sebagian besar kasus penggunaan/pengguna, ini akan berfungsi paling baik. Saya akan terbuka untuk mempertimbangkan ini sebagai default (dengan beberapa mitigasi, lihat di bawah).

Alasan kami memutuskan untuk membuat kedua format adalah untuk pertimbangan kompatibilitas mundur untuk beberapa kasus tepi yang kami identifikasi di mana gambar WebP mungkin tidak berfungsi: yaitu gambar yang dikirim melalui email (beberapa klien Outlook/windows yang lebih lama), tag Open Graph (beberapa layanan tidak mendukung WebP) dan browser Safari yang lebih lama. Satu kemungkinan yang kami pertimbangkan adalah menyimpan hanya JPEG berukuran penuh sehingga selalu tersedia untuk kasus tepi tersebut.

Dukungan "multi-mime" di sini dibuat untuk menghasilkan banyak format sehingga situs Anda dapat menyediakan format utama dan mundur dengan sesuatu seperti elemen picture . Ini kurang penting untuk WebP karena didukung secara luas, tetapi akan sangat membantu untuk mengadopsi format yang lebih baru seperti AVIF dengan plugin atau inti.

Silverstein juga mengatakan opsi untuk menghasilkan gambar dengan cepat adalah sesuatu yang perlu mereka pikirkan tetapi "merasa di luar jangkauan untuk upaya ini."

Menanggapi keluhan mengenai peningkatan dramatis dalam sumber daya untuk unggahan gambar, Silverstein mengatakan mereka mengandalkan mekanisme "coba lagi" untuk mengurangi masalah ini.

“Perubahan ini juga menggandakan berapa kali WordPress akan mencoba regenerasi gambar, jadi sementara waktu pemrosesan akan meningkat, saya tidak berpikir kita akan melihat lompatan kegagalan,” katanya. “Saya tahu kami kesulitan menambahkan ukuran baru di masa lalu, namun itu terjadi sebelum kami menambahkan mekanisme coba lagi.”

Tim di belakang proyek WebP secara default lebih fokus pada penyajian ukuran gambar yang lebih kecil di frontend dan menganggap penggunaan sumber daya tambahan saat mengunggah pengorbanan yang diperlukan untuk pengguna WordPress.

“Sumber daya tambahan pada waktu pengunggahan perlu ditimbang dengan pengurangan sumber daya untuk menyajikan gambar WebP yang lebih kecil, terutama karena penayangan biasanya lebih sering terjadi beberapa kali lipat daripada mengunggah,” kata Silverstein.

“Jika pengunggahan gagal setelah semua percobaan ulang, pengguna memiliki pengalaman yang sama seperti saat ini: mereka dibiarkan dengan gambar yang rusak dan tidak dapat digunakan. Itu mungkin bisa diperbaiki, meskipun saya tidak berpikir perubahan ini akan meningkatkan tingkat kegagalan.”

Pengembang utama WordPress Dion Hulse juga mengomentari tiket untuk melaporkan masalah dengan konversi WebP di Direktori Foto WordPress:

Perhatikan di sini, bahwa konversi webp tambahan ini tampaknya menjadi penyebab utama kegagalan pengunggahan di Direktori Foto WordPress dalam beberapa minggu terakhir. Lihat #meta6142 dan tiket ditutup sebagai duplikatnya.

Kesalahan umumnya sejalan dengan Allowed memory size of 256M bytes exhausted (tried to allocate 90M bytes (jelas dengan nilai byte) saat mencoba melakukan jpeg asli ukuran penuh awal -> konversi webp.

Itu tidak memengaruhi setiap unggahan , hanya pada gambar tertentu. Berpotensi terkait dengan nilai $quality yang diteruskan untuk permintaan webp (IIRC default 82 dioptimalkan untuk jpeg?).

Hulse menonaktifkan konversi JPEG ke WebP sebagai akibat dari kesalahan ini, karena direktori foto saat ini tidak menggunakan WebP tetapi mencatat bahwa "mungkin merupakan tanda bahwa mungkin perlu mempertimbangkan hanya menghasilkan webp untuk gambar yang diubah ukurannya, daripada untuk file aslinya juga.”

Silverstein mengatakan mereka sedang menyelidiki masalah yang dilaporkan Hulse, karena mungkin telah mengekspos bug.

Ozz melingkari kembali untuk merekomendasikan bahwa membuat sub-ukuran sesuai permintaan akan menjadi pendekatan yang lebih baik yang memiliki pemrosesan gambar yang diunggah lebih cepat dan kebutuhan ruang yang berkurang, karena gambar JPEG tambahan tidak akan dihasilkan kecuali diperlukan. Dia juga mencatat bahwa "coba lagi" untuk pasca-pemrosesan gambar "tidak bekerja sebaik yang diharapkan."

“Kabar buruknya adalah jika pemrosesan pos gagal, kemungkinan file yang diunggah semula akan tetap ada,” kata Ozz. “Kemudian itu akan digunakan di mana-mana karena sebagian besar kode di WP kembali ke ukuran yang tersedia, dan satu-satunya ukuran adalah yang asli. Itu berarti kami akan menyajikan gambar berukuran besar (4MB – 8MB rata-rata). Kelemahan yang serius.”

Silverstein menanggapi saran Ozz, setuju dengan banyak orang, dan mengusulkan dua jalur potensial ke depan untuk proyek tersebut:

1. Pertahankan infrastruktur multi-mime saat ini, tetapi ubah default sehingga hanya file WebP yang dihasilkan, mungkin hingga ukuran ambang batas di mana hanya JPEG yang akan dihasilkan. Sebagian besar pekerjaan yang ada akan berlanjut; pemfilteran konten mungkin dapat dihapus.
2. Kembalikan infrastruktur multi-mime dan beralih kembali ke pendekatan mime tunggal, menggunakan WebP untuk gambar hingga ukuran ambang batas dan menyesuaikan lapisan kompatibilitas untuk menggunakan JPEG yang kami simpan.

Tim Kinerja sedang melakukan lebih banyak penelitian dan untuk sementara berhenti melakukan hal lain sampai mereka menerima umpan balik tentang arah selanjutnya untuk proyek tersebut.