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

🇬🇧 English: Read this in English →

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. Açık konuşayım: bu klasörü ben de yıllarca taşıdım, ve çözümün “biraz daha PHP belleği” olmadığını çoktan öğrendim.

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.

Bunu daha önce gördüm: işi önündeki makineye yaptırmak

İzin ver de bir dakikalığına eski defteri açayım. Bu “piksel işini sunucuya değil, kullanıcının önündeki makineye yaptır” fikri bana hiç yabancı gelmedi, çünkü 1990’larda çok lisanlı CD-ROM projeleri ürettiğimde sunucu diye bir lüksümüz zaten yoktu. Görsel neyse, işleyecek olan da senin masandaki makineydi. Yüzlerce fotoğrafı doğru palete indirmek, doğru boyuta getirmek, diske sığdırmak — hepsi orada, önümdeki kutuda dönerdi. O disiplin bana şunu öğretti: ağır işi son kullanıcının cihazına yaklaştırdığında, o iş merkezi bir darboğaz olmaktan çıkar.

Web bu dersi tersinden ve geç öğrendi. Yıllarca her şeyi köken sunucuya yığdık, çünkü tarayıcıya güvenmiyorduk. Şimdi tarayıcı, o eski multimedya iş istasyonlarının rüyasında göremeyeceği kadar güçlü bir işlemci taşıyor ve boşta duruyor. WordPress 7.1’in yaptığı tam olarak bu: yıllardır sunucuda tuttuğumuz işi, zaten kapasitesi olan makineye geri veriyor. Nostalji satmıyorum — sadece “yeni” denen şeyin çoğu zaman eski bir prensibin doğru yere oturması olduğunu söylüyorum.

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üşterinin Pazartesi sabahındaki editör sayısıyla çarp, yönetilen barındırma paketinin fiyat basamağı ile karşılaştır. “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 bu kancalardan birine oturuyorsa Chromium kullanan editörlerinin 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’le. Her isabet bir adaydır. Mümkün olan yerde mantığı wp_generate_attachment_metadata filtresine taşı; 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 ver: özelliği add_filter( 'wp_client_side_media_processing_enabled', '__return_false' ); ile küresel olarak mı kapatacaksın, yoksa çatallı davranışı kabul edip iki dalı da ölçeklendirecek misin.

İki: her yönetilen sitede İçerik Güvenlik Politikası başlıklarını denetle. 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örmezsin. Sadece vaat edilen iyileşmenin hiç gelmediğini görürsün. 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ükle, EXIF döndürülmüş bir portre yükle, 40 MB’lık bir AVIF yükle, 8 MB üzerinde hareketli bir GIF yükle. 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ğrula. Müşteri açıkça istemedikçe otomatik dönüştürmeyi arayüzde açma — 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 koyma. 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. 7.1’i takvime ancak müşterinin ürün fotoğrafçılığı iş akışı güvendiğin bir tarayıcıdaysa — yani masaüstünde Chrome veya Edge, Android’de Chrome 146+ — ekle.

“Üretimde WebAssembly’ye güvenmiyoruz” refleksiyle özelliği kapatma. 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 kod. Yeni sideload ve finalize REST uçları üzerine de henüz üretim aracı kurma. Bir sürüm döngüsü daha yüzeyin oturmasını bekle.

Kazancı nasıl ölçersin

Bir uyarı: bu özelliği açıp “hallettik” demek kolay, ama gerçekten devrede olup olmadığını ölçmezsen kendini kandırırsın. Ben olsam üç basit sinyale bakardım. Birincisi köken sunucudaki CPU: yoğun bir yükleme seansında PHP işçilerinin görsel işlemeye harcadığı süre gözle görülür düşmeli — düşmüyorsa büyük ihtimalle o CSP başlığı worker’ı engelliyordur. İkincisi, üretilen JPEG’lerin dosya boyutu: MozJPEG tarzı kodlama gerçekten devredeyse aynı görselin çıktısı eski GD varsayılanına göre daha küçük olmalı. Üçüncüsü, editörlerin “yükleme takıldı” şikâyetlerinin sıklığı; asıl kazanç faturada değil, o destek kuyruğunun sessizleşmesinde görünür.

Bu ölçümleri 7.1 kurulmadan önce bir kez al, sonra bir kez daha. Aradaki fark senin gerçek kazancın — pazarlama slaytındaki rakam değil, kendi sunucunda kendi trafiğinle ölçtüğün rakam. Bu işin dinozoru olarak sana söyleyebileceğim en sağlam tavsiye bu: her “sessiz altyapı değişikliğini” kendi verinle doğrula, kimsenin sözüne güvenme.

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