WordPress libvips Görsel İşleme: Imagick’ten 18 Kat Hızlı

Görsel işleme, kimsenin gösterge paneline koymadığı sessiz maliyetlerden biridir. Yirmi yıldır WordPress ve WooCommerce projeleri için sunucu boyutlandırıyorum ve söyleyebilirim ki medya yoğun bir sitede — bir dergi arşivi, binlerce varyasyonu olan bir ürün kataloğu, hero kırpmalı bir portfolyo — yüklemeleri yeniden boyutlandıran Imagick işçisi genelde odadaki en sesli süreçtir. Aynı zamanda kimsenin dokunmadığı süreçtir, çünkü alternatif GD’dir ve GD küçük resimden öteye geçen hiçbir iş için ciddi bir alternatif değildir.

Dolayısıyla bir Çekirdek Trac önerisi gelip 25 yıllık bu tesisatı libvips ile değiştirmeyi ya da en azından tamamlamayı önerdiğinde dikkat kesilirim. libvips yeni bir şey değil — yıllardır Mastodon, Wikimedia, imgproxy, Rails Active Storage ve Node’un sharp kütüphanesinin görsel işlemesini sessizce yürütüyor. Asıl haber, birinin nihayet bunu WordPress Çekirdeği’nin de göndermesini önerecek olması.

Küçük gibi görünen ama ikinci dereceden etkileri çok büyük olan bir duyuru bu. Masadaki konunun ne olduğunu ve gerçek bir üretim sitesinde ne yapardım, anlatayım.

Gerçekten yeni olan ne

16 Haziran 2026 tarihli Performans Sohbeti özetinde, katkı sağlayıcı @nickchomey libvips entegrasyonunu öneren bir Çekirdek Trac biletini açacağını duyurdu. Belirtilen gerekçe net: libvips, Imagick’e kıyasla kayda değer CPU ve bellek avantajı sunuyor. Weston Ruter öneriyi kabul etti ve gerçekçi bir uyarı ekledi — barındırma sağlayıcılarının benimsemeye öncelik vermesi için Çekirdek desteği muhtemelen şart, o zaman bile yaygınlaşma yavaş olacaktır.

“Kayda değer” ifadesine rakam koymak gerekirse, yayımlanmış libvips kıyaslamaları aynı donanım üzerinde standart bir yükle-küçült-keskinleştir-kaydet testini libvips C varyantının yaklaşık 0,57 saniyede tamamladığını, PHP Imagick’in ise 10,53 saniye sürdüğünü gösteriyor. Bu 18 kat hızlanma demek. Aynı testte zirve bellek libvips için 94 MB iken ImageMagick için 1.500 MB’ye yakın — yaklaşık on altı kat daha az. Kıyaslama notu dürüst: bu test G/Ç ağırlıklı ve libvips’i kayırıyor. Saf işlem ağırlıklı gerçek dünya senaryosunda avantaj genellikle üç-beş kat daha hızlı ve bellekte beş-on kat daha hafif olur. Her iki şekilde de tartışılacak bir fark değil.

libvips C ile yazılmış, taleple çalışan, yatay olarak iş parçacığına bölünmüş bir görsel işleme kütüphanesi; lisansı LGPL-2.1-or-later, olgun PHP bağlamaları var. WordPress’in önemsediği her formatı işliyor — JPEG, PNG, WebP, AVIF, HEIC, TIFF, GIF — artı PDF ve SVG. Mastodon, MediaWiki, Rails Active Storage, sharp ve imgproxy üretiminde zaten kullanılıyor. Araştırma projesi değil bu.

Aynı Performans Sohbeti, ekibin WordPress 7.1 ile çekirdeğe almak istediği diğer iki yüksek öncelikli maddeyi de gündeme getirdi: özellik eklentisinden Çekirdek’e ön yüzde Görünüm Geçişlerinin (View Transitions) mezun edilmesi ve Gelişmiş Duyarlı Görsellerin yayımlanması. Her ikisi de Performance Lab şemsiyesi altında özellik eklentisi olarak var; her ikisi de Çekirdek birleştirme önerisi gelmeden önce bir tur daha tekrara ihtiyaç duyuyor. Bunların libvips ile ilgisiz olduğunu söylemek zor: hem Görünüm Geçişleri hem de duyarlı görsel varyantları, tipik bir isteğin tetiklediği görsel işlem sayısını çarpan etkisiyle büyütüyor.

libvips’in neyin yerine geçeceği ya da neyi tamamlayacağı konusunda bağlam vermek gerekirse, WordPress Çekirdek bugün iki görsel düzenleyici arka ucu gönderiyor: WP_Image_Editor_Imagick (PHP’nin ImageMagick bağlamaları) ve WP_Image_Editor_GD (PHP’nin GD bağlamaları). Mimari zaten takılabilir — üçüncü taraf görsel düzenleyiciler wp_image_editors filtresi üzerinden kaydolabiliyor. Bir libvips arka ucu aynı desene oturur. Öneri “Imagick’i söküp at” değil; “üçüncü, daha hızlı bir seçenek ekleyelim, sunucu ve kullanıcılar seçsin”.

WordPress ve WooCommerce dünyasında neden önemli

