Web Sitesi Yavaş Açılıyor: Sorun Hostingte mi, Sitede mi?

“Site yavaş” bir şikâyet; teşhis için yetmiyor. Yıllardır düşük gecikmeli servislerle uğraşıyorum ve bu işte öğrendiğim ilk şey, kullanıcının “yavaş” dediği sürenin en az üç ayrı parçadan oluştuğu. Her parçanın sahibi farklı.

Hangisinin büyüdüğünü bilmeden hosting değiştirmek, ateşi düşürmek için termometreyi değiştirmeye benzer.

1. 1Sunucu ilk baytı geç gönderiyorÖlçü: TTFBSahibi: Sunucu ya da uygulamaBağlantıya tıkladıktan sonra beyaz ekranda bekleme; sekme simgesi uzun süre döner.
2. 2Sayfa ağırÖlçü: LCP, sayfa ağırlığı, istek sayısıSahibi: Ön yüz: görsel, betik, fontSayfanın iskeleti hemen gelir ama ana görsel ve içerik geç oturur, sayfa kayar.
3. 3Ara ara takılıyor ya da hata veriyorÖlçü: 508/503 sıklığı, kaynak kullanım grafiğiSahibi: Kaynak limiti, bot, zamanlanmış görevBazen çok hızlı, bazen hiç açılmıyor; çoğunlukla belirli saatlerde.

Bu üç durumu birbirinden ayırmak için ücretli araca gerek yok. PageSpeed Insights hem gerçek kullanıcı verisini (Chrome kullanıcı deneyimi raporu, CrUX) hem de tek seferlik laboratuvar ölçümünü gösterir. Chrome DevTools (F12 → Network) kendi bilgisayarınızdan isteği evre evre ayırır. WebPageTest ise seçtiğiniz şehirden ve bağlantı hızından ölçüp şelale grafiği çizer. Komut satırını seviyorsanız curl aynı işi tekrarlanabilir biçimde görür; aşağıda onu kullanacağız.

TTFB iyi, LCP kötüyse süre tarayıcıda geçiyordur. En sık iki neden var: ana görselin (LCP öğesi) büyük ve sıkıştırılmamış olması ve sohbet, harita, reklam pikseli gibi üçüncü taraf betiklerin ilk görünümü bekletmesi. PageSpeed Insights raporundaki LCP öğesi satırı hangi görselin sorumlu olduğunu söyler. Bu durumda hosting değişikliği bir şey kazandırmaz; iş ön yüzdedir. Yavaş sayfanın talep ve form tarafına etkisini form gelmiyorsa bakılacak yerler yazımızda ayrıca ele aldık.

TTFB (Time to First Byte, ilk bayta kadar geçen süre), tarayıcının isteği başlatmasından sunucu yanıtının ilk baytı gelene kadar geçen süredir. İçinde yönlendirmeler, DNS çözümleme, TCP bağlantısı, TLS el sıkışması ve sunucunun yanıtı hazırlarken beklettiği süre vardır. Yani TTFB yalnız “sunucu hızı” değildir; ağın ve mesafenin de payı vardır.

Google’ın web.dev rehberi iyi bir TTFB için 0,8 saniye ve altını kaba hedef olarak verir; 1,8 saniyenin üstü kötü sayılır. Burada iki nokta sık karıştırılıyor. Birincisi, TTFB bir Core Web Vitals metriği değildir; Core Web Vitals üçlüsü LCP, INP ve CLS’dir. Ama TTFB, LCP’nin ilk parçasıdır: ilk bayt 1,5 saniyede geliyorsa LCP’nin 2,5 saniyelik iyi eşiğine sığmak için tarayıcıya yalnız bir saniye kalır. İkincisi, PageSpeed Insights’taki laboratuvar uyarısıyla saha verisi aynı şey değildir.

Sunucu türlerine göre hedef değer tablosunu sunucu türleri karşılaştırmamızın performans bölümünde verdik, burada tekrar etmeyeceğim. Bu yazıda sayının kendisinden çok, onu nereden ve nasıl ölçtüğünüz önemli.

TTFB’yi nereden ölçmeli? Altı kaynak, altı tuzak

