Elementor ve Divi İçin Hosting: CPU, RAM ve PHP Ayarları

Elementor, Divi ve Diğer Sayfa Oluşturucular Sunucudan Ne İster?

WordPress ile çalışan modern sayfa oluşturucular (Elementor, Divi, WPBakery, Bricks, Oxygen vb.) sade bir blog temasına kıyasla daha fazla PHP işlemi, veritabanı sorgusu ve daha ağır HTML/CSS/JS çıktısı üretebilir. Yükün boyutu tasarıma, eklentilere ve önbellek kullanımına bağlıdır. PHP işlemleri sunucunun CPU ve RAM kaynaklarını tüketirken, CSS/JS ve animasyonların işlenmesi tarayıcıya da yük bindirir. Özellikle görsel ağırlıklı ana sayfalar, animasyonlu bölümler, global widget’lar ve tema builder özellikleri kullanıldığında, yetersiz hosting kaynakları siteyi yavaşlatabilir veya editörde hatalara yol açabilir; ancak tarayıcı tarafındaki yavaşlık yalnızca sunucu kaynaklarını artırmakla çözülmez.

Sayfa oluşturucunun tasarımı ve eklentileri kadar, sunucu mimarisi, önbellekleme ve PHP konfigürasyonu da performansı etkiler. Aynı tasarımın TTFB değeri; önbellek durumu, eşzamanlı istek yükü ve sunucu kaynaklarına göre değişebilir. Bu yazıda, Elementor, Divi ve benzeri sayfa oluşturucular için hangi hosting kaynaklarına ihtiyacınız olduğunu; CPU, RAM ve PHP ayarlarını pratik örneklerle adım adım netleştireceğiz.

Sayfa Oluşturucular Neden Sunucu Kaynaklarına Hassastır?

Önce problemi doğru tarif etmek gerekiyor. Elementor, Divi ve benzeri araçlar yalnızca “görsel tasarım editörü” değildir; arka planda ciddi bir PHP mantığı ve veritabanı etkileşimi çalışır. Her bir section, column, widget ve global template için ek yapılandırma, meta alanı ve stil verisi tutulur.

Bu da şu sonuçları doğurur:

• Daha fazla PHP işlemi: Basit bir blog temasına göre sayfa oluşturuculu siteler aynı sayfayı üretmek için daha fazla PHP fonksiyonu ve sınıf çağırabilir.
• Daha karmaşık veritabanı sorguları: Özellikle global template, condition, display rule ve theme builder özellikleri, uygulamaya ve önbellek durumuna bağlı olarak MySQL tarafında ek sorgulara yol açabilir.
• Daha büyük HTML + CSS + JS çıktısı: Her widget kendi CSS/JS’ini getirebilir; bu da aktarım boyutunu ve tarayıcının işleme yükünü artırabilir.
• Editörde ek yük: Canlı önizleme, geri alma (undo), revision ve autosave fonksiyonları, editörde çalışırken ek CPU/RAM tüketir.

Bu nedenle kaynak planlamasını yalnızca “sade blog” veya “sayfa oluşturuculu site” etiketine değil, ölçülen iş yüküne göre yapmak gerekir. Özellikle WooCommerce ile birlikte Elementor veya Divi kullanıyorsanız, hem PHP hem MySQL hem de disk I/O tarafında doğru kapasite planlaması yapmak şarttır. WooCommerce tarafındaki veritabanı optimizasyonu için hazırladığımız büyük katalog siteleri için MySQL indeksleme ve sorgu optimizasyonu rehberine de göz atmanızı öneririz.

CPU: Elementor ve Divi İçin Kaç vCPU Yeter?

CPU (özellikle vCPU sayısı ve tek çekirdek performansı), sayfa oluşturuculu sitelerde sayfa oluşturma süresini, TTFB değerini ve editörde çalışma konforunu doğrudan etkiler. Eşzamanlı dinamik istek sayısı ve sayfa karmaşıklığı arttıkça CPU ihtiyacı da artabilir; artışın boyutu önbellek isabetine ve istek başına yapılan işe bağlıdır.

vCPU Nedir, Nasıl Düşünmeliyiz?

