WooCommerce Ürün Nesnesi Önbelleği 11.0’da Varsayılan

Yirmi yıldır kaç tane WooCommerce mağazasını teslim aldığımı saymayı bıraktım. Çoğunda biri üç farklı önbellekleme eklentisi, Redis arka ucu ve içerik dağıtım ağı kurmuş oluyordu; ürün sayfası yine de zamanının yarısını aynı ürün nesnesini tek bir istek içinde otuz kez yeniden kurmaya harcıyordu. Sorun donanım değildi. Sorun, WooCommerce’in veritabanına aynı soruyu defalarca sormasıydı; çünkü cevabı zaten bildiğini hatırlamıyordu.

Bu tür hatalar sürüm notlarında parlak kahraman görseli olmaz. Ama bir reklam yayını sırasında ayakta kalan ödeme sayfasıyla çöken ödeme sayfası arasındaki farkı yaratan tam olarak budur. O yüzden WooCommerce ekibinin ürün nesnesi önbelleğini 11.0 sürümünde yeni mağazalar için varsayılan olarak açmaya karar verdiğini okuduğumda dikkatimi verdim. Bu, platformun tabanını sessizce yükselten yapısal düzeltmelerden biri.

Aynı zamanda “varsayılan olarak açık” ifadesinin ne anlama geldiğini, kimi etkilediğini ve bir ajansın haftaya müşterilerine dürüstçe ne söz verebileceğini konuşmak için iyi bir an.

Asıl yeni olan ne

17 Haziran 2026’da WooCommerce mühendisi Vladimir Reznichenko, WooCommerce Geliştirici Blogu’nda ürün nesnesi önbelleğinin 11.0 ve sonrası yeni WooCommerce kurulumlarında varsayılan olarak açılacağını duyurdu. Özellik, wc_get_product() çağrılarını yakalıyor ve ürün nesnelerini her seferinde veritabanından yeniden kurmak yerine istek kapsamlı bir bellek içi önbellekten sunuyor.

Önbellek kalıcı değil. Yalnızca tek bir isteğin süresi boyunca yaşıyor ve sonra siliniyor. Kopya örnekler döndürüyor; böylece iki ayrı kod yolu aynı nesneyi yanlışlıkla değiştiremiyor. Site sahibinden de elle yönetim beklemiyor. Asıl iş 62041 numaralı çekme isteğiyle WooCommerce 10.5’e Aralık 2025’in sonunda isteğe bağlı özellik olarak girmişti; aylarca toplanan ölçüm verilerinden sonra ekip şimdi yeni kurulumlar için varsayılanı çeviriyor.

Reznichenko’nun yazısı iç testlerden iki somut sayı veriyor: varyasyonlu ürünler ürün sayfasında yaklaşık yüzde 9 ila 12 daha hızlı, paket ürünler ödeme sırasında yaklaşık yüzde 6 ila 12 daha hızlı işleniyor. Asıl çekme isteğindeki notlar sentetik yükte kazancı daha yukarı çıkarıyor (50 ürünün 50 kez çekildiği bir sıkı döngüde kabaca 4 ila 6 kat daha hızlı). Ama gerçek dünyadaki tavan tek haneli yüzdelerde; planlamada dürüst rakam bu.

Kimi nasıl etkiliyor:

• WooCommerce 11.0 üzeri yeni kurulumlar: önbellek varsayılan olarak açık. Hiçbir tıklama gerekmiyor.
• 11.0’a yükselten mevcut mağazalar: mevcut ayarınız korunuyor. Düğme kapalıysa kapalı kalıyor. Ekip canlı mağazanızın altında sessizce davranış değiştirmiyor.
• Zaten açmış mevcut mağazalar: yapacak bir şey yok.
• Düğme hâlâ WooCommerce → Ayarlar → Gelişmiş → Özellikler altında; eklentiler için varsayılan uyumluluk WooCommerce 10.6’da INCOMPATIBLE‘dan COMPATIBLE‘a çevrilmişti.

Bu değişiklik Action Scheduler 4.0.0 ile birlikte geliyor; o da WooCommerce 11.0 ile birlikte 28 Temmuz 2026’da yayımlanacak. Action Scheduler artık üç aydan eski başarısız işlemleri otomatik temizliyor, benzersiz işlemleri sadece kanca adına göre değil argümanlara göre de tekilleştiriyor ve temizliği kuyruk işleme sırasında satır içi çalıştırmak yerine her gün sabah 03.00’te ayrı bir işe taşıyor. Aynı tema: platform kendi ev işini üstlenmeye başlıyor; daha önce bu iş ajansa bırakılıyordu.

Takvim açısından, 10.9 beta duyurusuna göre WooCommerce 10.9 23 Haziran 2026’da yayımlanıyor; bu da temmuz sonundaki 11.0’ı bir sonraki büyük kilometre taşı yapıyor. Aynı 11.0 sürümü blok tabanlı ürün düzenleyici betasını da emekliye ayırıyor; yani birden fazla anlamda zemin süpürme sürümü.

WordPress ve WooCommerce ekipleri için neden önemli