Bu testi sevmemin nedeni basit: aynı sunucuda, aynı ağ yolundan geçen üç isteğin farkı katmanları tek tek soyar. Statik HTML dosyası yalnız web sunucusunu ve ağı ölçer. Boş bir PHP dosyası buna PHP işçisinin başlamasını ve hesap limitlerini ekler. Ana sayfa bunların üstüne CMS’i, eklentileri ve veritabanını koyar. Süre hangi basamakta sıçrıyorsa sorun oradadır.

1. 1test.html dosyasını yükleyinPlesk’te Dosyalar → httpdocs, cPanel’de Dosya Yöneticisi → public_html altına tek satırlık bir test.html oluşturun. İçerik önemli değil; ok yazmanız yeterli.
2. 2Boş bir PHP dosyası ekleyinAynı klasöre ping.php oluşturup içine yalnız <?php echo 'ok'; yazın. phpinfo() kullanmayın: sunucu sürümlerini ve dosya yollarını herkese açar, test bitince unutulan en tehlikeli dosyalardan biridir.
3. 3Üç adresi beşer kez ölçünAşağıdaki komut her adresi beş kez ölçer. Tek ölçüme güvenmeyin; ilk istekte DNS ve bağlantı önbelleği boş olduğu için hep daha yavaştır. Beş değeri sıralayıp ortadakini (ortanca) alın.
4. 4Farkın açıldığı basamağı bulunÜç ortancayı aşağıdaki karar tablosuyla karşılaştırın ya da doğrudan Kök Neden Sihirbazı’na girin.
5. 5Test dosyalarını silinİş bitince test.html ve ping.php dosyalarını kaldırın. Zararsız görünseler de sunucuda gereksiz dosya bırakmayın.

# httpdocs/test.html
ok

# httpdocs/ping.php
<?php echo 'ok';

for u in test.html ping.php ""; do
  echo "== /$u"
  for i in 1 2 3 4 5; do
    curl -o /dev/null -s -w 'dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n' "https://alanadiniz.com.tr/$u"
  done
done

Windows 10 ve 11’de curl yerleşik gelir. Windows PowerShell’de curl yazınca Invoke-WebRequest çalıştığı için curl.exe yazın; döngü yerine tek satırlık komutu beş kez çalıştırın. Komut İstemi’nde (cmd) biçim metnini tek tırnak yerine çift tırnakla verin. Çıktıdaki değerler saniye cinsindendir ve isteğin başından itibaren birikimlidir; ttfb alanı web.dev tanımındaki TTFB’ye karşılık gelir.

Karar tablosu: fark hangi basamakta açılıyor?

Eşikler yön gösterir, standart değildir. Türkiye’deki bir sunucuda statik bir dosyanın birkaç yüz milisaniyeyi geçmesini biz sunucu tarafında bir sorun işareti sayıyoruz; sunucu yurt dışındaysa bağlantı payı doğal olarak büyür ve eşik yukarı kayar.

Sihirbaz, statik dosya testinin sonuçlarını ve gözlemlediğiniz belirtileri beş olası kaynağa puan olarak dağıtır: sunucu ve kaynak limiti, uygulama, ön yüz, ağ ve konum, bot trafiği. Her alanda “bilmiyorum” seçeneği var; boş bıraktığınız alan puanı etkilemez, yalnız güven düzeyini düşürür.

Puanlar kural tabanlı bir tahmindir, ölçümün yerine geçmez. Kuralları ekipte hız şikâyetlerinde izlediğimiz sıraya göre yazdım: önce statik, PHP ve ana sayfa farkı, sonra hatanın türü ve zamanlaması, en son ortam. Sonuçtaki “hosting değiştirmek çözer mi?” cevabı da ölçüm girdikçe güçlenir. Elinizde ölçüm yoksa üstteki örnek senaryolardan birini yükleyip aracın nasıl düşündüğünü görebilirsiniz.

Sonucu nasıl okumalı?

Kaynak skoru

0–100 arası. Bir kaynağı destekleyen kanıtın gücünü gösterir, kaynakların birbirine oranını göstermez. İki kaynağın birden yüksek çıkması normaldir.

Güven düzeyi

Girilen sayısal ölçüm sayısına göre: 0–1 düşük, 2–3 orta, 4 ve üstü yüksek. Statik dosya testi girilmeden “yüksek” verilmez.

Hosting kararı

