Yavaş Site Teşhis Akışı: Nereden Başlamalı

"Site yavaş" cümlesi bir teşhis değil, bir semptomdur. Yavaş site sorunlarında en sık yapılan hata, elinin altındaki ilk araca sarılıp (genellikle bir hız testi sayfası) çıkan kırmızı maddeleri yukarıdan aşağıya düzeltmeye çalışmaktır. Oysa 3 saniyede açılan bir sayfanın 2,4 saniyesi sunucunun ilk baytı göndermesini beklemekle geçiyorsa, görselleri sıkıştırmak o sayfayı ancak 2,8 saniyeye indirir; harcadığın yarım günün karşılığı 200 milisaniye olur ve müşteri hâlâ "yavaş" diyor.

Bu rehberde teşhisi tahmine değil elemeye dayandıran bir akış kuracağız. Sırayla şunu yapacağız: yavaşlığın tanımını netleştirmek, bir sayfa yüklemesini ölçülebilir katmanlara ayırmak, tek bir curl komutuyla sorunun sunucuda mı tarayıcıda mı olduğunu kesinleştirmek, sonra da o katmanın içine inip gerçek darboğazı bulmak. Akışın sonunda "nereden başlamalı" sorusu senin için bir refleks hâline gelecek ve her yavaşlık şikâyetinde aynı beş dakikalık rutini işleteceksin.

Teşhise Başlamadan Önce Sorman Gereken Dört Soru#

Ölçmeye başlamadan önce problemi sınırlandırmak, teşhis süresini yarıya indirir. Çünkü "yavaş" kelimesi kullanıcının ağ bağlantısından tarayıcı eklentisine, tek bir raporlama sayfasından tüm siteye kadar çok farklı şeyleri kastediyor olabilir. Şikâyeti getiren kişiye ya da kendi kendine şu dört soruyu sor ve cevapları bir yere yaz.

Dördüncü soru en değerlisidir ve çoğu zaman atlanır. "Geçen salıdan beri" cevabı alıyorsan, teşhisin büyük kısmı zaten bitmiştir: o salı ne değişti sorusunun cevabı sorunun kendisidir. Sürüm geçmişine, eklenti güncelleme kayıtlarına ve sunucu paket güncellemelerine bak. Eğer yavaşlık sadece belirli saatlerde ortaya çıkıyorsa akışın geri kalanını uygulamadan önce site belirli saatlerde yavaşlıyor yazısındaki desen doğrulama adımlarını uygula; zamana bağlı bir sorunu rastgele bir anda ölçmek yanıltıcı sonuç verir.

Bir Sayfa Yüklemesinin Katmanları#

Bir sayfanın açılması tek bir olay değil, art arda dizilmiş altı aşamadır. Her aşamanın kendi süresi, kendi olası suçlusu ve kendi ölçüm aracı vardır. Teşhis akışının tamamı aslında "bu altı kutudan hangisi şişmiş" sorusunu cevaplamaktan ibarettir.

Bu tabloyu ezberlemene gerek yok ama mantığını içselleştir: ilk üç katman ağ ve altyapıya, dördüncü katman sunucuya, son iki katman ön yüze aittir. Teşhisin ilk hamlesi bu üç bölgeden hangisinde olduğunu bulmaktır; gerisi detaydır. Buradaki tek gerçekten belirsiz kutu TTFB'dir, çünkü hem sunucunun kendi işlem süresini hem de sunucuya gidip gelen ağ süresini içerir. Bu yüzden bir sonraki adımda TTFB'yi bileşenlerine ayıracağız.

Adım 1: curl ile Zaman Dökümü Al#

Tarayıcı geliştirici araçları güzeldir ama sonucu eklentiler, önbellek ve oturum çerezleri kirletir. Temiz bir ilk ölçüm için curl en dürüst araçtır. Önce bir biçim dosyası hazırla:

