Hangi Eklenti Siteyi Yavaşlatıyor? Suçlu Eklentiyi Bulma Yolu

Site bir sabah gözle görülür biçimde yavaşladı, yönetici paneli açılmıyor, ürün sayfaları saniyeler sürüyor ve aklınıza gelen ilk soru şu: hangi eklenti siteyi yavaşlatıyor? İnternette bulacağınız cevapların tamamına yakını "eklentileri tek tek kapatıp deneyin" diyor. Bu tavsiye canlı bir sitede uygulanabilir değildir — otuz eklentisi olan bir e-ticaret sitesinde ödeme eklentisini beş dakikalığına kapatmak, hem sipariş kaybı hem de veri tutarsızlığı demektir. Üstelik kapat-aç yöntemi size hangi eklentinin yavaş olduğunu değil, hangisini kapattığınızda sayfanın hızlandığını söyler; bu ikisi aynı şey değildir.

Bu yazıda tahmin etmeyi bırakıp ölçmeye geçiyoruz. Query Monitor eklentisiyle her isteğin nereye harcandığını bileşen bazında okumayı, canlı siteyi hiç etkilemeden yalnızca kendi oturumunuzda eklentileri devre dışı bırakmayı, otuz eklentiyi beş denemede eleyen ikili arama yöntemini ve sunucu taraflı kanıt için yavaş sorgu loglarını nasıl okuyacağınızı anlatacağım. Sonunda elinizde "şu eklenti sayfa başına 480 ms ve 214 sorgu ekliyor" gibi tartışılmaz bir sayı olacak; "bence bu eklenti ağır" cümlesi değil.

Önce Doğrulayın: Yavaşlık Gerçekten Eklentiden mi Geliyor#

Eklenti avına başlamadan önce yavaşlığın sunucu tarafında mı yoksa tarayıcı tarafında mı oluştuğunu ayırmanız gerekir; bu ayrımı yapmayanlar günlerce yanlış yerde arar. Ölçüt TTFB'dir (ilk bayta kadar geçen süre): tarayıcı isteği gönderdikten sonra sunucunun ilk cevabı vermesi ne kadar sürüyor?

curl -o /dev/null -s -w "baglanti:%{time_connect}s  ilk_bayt:%{time_starttransfer}s  toplam:%{time_total}s\n" https://siteniz.com/

Bu komutu birkaç kez çalıştırın. ilk_bayt değeri 200 ms civarındaysa sunucu tarafı sağlıklıdır ve yavaşlık büyük ihtimalle görsellerden, dış scriptlerden veya render engelleyen kaynaklardan geliyordur — o zaman doğru adres eklenti avı değil, TTFB ve sayfa hızı optimizasyonu tarafıdır. ilk_bayt 1 saniyenin üzerindeyse PHP tarafında bir şey uzun sürüyor demektir ve eklenti şüphesi haklıdır.

İkinci ayrım noktası: yavaşlık her sayfada mı, yoksa belirli sayfalarda mı? Anasayfa hızlı ama ürün arşivi yavaşsa, o arşivde çalışan bir filtre eklentisi ya da ilgili ürün sorgusu şüphelidir. Yönetici paneli ön yüzden daha yavaşsa konu farklıdır ve yönetici paneli yavaşlığı yazısında ele alınan nedenlere bakmak gerekir. Üçüncü ayrım: yavaşlık ne zaman başladı? Bir güncellemeden hemen sonra başladıysa suçlu listesi bir anda üç beş isme iner.

Son olarak sunucunun genel yükünü kontrol edin. Yük ortalaması çekirdek sayısının üzerindeyse sorun tek bir eklenti değil, sitenin toplam kaynak ihtiyacının paketi aşması olabilir:

uptime
top -bn1 | head -15

Query Monitor Kurulumu ve Panelin Okunması#

Query Monitor, her sayfa isteğinde çalışan sorguları, PHP hatalarını, HTTP isteklerini ve en önemlisi bunların hangi eklentiden geldiğini gösteren bir geliştirici aracıdır. Türkçe kaynaklarda neredeyse hiç anlatılmaz, oysa bu iş için elinizdeki en kesin araçtır.

Kurulum standart eklenti kurulumudur: Eklentiler → Yeni Ekle → "Query Monitor" → Kur → Etkinleştir. Kurulduktan sonra yönetici çubuğunda sağ tarafta şuna benzer bir sayı dizisi belirir:

0.84s   12.4MB   S: 214   O: 0.31s

Bu dört değer sırasıyla şu anlama gelir: sayfanın PHP tarafında üretilme süresi, harcanan bellek, çalıştırılan veritabanı sorgusu sayısı ve bu sorguların toplam süresi. Sağlıklı bir WordPress sayfasında sorgu sayısı genelde 30-80 arasındadır. 200'ün üzerindeki bir sayı neredeyse her zaman bir eklentinin döngü içinde sorgu çalıştırdığını gösterir.

Bu çubuğa tıkladığınızda alt tarafta ayrıntılı panel açılır. En çok kullanacağınız sekmeler:

• Queries → Queries by Component: Sorguların hangi eklenti, tema veya çekirdek bileşeninden geldiğini gösterir. Suçluyu bulduğunuz ekran budur.
• Queries → Slow Queries: Belirlenen eşiği aşan tekil sorguları listeler; sorgunun tam metnini ve çağıran fonksiyonu verir.
• Timing: Kodun kendi ölçüm noktaları arasındaki süreleri gösterir.
• HTTP API Calls: Sayfa üretilirken yapılan dış istekler. Bu sekme çok kritiktir, aşağıda ayrıca ele alıyorum.
• Hooks & Actions: Hangi eklentinin hangi kancaya kaç fonksiyon bağladığını görürsünüz.

Query Monitor'ün çıktısı yalnızca oturum açmış yöneticiye görünür, yani ziyaretçileriniz bu paneli görmez. Yine de teşhis bitince eklentiyi devre dışı bırakın; sürekli açık kalması her istekte küçük bir ek yük getirir.

Yalnızca kendi kullanıcınıza değil, çıkış yapmış ziyaretçi görünümüne de bakmak isterseniz wp-config.php dosyasına şu sabiti ekleyip kendi IP'nizle sınırlayabilirsiniz:

define( 'QM_COOKIE', 'gizli-bir-deger' );

Bileşen Bazlı Sorgu Dağılımı: Suçluyu Gösteren Ekran#

Query Monitor'ün Queries by Component tablosu, "hangi eklenti siteyi yavaşlatıyor" sorusunun doğrudan cevabıdır. Tablo üç sütundan oluşur: bileşen adı, o bileşenin çalıştırdığı sorgu sayısı ve bu sorguların toplam süresi. Gerçek bir sitede tipik bir görünüm şöyledir:

Bu tabloyu okumanın üç kuralı var. Birincisi, sorgu sayısı tek başına suçlama sebebi değildir; 148 sorgunun toplam 40 ms sürdüğü bir eklenti, 3 sorguda 900 ms harcayan bir eklentiden daha masumdur. Her zaman süre sütununa bakın. İkincisi, çekirdeğin (Core) sorgu sayısı anormal yükselmişse suçlu yine bir eklentidir: eklenti WP_Query üzerinden sorgu açtığında bunlar çekirdek hanesine yazılabilir. Bu durumda Slow Queries sekmesindeki "Caller" sütununa bakarak asıl çağıranı bulun. Üçüncüsü, aynı sorgunun defalarca tekrarlandığını görürseniz bu bir N+1 problemidir: eklenti bir döngü içinde her öğe için ayrı sorgu açıyordur ve içerik büyüdükçe site katlanarak yavaşlar.

Slow Queries sekmesinde bir satıra tıkladığınızda sorgunun tam metnini ve onu çağıran fonksiyon zincirini görürsünüz:

SELECT meta_value FROM wp_postmeta
WHERE post_id = 15234 AND meta_key = '_urun_stok'
LIMIT 1

Bu sorgu tabloda 148 kez tekrarlanıyorsa, eklenti 148 ürünün her biri için ayrı sorgu açıyor demektir. Doğru yazılmış bir eklenti bunu tek bir IN (...) sorgusuyla halleder. Böyle bir tablo gördüğünüzde eklentinin destek ekibine gönderebileceğiniz somut bir kanıtınız olur.

HTTP API Calls: En Sık Gözden Kaçan Yavaşlık Kaynağı#

Sayfa üretimi sırasında yapılan dış HTTP istekleri, eklenti kaynaklı yavaşlıkların en sinsi türüdür ve sorgu tablosunda hiç görünmez. Query Monitor'ün HTTP API Calls sekmesinde şuna benzer satırlar görürsünüz:

Bu istekler sayfa üretimini bloke eder: dış servis yavaşladığında sizin siteniz de yavaşlar, dış servis düştüğünde sizin siteniz zaman aşımına düşer. Bir eklentinin her sayfa yüklemesinde lisans sunucusuna gitmesi kötü yazılmış olduğunun en net göstergesidir; iyi yazılmış eklenti bu kontrolü günde bir kez yapıp sonucu transient olarak saklar.

Bu tür bir istek bulduğunuzda çözüm genelde eklentinin ayarlarında "lisans kontrol sıklığı" veya "dış veri güncelleme aralığı" seçeneğini bulmaktır. Bulunamıyorsa, WordPress'in dış isteklerini geçici olarak kapatarak etkiyi ölçebilirsiniz:

// Sadece test amaçlı: tüm dış HTTP isteklerini engeller
define( 'WP_HTTP_BLOCK_EXTERNAL', true );
define( 'WP_ACCESSIBLE_HOSTS', 'api.wordpress.org,*.wordpress.org' );

Bu sabitleri ekledikten sonra sayfa süresi belirgin biçimde düşüyorsa suçlu kesinleşmiştir. Testten sonra satırları kaldırmayı unutmayın; aksi hâlde eklenti güncellemeleri ve ödeme sağlayıcı iletişimi bozulur.

Canlı Siteyi Bozmadan Test: Yalnızca Size Özel Devre Dışı Bırakma#

Canlı sitede eklenti kapatmadan test yapmanın yolu var: Health Check & Troubleshooting eklentisinin sorun giderme modu, eklentileri yalnızca sizin oturumunuz için devre dışı bırakır. Ziyaretçiler siteyi normal görmeye devam eder, siz temiz bir kurulumda gezinirsiniz.

Adımlar:

1. Health Check & Troubleshooting eklentisini kurun ve etkinleştirin.
2. Araçlar → Site Sağlığı → Troubleshooting sekmesine gidin.
3. Enable Troubleshooting Mode düğmesine basın. Tüm eklentiler ve tema, yalnızca sizin için pasife düşer.
4. Yönetici çubuğundaki Troubleshooting menüsünden eklentileri tek tek geri açın.
5. Her açılıştan sonra yavaş olan sayfayı ziyaret edip Query Monitor'deki süreyi not edin.

Bu yöntemin canlı siteyi etkilememesi, üretim ortamında teşhis yapmanın en güvenli yoludur. Yine de kalıcı değişiklik yapacaksanız (eklenti silme, ayar değiştirme) doğru yer bir kopyadır; WordPress staging ortamı kurmak bu tür denemeleri risksiz hâle getirir.

Sorun giderme modu bir nedenle kullanılamıyorsa (panele hiç girilemiyor gibi), FTP üzerinden wp-content/plugins klasörünü plugins-devre-disi olarak yeniden adlandırmak tüm eklentileri kapatır. Bu yöntem canlı siteyi etkiler, bu yüzden yalnızca site zaten çalışmıyorsa tercih edilmelidir. Eklentiler arası çakışma şüphesi varsa eklenti çakışması teşhisi yazısındaki yöntem de aynı mantığı izler.

İkili Arama: 30 Eklentiyi 5 Denemede Elemek#

Otuz eklentiyi teker teker denemek otuz test demektir; ikili arama ile aynı sonuca beş testte ulaşırsınız. Yöntem basittir: eklentileri ikiye bölersiniz, hangi yarıda sorun devam ediyorsa o yarıyı tekrar ikiye bölersiniz.

Sorun giderme modunda uygulanışı:

1. Tüm eklentiler kapalıyken sayfa süresini ölçün. Bu sizin referans değeriniz (örnek: 0.28 s).
2. İlk 15 eklentiyi açın, ölçün. Süre 0.31 s ise bu yarı temiz.
3. Bu 15'i kapatın, diğer 15'i açın, ölçün. Süre 1.12 s ise suçlu bu yarıda.
4. Bu 15'in ilk 8'ini açın, ölçün. Süre 0.33 s ise suçlu kalan 7'de.
5. Kalan 7'nin 4'ünü açın, ölçün. Yükseldiyse bu 4'te, yükselmediyse kalan 3'te.

