WordPress 7.1 Tarayıcıda Medya İşleme: wasm-vips ile

WordPress içerik üretimi yapan her ajansın destek kuyruğunda aynı klasör vardır: görsel yüklenemedi. Bir editör iPhone’dan çıkan 22 MB’lık bir HEIC dosyasını doğrudan ortam kütüphanesine bırakır, PHP işçisi 256 MB bellek sınırına dayanır, Imagick tanımadığı bir renk profilinde patlar, müşteri de blok editörün “çalışmadığını” sorar. Yirmi yıl sonra hâlâ bu iş sunucu maliyetinin şaşırtıcı bir kısmını sırtlanıyor.

Bir süredir söylediğim şu: dürüst çözüm daha fazla PHP belleği değil. Çözüm, tarayıcının aptal bir boru olduğunu varsaymaktan vazgeçmek. Tarayıcılar yıllardır WebAssembly SIMD, Web Worker, WebCodecs ve yapılandırılmış dosya API’leriyle geliyor. Uyumsuzluk şuydu: WordPress piksel hesabını hâlâ paylaşımlı bir PHP sürecinde, beş yıllık bir GD derlemesiyle yaptırıyordu.

WordPress 7.1 bu varsayımın bittiği sürüm. Adam Silverstein geliştirici notunu dün Make/Core üzerinde yayımladı, özellik trunk’ta, Beta 3’te ve 19 Ağustos’ta yayına giren sürüm destekli tarayıcılarda varsayılan olarak açık gelecek. Bu bir eklenti değil. Çekirdeğin birinci sınıf yeteneği ve doğru okunmayı hak ediyor.

Aslında ne değişiyor

Yayımlanan Client-Side Media Processing in WordPress 7.1 geliştirici notu meseleyi net anlatıyor: görsel sıkıştırma, yeniden boyutlandırma, biçim dönüşümü, döndürme ve küçük resim üretimi artık kullanıcının tarayıcısında WebAssembly ile yapılıyor. Motor, Kleis Auke Wolthuizen’in libvips görüntü kütüphanesinden derlediği wasm-vips; editörün ana iş parçacığını kilitlememek için bir Web Worker içinde çalışıyor. Bunun için üç yeni JavaScript paketi geliyor — @wordpress/upload-media, @wordpress/vips ve @wordpress/video-conversion — bir de PHP tarafında wp_is_client_side_media_processing_enabled() özellik kapısı.

Desteklenen işlemler tam da sunucuları eskiden yiyip bitiren işler: JPEG / PNG / WebP / AVIF / GIF dönüşümü, EXIF döndürme, aşamalı (progressive) kodlama, doğrudan iPhone’dan HEIC ve HEIF kod çözümü, 10-bit ve 12-bit HDR kaynaklar dâhil uçtan uca AVIF, UltraHDR kazanç haritası (gain map) korunması, hareketli GIF’in sessiz döngülü MP4 / WebM’e çevrilmesi. Kayıtlı her alt boyut yerelde üretiliyor, sonra her alt boyut yeni REST uçlarına — POST /wp/v2/media/{id}/sideload ve POST /wp/v2/media/{id}/finalize — tek tek gönderiliyor. Yüklemeler çevrimdışı olunca duraklıyor, geri gelince kaldıkları yerden sürüyor, başarısız istekler üstel gecikmeli yeniden deneme ile yenileniyor. Geliştirici ayrıntıları aynı gün yayımlanan Gutenberg 23.6‘da; bu sürüm ayrıca GIF’ten videoya dönüşümü blok dönüşümüyle isteğe bağlı hâle getirdi ve yüksek bit derinlikli AVIF alt boyutlarının bit derinliğini koruyor.

Tarayıcı desteği önemli ve pazarlamanın söylediğinden daha dar. Chrome 137 ve Edge 137 tam boru hattını alıyor. Android’de Chrome 146+ gerekiyor. Firefox ve Safari bugün sunucu tarafına düşüyor çünkü wasm-vips için gereken SharedArrayBuffer‘ı açan Document-Isolation-Policy başlığını henüz uygulamıyorlar. Ayrıca çalışma zamanı kontrolleri de var: 2 GB’tan fazla aygıt belleği, en az iki CPU çekirdeği, slow-2G üstü ağ ve blob: worker’a izin veren bir İçerik Güvenlik Politikası (CSP). Herhangi bir denetim başarısız olursa WordPress sessizce mevcut sunucu tarafı yola geçiyor. Dün yayımlanan WordPress 7.1 Beta 3 notu özellikle hareketli GIF, EXIF döndürülmüş görsel ve Safari’de yinelenen HEIC girdisi düzeltmelerini sayıyor; bu da yüzeyin GA’ya bir ay kala hâlâ cilalandığını gösteriyor.

WordPress ve WooCommerce tarafında neyi değiştirir

Üç şey aynı anda değişiyor ve birbirini besliyor.

Birincisi: içerik yoğun sitelerde barındırma faturasını belirleyen sunucu tarafı görsel işi köken sunucudan çıkıyor. Bir WooCommerce kataloğu yükleme seansında — bir merchandiser, kırk ürün fotoğrafı, her biri altı alt boyut — bu PHP işçisinin artık yapmadığı 240 yeniden boyutlandırma işlemi demek. Bunu en yoğun müşterinizin Pazartesi sabahındaki editör sayısıyla çarpıp yönetilen barındırma paketinizin fiyat basamağı ile karşılaştırın. “Kalıcı nesne önbelleği kur, PHP belleğini artır” formülünün tek kaldıraç olmadığı ilk WordPress sürümü bu.