Yalnız sunucu ve konum kaynaklı skorlar hosting değişikliğiyle düzelir. Uygulama ve ön yüz skorları yeni sunucuya da taşınır.

Destek özeti

Sonuç adımındaki metni kopyalayıp hosting desteğine gönderin. “Site yavaş” yerine ölçüm vermek, cevabı hem hızlandırır hem somutlaştırır.

DevTools, isteği evrelerine ayırmanın en kolay yolu. Siteyi Chrome’da açın, F12 (Mac’te Cmd+Option+I) ile geliştirici araçlarını açın, Network sekmesine geçin, Disable cache kutusunu işaretleyin ve sayfayı yenileyin. Listenin başındaki, türü document olan satır HTML isteğidir. Ona tıklayıp Timing sekmesini açın.

Sık yapılan hata, “Waiting” satırını TTFB’nin tamamı sanmak. web.dev tanımındaki TTFB, DNS ve bağlantı evrelerini de içerir. Yurt dışındaki bir sunucuda bekleme örneğin 150 ms iken bağlantı ve TLS birlikte 300 ms tutabilir. Bu durumda sunucuyu hızlandırmak az şey kazandırır, sunucuyu ziyaretçiye yaklaştırmak çok şey.

DNS payı ilk ziyarette yüksek çıkıyorsa DNS sağlayıcınızın yanıt süresine ve CNAME zincirine bakın. Kayıtların nasıl kurulduğunu ve TTL’nin ne işe yaradığını domain ve DNS ayarları rehberimizde anlattık.

TTFB Parçalayıcı

Aşağıdaki araca DevTools’taki değerleri ya da statik dosya testindeki curl komutunun çıktısını yapıştırın. Birden fazla curl satırı yapıştırırsanız her alan için ortanca alınır; DevTools değerlerinde SSL, bağlantı süresinden otomatik düşülür.

Paylaşımlı hostingte çok sayıda hesap aynı sunucuyu paylaşır. CloudLinux işletim sistemi her hesabı LVE (Lightweight Virtual Environment, hafif sanal ortam) denen bir kafese koyar ve her kafese işlemci, bellek, süreç ve disk erişimi için tavan çizer. CageFS ise her hesabın dosya sistemini diğerlerinden yalıtır. Amaç, tek bir sitenin sunucunun tamamını tüketmesini engellemek.

508 Resource Limit Is Reached, bu tavanlardan birine vurduğunuzu söyleyen hatadır. En sık sebep EP (entry processes, eşzamanlı giriş süreci) limitidir: aynı anda işlenen PHP isteği sayısı tavana gelince yeni istek kafese giremez ve 508 alır. EP’yi ziyaretçi sayısıyla karıştırmayın. Önbellekten dönen sayfa EP harcamaz; önbelleksiz her PHP isteği, cron işi ve SSH oturumu birer giriş süreci sayılır. 20 ziyaretçili bir anda 508 görüp binlerce ziyaretçili bir günü hatasız geçirmeniz mümkün. Belirleyici olan, aynı saniyede kaç PHP isteğinin ne kadar uzun süre işlendiği. Bir ayrıntı daha: LiteSpeed giriş süreçlerini Apache’den farklı sayar, bu yüzden aynı EP değeri iki web sunucusunda aynı davranmayabilir.

503 Service Unavailable daha genel bir cevaptır: sunucu isteği şu an karşılayamıyor. Paylaşımlı hostingte süreç veya bellek limiti, PHP-FPM havuzunun dolması, bakım modu ya da önünüzdeki CDN’in sunucuya ulaşamaması 503 üretebilir. 508 ise neredeyse her zaman LVE’ye işaret eder. İkisinde de ilk soru aynı: o dakikada hesabınızda ne çalışıyordu?

Limiti en sık dolduran altı şey

