WordPress Baş Geliştiricilerinden Gelen Yeni İtirazlardan Sonra Varsayılan Olarak 6.1 için Beklemede WebP

Geçen hafta Performans ekibine katkıda bulunanlar, Temmuz sonunda ana çalışma 6.1 için çekirdeğe birleştirildikten sonra çoklu mime/WebP özelliği için takip yamalarını iyileştirme üzerinde çalışıyorlardı. Bu, desteklenmeyen tarayıcılar için altlık ve ayrı biletlerde işlenen PDF desteği ekleme gibi daha küçük ilgili öğeleri içerir.

Yeni JPEG resim yüklemeleri için varsayılan olarak WebP resimleri oluşturma önerisi başından beri tartışmalı olmuştur. Projeyi yürüten Google sponsorluğundaki katkıda bulunanlar, ilk önemli kritik geri bildirim turundan sonra bazı revizyonlar yapmış olsa da, diğer katkıda bulunanlar dikkate alınmadıklarını söyledikleri endişelerini dile getirmeye devam ettiler. Katkıda bulunan birkaç kişi, özellikle ilgili sorunları bildirdi ve ana çalışma yapılmadan önce özetle reddedilen bir fikir olan kaydolarak başlaması gerektiğini önerdi.

Geçen hafta, WordPress baş geliştiricisi Andrew Ozz, yeni itirazlarla bilete ağırlık verdi:

@MatthiasReinholz, @eatingrules ve diğerleri gibi, bu yaklaşımın belki de eksik olduğunu düşünüyorum. Yarısı hiçbir zaman hiçbir yerde kullanılmayacakken neden fazladan yer kaplayan iki kat daha fazla görüntü dosyası olsun ki?

IMHO daha iyi bir yaklaşım, tüm görüntü alt boyutlarını WEBP yapmak olacaktır. JPEG'lere gerçekten ihtiyaç duyulursa, bunlar gerektiğinde anında oluşturulabilir. Tüm bu gereksiz dosyalarla web sunucularının deposunu tıkamanın bir anlamı yok.

Öte yandan, WEBP dosya boyutları aslında JPEG'lerden daha büyükse, bu muhtemelen daha iyi araçlara ihtiyaç olduğu anlamına gelir ve bu yama erkendir.

Altı hafta önce, "dönüşüm için kaynakların muazzam olacağına" dair bir şikayete yanıt olarak, Google'ın sponsorluğundaki temel sorumlu Adam Silverstein, yükleme sırasında görüntüleri oluşturmak için kaynakların "önemli ölçüde artacağını" doğruladı.

Silverstein, "Ancak bir imaja hizmet edecek kaynaklar azaltılacak" dedi. "Resim yükleme, resim sunmaya kıyasla çok nadir olduğundan, resimleri sıkıştırmak ve depolamak için harcanan ekstra çaba buna değer olmalı."

Bu, Ozz'ın bu yaklaşıma itirazında değindiği bir başka sorundur.

Ozz, "Aslında bir resim yüklerken kaynak kullanımındaki bu çarpıcı artış burada çok kötü bir yan etki" dedi. “Bu, birçok yüklemenin başarısız olacağı ve kullanıcıları yarı yolda bırakacağı anlamına geliyor. Ayrıca hem WordPress hem de barındırma şirketleri için destek taleplerini önemli ölçüde artıracaktır. Bunun kabul edilebilir olduğunu düşünmeyin. Bu nedenle, WordPress'te görüntü çoklu mime desteğine ihtiyaç duyulsa bile, mevcut yaklaşım iyi bir çözüm gibi görünmüyor.”

Yaklaşık 24 saat sonra, Google sponsorluğunda katkıda bulunan Felix Arntz, eski tarayıcılar için WebP'nin JPEG'e geri dönüş mekanizmasının kullanıma hazır olduğunu ve birkaç gün içinde gerçekleştirmeyi planladığını bildirmek için yorum yaptı.

