Seçici Eklenti Yükleme WooCommerce.com’da Belleği %50 Kısıyor

Son on yılda çağrıldığım her performans kurtarma işi aynı biçimi izliyor. Bir şey yavaş, bir şey salı günleri patlıyor ya da bir şey kimsenin faturalandırmadığı API sunucusunun belleğini yiyor. Her seferinde izi çıkardığımda aynı sessiz suçlu orada oluyor: WordPress, isteğin ihtiyacı olsun ya da olmasın, her istekte etkin durumdaki her eklentiyi yükledi.

Bu bir hata değil. WordPress böyle çalışıyor. Küçük bir sitede fark etmiyor. Elli etkin eklentisi olan ve mobil uygulamanın üç saniyede bir vurduğu bir REST uç noktası olan bir mağazada çok fark ediyor. Bu yüzden dün yayımlanan WooCommerce mühendislik yazısı — WooCommerce.com tanıtım sitesinin istek başına daha az eklenti yükleme yöntemi — kurum içi meraktan ibaret değil. Üzerine düşünülmeye ve dikkatli biçimde ödünç alınmaya değer bir desen.

Gerçekte ne sevk ettiklerini, desenin bazı yollarda neden güvenli, bazılarında neden ürkütücü olduğunu ve önümüzdeki hafta gerçek bir müşteri mağazasında bunu nasıl düşüneceğimi anlatmak istiyorum.

Gerçekten yeni olan ne

21 Temmuz 2026’da Thilina Pituwala, WooCommerce Geliştirici Blogu’nda How WooCommerce.com speeds up requests by loading fewer plugins başlıklı yazıyı yayımladı. Yazı, woocommerce.com’un arkasındaki tanıtım ve belge sitesini çalıştıran ekipten geliyor ve platform ekibinin üretimde bir süredir işlettiği bir deseni belgeliyor.

Mekanizma küçük. Bir must-use eklenti — PHP’nin normal eklentilerden önce yüklediği türden — option_active_plugins süzgecine takılıyor ve denetim altındaki bir dizi yol için etkin eklenti listesini geçerli isteğin ihtiyacı olmayan her şey çıkarılmış olarak geri döndürüyor. Yazıdaki tam biçim:

add_filter( 'option_active_plugins', function ( array $plugins ): array {
    if ( ! should_limit_plugins_for_this_request() ) {
        return $plugins;
    }
    return array_values( array_diff( $plugins, plugins_to_skip_for_this_request() ) );
} );

Hepsi bu kadar. WordPress önyükleme sırasında hangi eklenti dosyalarını dahil edeceğine karar vermek için get_option( 'active_plugins' ) çağırıyor, must-use eklenti sessizce daha kısa bir liste veriyor ve eklenti çizgesinin yarısı isteğe hiç girmiyor.

Yazıda geçen sayılar, üretimdeki WooCommerce.com trafiğine karşı ölçülmüş: hedeflenen isteklerde bellek kullanımı %50’nin üzerinde düşüyor. Abonelik arama uç noktası yaklaşık 800ms’den 475ms’ye iniyor. Eklenti güncelleme uç noktası yaklaşık 880ms’den 550ms’ye iniyor. Ürün sayfaları oluşturma süresinde yaklaşık %10 iyileşme elde ediyor. Bunlar Hello World kurulumundaki bireşimsel sayılar değil.

Yazı, neye dokunmayı reddettikleri konusunda dürüst. wc-ajax istekleri, wc-api web kancaları, sorgu parametresi taşıyan REST çağrıları ve dosya indirmeleri “kırpma” listesinin dışında. Ödeme, sepet, hesap akışları, cron, web kancaları ve ödeme geri çağrıları, eksik bir eklentinin sessizce paraya mal olabileceği yüksek dikkat bölgeleri olarak işaretlenmiş. Yol eşleştirme; kesin yollar, önekler ve düzenli ifadelerle yapılıyor, kurallar üretim kodu gibi gözden geçiriliyor ve hem izin listesi hem de dışlama listesi yaklaşımı masada.

Duvara asılmaya değer alıntı: “Eksik bir eklenti yalnızca tek bir üründe, tek bir dilde, tek bir istek parametresinde, tek bir önbellek kaçmasında veya tek bir oturum açık durumunda başarısız olabilir.”

WordPress / WooCommerce insanları için neden önemli

İki neden.