Her adımda arama alanı yarıya iner; 30 eklenti için 5 adım, 100 eklenti için 7 adım yeter. Ölçümleri bir tabloya yazın, çünkü dördüncü adımda hangi kombinasyonu denediğinizi hatırlamak zorlaşır.

Bu yöntemi WP-CLI ile çok daha hızlı uygulayabilirsiniz; her seferinde panelde tıklamak yerine tek komutla toplu açıp kapatırsınız:

# Tüm eklentileri listele
wp plugin list --field=name

# Bir grubu topluca kapat
wp plugin deactivate eklenti-a eklenti-b eklenti-c

# Sayfa süresini ölç
curl -o /dev/null -s -w "%{time_starttransfer}\n" https://siteniz.com/urunler/

# Geri aç
wp plugin activate eklenti-a eklenti-b eklenti-c

⚠️ WP-CLI ile yapılan devre dışı bırakma tüm ziyaretçileri etkiler. Bu yüzden bu yöntemi canlı sitede değil, staging kopyasında veya trafiğin en düşük olduğu saatte uygulayın. WP-CLI'yi hiç kullanmadıysanız WP-CLI temelleri yazısı komut yapısını anlatıyor.

Sunucu Tarafında Kanıt: Yavaş Sorgu ve PHP Logları#

Query Monitor size tarayıcıdan bakılan tekil bir isteği gösterir; sunucu logları ise günler boyunca biriken gerçek trafiği gösterir. İkisi birlikte kullanıldığında teşhis kesinleşir.

MySQL yavaş sorgu logu, belirlenen süreyi aşan her sorguyu dosyaya yazar. Kendi sunucunuzda şöyle açılır:

# /etc/mysql/mysql.conf.d/mysqld.cnf
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
log_queries_not_using_indexes = 1

Servisi yeniden başlattıktan sonra birkaç saat bekleyin, ardından logu okuyun:

sudo mysqldumpslow -s t -t 10 /var/log/mysql/slow.log

Bu komut en çok zaman harcayan on sorguyu özetler. Çıktıda wp_postmeta veya wp_options üzerinde autoload taraması yapan sorgular görüyorsanız, muhtemelen bir eklenti wp_options tablosuna büyük veri yazıyordur — bu, sitenin her isteğinde yüklenen bir yüktür ve klasik bir yavaşlık nedenidir. Sorgu tarafında yapısal iyileştirme gerekiyorsa MySQL performans optimizasyonu yazısı indeks ve yapılandırma tarafını kapsıyor.

wp_options şişkinliğini tek sorguyla kontrol edebilirsiniz:

SELECT ROUND(SUM(LENGTH(option_value))/1024/1024, 2) AS mb_autoload
FROM wp_options WHERE autoload = 'yes';

Bu değer 1 MB'ın üzerindeyse her sayfa isteğinde o kadar veri belleğe alınıyor demektir; hangi satırların şiştiğine bakıp kaynağını bulun.

PHP-FPM tarafında da yavaş istek logu vardır ve hangi PHP fonksiyonunda takıldığınızı gösterir:

; havuz yapılandırmasında
slowlog = /var/log/php-fpm/slow.log
request_slowlog_timeout = 3s

Bu log, üç saniyeden uzun süren isteklerin yığın izini yazar. Çıktıdaki dosya yolları doğrudan wp-content/plugins/eklenti-adi/ altını gösteriyorsa tartışma biter.

Yavaşlatan Eklenti Türleri ve Tipik Belirtileri#

Yıllar içinde suçlu çıkan eklentiler belli kategorilerde toplanıyor. Aşağıdaki tablo, hangi belirtinin hangi eklenti türüne işaret ettiğini özetliyor:

Son satır özel bir durumdur: WordPress'in zamanlanmış görevleri ziyaretçi isteğiyle tetiklenir, yani ağır bir yedekleme görevinin faturası o an siteye giren ziyaretçiye çıkar. Görev listesini kontrol edin:

wp cron event list --fields=hook,next_run_relative

Ağır görevleri gerçek sistem cron'una taşımak ve DISABLE_WP_CRON sabitini açmak bu tür rastgele yavaşlamaları ortadan kaldırır.

Suçlu Bulundu: Silmek Dışındaki Seçenekler#

Eklentinin yavaşlattığını kanıtladınız; bu her zaman silmeniz gerektiği anlamına gelmez. Sırayla değerlendirilecek seçenekler şunlardır:

1. Ayarları kısın. Çoğu ağır eklentinin kapatılabilir modülleri vardır: ilgili ürün sayısını 12'den 4'e indirmek, istatistik toplamayı kapatmak, gerçek zamanlı taramayı gecelik moda almak sorunu çözebilir.
2. Yalnızca gereken sayfalarda yükleyin. İletişim formu eklentisi tüm sayfalarda CSS/JS yüklüyorsa, koşullu olarak kaldırın:

add_action( 'wp_enqueue_scripts', function () {
    if ( ! is_page( 'iletisim' ) ) {
        wp_dequeue_style( 'form-eklentisi-stil' );
        wp_dequeue_script( 'form-eklentisi-script' );
    }
}, 100 );

3. Önbellekle örtün. Eklenti ağır ama çıktısı nadiren değişiyorsa, tam sayfa önbelleği yükü ziyaretçiden kaldırır. Ancak bu bir çözüm değil, üstünü örtmektir: giriş yapmış kullanıcılar ve sepet sayfaları yine yavaş kalır.
4. Hafif alternatifini bulun. Aynı işi yapan daha az sorgu açan bir eklenti çoğu kategoride vardır.
5. Geliştiriciye bildirin. Query Monitor çıktısı ve tekrarlanan sorgu metniyle açılan bir destek talebi çoğu zaman bir sonraki sürümde düzeltilir.

Silmeye karar verirseniz, eklentiyi kaldırmadan önce mutlaka yedek alın; bazı eklentiler kaldırılırken kendi tablolarını ve ayarlarını da siler. Yedekleme akışını kurmadıysanız UpdraftPlus kullanımı pratik bir başlangıçtır. Genel hız çalışmasına devam edecekseniz WordPress hız optimizasyonu yazısı eklenti dışındaki kaldıraçları topluyor, ölçüm tarafını dışarıdan doğrulamak isterseniz GTmetrix ile hız testi yazısındaki metrikleri kullanabilirsiniz.

Sıkça Sorulan Sorular#

Query Monitor canlı sitede güvenle kullanılabilir mi#

Kullanılabilir, çünkü çıktısı yalnızca oturum açmış yöneticilere görünür ve ziyaretçiler paneli hiç görmez. Yine de eklenti her istekte sorguları ve kancaları izlediği için küçük bir ek yük getirir; teşhis bittikten sonra devre dışı bırakmak doğru davranıştır. Yoğun bir e-ticaret sitesinde uzun süre açık bırakmak bellek kullanımını da yükseltir. Kalıcı izleme istiyorsanız sunucu tarafındaki yavaş sorgu logu daha uygun bir araçtır.

Eklenti sayısı fazla olması tek başına siteyi yavaşlatır mı#

Hayır, belirleyici olan sayı değil eklentilerin ne yaptığıdır. Kırk hafif eklentisi olan bir site, kötü yazılmış tek bir eklentisi olan siteden daha hızlı çalışabilir. Bir eklentinin maliyeti çalıştırdığı sorgu sayısı, yüklediği CSS/JS dosyaları ve yaptığı dış isteklerle ölçülür. Bu yüzden "eklenti sayısını on beşin altında tutun" gibi genel tavsiyeler yerine bileşen bazlı ölçüm yapmak gerekir.

Sorun giderme modu ziyaretçileri etkiler mi#

Etkilemez. Health Check eklentisinin sorun giderme modu, eklenti ve tema devre dışı bırakmayı yalnızca sizin oturumunuza uygular; ziyaretçiler siteyi normal yapılandırmasıyla görmeye devam eder. Bu, canlı sitede teşhis yapmanın en güvenli yoludur. Buna karşılık WP-CLI ile ya da panelden yapılan devre dışı bırakma herkesi etkiler, o yüzden bu iki yöntemi karıştırmamak gerekir.

Yavaş sorgu logunu sürekli açık bırakmak zararlı mı#

Eşik değeri makul tutulduğunda zararlı değildir. long_query_time değerini 1 saniye gibi bir seviyede bırakmak yalnızca gerçekten problemli sorguları kaydeder ve log dosyası yavaş büyür. Ancak log_queries_not_using_indexes seçeneğini uzun süre açık bırakmak, indekssiz her küçük sorguyu da yazdığı için dosyayı hızla şişirir ve disk doldurabilir. Teşhis bittikten sonra bu ikinci seçeneği kapatmak ve log dosyasını logrotate kapsamına almak doğru olur.