Ozz, "Yüklemeden sonra görüntü alt boyutlarını oluşturmak için gereken kaynakların çarpıcı biçimde artmasını ele almadıkça, lütfen burada daha fazla kod işlemeyin," dedi. “Yukarıda söylediğim gibi bu artış kabul edilemez.

“Farklı görüntü boyutları yüklerken ne kadar daha fazla kaynağa (bellek, işlem süresi vb.) ihtiyaç duyulduğuna dair herhangi bir veri var mı? Bundan kaç sitenin etkilenebileceğine dair herhangi bir tahmin var mı? Bununla nasıl başa çıkılacağına dair herhangi bir öneriniz var mı? Yüklenen bir görüntünün sonradan işlenmesi başarısız olduğunda ne olduğunu biliyor musunuz?

"Açıkçası şimdilik bu yamanın bunu ele almak için geri alınması ve yeniden düzenlenmesi gerekecek gibi görünüyor."

Adam Silverstein, endişelerine, bazı uç durumlar beklentisiyle ve daha yaygın olarak desteklendiğinde AVIF gibi formatlar için destek ekleyerek neden mevcut yaklaşımı seçtiklerine açıklık getirerek yanıt verdi:

Tüm alt boyutların yalnızca WebP olarak oluşturulması gerektiği konusundaki değerlendirmenize katılma eğilimindeyim, orijinal teklifin şekli buydu. Kullanım durumlarının/kullanıcıların büyük çoğunluğu için bu en iyi sonucu verecektir. Bunu varsayılan olarak değerlendirmeye açığım (bazı hafifletmelerle, aşağıya bakın).

Her iki formatı da oluşturmaya karar vermemizin nedeni, WebP görüntülerinin çalışmayabileceğini belirlediğimiz birkaç uç durum için geriye dönük uyumluluk hususlarıydı: yani e-postayla gönderilen görüntüler (bazı eski görünüm/windows istemcileri), Açık Grafik etiketleri (bazı hizmetler desteklemez). WebP) ve daha eski Safari tarayıcıları. Düşündüğümüz bir olasılık, yalnızca tam boyutlu JPEG'i tutmaktır, böylece bu uç durumlar için her zaman kullanılabilir.

Buradaki "çoklu mim" desteği, sitelerinizin picture öğesi gibi bir şeyle birincil ve geri dönüş biçimi sağlayabilmesi için birden çok biçim oluşturmak üzere oluşturulmuştur. Bu, WebP için daha az önemlidir, çünkü çok yaygın olarak desteklenir, ancak eklentiler veya çekirdek tarafından AVIF gibi daha yeni biçimlerin benimsenmesi için yararlı olacaktır.

Silverstein ayrıca anında görüntü oluşturma seçeneğinin anlamaları gereken bir şey olduğunu, ancak "bu çaba için kapsam dışında hissettiklerini" söyledi.

Silverstein, resim yükleme kaynaklarındaki çarpıcı artışla ilgili şikayete yanıt olarak, bu sorunu azaltmak için "yeniden deneme" mekanizmasına güvendiklerini söyledi.

"Bu değişiklik aynı zamanda WordPress'in görüntü yenilemeyi yeniden deneme sayısını iki katına çıkarıyor, bu nedenle işlem süresi artacak olsa da, başarısızlıklarda mutlaka bir sıçrama göreceğimizi sanmıyorum" dedi. "Geçmişte yeni boyutlar eklemekte sorun yaşadığımızı biliyorum, ancak bu, yeniden deneme mekanizmasını eklemeden önceydi."

Varsayılan olarak WebP projesinin arkasındaki ekip, ön uçta daha küçük görüntü boyutları sunmaya daha fazla odaklanıyor ve yükleme sırasında ek kaynak kullanımını WordPress kullanıcıları için gerekli bir fedakarlık olarak görüyor.

Silverstein, "Yükleme sırasındaki ek kaynakların, daha küçük WebP görüntüsünü sunmanın azalan kaynaklarına karşı tartılması gerekiyor, özellikle de hizmet genellikle yüklemeden birkaç büyüklük sırası daha sık gerçekleştiğinden," dedi.