# Zaman dökümü şablonunu bir kez oluştur
cat > /tmp/curl-format.txt <<'FMT'
   dns_cozumleme:  %{time_namelookup}s
   tcp_baglanti:   %{time_connect}s
   tls_elsikisma:  %{time_appconnect}s
   istek_gonderdi: %{time_pretransfer}s
   ilk_bayt_ttfb:  %{time_starttransfer}s
   ------------------------------
   toplam:         %{time_total}s
   http_kodu:      %{http_code}
   indirilen_bayt: %{size_download}
FMT

Sonra ölçmek istediğin adresi çalıştır. Değerler kümülatiftir; yani ilk_bayt_ttfb değeri kendinden öncekileri de içerir.

# Önbelleği atlamak için rastgele bir sorgu parametresi ekle
curl -w "@/tmp/curl-format.txt" -o /dev/null -s "https://firmaniz.com/?nocache=$(date +%s)"

Tipik bir sağlıklı çıktı şuna benzer:

   dns_cozumleme:  0.021s
   tcp_baglanti:   0.048s
   tls_elsikisma:  0.112s
   istek_gonderdi: 0.112s
   ilk_bayt_ttfb:  0.298s
   ------------------------------
   toplam:         0.341s
   http_kodu:      200
   indirilen_bayt: 68412

Burada gerçek sunucu işlem süresi ilk_bayt_ttfb - istek_gonderdi farkıdır: yukarıdaki örnekte 186 ms. Bu tek çıkarma işlemi, teşhisin en değerli sayısıdır çünkü ağ gecikmesini denklemden çıkarır. Ölçümü en az beş kez tekrarla ve en kötü değere bak; tek ölçüm bir istatistik değil, bir anekdottur. Aynı komutu sunucunun kendi üzerinden localhost'a karşı da çalıştırırsan ağ payını tamamen sıfırlarsın:

# Sunucunun içinden, ağ gecikmesi olmadan saf uygulama süresi
curl -w "%{time_starttransfer}\n" -o /dev/null -s -H "Host: firmaniz.com" http://127.0.0.1/

Adım 2: Sunucu mu, Ön Yüz mü Karar Ver#

Elde iki sayı var: saf sunucu süresi ve toplam süre. Karar kuralı basittir ve bu akışın kalbidir.

1. Saf sunucu süresi 600 ms'den büyükse sorun sunucudadır. Adım 3'e geç, ön yüzle şimdilik hiç ilgilenme.
2. Saf sunucu süresi 200 ms'nin altında ama kullanıcı hâlâ yavaş diyorsa sorun ön yüzdedir. Adım 4'e geç.
3. İkisi de makul ama toplam süre yüksekse sorun ağ katmanında ya da coğrafyadadır. Adım 5'e geç.
4. Sunucu süresi ölçümden ölçüme 100 ms ile 4 saniye arasında zıplıyorsa kaynak doygunluğu ya da komşu etkisi vardır; sabit bir darboğaz aramayı bırak, zaman serisi kur.

Dördüncü madde en çok atlanan durumdur. Kararsız bir TTFB, yavaş bir TTFB'den daha kötü bir işarettir çünkü tekrarlanabilir değildir ve klasik profil çıkarma yöntemleri onu yakalayamaz. Böyle bir tabloda doğrudan sunucu yanıt süresi izleme kurulumuna geçip birkaç saatlik veri toplaman, tek tek komut çalıştırmaktan çok daha hızlı sonuç verir.

Adım 3: Sunucu Tarafını Daraltmak#

Sunucu tarafı da kendi içinde katmanlıdır: sistem kaynakları, web sunucusu, uygulama (PHP) ve veritabanı. Sırayla yukarıdan aşağı in, çünkü doygun bir sistemde alt katmanların ölçümleri de bozulur.

Önce sistem kaynaklarına bak. uptime ile yük ortalamasını al, çekirdek sayısına böl ve top içinde wa (iowait) sütununu kontrol et. Yük yüksek ama CPU boştaysa problem diskte ya da ağ beklemesindedir; bu ayrımı doğru yapmak için load average nasıl okunur yazısındaki normalizasyon yöntemini kullan.