Eklentiyi silmek yerine devre dışı bırakmak yeterli mi#

Performans açısından devre dışı bırakmak yeterlidir; pasif eklentinin kodu çalıştırılmaz ve hiçbir sorgu açmaz. Ancak güvenlik açısından yeterli değildir, çünkü eklentinin dosyaları sunucuda durmaya devam eder ve bilinen bir açık varsa doğrudan dosya çağrısıyla istismar edilebilir. Kullanmayacağınıza karar verdiğiniz eklentiyi silmek en doğrusudur. Silmeden önce ayarlarını ve varsa oluşturduğu tabloları yedeklemeyi ihmal etmeyin.

Aynı anda birden fazla eklenti yavaşlatıyorsa nasıl anlarım#

İkili arama sırasında her iki yarıda da süre yükseliyorsa birden fazla suçlu var demektir. Bu durumda yöntemi değiştirmek yerine her yarıyı ayrı ayrı sonuna kadar götürün; ikili arama birden fazla suçluyu da bulur, sadece daha çok adım gerekir. Query Monitor'ün bileşen tablosu zaten tüm eklentileri aynı anda listelediği için, iki farklı eklentinin üst sıralarda yer aldığını doğrudan görebilirsiniz. Toplam etkiyi anlamak için ikisini birlikte kapatıp ölçün.

Tema da yavaşlatabilir mi, nasıl ayırt ederim#

Tema da en az eklentiler kadar yavaşlatabilir ve Query Monitor'ün bileşen tablosunda "Theme" satırı olarak görünür. Ayırt etmenin en hızlı yolu, sorun giderme modunda tüm eklentiler kapalıyken temayı varsayılan bir temaya çevirip aynı sayfayı ölçmektir. Süre belirgin biçimde düşüyorsa sorun temadadır. Özellikle sayfa oluşturucu ile kurulmuş temalarda tek bir sayfa yüzlerce ek sorgu ve büyük CSS dosyaları getirebilir.

Ölçüm sonuçları her seferinde farklı çıkıyor, hangisine güveneyim#

Tek ölçüme asla güvenmeyin; sunucu yükü, önbellek durumu ve veritabanı sorgu önbelleği sonucu değiştirir. Doğru yöntem aynı sayfayı arka arkaya beş kez ölçüp ortanca değeri almak ve karşılaştırmaları hep aynı koşullarda yapmaktır. Ayrıca ilk ölçümü daima atın: önbellekler boşken alınan değer gerçekçi değildir. Ölçümleri günün aynı saatinde tekrarlamak da dış etkenlerin payını azaltır.

Kapanış#

Siteyi yavaşlatan eklentiyi bulmak tahmin işi değil, ölçüm işidir. Doğru sıra şudur: önce TTFB ile yavaşlığın sunucu tarafında olduğunu doğrulayın, sonra Query Monitor'ün bileşen tablosuyla sorgu ve süre dağılımını okuyun, dış istekleri HTTP API Calls sekmesinde kontrol edin, canlı siteyi etkilemeden sorun giderme modunda ikili arama uygulayın ve bulgularınızı sunucu taraflı yavaş sorgu loglarıyla doğrulayın. Bu zincirin sonunda elinizde bir tahmin değil, "şu eklenti sayfa başına şu kadar sorgu ve şu kadar süre ekliyor" diyen bir ölçüm olur — hem karar vermeyi hem de gerekirse eklenti geliştiricisine dert anlatmayı kolaylaştıran şey budur.

Ölçüm sonunda darboğazın tek bir eklenti değil sunucu kaynağı olduğu ortaya çıkarsa, altyapıyı büyütmek gerekir: yoğun sorgu üreten WordPress kurulumları için WordPress hosting paketleri önbellek ve PHP ayarlarıyla hazır gelir, kaynak sınırlarını kendiniz belirlemek isterseniz VDS sunucu veya daha yüksek işlem gücü gerektiren siteler için performans sunucu seçenekleri uygun zemini sağlar. Bu teşhis ve bakım döngüsünü düzenli olarak birinin yürütmesini istiyorsanız WordPress bakım hizmeti ölçüm, güncelleme ve optimizasyon işini üstlenir.