Birincisi, WooCommerce’in kendi platform ekibi, belirli büyüklükteki her WordPress uygulamasında her-istekte-her-eklenti modelinin gerçek bir dar boğaz olduğunu açıkça söylüyor. Bu on yıldır doğruydu ama çoğunlukla ajans folklorunda ve bir avuç yönetimli barındırıcının kurum içi araçlarında yaşadı. Resmi geliştirici blogunda, sayılar ve kodla birlikte olması bunu bir püf noktası değil, birinci sınıf bir konuşma yapıyor.

İkincisi, desen WooCommerce’in zaten gittiği yönle uyuşuyor. 28 Temmuz’daki WooCommerce 11.0 ile ürün nesnesi önbelleklemesi yeni mağazalar için varsayılan olarak açık hale geliyor. Store API uç noktaları yinelemeden arındırılıyor. Kalıcı nesne önbellekleri “uzman ayarı” olmaktan çıkıp “sıkıcı temel” oluyor. Seçici eklenti yükleme bir üst kat: veriyi önbellekledikten sonra, o veriyi sorgulayacak kodu bile yüklememek.

Risk tarafında, bu tanıdığım birden fazla ajansı ısırmış bir desendir. Biri mu-plugins/ içine yola dayalı bir atlatma listesi bırakıyor, hazırlık ortamında her şey iyi görünüyor ve üç hafta sonra belirli bir tarayıcı dilinden gelen belirli bir ürün varyasyonundaki wc-ajax sepete ekle isteği, çok dilli eklenti o yolda dışlandığı için sessizce başarısız oluyor. Başarısızlık biçimi tam olarak Pituwala’nın anlattığı gibi: dar, yeniden üretmesi zor, bilinçli olarak izlemediğiniz sürece günlüklerde görünmez.

Ne yapardım (ya da yapmazdım)

Yazıyı iki kez okurdum, bir kez desen için, bir kez uyarılar için. Sonra bellek veya gecikmenin gerçekten ölçebildiğim, kuramsal olmayan bir sorun olduğu büyük bir müşteri mağazasında iki haftalık bir deney taslağı çıkarırdım.

Birinci hafta: ölçüm koy. Sıcak yollarda eklenti-yükleme ve bellek günlüğü ekle. Ödemeye ihtiyaç duymadığı, sepete veya ödemeye dokunmadığı ve üçüncü taraf entegrasyonu bağlı olmadığı açık olan iki üç dar, sıkıcı uç nokta seç. Salt okunur ürün akışları, mağaza saatlerini döndüren genel bir REST uç noktası, CDN’in vurduğu bir tanıtım açılış sayfası. Önce mevcut yığında sayıları kanıtla; çünkü %100’ü hiç ölçmediysen sonra %50 bellek düşüşünü iddia edemezsin.

İkinci hafta: atla. Tek bir yol kuralı ve çok kısa bir dışlama listesi olan küçük bir must-use eklenti sevk et. Hem soğuk hem sıcak önbellekle, hem oturum açık hem oturum kapalı olarak test et; dışlanan eklentilerin sessizce takılmış olabileceği her şey için tam bir gerileme geçişi yap. Üretimi ölümcül hatalar için izle, belleği izle, yanıt sürelerini izle ve süzgeci bir yayın değil bir yapılandırma değişikliğiyle etkisiz duruma çeviren bir “acil kapatma” düğmesi bulundur.

Yapmayacaklarım: ödeme geçidi, vergi eklentisi veya kargo hesaplayıcısı dolaylı olarak bile kapsamda olan bir mağazada bu deseni sevk etmek. wc-ajax‘tan hiçbir şeyi asla dışlamamak. Kendi yola dayalı eklenti boşaltmasını yapan yönetimli bir barındırıcıda çalıştırmamak — platformla dövüşürsün. Bunu, kimsenin kullanmadığı on iki eklentiyi gerçekten silmenin yerine koymamak. Hemen hemen her WooCommerce mağazasındaki ilk performans kazanımı hâlâ eklenti listesini denetleyip kirasını hak etmeyenleri kaldırdığın andır.

Ve lütfen bu hafta bunu bir WordPress 7.1 Beta 2 hazırlık sitesinde yapmayın. Aynı anda tek hareketli hedef.

İyi haber şu: desen küçük, kod herkese açık ve başarısızlık biçimleri onu üretime koyan ekip tarafından iyi anlaşılmış. Bu birleşim olması gerekenden çok daha nadir.