• 01Bot dalgasıBir tarayıcı ya da kaba kuvvet aracı kısa sürede yüzlerce önbelleksiz istek atar; EP birkaç saniyede dolar.
• 02wp-cron yığılmasıZiyaretçi geldiğinde tetiklenen zamanlanmış görevler üst üste biner; özellikle kampanya e-postası sonrasında.
• 03Yedek eklentisiGece çalışan site içi yedek, IO ve CPU’yu dakikalarca tavanda tutar. Hosting zaten yedek alıyorsa ikincisine gerek yoktur.
• 04Önbelleksiz sayfalarSepet, arama, filtre ve giriş yapmış kullanıcı sayfaları her seferinde PHP’de yeniden üretilir.
• 05Yavaş sorguTek bir istek 8 saniye sürerse 8 saniye boyunca bir EP yuvasını tutar. Yavaşlık limiti doldurur, dolan limit yavaşlığı büyütür.
• 06Dış API çağrısıKur, kargo ya da stok servisine her sayfada senkron istek atan eklenti, karşı taraf yavaşlayınca bütün yuvaları kilitler.

Paket yükseltmek, limiti dolduran iş meşru ve kalıcıysa doğru çözümdür: trafik gerçekten artmış, önbellek açık, botlar süzülmüş ve hesap hâlâ yoğun saatlerde tavana vuruyorsa. Limit bot ya da bozuk bir cron yüzünden doluyorsa daha büyük paket aynı sorunu biraz daha geç gösterir. Paketler arasındaki gerçek maliyet farkını hosting fiyatları rehberimizde hesapladık.

WordPress’te “kaç eklenti fazla?” tartışması bence yanlış soru. On beş hafif eklenti, tek bir kötü yazılmış eklentiden daha az zarar verir. Benim sorduğum soru şu: her istekte hangi kod çalışıyor ve ne kadar sürüyor?

Bunu tahmin etmek yerine ölçmek için Query Monitor eklentisini kurun. Yönetici olarak giriş yaptığınızda üst çubukta sayfanın üretim süresini, sorgu sayısını, en yavaş sorguları ve bu sorguları hangi eklentinin çağırdığını gösterir. “Queries by Component” ve “HTTP API Calls” panelleri suçluyu çoğu zaman ilk beş dakikada ele verir.

// wp-config.php (dosyanın sonundaki "stop editing" satırından önce)
define( 'DISABLE_WP_CRON', true );

# Zamanlanmış görev, 5 dakikada bir
# (Plesk → Zamanlanmış Görevler, cPanel → Cron Jobs)
*/5 * * * * curl -s "https://alanadiniz.com.tr/wp-cron.php?doing_wp_cron" >/dev/null 2>&1

# WP-CLI varsa alternatif:
*/5 * * * * cd /var/www/vhosts/alanadiniz.com.tr/httpdocs && wp cron event run --due-now >/dev/null 2>&1

SELECT option_name, LENGTH(option_value) AS bayt
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto', 'auto-on')
ORDER BY bayt DESC
LIMIT 10;

Tablo öneki wp_ değilse kendi önekinizi yazın. Listede tanımadığınız büyük bir satır görürseniz silmeden önce veritabanı yedeği alın ve hangi eklentiye ait olduğunu doğrulayın; aktif bir eklentinin ayarını silmek onu sıfırlar.

OpenCart mağazalarda tablo farklı ama mantık aynı: önbelleksiz kategori ve filtre sayfaları, her istekte çalışan modifikasyonlar (OCMOD) ve büyük ürün tablolarında indekssiz sorgular. OpenCart’a özel geliştirme, bakım ve yönetilen hosting işini OpencartExtra markamız altında yürütüyoruz. Sorun eklenti düzeyini aşıp kodun kendisine indiyse, örneğin özel bir modül her sayfada stok servisine gidiyorsa bu bir web yazılım geliştirme işidir. Büyüyen mağazalarda platform tarafını e-ticaret platformu için web yazılım sayfamızda anlattık.

PHP her istekte kaynak kodu okuyup derler ve ortaya çıkan ara kodu (opcode) çalıştırır. OPcache bu derlenmiş kodu paylaşımlı bellekte tutar; ikinci istekten itibaren derleme adımı atlanır. OPcache kapalı bir WordPress sitesi, her sayfa isteğinde yüzlerce dosyayı yeniden derler. Çoğu hostingte varsayılan olarak açıktır, ama ben her teşhiste kontrol ederim: panelin PHP ayarlarında ya da opcache_get_status() çıktısında görünür.

Sürüm tarafında iki ayrı konu var: hız ve güvenlik. PHP 8 serisi aynı kodu 7.4’e göre genellikle daha az işlemciyle çalıştırır. Ne kadar kazanacağınız uygulamaya göre değişir; bu yüzden kesin bir yüzde vermeyeceğim. Güvenlik tarafı ise tartışmasız: güvenlik desteği biten sürüm, yeni bulunan açıklar için yama almaz.