VPS veya bulut sunucu tarafında gördüğünüz “1 vCPU, 2 vCPU, 4 vCPU” gibi değerler, aslında sanal çekirdek adedini ifade eder. Bu sayı paralel işlem kapasitesini etkiler; ancak tek çekirdek performansı ve fiziksel CPU’nun paylaşım koşulları da önemlidir. Bir vCPU, bir PHP işleminin kesintisiz tam performansla çalışacağını garanti etmez. paylaşımlı hosting’lerde ise CPU kullanım ve hesap limitlerini, sağlayıcının sunduğu kaynak raporlarından değerlendirmek gerekir.

PHP-FPM kullanılan bir sitede, PHP çalıştırılmadan tam sayfa önbellekten karşılanmayan bir sayfa isteği için tipik akış şu şekildedir:

• PHP-FPM, isteği alır ve WordPress çekirdeğini yükler.
• Tema + sayfa oluşturucu (Elementor/Divi) dosyaları dahil olur.
• Veritabanından sayfa içeriği, template ve widget ayarları çekilir.
• PHP, bu içeriği birleştirip HTML çıktısını üretir.

CPU darboğazı varsa daha güçlü çekirdekler işlem süresini, ek vCPU’lar ise eşzamanlı yük altında beklemeyi azaltabilir. Veritabanı veya disk beklemeleri baskınsa yalnızca CPU artırmak yeterli olmayabilir.

Senaryo 1: Küçük Kurumsal Site (5–15 Sayfa)

Örnek: Elementor ile hazırlanmış, ürün/hizmet tanıtımı yapan, blogu az kullanılan veya hiç olmayan bir kurumsal site. Aynı anda sitede 5–10 kullanıcı civarında dolaşıyor.

• Paylaşımlı hosting: Hesap limitleri iş yüküne uygunsa bu senaryo paylaşımlı hosting üzerinde çalışabilir. CPU kullanımını, limit aşımı kayıtlarını ve yanıt sürelerini birlikte izleyin.
• VPS: Sunucu yapılandırması üzerinde daha fazla kontrol için 1–2 vCPU’lu bir VPS başlangıç adayı olabilir; yeterliliğini gerçek istek yüküyle değerlendirin. Fiziksel CPU’nun ayrılmış mı paylaşımlı mı olduğu ayrıca önemlidir.

Senaryo 2: Blog + Elementor Layout (Orta Trafik)

Örnek: Haftada düzenli içerik üretilen, Elementor ile tasarlanmış blog sayfaları, kategori layout’ları ve birkaç landing page bulunan bir proje. Aynı anda 20–50 kullanıcı aktif olabiliyor.

• Başlangıç adayı: 2–4 vCPU’lu bir VPS değerlendirilebilir; bu bir asgari gereksinim değildir. Aktif kullanıcı sayısı, aynı anda PHP çalıştıran istek sayısıyla aynı değildir.
• Neden: Özellikle yeni içerik yayınlandığında ve trafik dalgalandığında, önbellekten karşılanmayan istekler CPU yükünü artırabilir. CPU doygunluğunda istekler bekleyebilir ve TTFB uzayabilir.
• İpucu: Nginx + PHP-FPM ortamında tam sayfa önbellekleme, önbellekten karşılanabilen isteklerde PHP çalıştırma ihtiyacını ve CPU yükünü azaltabilir. Bunun için WordPress’te tam sayfa önbellekleme rehberimizde ayrıntılı örnekler bulabilirsiniz.

Senaryo 3: WooCommerce + Elementor/Divi Mağaza

Örnek: Katalogta 200–2000 ürün bulunan, kampanya dönemlerinde aynı anda 50–200 kullanıcının gezindiği bir WooCommerce mağazasını Elementor veya Divi ile tasarladınız. Ürün arşivleri, kampanya sayfaları, sepet/checkout adımları da sayfa oluşturucuyla özelleştirilmiş.

• Başlangıç adayı: 4 vCPU; kampanya yükünü değerlendirmek için 6–8 vCPU aralığı da düşünülebilir. Bunlar minimum veya yeterlilik garantisi değildir; özellikle sepet/checkout gibi dinamik isteklerin yükü ölçülmelidir.
• Gerekçe: WooCommerce zaten kendi başına veritabanı ve PHP yükü oluşturur. Buna sayfa oluşturucunun template mantığı ve ek sorguları eklendiğinde, CPU darboğazı oluşma riski artabilir.
• Ek not: PHP-FPM havuz ayarlarını doğru yapmak, bu noktada CPU kadar kritiktir. PHP-FPM için hazırladığımız detaylı ayar rehberine göz atmanızı özellikle öneririz.

