Paylaşımlı hostingte hızlı site için önbellek ve sıkıştırma

25/09/26

Paylaşımlı hostingteki bir WordPress sitesi yavaş olduğunda ilk öneri genelde "VPS'e geç" oluyor. Çoğu zaman erken bir öneri. Aynı sunucuda, aynı paketle, sadece doğru PHP sürümü, sayfa önbelleği ve birkaç satırlık .htaccess ile TTFB'yi ciddi şekilde düşürmek mümkün.

Ama paylaşımlı hostingin bir tavanı da var. Aşağıda önce ölçmeyi, sonra yapılabilecekleri, en sonda da o tavana ne zaman çarptığınızı nasıl anlayacağınızı anlatıyorum.

Önce ölçün: curl ile TTFB

Tarayıcı eklentileri ve online araçlar faydalı, ama ben ilk ölçümü komut satırından yapıyorum. curl ile her aşamanın süresini görebilirsiniz:

# Aşama aşama süreler (saniye cinsinden)
curl -o /dev/null -s -w "DNS: %{time_namelookup}\nBağlantı: %{time_connect}\nTLS: %{time_appconnect}\nTTFB: %{time_starttransfer}\nToplam: %{time_total}\n" https://ornek.com/

# Sıkıştırma ve önbellek başlıklarını kontrol etme (GET isteği, gövde atılır)
curl -s -D - -o /dev/null -H "Accept-Encoding: br, gzip" https://ornek.com/ | grep -i -E "content-encoding|cache-control|expires|x-litespeed-cache"

time_starttransfer değeri TTFB'dir. Aynı URL'yi birkaç kez çalıştırın; ilk istek önbelleği ısıtabilir. Önbellekli bir HTML sayfasında TTFB'nin önbelleksiz haline göre belirgin şekilde düşmesi gerekir. Düşmüyorsa sayfa önbelleği çalışmıyor demektir.

PHP sürümü ve OPcache

cPanel'de PHP sürümü genellikle "MultiPHP Manager" veya CloudLinux kullanan sunucularda "Select PHP Version" ekranından değiştirilir. Kuralım basit: resmi olarak hâlâ desteklenen bir PHP 8.x sürümü kullanın. Hangi sürümlerin desteklendiğini php.net'in desteklenen sürümler sayfasından kontrol edin; eski 7.x sürümleri hem yavaş hem güvenlik açısından risklidir.

Sürüm yükseltmeden önce:

Tam yedek alın (dosyalar ve veritabanı).
Eklenti ve temaların yeni sürümle uyumlu olduğunu kontrol edin.
Mümkünse önce bir staging kopyasında deneyin.

OPcache, PHP dosyalarının derlenmiş halini bellekte tutar ve her istekte yeniden derlemeyi engeller. Çoğu hostingte varsayılan olarak açıktır, ama "Select PHP Version" ekranındaki eklentiler listesinde opcache işaretli mi diye bakmakta fayda var. Bir phpinfo() sayfasında "Zend OPcache" bölümünü görmek de yeterli bir kontrol; işiniz bitince o dosyayı silin.

Sayfa önbelleği: en büyük kazanç burada

Önbelleksiz bir WordPress sayfasında her istek PHP'yi çalıştırır, onlarca veritabanı sorgusu yapar ve HTML'i sıfırdan üretir. Sayfa önbelleği bu HTML'i bir kez üretip sonraki ziyaretçilere hazır sunar.

Sunucu LiteSpeed ise tercih bellidir: LiteSpeed Cache eklentisi. Önbellek sunucu seviyesinde çalışır ve PHP hiç devreye girmez. Başarılı olup olmadığını yanıt başlığındaki x-litespeed-cache: hit değerinden anlarsınız. Sunucu türünü curl -sI çıktısındaki server başlığından veya hosting firmasına sorarak öğrenebilirsiniz.

Sunucu Apache ise dosya tabanlı önbellek yapan bir eklenti kullanın. Bu eklentiler HTML'i diske yazar ve PHP'yi mümkün olduğunca erken atlatır.

Her iki durumda da dikkat edilecekler:

Giriş yapmış kullanıcılar, sepet ve ödeme sayfaları önbelleğe alınmamalı.
İçerik güncellendiğinde ilgili sayfaların önbelleği temizlenmeli (eklentiler bunu genelde otomatik yapar).
Aynı anda iki önbellek eklentisi kullanılmamalı.

.htaccess ile sıkıştırma ve tarayıcı önbelleği

Metin tabanlı dosyaları (HTML, CSS, JS, SVG, JSON) sıkıştırmak aktarılan veriyi ciddi şekilde azaltır. Statik dosyalar için tarayıcı önbelleği ise tekrar eden ziyaretlerde isteği tamamen ortadan kaldırır. Aşağıdaki blok Apache ve LiteSpeed'de çalışır; IfModule sarmalayıcıları sayesinde modül yoksa hata vermez.

.htaccess

# --- Sıkıştırma (gzip) ---
<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/plain text/css text/xml
  AddOutputFilterByType DEFLATE text/javascript application/javascript application/json
  AddOutputFilterByType DEFLATE application/xml application/rss+xml application/xhtml+xml
  AddOutputFilterByType DEFLATE image/svg+xml font/ttf font/otf
</IfModule>