# Anlık kaynak fotoğrafı
uptime
nproc                      # çekirdek sayısı
vmstat 1 5                 # r, b, wa sütunlarına bak
df -h                      # dolu disk her şeyi yavaşlatır
free -m                    # swap kullanımı varsa RAM darboğazı

Sistem sağlıklıysa uygulama katmanına in. PHP-FPM kullanıyorsan yavaş istek günlüğünü açmak, hangi dosyanın hangi satırında takıldığını doğrudan gösterir:

; /etc/php/8.2/fpm/pool.d/www.conf
slowlog = /var/log/php-fpm-slow.log
request_slowlog_timeout = 3s
; Havuz doygunluğunu görmek için durum sayfasını da aç
pm.status_path = /fpm-status

Sonra veritabanına bak. Yavaş sorgu günlüğü, PHP profilleyicilerinin çoğundan daha hızlı sonuç verir:

-- Oturum bazında yavaş sorguları yakala
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

-- Şu anda takılı olan sorguları anlık gör
SHOW FULL PROCESSLIST;

Son olarak önbellek katmanının gerçekten çalışıp çalışmadığını doğrula. Bir sayfanın önbellekten mi üretildiğini yanıt başlıklarından anlarsın; nginx tarafında X-Cache-Status başlığı HIT demiyorsa her istek uygulamaya kadar iniyor demektir. Bu durumda önce nginx FastCGI cache yapılandırması ya da uygulama düzeyinde LiteSpeed Cache kurulumunu düzelt; tek bir doğru önbellek ayarı, günlerce sürecek sorgu optimizasyonundan daha fazla kazandırır.

Adım 4: Ön Yüz Tarafını Daraltmak#

Sunucu 200 ms'de cevap veriyorsa ama sayfa 5 saniyede açılıyorsa, kaybedilen zamanın tamamı tarayıcının içindedir. Burada bakılacak üç şey vardır: indirilen toplam ağırlık, engelleyen kaynaklar ve üçüncü taraf betikler.

Ağırlık tarafı ölçülmesi en kolay olanıdır. Tarayıcı geliştirici araçlarında Network sekmesini aç, önbelleği devre dışı bırak ve sayfayı yenile; alt bardaki toplam transfer boyutuna ve istek sayısına bak. 4 MB'ın üzerindeki bir sayfa, mobil bağlantıda hiçbir sunucu optimizasyonuyla kurtarılamaz. Makul hedefler için ideal sayfa ağırlığı yazısındaki bütçe tablosunu referans al.

Engelleyen kaynaklar tarafında aradığın desen şudur: head içinde duran, async ya da defer taşımayan betikler ve gereğinden fazla yazı tipi dosyası. En büyük içerik ögesinin ne zaman çizildiğini ve neyin geciktirdiğini bulmak için LCP nasıl iyileştirilir yazısı adım adım yöntemi veriyor; sayfa yüklenirken içerik zıplıyorsa CLS düzen kayması tarafına da bakman gerekir.

Üçüncü taraf betikler en sinsi kalemdir çünkü senin sunucunda değildirler ve hız testlerinde bazen hiç görünmezler. Sohbet widget'ları, ısı haritası araçları, reklam etiketleri ve yazı tipi CDN'leri tek tek küçük ama toplamda ana iş parçacığını kilitleyecek kadar büyüktür. Hepsini geçici olarak devre dışı bırakıp ölçümü tekrarlamak, hangisinin ne kadar maliyetli olduğunu beş dakikada gösterir.

Adım 5: Ağ, CDN ve Coğrafya Katmanı#