Senaryo 4: Ajanslar ve Freelancer’lar (20+ Site)

Örnek: Bir ajans olarak 25 müşterinizin sitesini yönetiyorsunuz; çoğu Elementor veya Divi ile inşa edilmiş. Bazıları sade kurumsal siteler, bazıları WooCommerce mağazaları, bazıları ise kampanya landing sayfaları.

• Mimari: Tek güçlü VPS veya birkaç VPS’e bölünmüş mimari.
• Örnek kaynak bütçesi: 8 vCPU + 16 GB RAM, bu varsayımsal portföy için değerlendirilebilecek bir başlangıç adayıdır. 20–30 siteyi taşıyacağı garanti değildir; sitelerin toplam dinamik istek yükü, bellek tüketimi ve önbellek isabeti belirleyicidir.
• İzleme: CPU piklerini, load average değerlerini ve PHP-FPM process sayısını düzenli takip edin. Yönetici erişiminiz ve plan koşulları izin veriyorsa htop, Netdata vb. izleme araçlarından yararlanabilirsiniz; ayrıca VPS kaynak kullanımı izleme rehberimizde örnek kurulum akışlarını paylaştık.

RAM: Elementor, Divi ve Diğerleri İçin Bellek Planlama

RAM, PHP işlemlerinin ve MySQL’in sağlıklı çalışması için kritik. Yetersiz RAM, yavaşlığa ve isteklerin başarısız olmasına yol açabilir. Ancak “Allowed memory size exhausted” hatası PHP’nin memory_limit sınırına ulaşıldığını gösterir; sunucunun toplam RAM’inin tükendiğini tek başına kanıtlamaz. “500 Internal Server Error” veya editörün açılmaması da tek başına RAM yetersizliği teşhisi değildir.

WordPress + Sayfa Oluşturucu İçin RAM Planlama Örnekleri

Aşağıdaki değerler ölçülmüş saha sonuçları veya ürün gereksinimleri değil, VPS kapasitesini değerlendirmek için örnek başlangıç bütçeleridir. Gerçek ihtiyacı eşzamanlı PHP işlemleri, işlem başına bellek tüketimi ve diğer servisler belirler:

• Tek Elementor/Divi site, düşük trafik: VPS için 2 GB RAM bir başlangıç adayıdır. Paylaşımlı hostingde hesap bellek limitini, toplam sunucu RAM’iyle aynı ölçü olarak değerlendirmeyin.
• Blog + landing + orta trafik: 2–4 GB RAM.
• WooCommerce + sayfa oluşturucu: 4–8 GB RAM (ürün sayısı ve eşzamanlı kullanıcıya bağlı).
• Ajans mimarisi (20+ site): 16 GB ve üzeri RAM, doğru PHP-FPM ve MySQL ayarlarıyla birlikte anlam kazanır.

Burada önemli nokta: RAM yalnızca PHP tarafından kullanılmıyor. MySQL, Redis/Memcached, web sunucusu (Nginx/Apache/LiteSpeed) ve işletim sistemi de bellek tüketiyor. Bu nedenle “PHP memory_limit’im 512M, o halde 1 GB RAM yeter” gibi bir denklem gerçekçi değil.

PHP memory_limit, max_execution_time ve Diğerleri

Sayfa oluşturucular özellikle editör tarafında daha yüksek memory_limit gerektirebilir. Büyük şablonlar ve tek sayfada çok sayıda widget kullanımı, PHP bellek tüketimini artırabilir; 128M sınırı bazı işlemlerde yetersiz kalabilir. Bu konuyu detaylı ele aldığımız PHP ayarlarını doğru yapmak rehberinde önerilen değerler ve hesaplama mantığı yer alıyor; burada özetleyelim:

• memory_limit: 256M, 512M ve ağır iş yükleri için 768M gibi değerler kapasite planlamasında değerlendirilebilir; bunlar tüm Elementor/Divi kurulumları için doğrulanmış alt sınırlar veya ideal değerler değildir. Kullanılan sürümün gereksinimleri ve gerçek bellek tüketimi esas alınmalıdır.
• max_execution_time: 30–60 saniye aralığı başlangıç değerlendirmesinde kullanılabilir; uzun süren içe aktarma gibi işlemler ayrıca değerlendirilmelidir. Zaman aşımını yalnızca yükseltmek yerine yavaş işlemin nedenini araştırın.
• max_input_vars: Güncel Elegant Themes Divi barındırma rehberi max_input_vars=1000 listeler; 1000–3000 aralığı tüm Divi sürümleri için zorunlu bir gereksinim değildir. Kurulu sürümün gereksinimlerini esas alın; çok alanlı formlar için daha yüksek bir değere ihtiyaç olup olmadığını gerçek istekleri inceleyerek belirleyin.
• upload_max_filesize ve post_max_size: upload_max_filesize tek dosyanın, post_max_size ise tüm POST gövdesinin sınırıdır. post_max_size, dosya sınırından büyük olmalı; aynı istekteki tüm dosyalar, form verileri ve kodlama ek yükü için yer bırakmalıdır. Örneğin upload_max_filesize=32M ve post_max_size=64M tek dosyalı bir yükleme için değerlendirilebilir; çoklu yükleme ve template import boyutlarına göre yeniden hesaplayın.

Bu değerleri yükseltirken toplam RAM’i de denklemde tutmak gerekiyor. 1 GB RAM’li bir VPS’te 512M memory_limit ile 4–5 eşzamanlı PHP süreci çalıştırmak, RAM’in çok hızlı tükenmesine neden olabilir.

PHP-FPM ve Havuz Ayarları: pm.max_children Nasıl Hesaplanır?

Elementor ve Divi gibi sayfa oluşturucular, özellikle eşzamanlı kullanıcı sayısı arttığında PHP-FPM havuz ayarlarınızın ne kadar sağlıklı olduğunu net biçimde ortaya çıkarır. Yanlış ayarlar, CPU/RAM yeterli olsa bile isteklerin beklemesine veya başarısız olmasına yol açabilir. “server reached pm.max_children setting” kaydı havuzun eşzamanlı işleme sınırına ulaştığını gösterir; “503 Service Unavailable” yanıtı ise tek başına PHP-FPM ayarlarını neden olarak kanıtlamaz.

Basit Hesaplama Mantığı

PHP-FPM için kaba bir yaklaşım olarak şu formülü kullanabilirsiniz:

• Örnek hesap için süreç başına 80–150 MB RAM tüketimi varsayalım; kendi hesabınızda yoğun işlemler sırasındaki ölçümleri kullanın.
• Sunucunuzda PHP’ye ayırabileceğiniz RAM miktarını hesaplayın (örneğin toplam 8 GB RAM’in 4 GB’ını PHP’ye, kalanını MySQL, cache ve OS’ye bırakmak gibi).
• PHP’ye ayırdığınız RAM’i, ortalama süreç tüketimine bölün: 4096 MB / 128 MB ≈ 32 proses.

Bu varsayımlarla pm.max_children için 25–30 aralığı değerlendirilebilir; yalnızca ortalama belleğe dayanan bu hesap güvenli kapasiteyi kanıtlamaz. Yoğun işlemlerdeki bellek tüketimini, CPU yükünü ve diğer havuzların toplam tüketimini de ölçerek sınırı belirleyin. Ayrıntılı hesaplama ve pratik örnekler için WordPress ve WooCommerce için PHP-FPM ayarları rehberimize göz atabilirsiniz.

Önerilen Temel Ayarlar

Aşağıdaki dynamic havuz örneği, ayarlar arasındaki ilişkileri göstermek içindir; kaynak ölçümü yapılmadan doğrudan uygulanacak bir kapasite profili değildir. Değerleri site başına değil havuz başına değerlendirin. Birden fazla havuz varsa toplam kaynak bütçesini birlikte hesaplayın:

• pm: dynamic
• pm.max_children: 8 (yalnızca örnek; gerçek sınırı kaynak hesabınızla belirleyin)
• pm.start_servers: 2
• pm.min_spare_servers: 2
• pm.max_spare_servers: 4
• Bu değerleri birlikte değiştirin: 0 < pm.min_spare_servers <= pm.max_spare_servers <= pm.max_children olmalıdır. Açıkça pozitif bir pm.start_servers seçildiğinde değer, min_spare ile max_spare arasında (sınırlar dahil) kalmalıdır. Örnekte 2 <= 2 <= 4 <= 8 ilişkisi sağlanır; bu uyumluluk yeterli kapasiteyi kanıtlamaz.
• pm.max_requests: 500–1000 (iş yüküne göre değerlendirilecek örnek aralık; süreçleri yenilemek bellek sızıntısının birikmesini sınırlayabilir, ancak sızıntının nedenini düzeltmez)