Kaynak: php.net “Supported Versions” sayfası, Ekim 2026 itibarıyla.

Plesk’te sürüm site bazında değişir: Web Siteleri ve Alan Adları → alan adı → PHP (panel sürümüne göre “PHP Ayarları”) ekranında sürümü ve çalıştırma biçimini (FPM) seçersiniz. Aynı ekranda memory_limit, max_execution_time ve OPcache ayarları da bulunur. Bizim hosting altyapımızda PHP sürümü site bazında seçiliyor ve PHP 8.4 hazır. Eski projeler için 7.4 desteği de sürüyor; dürüst olmak gerekirse onu yalnız henüz taşınamamış siteler için tutuyoruz, yeni kurulumda önermiyoruz.

Önbellek, pahalı bir işin sonucunu saklayıp bir sonraki istekte o işi hiç yapmamaktır. Bir sitede bunun beş katmanı var ve her biri farklı bir şeyi saklar. Gördüğüm sorunların çoğu eksik katmandan çok, hangi katmanın neyi sakladığının bilinmemesinden çıkıyor.

1. L1Tarayıcı önbelleğiGörsel, CSS ve JS dosyalarını ziyaretçinin cihazında tutar (Cache-Control başlığı).Tekrar ziyareti hızlandırır, ilk ziyarete etkisi yoktur.
2. L2CDNStatik dosyaları ziyaretçiye yakın noktalardan dağıtır.Görsel ağırlıklı sayfada LCP’yi düşürür; dinamik HTML’in TTFB’sini kendiliğinden düşürmez.
3. L3Tam sayfa önbelleğiHazır HTML’i saklar: LiteSpeed’de LSCache, nginx’te FastCGI cache, diğerlerinde eklenti tabanlı çözümler.Ziyaretçi TTFB’sinde en büyük kazanç; PHP hiç çalışmaz.
4. L4Nesne önbelleğiVeritabanı sorgu sonuçlarını Redis veya Memcached’de tutar.Sayfa önbelleğinin atlandığı sepet, panel ve üye alanında işe yarar.
5. L5OPcacheDerlenmiş PHP kodunu bellekte tutar.Her PHP isteğini hafifletir; sayfa önbelleğinin yerine geçmez.

Önbelleğin çalıştığını tahmin etmeyin, yanıt başlığına bakın. Aynı adresi iki kez isteyin; ikincisinde HIT görmelisiniz:

curl -sI https://alanadiniz.com.tr/ | grep -iE 'x-litespeed-cache|cf-cache-status|x-cache|cache-control|age'

# LiteSpeed sayfa önbelleği:  x-litespeed-cache: hit
# Cloudflare:                 cf-cache-status: HIT   (DYNAMIC = önbelleğe alınmadı)
# Diğer kurulumlar:           x-cache: HIT           (başlık adı kuruluma göre değişir)

Önbellekte en sık gördüğüm beş hata

• Çift sayfa önbelleğiSunucuda LSCache varken ayrıca başka bir sayfa önbelleği eklentisi kurmak. İki katman birbirinin temizlemesinden habersizdir; eski sayfa görünür, sorun ararken saatler gider. Tek bir sayfa önbelleği seçin.
• “Her şeyi önbelleğe al” kuralıCDN’de HTML dahil her şeyi saklayan kural, oturum açılmış sayfaları ve sepeti de saklayabilir; bir müşterinin sepeti başkasına görünebilir. Giriş, sepet, ödeme ve hesap yollarını hariç tutmadan bu kuralı açmayın.
• Isınmamış önbellekHer güncellemede bütün önbelleği temizleyen yapılandırmada ilk ziyaretçiler hep yavaş sayfayı görür. Seçici temizleme ve önbellek ısıtma bunu azaltır; ama ısıtmayı paylaşımlı hostingte düşük hızda çalıştırın, yoksa kendi EP limitinize kendiniz vurursunuz.
• Sorgu parametreleriutm_, gclid ve fbclid gibi reklam parametreleri her biri ayrı sayfa sayılırsa reklam trafiği önbellekten hiç yararlanmaz. LSCache’te ve CDN’lerde bu parametreleri yok sayma ayarı vardır.
• Mobil ve masaüstü ayrımıTema mobil için ayrı HTML üretiyorsa önbelleğin de iki görünümü ayrı saklaması gerekir; yoksa masaüstü sayfa telefona gider.