"Tüm yeniden denemelerden sonra yükleme başarısız olursa, kullanıcı şu anda olduğu gibi aynı deneyime sahip olur: kırık, kullanılamaz bir görüntü ile kalırlar. Bu muhtemelen düzeltilebilir, ancak bu değişikliğin başarısızlık oranlarını artıracağını düşünmüyorum.”

WordPress baş geliştiricisi Dion Hulse, WordPress Fotoğraf Dizini'ndeki WebP dönüşümleriyle ilgili sorunları bildirmek için bilete yorum yaptı:

Sadece burada, bu ek webp dönüşümlerinin, son haftalarda WordPress Fotoğraf Dizini'ndeki yükleme hatalarının önde gelen nedeni olduğu görülüyor. Bakın #meta6142 ve biletler bunun kopyası olarak kapatıldı.

Hatalar genellikle, başlangıçtaki tam boyutlu orijinal jpeg -> webp dönüşümünü gerçekleştirmeye çalışırken Allowed memory size of 256M bytes exhausted (tried to allocate 90M bytes (belli ki bayt değerleriyle).

Her yüklemeyi etkilemedi, yalnızca belirli resimlerin yüklemesini etkiledi. Webp istekleri için iletilen $quality değeriyle potansiyel olarak ilişkilidir (IIRC varsayılanı 82, jpeg için optimize edilmiştir?).

Hulse, bu hataların bir sonucu olarak JPEG'den WebP'ye dönüştürmeyi devre dışı bıraktı, çünkü fotoğraf dizini şu anda WebP'yi kullanmıyor, ancak bunun "yeniden boyutlandırılmış resimler için değil, yalnızca yeniden boyutlandırılmış resimler için webp'ler oluşturmayı düşünmeye değer olabileceğinin bir işareti olabileceğini" belirtti. orijinal dosya da."

Silverstein, bir hatayı ortaya çıkarmış olabileceği için Hulse'nin bildirdiği sorunları araştırdıklarını söyledi.

Ozz, talep üzerine alt boyutların oluşturulmasının, yüklenen görüntülerin daha hızlı işlenmesi ve ek JPEG görüntüleri gerekmedikçe oluşturulmayacağından daha az alan gereksinimlerine sahip daha iyi bir yaklaşım olacağını önermek için geri döndü. Ayrıca, görüntü son işleme için "yeniden denemenin" "beklendiği kadar iyi çalışmadığını" da belirtti.

Ozz, "Kötü haber şu ki, sonradan işleme başarısız olursa, orijinal olarak yüklenen dosyanın kalma olasılığı yüksek" dedi. “Sonra, WP'deki kodun çoğu mevcut boyutlara düştüğü için her yerde kullanılacak ve tek boyut orijinal olacak. Bu, devasa (4MB – 8MB ortalama) görseller sunacağımız anlamına geliyor. Ciddi bir dezavantaj.”

Silverstein, Ozz'ın önerilerine yanıt verdi, birçok kişiyle aynı fikirde oldu ve proje için ileriye dönük iki potansiyel yol önerdi:

1. Mevcut çoklu mime altyapısını koruyun, ancak varsayılanları, yalnızca WebP dosyalarının oluşturulması için değiştirin, muhtemelen ötesinde yalnızca JPEG'lerin oluşturulacağı bir eşik boyutuna kadar. Mevcut çalışmaların çoğu devam edecekti; içerik filtreleme muhtemelen kaldırılabilir.
2. Çoklu mime altyapısını geri alın ve eşik boyutuna kadar olan görüntüler için WebP kullanarak ve tuttuğumuz JPEG'leri kullanmak için uyumluluk katmanını ayarlayarak tek bir mim yaklaşımına geri dönün.

Performans ekibi daha fazla araştırma yapıyor ve projenin bir sonraki yönü hakkında geri bildirim alana kadar başka bir şey yapmayı geçici olarak durdurdu.