Bir ajans için bu, yıllardır taşıdığınız biletleri sessizce kapatan türden bir değişiklik. Hepimiz bir öğleden sonramızı wc_get_product()‘u önce şablondan, sonra kısa koddan, sonra ilgili ürünler sorgusundan, sonra bir yapılandırılmış veri filtresinden, hep aynı ürün için çağıran ürün arşiv sayfalarını profillemekle harcadık. Çözüm yerel olurdu: özel bir eklentinin içinde bellek içi durağan önbellek ya da temada dikkatli bir yeniden düzenleme. 11.0 ile defteri platformun kendisi tutuyor; bu da özel iyileştirme katmanımızın bir kısmının doğrudan silinebileceği anlamına geliyor.

Dürüst uyarı şu: ürün sayfasında tek haneli yüzde kazançlar, alışılmış sebeplerle yavaşlayan bir mağazayı kurtarmaz. Şişkin bir tema, on iki pazarlama izleme kodu, gereksiz büyük bir kahraman görseli, her gösterimde eşzamanlı çağrı yapan üçüncü taraf öneri parçacığı… Ürün nesnesi önbelleği bir temel, bir çözüm değil. 3 saniyelik Largest Contentful Paint’i 1,5 saniyeye çevirmez. Belki 3’ü 2,7’ye çevirir; ama yüksek trafikli bir katalog sayfasında o 0,3 saniye sunucudaki işlemci kullanımı boyunca ve her ziyaretçinin Core Web Vitals puanı üstüne birikir.

Daha büyük hikâye, “varsayılan açık” kararının platformun olgunluk eğrisi hakkında söyledikleri. WooCommerce her performans iyileştirmesinin elle kurmanız gereken bir tuzak olduğu bir eklenti olmaktan çıkıyor. WordPress çekirdeğinin nesne önbelleğini, tembel yüklemeyi ve spekülatif ön yüklemeyi “yapılandırmalısınız”dan “artık zaten açık”a taşıması gibi, mantıklı varsayılanlara sahip bir platform haline geliyor. Daha önce yazdığımız WordPress oyununu hatırlayın: uzun vadede olgunluk kazanıyor, çünkü her mağaza taban iyileştirmeyi kabul etmeden devralıyor.

Eklenti yazarları için bir sonuç: ürün verisi için posts veya postmeta tablolarına ham SQL çalıştıran bir uzantınız varsa, sorgularınız yeni istek kapsamlı önbelleği geçersiz kılmaz. Çekme isteği belgeleri bunu açıkça belirtiyor. Çözüm sıradan: WooCommerce CRUD arayüzlerini kullanın ya da yazma işleminizden sonra doğru grupta wp_cache_delete çağırın. Ama o kod yoluna 2019’dan beri dokunmadıysanız, şimdi iyi bir zaman.

Ben ne yaparım (ya da yapmam)

10.x üzerinde mevcut bir mağaza işletiyorsanız: panik yapmayın, düğmeye koşmayın. Yükseltmede davranışınız korunur. Önce bir hazırlama kopyasında test edin — özellikle ürün sınıfında ağır özelleştirmeleriniz, özel fiyat filtreleriniz ya da WC_Product‘ı alt sınıflayan bir eklentiniz varsa. Gerçek bir ödeme, gerçek bir abonelik yenileme, gerçek bir varyasyon değişimi çalıştırın. 48 saatten sonra hiçbir şey kötü davranmıyorsa, üretimde açın ve uygulama izleme panonuzu bir hafta gözleyin.

28 Temmuz’dan sonra yeni bir mağaza kuruyorsanız: varsayılana dokunmayın. Ekibin bunu varsayılan yapmasının nedeni, hata modunun küçük, kazancın gerçek olması. Bir yeni kurulumda devre dışı bırakacağım tek senaryo, standart ürün önbelleği geçersiz kılma kancalarını uygulamayan özel bir veri deposu çalıştıran alışılmadık bir yığına sahip olmaktır — bu da nişin nişi.

Eklenti satıyorsanız: bu ay bir 11.0 uyumluluk denetimi yayımlayın. Özellik açıkken test paketinizi yeniden çalıştırın, ürün yazmalarından sonra bayat veri hatalarına bakın ve readme dosyanızı güncelleyin. FeaturesUtil bildiriminde eklentinizi COMPATIBLE olarak işaretlemeyi nezaketten değil, gerçekten kontrol ettikten sonra yapın.

Ve herkes için: bu yükseltmeyi, kendinizi iyi hissettiren bir performans incelemesiyle değil, gerçek bir performans incelemesiyle eşleştirin. Ödeme sayfanız kullanmadığınız dört ödeme betiğini hâlâ yüklüyorsa, ürün sayfasında yüzde 10 kazanç boşa gider. Önbelleği gerisini temizlemek için fırsat olarak kullanın.

WordPress ve WooCommerce’te şu an aynı örüntü tekrar ediyor: platform, daha önce faturalandırdığımız iyileştirmeleri kendi içine alıyor. Bu iyi bir şey. Ekmek parasını yazılım üreterek kazanan insanları, hâlâ insan gerektiren sorunlara — ürün sunumu, içerik, entegrasyonlar, güven sinyalleri — odaklanmaya bırakıyor; aynı önbellek sarmalayıcısını dördüncü kez yeniden satmaktan kurtarıyor.