LiteSpeed ve LSCache, Cloudflare CDN entegrasyonu ve Imunify360 bizim Business ve üstü hosting paketlerimizde yer alıyor; paketler arasındaki farkı web hosting sayfasında görebilirsiniz.

Siteye gelen isteklerin hepsi insan değil. Arama motoru tarayıcıları, SEO araçları, yapay zekâ veri toplayıcıları, fiyat karşılaştırma botları ve kaba kuvvet (brute-force) giriş denemeleri, küçük bir kurumsal sitenin isteklerinin azımsanmayacak bir kısmını oluşturabilir. Dert şu ki botlar çoğunlukla önbelleğin en az işe yaradığı adreslere gider: giriş sayfası, arama, filtre kombinasyonları, xmlrpc.php.

Yavaşlık belli saatlerde geliyor ve yanında 508 varsa ilk bakacağım yer erişim günlüğüdür. Plesk’te Web Siteleri ve Alan Adları → alan adı → Günlükler ekranından görüntüleyebilir, SSH erişiminiz varsa doğrudan dosyadan sayabilirsiniz. Plesk’te HTTPS günlüğü genellikle access_ssl_log adını taşır.

# En çok istek atan 10 IP
awk '{print $1}' access_ssl_log | sort | uniq -c | sort -rn | head -10

# En çok istenen 10 adres
awk '{print $7}' access_ssl_log | sort | uniq -c | sort -rn | head -10

# wp-login.php ve xmlrpc.php'ye POST atan IP'ler
grep -E 'POST /(wp-login|xmlrpc)\.php' access_ssl_log | awk '{print $1}' | sort | uniq -c | sort -rn | head

Günlükte tanımadığınız PHP dosyalarına giden istekler, wp-content/uploads altında çalıştırılan betikler ya da sizin göndermediğiniz e-posta trafiği görüyorsanız konu hız olmaktan çıkar. Bu durumda site hacklendiğinde ilk 24 saatte yapılacakları ayrıca yazdık; uygulama düzeyinde zafiyet şüphesinde güvenlik ve sızma testi hizmetimiz devreye girer.

Işık fiberde de zaman harcar ve bir HTTPS isteği sunucuya tek seferde gitmez. Yeni bir bağlantıda tarayıcı önce TCP için bir tur (gidiş-dönüş, RTT) yapar, ardından TLS el sıkışması için en az bir tur daha, sonra isteği gönderip yanıtı bekler. TLS 1.3 ile ilk bayta kadar kabaca üç tur, TLS 1.2 ile dört tur gerekir. HTTP/3 (QUIC) bağlantıyla şifrelemeyi birleştirerek bir tur daha kazandırır.

Bu yüzden konumun etkisi tek bir ping süresinden büyüktür; tur süresi, tur sayısıyla çarpılır. Aşağıdaki tablo yalnız örnek bir hesap, ama mantığı gösteriyor.

RTT değerleri örnektir; gerçek değer İSS’ye, güzergâha ve saate göre değişir. Kendi değerinizi ping komutuyla ya da TTFB Parçalayıcı’daki bağlantı payıyla görebilirsiniz. DNS süresi ve sunucunun yanıtı hazırlama süresi bu tablonun üstüne eklenir.

HTTP/2 ve HTTP/3

Tek bağlantı üzerinden çok sayıda dosyayı paralel taşır. curl -I çıktısında HTTP/2 görmelisiniz; HTTP/3 desteği yanıttaki alt-svc: h3 başlığıyla duyurulur.

Sıkıştırma

HTML, CSS ve JS için Brotli veya Gzip açık olmalı; yanıt başlığında content-encoding: br ya da gzip görünür. Kapalıysa indirme evresi boşuna uzar.

DNS sağlayıcısı

İlk ziyaretteki DNS süresi sağlayıcıya ve TTL ayarına bağlıdır. Çok kısa TTL, çözümleyicinin kaydı sık sık yeniden sorması demektir.

Bağlantının yeniden kullanımı