Ajans mimarisinde, her müşteri için ayrı kullanıcı hesabı ve mümkünse ayrı PHP-FPM havuzu kullanmak, sorunları izole etmek açısından büyük avantaj sağlar. Bu tasarım için seçilen sunucu ortamında kullanıcı ve PHP-FPM havuzu yönetimi yetkilerinin bulunması gerekir.

OPcache ve Object Cache: CPU Yükünü Nasıl Azaltır?

Sayfa oluşturuculu sitelerde tekrarlayan PHP kodu ve tekrarlayan veritabanı sorguları çok fazladır. Bu nedenle iki tür cache katmanı kritik önem taşır:

• OPcache: PHP dosyalarının derlenmiş halini RAM’de tutar, her istekte kodu baştan derleme ihtiyacını azaltır.
• Nesne önbelleği (Redis/Memcached): WordPress’in nesne önbelleğini kullanan verileri saklayarak tekrarlayan sorguları azaltabilir. İstekler arasında kalıcılık için Redis/Memcached ile uyumlu bir nesne önbelleği entegrasyonu gerekir; tüm sorgular otomatik olarak önbelleğe alınmaz.

Elementor template’leri, global widget’lar, tema ayarları ve WooCommerce ürün verilerinde sağlanacak fayda, ilgili kodun nesne önbelleğini kullanımına ve iş yüküne bağlıdır. Kurulum seçenekleri için WordPress’te Redis/Memcached object cache kurulum rehberini inceleyerek ortamınızın gerekli desteğe sahip olup olmadığını değerlendirebilirsiniz.

OPcache için Önerilen Ayarlar

Sayfa oluşturuculu bir WordPress kurulumu için kabaca şu ayarlar iyi bir başlangıç noktasıdır:

• opcache.enable=1
• opcache.memory_consumption=128 (büyük ajans ortamlarında 256–512 MB)
• opcache.interned_strings_buffer=16
• opcache.max_accelerated_files=10000 (çok fazla eklenti ve multi-site varsa 20000+)
• opcache.validate_timestamps=1 (geliştirmede ve üretimde kullanılabilir; dosya değişiklikleri opcache.revalidate_freq aralığıyla denetlenir). Üretimde 0 seçilecekse dağıtım süreci, istekleri karşılayan ortamın OPcache önbelleğini açıkça geçersiz kılmalı/sıfırlamalı veya ilgili sunucu sürecini yeniden başlatmalıdır; CLI üzerinden yapılan bir sıfırlamanın PHP-FPM önbelleğini temizlediğini varsaymayın.
• opcache.revalidate_freq=60 (timestamp doğrulaması açıkken denetim aralığı 60 saniyedir; dosya değişikliklerinin fark edilmesi bu aralık nedeniyle gecikebilir). Geliştirmede opcache.revalidate_freq=0 her istekte denetim sağlar. opcache.validate_timestamps=0 olduğunda bu ayar dikkate alınmaz.

OPcache, derleme işini azaltarak CPU kullanımını ve TTFB’yi iyileştirebilir; Elementor/Divi kurulumunuzdaki kazancı öncesi/sonrası ölçümleriyle değerlendirin.

Paylaşımlı Hosting, VPS ve Dedicated: Hangi Aşamada Hangisi?

Paylaşımlı hosting, VPS, dedicated sunucu ve colocation farklı kaynak ve yönetim ihtiyaçlarına yanıt veren seçeneklerdir. WordPress hosting ve dedicated sunucu sayfalarındaki planları değerlendirirken kaynak sınırlarını ve yönetim kapsamını karşılaştırın. En ucuz paylaşımlı paket bazı siteler için yeterli olabilir; seçim yalnızca fiyata değil, iş yüküne dayanmalıdır.

Paylaşımlı Hosting Ne Zaman Yeterli?

Aşağıdaki koşullar paylaşımlı hosting değerlendirmesi için örnek bir profil oluşturur; sayfa veya kullanıcı sayıları tek başına yeterlilik eşiği değildir. Sonuç, paketin kaynak sınırlarına, önbellekleme oranına ve dinamik istek yüküne bağlıdır:

• Tek site veya az sayıda site barındırıyorsunuz.
• Sayfa sayısı kısıtlı (örneğin 10–20 civarı).
• WooCommerce yok ya da çok küçük bir katalog.
• Aynı anda sitede 10–15 kullanıcıdan fazla olmuyor.
• Yoğun kampanya veya TV reklamı gibi ani trafik patlamaları planlamıyorsunuz.