Sunucu ve ön yüz temizse geriye aradaki yol kalır. Burada ilk kontrol edeceğin şey, ölçümü nereden yaptığındır. Sunucun İstanbul'da, sen Frankfurt'tan test ediyorsan ölçtüğün gecikmenin bir kısmı fiziktir ve hiçbir yazılım ayarıyla düzelmez. Farklı konumlardan gelen kullanıcıların gerçekten ne yaşadığını görmek için sentetik testler yerine RUM gerçek kullanıcı ölçümü verisine bakmak gerekir.

Önünde bir CDN varsa teşhis biraz karmaşıklaşır çünkü artık iki sunucu vardır: kenar düğüm ve senin sunucun. Kenar düğümün önbellekten mi cevap verdiğini, yoksa her seferinde kaynağa mı gittiğini yanıt başlıklarından doğrula:

# Cloudflare arkasında önbellek durumunu ve kenar düğümü gör
curl -sI "https://firmaniz.com/" | grep -Ei "cf-cache-status|cf-ray|server|age"

cf-cache-status: DYNAMIC görüyorsan hiçbir şey önbelleklenmiyor ve CDN sana yalnızca ek bir atlama noktası maliyeti çıkarıyor demektir. Kaynak sunucuya erişimle ilgili aralıklı hatalar alıyorsan Cloudflare 520, 521, 522 hataları yazısındaki eşleştirme tablosu hangi tarafın sustuğunu söyler. CDN'in genel olarak senin senaryonda kazandırıp kazandırmayacağı ayrı bir tartışma; CDN mi daha iyi hosting mi karşılaştırması bu kararı verirken işine yarar.

Teşhiste Sık Yapılan Hatalar#

En pahalı hata, tek bir ölçüme dayanarak karar vermektir. Sunucular arka planda yedek alır, günlük döndürür, güncelleme indirir; tek bir zamanlama denk gelirse tamamen sağlıklı bir sistemi hasta sanabilirsin. Her ölçümü en az beş kez tekrarla ve dağılıma bak.

İkinci hata kendi oturumunla test etmektir. Yönetici olarak giriş yapmış bir tarayıcıda çoğu önbellek katmanı devre dışı kalır ve sayfa her zaman en yavaş hâliyle üretilir. Ölçümü mutlaka gizli sekmede ya da curl ile, oturum çerezi olmadan yap.

Üçüncü hata birden fazla değişikliği aynı anda uygulamaktır. Önbelleği açıp, PHP sürümünü yükseltip, görselleri sıkıştırıp sonra "düzeldi" demek hiçbir bilgi üretmez; bir sonraki sefer aynı sorun geldiğinde yine sıfırdan başlarsın. Tek seferde tek değişiklik yap, ölç, kaydet.

Dördüncü hata semptomu ölçüp nedeni ölçmemektir. Yüksek load average bir neden değil, sonuçtur. "Load 12'ye çıktı, CPU aldım" kararı, aslında disk beklemesinden kaynaklanan bir sorunu daha pahalı bir sunucuda aynen yaşamana yol açar.

Son olarak, teşhis bitmeden optimizasyona başlama. Kontrol listesi çalıştırmak teşhisin yerine geçmez; ancak darboğazı bulduktan sonra site hızı optimizasyonu kontrol listesi sana o katmanda ne yapılacağını sırayla verir.

Sıkça Sorulan Sorular#

Yavaş site teşhisi ne kadar sürer#

Doğru akışla ilerlersen sorunun hangi katmanda olduğunu 10–15 dakikada belirlersin. Zaman alan kısım teşhis değil, düzeltmedir. Katmanı bulduktan sonra sunucu tarafı sorunları genelde birkaç saat, ön yüz ve sayfa ağırlığı sorunları ise tema veya eklenti değişikliği gerektirdiği için birkaç güne yayılabilir. Aralıklı ortaya çıkan yavaşlıklarda ise en az 24 saatlik ölçüm verisi toplaman gerekir.

TTFB kaç milisaniye olmalı#