# --- Tarayıcı önbelleği ---
<IfModule mod_expires.c>
  ExpiresActive On
  # HTML her zaman yeniden doğrulansın
  ExpiresByType text/html "access plus 0 seconds"
  # CSS ve JS: dosya adında sürüm varsa daha uzun tutulabilir
  ExpiresByType text/css "access plus 1 month"
  ExpiresByType text/javascript "access plus 1 month"
  ExpiresByType application/javascript "access plus 1 month"
  # Görseller ve fontlar
  ExpiresByType image/avif "access plus 6 months"
  ExpiresByType image/webp "access plus 6 months"
  ExpiresByType image/jpeg "access plus 6 months"
  ExpiresByType image/png "access plus 6 months"
  ExpiresByType image/gif "access plus 6 months"
  ExpiresByType image/svg+xml "access plus 6 months"
  ExpiresByType image/x-icon "access plus 6 months"
  ExpiresByType font/woff2 "access plus 1 year"
</IfModule>

# --- Cache-Control'e public ekleme ---
<IfModule mod_headers.c>
  <FilesMatch "\.(css|js|avif|webp|jpe?g|png|gif|svg|ico|woff2)$">
    Header append Cache-Control "public"
  </FilesMatch>
</IfModule>

mod_expires, Expires başlığıyla birlikte Cache-Control: max-age değerini de üretir; bu yüzden aynı dosya türü için ikinci bir max-age yazmıyorum. Süreleri uzatmadan önce şunu bilin: dosya adı veya sorgu parametresinde sürüm yoksa (style.css?ver=6.5 gibi), dosyayı güncellediğinizde bazı ziyaretçiler eski sürümü görmeye devam eder. WordPress çoğu dosyaya ver parametresi ekler; tema veya eklentinin elle eklediği dosyalarda bunu kontrol edin.

Brotli

Brotli, gzip'ten genellikle daha iyi sıkıştırır. LiteSpeed sunucularda sıkıştırma çoğunlukla sunucu seviyesinde yönetilir ve Brotli destekleniyor olabilir. Apache'de mod_brotli yüklüyse şu blok eklenebilir:

.htaccess

<IfModule mod_brotli.c>
  AddOutputFilterByType BROTLI_COMPRESS text/html text/plain text/css text/xml
  AddOutputFilterByType BROTLI_COMPRESS text/javascript application/javascript application/json image/svg+xml
</IfModule>

Hangi kodlamanın döndüğünü yukarıdaki curl komutundaki content-encoding satırından görürsünüz: br ise Brotli, gzip ise gzip çalışıyor. Site Cloudflare arkasındaysa ziyaretçiye giden sıkıştırmayı Cloudflare yönetir; bu konuyu Cloudflare ayarları yazısında anlattım.

Veritabanı temizliği

WordPress veritabanı zamanla şişer: binlerce yazı revizyonu, süresi dolmuş transient'lar, silinmiş eklentilerden kalan ayarlar. En çok etkisini gördüğüm kalem, her sayfa yüklemesinde okunan "autoload" ayarlarıdır. Şu sorgu en büyük autoload kayıtlarını gösterir (tablo önekiniz farklıysa wp_ kısmını değiştirin):

-- En büyük 20 autoload kaydı (WordPress 6.6+ değerleri dahil)
SELECT option_name, LENGTH(option_value) AS boyut
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY boyut DESC
LIMIT 20;

Kaldırılmış bir eklentiye ait büyük bir kayıt görürseniz, yedek aldıktan sonra silebilirsiniz. Revizyon sayısını sınırlamak için wp-config.php içine define('WP_POST_REVISIONS', 5); eklemek de yeni birikmeyi önler.

Daha az eklenti, daha hafif görseller

Eklenti sayısı tek başına bir ölçü değil; önemli olan her eklentinin ön yüzde ne yüklediği. Kaynak kodda her sayfada yüklenen CSS ve JS dosyalarına bakın; sadece iletişim sayfasında gereken bir form eklentisinin her sayfada dosya yüklemesi tipik bir israftır. Sayfanın kaynak kodunu hızlıca incelemek için kaynak kod analiz aracını kullanabilirsiniz.

Görseller çoğu sitede sayfa ağırlığının en büyük kısmı. Doğru boyutta yüklemek ve WebP/AVIF'e dönüştürmek için Görsel optimizasyonu: WebP, AVIF ve lazy load yazısına bakın.

Paylaşımlı hostingin sınırları

Dürüst olmak gerekirse, paylaşımlı hostingte CPU, bellek ve eşzamanlı süreç sayısı sizin kontrolünüzde değil. Aynı sunucudaki başka bir site yoğunlaştığında sizin TTFB'niz de dalgalanabilir. cPanel'deki "Resource Usage" ekranında (CloudLinux varsa) limitlere çarpıp çarpmadığınızı görebilirsiniz.

Benim VPS'e geçiş için kuralım şu:

Durum	Karar
Önbellekli sayfada TTFB iyi, önbelleksizde kötü	Önbellek ayarlarını iyileştirin, paylaşımlı yeterli
Önbellekli sayfada bile TTFB sürekli yüksek	Hosting firmasını veya paketi sorgulayın
Resource Usage ekranında sık limit aşımı	Daha üst paket veya VPS
Önbelleğe alınamayan çok sayfa (üyelik, e-ticaret sepeti)	VPS daha mantıklı
Sunucu seviyesi ayar gerekiyor (özel önbellek, worker)	VPS

Özetle: önce ölçün, sonra PHP sürümü ve OPcache, ardından sayfa önbelleği, sıkıştırma ve tarayıcı önbelleği. Bu dördü yapıldıktan sonra hâlâ yavaşsanız, sorun muhtemelen artık ayarlarda değil sunucudadır. LCP üzerindeki etkisini görmek için LCP'yi 2,5 saniyenin altına indirmek yazısına da göz atın.

Comments / questions

If you have a question about any topic or wish to contact me: Telegram or send an email to [email protected] Thanks!