Önemli, çünkü görsel işleme, içerikle doğrusal ve format sayısıyla karesel olarak büyüyen birkaç WordPress maliyetinden biri. add_image_size() ile her yeni boyut eklediğinizde, WooCommerce bir ürün varyasyon galerisini her yeniden ürettiğinde, biri tema değişiminden sonra Regenerate Thumbnails her çalıştırdığında — bu iş uygulama sunucusunda CPU saniyesi ve RSS bellekle ödeniyor. Yanında AVIF ve WebP’yi JPEG ile birlikte üretmeyi koyun, üzerine duyarlı srcset’leri ekleyin; fatura çok gerçek.

libvips Çekirdeğe girerse, isteğe bağlı bir arka uç olarak bile, üç somut sonuç çıkar.

Bir. Barındırma ekonomisi değişir. Yönetilen WordPress barındırma sağlayıcıları Imagick’i ölçekte koşturuyor ve her bellek tepe noktasını hissediyor. Görsel işlem başına bir kat daha az RAM isteyen bir arka uç, aynı makinenin daha fazla eşzamanlı yükleme, daha hızlı yeniden üretim ve daha agresif duyarlı varyant üretimi servis etmesini sağlar. Bu, her WP Engine, Kinsta, Pressable, Hostinger ve kendi sunucusunu işleten ops ekibinin bir sonraki fatura döneminde sessizce fark edeceği bir marj.

İki. WooCommerce katalogları yeniden yönetilebilir hale gelir. Binlerce ürünü, her birinde birkaç varyasyon galerisi olan ve WooCommerce 10.9 ile çekirdeğe gelen varyasyon görsel galerilerini kullanan bir Woo mağazanız varsa, bugün tam bir küçük görsel yeniden üretiminin maliyeti saatlerle ve migrenle ölçülüyor. libvips ile bu dakikalara iner. Aynı şey toplu içe aktarımlar ve CSV güdümlü katalog göçleri için de geçerli.

Üç. Modern formatlar artık lüks olmaktan çıkar. AVIF ve HEIC, Imagick’te üretmesi pahalı formatlar. libvips’te değil. Çekirdek hızlı bir arka uç gönderirse, AVIF varyantlarını WebP ve JPEG’in yanında üretmek “CDN’de hallederiz” konuşmasından çıkıp varsayılan olmaya başlar. Bu hem Core Web Vitals için iyi, hem de yavaş mobil bağlantıdaki herkes için iyi.

Ben ne yapardım (ya da yapmazdım)

Şu an, bugün, üretimde hiçbir şey. Öneri henüz bir öneri. Birleşmiş bir Çekirdek Trac bileti yok, yama yok, zaman çizelgesi yok. Görünüm Geçişleri ve Gelişmiş Duyarlı Görseller WordPress 7.1 kuyruğunda önde ve onlar bile hâlâ özellik eklentisi tekrarında. Çekirdekte libvips’i 2026 dördüncü çeyrek ya da sonrası bir beklenti olarak ele alın, üçüncü çeyrek planı olarak değil.

Yapardım dediğim şey ölçmeye başlamak. En yüklü üç sitenizde mevcut görsel hattınızın duvar saati süresini ve zirve belleğini kayıt altına alın. Hazırlık ortamında --dry-run ile wp media regenerate ilk ölçüm için yeterli. Tam yeniden üretim sırasında Imagick’in zirve RSS değerini yakalayın. Bu rakamları saklayın. libvips isteğe bağlı arka uç olarak geldiğinde, üretimde değişikliği onaylayan kişiye geçişin gerekçesini gösterebilmek için temiz bir önce/sonra karşılaştırması işinize yarayacak.

Yapmayacağım şey, bu haberin gücüne dayanarak bu çeyrek üretim sitesine GitHub’da yer alan üçüncü taraf libvips görsel düzenleyici eklentilerinden birini kurmak. Birkaçı var. Hazırlık ortamında denemek için makuller. WordPress.org dağıtım ölçeğinde savaş testinden geçmiş değiller ve Çekirdek uygulaması geldiğinde soyutlama büyük olasılıkla değişecek. Trac biletini bekleyin. Yamayı okuyun. Sonra değerlendirin.

Yönetilen bir barındırma işletseydim yapardım dediğim şey, libvips ve PHP vips uzantısını temel imaja almak için satın alma konuşmasını şimdiden başlatmak. Bu bir sistem bağımlılığı, Composer paketi değil. Barındırma sağlayıcıları sistem düzeyi değişikliklerde yavaş olabiliyor ve en kötü senaryo Çekirdeğin 2027’de libvips arka ucunu göndermesi ve kimsenin etkinleştirememesi — çünkü hiçbir yerde php-vips yüklü değil.

Bu haftaki Performans Sohbeti’nin dürüst okuması şu: WordPress Çekirdek nihayet görsel işlemeyi yalnızca bir doğruluk yüzeyi değil, bir performans yüzeyi olarak ciddiye almaya başlıyor. Geç kalınmış bir adım ve hoş geldi. Yamasıyla birlikte ilk Trac bileti açıldığında bunun gerçek olduğunu anlayacağız.