Bu durumda bile cPanel istatistiklerini düzenli kontrol etmek, CPU, I/O ve Entry Process (EP) limitlerine çarpıp çarpmadığınızı görmek çok önemli. Paylaşımlı ortamlarda sık görülen “Resource Limit Reached” hatasını nasıl teşhis edeceğinizi ve önleyeceğinizi ayrıntılı olarak anlattığımız rehberden yararlanabilirsiniz.

Ne Zaman VPS’e Geçmelisiniz?

Elementor/Divi kullanan bir sitede aşağıdaki işaretler darboğaz analizi yapmayı gerektirir. Optimizasyona rağmen kaynak veya yapılandırma sınırları sürüyorsa VPS’e geçiş değerlendirilebilir:

• cPanel’de CPU ve I/O grafikleri sık sık tavana vuruyor.
• Kampanya veya reklam dönemlerinde sayfalar 3–5 saniyeden önce açılmıyor.
• Elementor/Divi editöründe kayıt ve önizleme sırasında sık sık zaman aşımı yaşıyorsunuz.
• Aynı hosting paketinde 5+ site barındırıyor ve her birinin trafiği büyümeye devam ediyor.
• Özel PHP ayarları, ek modüller, gelişmiş önbellekleme veya Nginx/LiteSpeed yapılandırması yapmak istiyorsunuz.

VPS boyutlandırmasını yaparken yalnızca bugünkü trafiği değil, 6–12 ay içindeki büyüme planını da hesaba katmak gerekiyor. Kendi siteniz için CPU, RAM ve trafik ihtiyacını hesaplamayı adım adım anlattığımız kapsamlı kapasite planlama rehberini mutlaka okumanızı öneririz.

Dedicated Sunucu ve Colocation Ne Zaman Gündeme Gelir?

Şu senaryolarda dedicated sunucu veya colocation akla yatkın hale gelir:

• Çok yüksek trafikli bir WooCommerce + Elementor/Divi mağazanız var ve kampanya dönemlerinde yüzlerce eşzamanlı kullanıcıyı kaldırmanız gerekiyor.
• Ajans olarak yüzlerce sitesi olan müşterileriniz var; kaynakları tamamen kendiniz yönetmek istiyorsunuz.
• Kuruma özgü uyum veya güvenlik gereksinimleri doğrultusunda kendi fiziksel sunucunuzu barındırma kararı alınmış; bu durumda colocation değerlendirilebilir.

Dedicated veya colocation seçimi tek başına çok katmanlı mimari gerektirmez. Büyük WooCommerce ve ajans projelerinde ölçülen darboğazlara göre uygulama ile veritabanını ayırmak ve ayrı bir önbellek katmanı kurmak değerlendirilebilir. İzleme ve alarm sistemi, bu kararların etkisini takip etmeyi sağlar.

Sayfa Oluşturuculu Sitelerde Uygulanabilir Optimizasyon Adımları

CPU, RAM ve PHP ayarlarını doğru yapmak tek başına yeterli değil; uygulama tarafındaki tercihler de performansı etkiler. Elementor, Divi ve diğer sayfa oluşturucular için en sık önerdiğimiz pratik adımlar şunlar:

1. Gereksiz Eklentileri Temizleyin

• Aynı işi yapan birden fazla eklenti kullanmayın (örneğin 3 farklı form eklentisi, 2 farklı slider vb.).
• Sayfa oluşturucunuzun kendi widget’ı varken ekstra eklenti yüklememeye çalışın.
• “Her ihtimale karşı” kurduğunuz ama aktif kullanmadığınız eklentileri kaldırın.

Eklentiler ek PHP kodu çalıştırabilir; bazıları yeni veritabanı tabloları oluşturur veya ek sorgular çalıştırır. Kaynak etkisi eklentinin işlevine ve kullanımına bağlıdır; her eklenti aynı yükü oluşturmaz.

2. Görselleri ve Medyayı Optimize Edin

Sayfa oluşturuculu sitelerde genellikle çok fazla görsel kullanılır: arka planlar, ikonlar, slider’lar, galeri blokları… Bunların her biri hem disk hem bant genişliği hem de tarayıcı tarafında CPU tüketir.