İkincisi: biçim desteği artık barındırıcının ne kurduğuna bağlı değil. Tarayıcı kapısını geçen her kullanıcı, sunucuda GD WebP ile mi derlenmiş, Imagick derlemesi AVIF anlıyor mu diye bakmadan libvips’in ürettiği çıktıyı alıyor. Modern bir iPhone’dan HEIC yüklemesi ücretli bir dönüştürme hizmeti olmadan sonunda çalışıyor. AVIF uçtan uca ve HDR bilgisi bozulmadan geliyor. JPEG’ler mevcut GD varsayılanına göre yaklaşık yüzde on beş daha küçük çıkıyor çünkü kodlama MozJPEG tarzı. Tek satır tema değişikliği yapmadan ön yüz teslimi kendiliğinden hızlanıyor.

Üçüncüsü — ve geliştirici notunu okumayanları ısıracak olan bu — sunucu tarafı uzatma noktaları kayıyor. wp_generate_attachment_metadata filtresi hâlâ çalışıyor, hatta artık iki kez: ilk yüklemede 'create' bağlamıyla, istemci sonlandırdıktan sonra 'update' bağlamıyla. Filigran ekleyen eklentiler, CDN eşitleyicileri, üstveri işleyen uzantılar bu filtreyi doğru bağladıysa uyumlu kalıyor. Ama wp_image_editors, image_memory_limit ve wp_image_make_intermediate_size istemci yolunda hiç çalışmıyor. Özel görsel boru hattınız bu kancalardan birine oturuyorsa Chromium kullanan editörlerinizin altmıştan fazla yüzdesi için sessizce devre dışı kalıyor. Bu denetimin 19 Ağustos GA’sından sonra değil, önce yapılması gerekiyor.

Yapacaklarım (ve yapmayacaklarım)

Bu hafta, staging ortamda, blok temayla, Chrome 137 veya üstü tarayıcıda dört geçiş.

Bir: her özel eklentide ve mu-plugin’de wp_image_editors, wp_image_make_intermediate_size, image_memory_limit ve yükleme sırasında doğrudan $_FILES‘i inceleyen kodu grep’leyin. Her isabet bir adaydır. Mümkün olan yerde mantığı wp_generate_attachment_metadata filtresine taşıyın; iki yolda da çalışan tek filtre bu. Bir eklenti sunucu tarafı yolu zorunlu tutuyorsa — lisanslı bir görsel tanıma SDK’sı, PHP’den piksel okuyan özel bir DAM eşitleyici — şimdi karar verin: özelliği add_filter( 'wp_client_side_media_processing_enabled', '__return_false' ); ile küresel olarak kapatacak mısınız yoksa çatallı davranışı kabul edip iki dalı da ölçeklendirecek misiniz.

İki: her yönetilen sitede İçerik Güvenlik Politikası başlıklarını denetleyin. CSP worker-src 'self' blob:; içermiyorsa wasm worker başlayamıyor, her Chromium kullanıcısı sessizce sunucu tarafına düşüyor. Bir hata görmezsiniz. Sadece vaat edilen iyileşmenin hiç gelmediğini görürsünüz. 7.1 kurulduktan sonra gerçek bir üretim sitesinde ölçülebilir bir kazanç görülmemesinin en olası tek nedeni budur.

Üç: gerçek bir iPhone fotoğrafıyla HEIC yükleyin, EXIF döndürülmüş bir portre yükleyin, 40 MB’lık bir AVIF yükleyin, 8 MB üzerinde hareketli bir GIF yükleyin. Beta 3’ün özellikle düzelttiği dört başarısızlık modu bunlar — büyük ihtimalle en sık karşılaşılanları. Hareketli GIF’in dönüşümde sessiz döngülü bir Video bloğuna çevrildiğini ve orijinal image/gif ekinin, video varyantı media_details.animated_video‘da kayıtlı hâlde, hâlâ durduğunu doğrulayın. Müşteri açıkça istemedikçe otomatik dönüştürmeyi arayüzde açmayın — Gutenberg 23.6’nın onu tekrar isteğe bağlı yapmasının sebebi tam da bu.

Dört: WooCommerce mağazaları için bu değişikliği WooCommerce 11.0 yükseltme penceresinin üstüne koymayın. WooCommerce 11.0 28 Temmuz’da yeni mağazalar için ürün nesne önbelleği varsayılan açık olarak geliyor. WordPress 7.1 19 Ağustos’ta desteklenen tarayıcılar için istemci taraflı medya işleme varsayılan açık olarak geliyor. Aynı triyaj kuyruğunda iki hareketli hedef, hafta sonlarının nasıl buharlaştığının tarifidir. WooCommerce 11.0 geçişini önce WordPress 7.0.2 kararlı sürüm üzerinde yapın. 7.1’i takvime ancak müşterinizin ürün fotoğrafçılığı iş akışı güvendiğiniz bir tarayıcıdaysa — yani masaüstünde Chrome veya Edge, Android’de Chrome 146+ — ekleyin.

“Üretimde WebAssembly’ye güvenmiyoruz” refleksiyle özelliği kapatmayın. Chrome ve Edge wasm-vips sınıfı yükleri yıllardır çalıştırıyor, izolasyon modeli site geneline değil belge bazında uygulanıyor ve yedek yol zaten bugün çalıştırdığınız kod. Yeni sideload ve finalize REST uçları üzerine de henüz üretim aracı kurmayın. Bir sürüm döngüsü daha yüzeyin oturmasını bekleyin.

Büyük resim şu: WordPress çekirdeği 2003’ten beri sunucuda duran bir iş kategorisini az önce oradan çıkardı. Bu, ancak dikişleri denetlerseniz karşılığını veren, denetlemezseniz sizi sonradan ısıran o sessiz altyapı değişikliklerinden biri.