Keep-alive ve TLS oturum yeniden kullanımı ikinci istekten itibaren turları azaltır; tekrar ziyaretler bu yüzden ilk ziyaretten hızlıdır.

Kitleniz Türkiye’deyse Türkiye’deki ya da yakın bir veri merkezi ağ payını en aza indirir. Kitleniz dünyaya dağılmışsa sunucuyu tek bir yere koyup statik dosyaları CDN’den dağıtmak daha mantıklıdır. Ölçerken de test noktasını kitlenizle eşleştirin: Türkiye’de satış yapan bir sitenin hızını ABD’deki bir test noktasından ölçüp “hosting yavaş” sonucuna varmak, en sık gördüğüm yanlış alarmlardan biri.

Hız şikâyetiyle gelen sitelerde en sık duyduğum soru bu ve cevabım hep aynı: ölçümler ne diyorsa o. Yukarıdaki testler bir yöne işaret ettiyse kararı vermek zor değil.

Beş seçenek, beş farklı sonuç

Paylaşımlı hostingten VPS’e geçişi ve sunucu türlerinin farkını web hosting, VPS, bulut ve dedicated karşılaştırmamızda anlattık; kaynakları size ayrılmış seçenekler için bulut sunucu sayfamıza bakabilirsiniz. Zaten VPS’teyseniz LVE yoktur; sorun sunucunun kendi işlemci, bellek ya da disk darboğazıdır ve onu sunucu yavaşladığında darboğaz teşhisi yazımızda ele alıyoruz.

Taşımaya karar verdiyseniz iki şeyi atlamayın. DNS değişikliği e-postayı kesmesin diye kayıtları önceden planlayın; adımlar domain ve hosting bağlama rehberimizde var. Adres yapısı da değişecekse arama trafiğini korumak için SEO kaybetmeden taşıma rehberimize göz atın. Taşımadan önce ve sonra aynı üç adresi aynı yöntemle ölçün; karşılaştıramadığınız bir iyileşme, iyileşme değildir.

Hız sorunu çoğu zaman bir kez çözülüp unutulur, sonra bir eklenti güncellemesiyle geri gelir. Bunu yakalamak için pahalı bir izleme aracı gerekmiyor; düzenli ve hep aynı yöntemle yapılan ölçüm yeterli.

1. 1Haftalık üç adres ölçümüBu kez ana sayfa, en çok trafik alan kategori ya da hizmet sayfası ve bir ürün ya da form sayfası. Aynı komut, aynı saat, aynı ağ.
2. 2Search ConsoleDeneyim → Önemli Web Verileri raporu URL gruplarının saha durumunu gösterir. Kötü gruba düşen şablonu görürseniz o şablondan bir sayfayı ölçün.
3. 3Çalışma süresi izlemeDakikalık kontrol yapan bir uptime servisi yanıt süresini de kaydeder. Grafikte yavaşlığın başladığı saati görmek, değişiklik günlüğüyle eşleştirmeyi kolaylaştırır.
4. 4Değişiklik günlüğüEklenti kurulumu, tema güncellemesi, PHP sürümü, yeni bir pazarlama betiği. Tarih ve saatle tutulan basit bir liste, “ne zaman başladı?” sorusunun cevabıdır.

Tarih / saat      Adres         TTFB (ortanca)  LCP (PSI)  Not
2026-11-04 10:00  /             420 ms          2,1 sn     Eklenti güncellemesi öncesi
2026-11-04 10:00  /test.html    85 ms           -          Karşılaştırma için
2026-11-11 10:00  /             1.310 ms        3,4 sn     Güncellemeden sonra yavaşladı

İzlemenin SEO tarafı da var: Search Console’daki Önemli Web Verileri raporu, Google’ın sayfa deneyimi sinyallerinde kullandığı saha verisini gösterir. Sıralamadaki ağırlığı içeriğin alaka düzeyinden düşüktür; bu yüzden hızı sıralama hilesi değil, ziyaretçiyi kaybetmeme işi olarak görüyorum. Teknik SEO tarafının tamamı için teknik SEO audit kontrol listemize bakabilirsiniz.

Birden fazla site, ERP entegrasyonu ve sunucu bir arada büyüdüyse sorun tek bir siteden büyüktür. O durumda altyapı değerlendirmesi için teknik danışmanlık daha doğru bir başlangıç olur.