Dinamik bir sayfa için 200–400 ms arası iyi, 600 ms üstü ise incelenmesi gereken bir değerdir. Tam önbelleklenmiş statik bir sayfa 100 ms'nin altında dönmelidir. Ancak bu sayıyı yorumlarken ölçümü nereden yaptığını hesaba kat: aynı kıtadan yapılan bir ölçümle okyanus ötesinden yapılan ölçüm arasında 150 ms'lik bir fark tamamen normaldir ve sunucunla ilgili değildir.

Hız testi sonucu ile kullanıcıların şikâyeti neden uyuşmuyor#

Çünkü hız testleri sentetik ölçümdür: sabit bir konumdan, sabit bir cihaz profiliyle, tek seferlik yapılır. Gerçek kullanıcıların cihazları daha yavaş, ağları daha değişken ve oturum durumları farklıdır. İki dünya arasındaki farkı kapatmanın tek yolu gerçek kullanıcı ölçümüdür; sentetik test yalnızca bir laboratuvar referansı verir, saha gerçeğini vermez.

Sorunun eklentiden kaynaklandığını nasıl anlarım#

En hızlı yöntem ikili elemedir. Eklentilerin yarısını devre dışı bırak, ölç; sorun devam ediyorsa kalan yarıdaysa değil demektir, diğer yarıya geç. Beş altı adımda tek bir eklentiye inersin. Bunu canlı sitede yapamıyorsan bir kopya ortam kurup orada dene. Sunucu tarafında ise PHP yavaş istek günlüğü zaten hangi eklenti dosyasında takıldığını doğrudan yazar.

Sunucuyu büyütmek yavaşlığı çözer mi#

Sadece darboğaz gerçekten kaynak yetersizliğiyse çözer. CPU'su sürekli doygun ya da RAM yetmediği için sürekli takas alanına inen bir sunucuda büyütmek anında sonuç verir. Ancak yavaşlık indekssiz bir veritabanı sorgusundan, önbelleksiz bir yapılandırmadan ya da 6 MB'lık bir ana sayfadan geliyorsa daha büyük sunucu yalnızca faturayı büyütür; aynı sorun bir süre sonra geri gelir.

Teşhis sırasında canlı siteye zarar verir miyim#

Okuma amaçlı komutlar (curl, uptime, vmstat, SHOW PROCESSLIST) güvenlidir ve canlı sitede rahatça çalıştırılır. Dikkat etmen gereken iki şey var: yavaş sorgu günlüğünü çok düşük bir eşikle açıp unutursan disk dolabilir, ve önbelleği temizleme gibi işlemler kısa süreli bir yük artışı yaratır. Bu tür işlemleri trafiğin en düşük olduğu saatte yap ve değişiklikleri geri alabileceğin şekilde not et.

Kapanış#

Yavaş site teşhisinin özü tahmin etmeyi bırakıp elemeye geçmektir. Aklında kalması gereken dört alışkanlık şu: önce problemi tanımla (hangi sayfa, kimde, ne zaman, ne zamandan beri), sonra tek bir curl ölçümüyle sunucu ve ön yüz ayrımını kesinleştir, darboğazı bulmadan hiçbir optimizasyona başlama, ve her seferinde tek bir değişiklik yapıp ölçümü tekrarla. Bu dört adım, en karmaşık performans şikâyetlerini bile yönetilebilir parçalara böler.

Teşhis sonucunda darboğazın sunucu kaynaklarında olduğunu gördüysen ve mevcut paketin sınırına gelmişsen, tam root erişimli VDS ya da esnek ölçeklenen bulut sunucu seçenekleriyle ilerleyebilirsin. Sorun sunucuda değil de yapılandırmada çıktıysa ve bu işi kendin üstlenmek istemiyorsan sunucu yönetimi hizmetimiz izleme kurulumundan önbellek yapılandırmasına kadar tüm süreci devralır. Hızlı bir altyapıda temiz bir başlangıç arıyorsan web hosting ve WordPress hosting paketlerimiz önbellek katmanı hazır gelir.