Hosting Tarafında Site Hızlandırmak: 10 Net Ayar

Web sitesi hızını artırmak için en sık yapılan hata, sadece içerik tarafına yüklenmek; oysa aynı sayfayı farklı hosting ayarlarıyla 2-5 kat aralığında daha hızlı teslim etmek mümkündür. Bu rehberde, hosting (sunucu) tarafında uygulanabilir 10 net ayarı adım adım anlatıyoruz. Her ayar için “ne yapacağım?”, “nerede ayarlanır?” ve “performansı nasıl etkiler?” çerçevesiyle ilerleyeceksiniz. Hedef, ölçülebilir şekilde Lighthouse/TTFB ve sayfa yükleme süresini düşürmek.

1) Cache (önbellek) katmanlarını doğru kurun

Önbellek; HTML, CSS/JS ve statik dosyalar için tarayıcı + sunucu + kenar (CDN) katmanlarında çalışır. Hosting tarafında en kritik nokta, cache’in gerçekten aktif olup olmadığını kontrol etmektir.

Kontrol listesi

• Kontrol panelinde (cPanel/DirectAdmin/plesk vb.) “Cache” / “PageSpeed” / “Optimization” benzeri modüller var mı?
• Web sunucusu (genelde Nginx/Apache) tarafında “ETag”, “Expires”, “Cache-Control” başlıkları doğru mu?
• Uygulama cache’i (ör. WordPress cache) kurulu mu ve sayfa bozmayacak şekilde mi?

Somut beklenti

Önbelleği doğru kurduğunuzda aynı URL için tekrar ziyaretlerde TTFB belirgin düşer, transfer süreleri azalır.

2) HTTP sıkıştırmayı (compression) etkinleştirin

Gzip/Brotli sıkıştırma, sunucunun yanıtlarını daha küçük boyuta indirir. Hosting tarafında bunu açmak, özellikle içerik boyutu yüksek sitelerde doğrudan fark ettirir.

Ne ayarlamalısınız?

• Brotli (Brotli, gzip’ten genellikle daha verimli) mümkünse önceliklendirin.
• Gzip’i geri dönüş (fallback) olarak tutun.
• Sıkıştırma yapılacak MIME türlerini netleştirin: text/html, text/css, application/javascript, application/json, image/svg+xml gibi.

Ölçüm yöntemi

Tarayıcı Network panelinde yanıt başlıklarında Content-Encoding kontrol edin: br veya gzip görmelisiniz.

3) CDN (Content Delivery Network) kullanın ve cache sürelerini yerinde ayarlayın

CDN, içerikleri coğrafi olarak yakın edge lokasyonlardan teslim eder. Hosting tarafında CDN kurulumundan sonra “cache ne kadar süre” ve “hangi URL’ler” sorusu önem kazanır.

Somut kurulum mantığı

• Statik dosyalar (CSS, JS, görsel) için uzun cache: ör. 1-12 ay (dosya adında hash kullanıyorsanız).
• Dinamik sayfalar (sepet, profil, arama sonucu) için kısa cache veya hiç cache değil.

Kritik kontrol

• CDN ile birlikte uygulama cache’i çakışmasın. Yanlış kombinasyon, “eski içerik” üretir.
• Cache purge (temizleme) mekanizması var mı? Deploy sonrası doğru temizleniyor mu?

4) TLS/HTTPS ayarlarını hız odaklı yapın

TLS tek başına “siteyi hızlandırır” gibi görünse de doğru ayarlar handshake süresini azaltır ve yeniden kullanım (session resumption) sağlar.

Hosting tarafında net ayarlar

• TLS sürüm tercihi: modern tarayıcılar için TLS 1.2+ ve mümkünse TLS 1.3.
• Sertifika doğrulama ve zincir (chain) doğru mu.
• Gerekmedikçe zayıf cipher’ları kapatın.
• HTTP/2 veya HTTP/3 (varsa) etkin mi?

Test

Qualys/SSL test aracıyla “handshake ve protocol” durumunu kontrol edin. Hedef, modern protokollerin devrede olması.

5) HTTP/2 ve (mümkünse) HTTP/3’ü aktif edin

HTTP/2; çoklu istekleri tek bağlantı üzerinde daha verimli taşır, başlık sıkıştırması sağlar. HTTP/3 ise QUIC tabanlı olduğu için bazı ağ koşullarında daha stabil olabilir.

Nerede açılır?

• Sunucu tarafında (Nginx/Apache ayarları) ya da hosting sağlayıcısının panelinde “HTTP/2” seçeneği.
• CDN üzerinden geliyorsa CDN panelinde “HTTP/2/H3” tarafını kontrol edin.

Somut etki

Özellikle mobil ağlarda çoklu asset (CSS/JS/görsel) çağrılarında gecikme azalır.

6) DNS ve domain servislerinin performansını optimize edin

DNS kaynaklı gecikme, doğru CDN kurulumu yapılmış olsa bile ilk bağlantıyı etkileyebilir. Hosting tarafında DNS yönetimi, TTL (Time To Live) ve record türleri hızla ilişkilidir.

Net uygulamalar