• WebP/AVIF formatlarını kullanın; görselleri yüklemeden önce sıkıştırın.
• Lazy load (gecikmeli yükleme) özelliğini ilk ekranın dışındaki görseller için etkinleştirin; ilk ekranda görünen, özellikle LCP öğesi olan görseli geciktirmeyin.
• Slider ve ağır animasyonları gerçekten gerekli olduğu yerlerle sınırlayın.

Görsel odaklı projeler için disk, CDN ve WebP/AVIF stratejisini detaylı anlattığımız rehbere de mutlaka göz atın.

3. Tam Sayfa Önbellekleme Kullanın

Bir sayfanın dinamik olarak her istekte yeniden üretilmesi yerine, önceden oluşturulmuş HTML’nin saklanıp ziyaretçilere sunulması, CPU yükünü, önbellekten karşılanan isteklerin oranına bağlı olarak önemli ölçüde azaltabilir. Bu, özellikle Elementor ve Divi gibi ağır sayfa oluşturucularda fark yaratır.

• Nginx FastCGI cache, LiteSpeed Cache veya Varnish gibi çözümlerle tam sayfa cache kurun.
• WooCommerce sepet, ödeme ve hesabım sayfalarını cache dışında tutun; oturum açmış kullanıcılara veya sepet/oturum çerezlerine göre kişiselleştirilen yanıtların ortak önbellekten sunulmasını da engelleyin.
• Cache temizleme (purge) mantığını, içerik güncellendiğinde tetiklenecek şekilde ayarlayın.

Önbellekleme çözümünü seçerken web sunucusu uyumluluğunu, gerekli kurulum yetkilerini ve hosting planının izin verdiği yapılandırmaları değerlendirin.

4. Nesne Önbelleği ile Veritabanı Yükünü Azaltın

WordPress’e entegre edilmiş Redis veya Memcached tabanlı kalıcı nesne önbelleği, tekrar kullanılan veriler için TTFB’yi ve veritabanı kaynaklı CPU yükünü azaltabilir. WordPress’in varsayılan nesne önbelleği yalnızca aynı istek içinde çalışır; istekler arasında kalıcılık için ayrı bir entegrasyon gerekir. Önbellekten yararlanabilecek alanlara örnekler:

• Global template’ler
• Ürün listeleri, filtreler
• Blog arşivleri ve özel sorgular

Bu alanlarda kullanılan veriler nesne önbelleğine yazılıyor ve sonraki isteklerde önbellekten okunabiliyorsa, ilgili MySQL sorgularının bir kısmı önlenebilir; tüm sorgular otomatik olarak önbelleğe alınmaz. Konuya pratik açıdan yaklaşan Redis/Memcached object cache rehberimiz ile adım adım kurulum yapabilirsiniz.

5. Veritabanını Temiz ve Sağlıklı Tutun

Sayfa oluşturuculu sitelerde revizyonlar, eski taslaklar, kullanılmayan şablonlar ve eklenti kalıntıları veritabanını zamanla şişirir. Bu birikim, verilerin nasıl sorgulandığına ve yüklendiğine bağlı olarak RAM kullanımını ve sorgu sürelerini olumsuz etkileyebilir.

• Temizlikten önce geri yüklenebilir bir veritabanı yedeği alın; gereksiz olduğu doğrulanan revizyonları ve eski taslakları periyodik olarak temizleyin.
• Silinen eklentilerin geride bıraktığı tabloları gözden geçirin.
• wp_options ve autoload verilerini düzenli olarak kontrol edin.

Bu konuda adım adım anlatımlı bir rehbere ihtiyacınız varsa, WordPress veritabanı optimizasyonu: wp_options ve autoload şişmesi rehberimizi mutlaka inceleyin.

Performansı Ölçmek: Gerçek Sorun CPU mu, PHP mi, Ağ mı?

Doğru CPU, RAM ve PHP ayarlarını yaptığınızdan emin olmanın tek yolu, ölçmek ve izlemektir. Siteniz yavaşladığında, sorunun sayfa oluşturucudan mı, kötü kodlanmış bir eklentiden mi, yanlış bir PHP ayarından mı yoksa ağ/bant genişliğinden mi kaynaklandığını ancak ölçüm yaparak anlayabilirsiniz.

Tarayıcı Tarafı Ölçümler: TTFB, LCP, CLS