• CDN kullanıyorsanız CNAME/A record’larını doğru CDN endpoint’lerine yönlendirin.
• Dinamik geçişler için TTL’i düşük tutun, ama kalıcı durumda makul seviyeye çekin.
• MX/NS kaydı gibi servis kayıtlarının yanlış taşınmasını engelleyin (mail tarafı etkilenmesin).

Ölçüm

Birden çok lokasyonda DNS lookup süresi ölçün. Hedef, ilk DNS sorgusunu hızlandırmaktır.

7) Yüksek I/O gecikmesini azaltın: disk ve storage seçimi

Sunucu tarafında disk gecikmesi (I/O wait), özellikle veritabanı erişimi ve dinamik sayfalarda TTFB’yi yükseltir. Burada yalnız “disk boyutu” değil; IOPS ve storage türü belirleyicidir.

Net karar

• VDS/VPS sağlayıcınız “SSD/NVMe” ve mümkünse “yüksek IOPS” vaat ediyor mu?
• Paylaşımlı storage mı yoksa node-local (daha düşük gecikme) yaklaşımı var mı?
• Disk doygunluğu (disk yüzde 80+ doluluk) gecikmeyi artırır.

Somut kontrol

CPU/RAM yeterli olsa bile TTFB yüksek kalıyorsa I/O gecikmesi için izleme yapın.

8) PHP/ uygulama çalışma zamanını hızlandırın (FPM ayarları)

Çoğu web sitesi için CPU zamanı ve PHP yürütme şekli kritik. Hosting tarafında PHP-FPM (FastCGI Process Manager) veya Apache mod_php ayarları TTFB’yi etkiler.

Net ayarlar

• PHP-FPM worker sayıları ve process limitleri; RAM’e göre doğru ölçeklenmeli.
• OpCache (bytecode cache) mutlaka aktif olmalı.
• Script max execution time ve memory_limit gereksiz yüksek/ düşük olmamalı.

Somut beklenti

OpCache aktif olduğunda PHP kod derleme adımı azalır; tekrar isteklerde performans artar.

9) Veritabanı (DB) performansını hosting seviyesinde iyileştirin

Dinamik içerik üreten sitelerde (WordPress, e-ticaret, portal) DB ayarları hızın merkezindedir.

Net uygulamalar

• MySQL/MariaDB için yavaş sorgu (slow query) log’u açın.
• Otomatik index oluşturma değil; yavaş sorgulara uygun index ekleyin.
• Connection handling: uygulama her istekte yeni bağlantı açmak yerine doğru bağlantı havuzu/kalıcılık stratejisi kullanmalı.
• Backup (yedek) sırasında DB yükünü planlayın (yoğun saat değil).

Doğru yaklaşım

“DB’i hızlandırdım” demek için önce ölçüm gerekir: slow query raporu + saniyedeki sorgu sayısı (QPS) + en ağır sorgular.

10) İzleme ve log yönetimi: hız regresyonunu anında yakalayın

Performans optimizasyonu bir kez yapılıp bırakılmaz. Hosting tarafında izleme ve log yönetimi yapılmazsa, hız düşüşlerini fark etmek gecikir.

Net kurulum

• APM/izleme (ör. application performance monitoring) veya en azından erişim log + hata log rotasyonu (rotation) otomatik olsun.
• WAF/Firewall ve rate-limit yapılandırmalarında “yanlış pozitif” riskini azaltın.
• 4xx/5xx artışını ayrı izleyin; hız sorunu bazen “hata” kaynaklıdır.

Somut kontrol noktaları

• CPU sürekli %90+ mi?
• Disk doluluk yükseliyor mu?
• DB CPU/IO wait yükseliyor mu?

Hosting tarafında hızlandırma için hızlı uygulama planı

Aşağıdaki sırayla ilerlemek, daha az deneme-yanılma ile sonuca götürür.

1. Cache (sunucu + uygulama) aktif et
2. Compression (Brotli/gzip) aç
3. CDN doğrula ve cache sürelerini ayarla
4. HTTP/2/HTTP/3 ve TLS modernleştir
5. PHP-FPM/opcache ayarlarını kontrol et
6. Storage/IO gecikmesini test et (özellikle DB var ise)
7. DB slow query + index ile yavaş sorguları düzelt
8. Son olarak izleme/log rotasyonunu “hız regresyonu yakalayacak” şekilde kur

Hız kazanımı nereden gelir? En sık 5 kök neden

Aşağıdaki tabloda hosting tarafında en sık görülen darboğazları ve tipik çözümü özetledim.

Sonuç: 10 ayarı uygulayın, ölçün ve tek tek kalıcı hale getirin

NetKıyas’ta hız odaklı karar verirken “hangi ayar nerede?” sorusunun cevabı nettir: önbellek + sıkıştırma + CDN + modern protokoller + PHP opcache + DB slow query + izleme. Bu 10 başlığı önerilen sırayla devreye alın; her adım sonrası Lighthouse veya gerçek kullanıcı izleme (RUM) ile TTFB ve toplam yükleme süresini karşılaştırın. Son adım olarak, yaptığınız değişikliklerin etkisini log/izleme ile takip ederek hız regresyonunu erken yakalayın.