GTmetrix, PageSpeed Insights ve WebPageTest gibi araçlar; TTFB (Time To First Byte), LCP (Largest Contentful Paint) ve CLS (Cumulative Layout Shift) gibi metriklerle hem sunucu hem frontend tarafındaki sorunları ortaya koyar.

• TTFB yüksekse: PHP/CPU/MySQL yükü olası nedenlerdir; ağ gecikmesi, bağlantı kurulumu, yönlendirmeler ve önbellek durumu da incelenmelidir.
• LCP yüksekse: Büyük görseller, ağır JS/CSS, görselin geç keşfedilmesi veya yüksek TTFB olası nedenlerdir; yükleme zaman çizelgesini inceleyin.
• CLS yüksekse: Özellikle sayfa oluşturuculu sitelerde sonradan yüklenen fontlar, banner’lar ve dinamik bloklar buna neden olabilir.

Bu metrikleri nasıl okuyacağınızı ve doğru yorumlayacağınızı web sitenizin hızını doğru ölçmek rehberimizde ayrıntılı anlattık.

Sunucu Tarafı Ölçümler: CPU, RAM, Disk I/O

VPS veya dedicated bir sunucu kullanıyorsanız htop, iotop ve Netdata gibi araçlarla aşağıdakileri izleyebilirsiniz:

• CPU çekirdeklerinin tek tek kullanım oranı
• RAM ve swap kullanımı
• CPU’nun I/O bekleme oranı (iowait); disk gecikmesiyle aynı ölçüm değildir
• MySQL ve PHP-FPM process sayı ve yükleri

Bu veriler, gerektiğinde PHP ve veritabanı sorgu kayıtlarıyla birlikte, şu soruları araştırmanıza yardımcı olur:

• Gerçekten daha fazla vCPU’ya mı ihtiyacım var?
• RAM yetersiz olduğu için mi yavaşlık yaşıyorum?
• Yoksa disk I/O ya da veritabanı sorguları mı sıkıntılı?

DCHost olarak yayınladığımız VPS kaynak kullanımı izleme rehberinde bu araçların kurulum ve yorumlama adımlarını detaylı paylaştık.

Son Değerlendirme

Elementor, Divi ve diğer sayfa oluşturucular; doğru kullanıldığında tasarım sürecini ciddi şekilde hızlandıran, müşterilere esneklik sağlayan güçlü araçlar. Ancak bu esneklik, tasarıma ve kullanılan bileşenlere bağlı olarak CPU ve RAM ihtiyacını, PHP işlem yükünü artırabilir. Kaynak planlamasında temel noktalar şöyle özetlenebilir:

• Küçük ve düşük trafikli projeler için iyi yapılandırılmış paylaşımlı hosting yeterli olabilir; optimizasyona rağmen kaynak limitleri düzenli olarak darboğaz yaratıyorsa daha yüksek kaynaklı bir planı veya VPS’i değerlendirin.
• WooCommerce + Elementor/Divi kombinasyonunda CPU ve RAM önemli kaynaklardır. Örneğin 4 vCPU ve 4–8 GB RAM, yük ölçümleriyle değerlendirilecek bir başlangıç adayı olabilir; evrensel bir alt sınır veya yeterlilik garantisi değildir.
• PHP ayarlarını (özellikle memory_limit, max_execution_time, max_input_vars ve PHP-FPM pm.max_children) sitenizin gerçek yüküne ve sunucu kaynaklarına göre değerlendirin; varsayılanları yalnızca ihtiyaç varsa değiştirin.
• “Hosting yetersiz” sonucuna varmadan önce OPcache, nesne önbelleği (Redis/Memcached) ve tam sayfa önbelleklemenin sitenize uygunluğunu ve ölçülen etkisini değerlendirin; her site tüm katmanlara ihtiyaç duymaz.
• Düzenli izleme ve ölçüm yapmadan yalnızca hislerle karar vermeyin; metriklere bakın.

Elementor/Divi projeniz için paylaşımlı hosting, VPS, dedicated sunucu veya colocation seçeneklerini karşılaştırırken tahmini trafik ve eşzamanlı istek sayısını, sayfa sayısını, WooCommerce kullanımını ve barındırılacak site sayısını listeleyin. Bugünkü ölçümlerinizi önümüzdeki 12 aya ilişkin büyüme beklentinizle birlikte değerlendirerek kaynak kapasitesini, yönetim sorumluluklarını ve yükseltme seçeneklerini karşılaştırın.