Sitem Neden Yavaş Açılıyor? Suçluyu Bulmanın Yolu

"Sitem yavaş açılıyor" cümlesi bu işte en sık duyduğum şikâyet ve neredeyse her seferinde arkasında aynı hikâye var: kullanıcı bir hız testi çalıştırmış, kırmızı bir puan görmüş, hosting firmasına yazmış, "paketiniz yetersiz, üst pakete geçin" cevabını almış ve geçmiş. Sonra hiçbir şey değişmemiş. Değişmemesinin sebebi basit — yavaşlığın kaynağı ölçülmeden tahmin edildi. Web sitesi yavaşlığı nedenleri arasında sunucu yetersizliği sadece bir tanesi ve dürüst olmak gerekirse en sık rastlananı da değil. Çoğu vakada suçlu, ana sayfaya konulmuş 6-8 MB'lık bir kapak görseli, ya da başlıkta yüklenen sekiz ayrı JavaScript dosyasıdır.

Bu yazıda bir hız aracının size ne söylediğini tekrar etmeyeceğim. Onun yerine tek bir komutla — hiçbir eklenti kurmadan, hiçbir siteye üye olmadan — yavaşlığın sunucu tarafında mı yoksa tarayıcı tarafında mı olduğunu kesin biçimde ayırmayı göstereceğim. Bu ayrım yapıldıktan sonra yapılacak iş listesi otomatik olarak ikiye bölünür ve yanlış tarafa harcanan emek sıfıra iner. Yıllardır gördüğüm en pahalı hata, teşhis konmadan tedaviye başlamak; bu yazının tamamı o hatayı önlemek üzerine kurulu.

Yavaşlık Tek Bir Şey Değil: İki Ayrı Katman Var#

Bir sayfanın "açılması" arka arkaya gerçekleşen iki bağımsız işten oluşur ve bunlar farklı makinelerde çalışır. Birinci katman sunucu tarafıdır: tarayıcı isteği gönderir, sunucu PHP'yi çalıştırır, veritabanını sorgular, HTML'i üretir ve ilk baytı geri yollar. İkinci katman tarayıcı tarafıdır: gelen HTML okunur, içindeki CSS, JavaScript, font ve görsel dosyaları tek tek indirilir, sayfa çizilir.

Bu iki katmanın çözümleri ortak değildir. Sunucu tarafı yavaşsa CDN kurmak neredeyse hiçbir işe yaramaz — çünkü CDN önbelleğe alınabilen statik dosyaları hızlandırır, dinamik olarak üretilen HTML'i değil. Tarayıcı tarafı yavaşsa daha güçlü bir sunucuya geçmek de işe yaramaz — çünkü sunucu zaten işini 200 milisaniyede bitiriyor, kalan 6 saniye görsellerin inmesiyle geçiyor.

Türkçe içeriklerde bu ayrımın neredeyse hiç yapılmamasının sonucu şu: kullanıcı "hosting mi yavaş site mi" sorusuna cevap bulamadığı için, satın alması en kolay olan şeyi satın alıyor. Oysa cevap ölçülebilir bir şey ve ölçmesi otuz saniye sürüyor.

Tek Ölçümle Suçluyu Bulma: curl ile Zaman Kırılımı#

Yavaşlığın hangi katmandan geldiğini ayırt etmenin en temiz yolu curl'ün zaman değişkenlerini okumaktır; çünkü bu ölçüm tarayıcı, eklenti ve önbellekten tamamen bağımsızdır.

Önce bir biçim dosyası oluşturun:

cat > /tmp/curl-format.txt <<'EOF'
    dns_cozumleme:  %{time_namelookup}s
      tcp_baglanti:  %{time_connect}s
       tls_el_sikma:  %{time_appconnect}s
    istek_gonderimi:  %{time_pretransfer}s
        ilk_bayt_ttfb:  %{time_starttransfer}s
   ------------------------------
         toplam_sure:  %{time_total}s
      indirilen_boyut:  %{size_download} bayt
EOF

Sonra sitenizi ölçün:

curl -o /dev/null -s -w "@/tmp/curl-format.txt" https://ornek-site.com/

Tipik bir çıktı şuna benzer:

    dns_cozumleme:  0.024s
      tcp_baglanti:  0.061s
       tls_el_sikma:  0.132s
    istek_gonderimi:  0.132s
        ilk_bayt_ttfb:  1.874s
   ------------------------------
         toplam_sure:  1.902s
      indirilen_boyut:  84120 bayt

Bu çıktıyı okumanın kuralı tek cümle: ilk_bayt_ttfb ile istek_gonderimi arasındaki fark, sunucunun sayfayı üretmek için harcadığı süredir. Yukarıdaki örnekte 1,874 − 0,132 = 1,742 saniye. Yani sunucu, HTML'in ilk baytını yollamadan önce 1,7 saniye düşünmüş. Burada suçlu net biçimde sunucu tarafıdır ve görsellerle hiç ilgisi yoktur — zaten toplam indirilen boyut 84 KB, yani HTML'den ibaret.

Karşı örnek şöyle görünür:

        ilk_bayt_ttfb:  0.211s
         toplam_sure:  0.219s
      indirilen_boyut:  61340 bayt

Sunucu işini 80 milisaniyede bitirmiş. Buna rağmen tarayıcıda sayfa 7 saniyede açılıyorsa, o 7 saniyenin tamamı HTML geldikten sonraki aşamada, yani tarayıcı tarafında geçiyor demektir. Bu ölçümü aynı komutla üç-dört kez tekrarlayın; tek ölçüm bir anlık dalgalanmayı yakalayabilir. curl'ün diğer kullanımları için curl ile HTTP istekleri yazısı işinize yarar.

Sunucu Tarafı Yavaşsa: Gerçek Nedenler ve Sırası#

Sunucu üretim süresi 800 ms'nin üzerindeyse, aşağıdaki nedenler istatistiksel olarak bu sırayla karşınıza çıkar.

1. HTML önbelleği yok. Bir WordPress sayfası her istekte sıfırdan üretiliyorsa, 30-60 veritabanı sorgusu ve onlarca PHP dosyası her ziyaretçi için tekrar çalışır. Sayfa önbelleği devreye girdiğinde bu iş bir kez yapılır, sonrası hazır HTML servisidir. Çoğu vakada tek başına bu değişiklik üretim süresini 1,5 saniyeden 150 ms'ye indirir. Katmanları ve hangi eklentinin ne yaptığını WordPress önbellek rehberi yazısında ayrıntılı anlattık.
2. Eski PHP sürümü. PHP 7 ile modern sürümler arasında aynı kod için ciddi bir işlem farkı vardır ve bu fark ölçülebilir. Panelden sürüm yükseltmek çoğu zaman bedava bir kazançtır ve genelde tek bir açılır listeden yapılır.
3. OPcache kapalı. PHP dosyalarının derlenmiş hâli bellekte tutulmuyorsa, her istekte aynı dosyalar tekrar derlenir. PHP OPcache yapılandırması genelde birkaç satırlık bir iştir.
4. Şişmiş veritabanı. wp_options tablosundaki autoload kayıtları, birikmiş revizyonlar, geçici (transient) kayıtlar ve indekssiz sorgular üretim süresini sessizce büyütür. MySQL/MariaDB performans optimizasyonu tarafında yapılacak temizlik çoğu zaman fark ettirir.
5. Dışarıya giden yavaş istekler. Sayfanın içinde çalışan bir eklenti, sayfa üretilirken uzak bir API'ye bağlanıyor ve o API yavaşsa, sizin sayfanız o kadar bekler. Bu, kaynağı en zor bulunan gruptur; sunucu kaynakları boştur ama süre yüksektir.
6. Kaynak limiti doygunluğu. Paylaşımlı ortamda CPU veya eşzamanlı işlem limitine dayanıyorsanız istekler kuyruğa girer. Bunun işareti, yavaşlığın belirli saatlerde yoğunlaşmasıdır. Sınırların nasıl okunacağı paylaşımlı hosting kaynak limitleri yazısında; limit tamamen dolduğunda ise sayfa yavaşlamayı bırakıp doğrudan hata verir.

Bu maddelerin sırası tesadüf değil: yukarıdan aşağıya doğru hem uygulama maliyeti artar hem de kazanç ihtimali azalır. Önbellek olmadan PHP sürümüyle uğraşmak, delik teknede motor değiştirmeye benzer.

Tarayıcı Tarafı Yavaşsa: Ağırlık Nerede Birikiyor#

Sunucu 200 ms'de cevap veriyor ama sayfa hâlâ geç açılıyorsa, problem indirilen ve işlenen içeriktedir. Burada üç ayrı maliyet kalemi vardır ve karıştırılmamaları gerekir.

Bayt maliyeti. Toplam sayfa ağırlığı. En sık suçlu, telefonla çekilip doğrudan yüklenmiş görsellerdir: 4000×3000 piksel, 6 MB'lık bir JPEG, sitede 800 piksel genişliğinde gösterilir. Tarayıcı 6 MB'ı indirir, sonra küçültüp çizer. Aynı görsel doğru boyutta ve modern formatta 60-80 KB olabilir. Yani seksen kat. Bu tek maddeyi düzeltmek, çoğu sitede diğer bütün optimizasyonların toplamından fazla kazandırır; yöntem için WordPress görsel optimizasyonu yazısına bakın.

İstek maliyeti. Sayfanın kaç ayrı dosya çektiği. On beş eklenti kuruluysa, her biri kendi CSS ve JS dosyasını ekler ve sayfa 90 ayrı istek yapar. Her isteğin kendi gecikmesi vardır.

İşlem maliyeti. İndirilen JavaScript'in çalıştırılması. Bu, orta seviye bir telefonda masaüstünün birkaç katı sürer ve "bende hızlı açılıyor ama müşterim yavaş diyor" tablosunun asıl açıklamasıdır.

Bu üçünü ayırmanın pratik yolu, tarayıcının geliştirici araçlarında Ağ sekmesini açıp isteği boyuta göre sıralamaktır. Listenin en üstündeki üç-beş dosya, sayfanın gerçek ağırlığını taşıyanlardır. Genellikle o listede bir kapak görseli, bir slider kütüphanesi ve bir font ailesi bulunur. Bu üç dosyanın toplam boyutunu not edin; sayfa ağırlığının çoğu zaman yüzde yetmişinden fazlasını oluştururlar.

Sayfa Ağırlığını Komut Satırından Ölçmek#

Tarayıcı açmadan da kaba bir ağırlık ölçümü yapabilirsiniz. Aşağıdaki komut yalnızca HTML'i indirir ve boyutunu yazar:

curl -so /dev/null -w "HTML boyutu: %{size_download} bayt\n" https://ornek-site.com/

HTML'in kendisi 400 KB çıkıyorsa, orada bir sorun vardır — büyük ihtimalle sayfa oluşturucu (page builder) eklentisi satır içi CSS basıyordur. Sağlıklı bir HTML genelde 30-120 KB arasındadır.

Sıkıştırmanın açık olup olmadığını da tek satırda görebilirsiniz:

curl -sI -H "Accept-Encoding: gzip, br" https://ornek-site.com/ | grep -i content-encoding

Çıktı boşsa metin dosyaları sıkıştırılmadan gönderiliyor demektir; bu, HTML/CSS/JS için üç-dört kat gereksiz trafik anlamına gelir. Sıkıştırmayı açmak sunucu tarafında birkaç satırlık bir yapılandırmadır ve etkisi hemen ölçülür.

İlk Ziyaret mi, Tekrar Ziyaret mi: Önbellek Yanılgısı#

Site sahiplerinin kendi sitelerini yavaş bulmamasının bir numaralı sebebi budur. Siz sitenizi günde on kez açarsınız; tarayıcınızda bütün görseller, fontlar ve script'ler zaten önbellektedir. İkinci ziyarette sayfa 400 ms'de açılır. Yeni gelen bir ziyaretçi ise her şeyi sıfırdan indirir ve 7 saniye bekler.

Ölçüm yaparken bu farkı ortadan kaldırmanın yolu, gizli pencere kullanmak değil — gizli pencere de oturum boyunca önbellek tutar. Doğru yöntem, geliştirici araçları açıkken Ağ sekmesindeki "önbelleği devre dışı bırak" seçeneğini işaretlemek ve sayfayı öyle yenilemektir. Böylece her istek gerçekten ağdan gider.

Aynı yanılgının bir başka biçimi de sunucu tarafında yaşanır: sayfa önbelleği eklentisi kuruluysa, ilk isteğiniz önbelleği ısıtır, ikinci isteğiniz hazır dosyayı alır. curl ölçümünü peş peşe yaptığınızda ikinci ve üçüncü sonucun birdenbire düşmesi bunun işaretidir ve aslında iyi haberdir — önbellek çalışıyor demektir. Kötü haber, ilk ziyaretçinin o ısıtma maliyetini ödemesidir.

"Bende Hızlı Açılıyor" Tuzağı: Konum, Ağ ve Cihaz#

Ölçüm yaptığınız yer sonucu doğrudan değiştirir. Sunucunuz Türkiye'deyse ve siz Türkiye'den ölçüyorsanız, ağ gecikmesi 10-30 ms civarındadır. Aynı sitenin yurt dışından ölçümünde bu sayı 150 ms'ye çıkar ve TTFB'nizin üstüne eklenir — sunucunuzda hiçbir şey değişmemiştir. Bu yüzden farklı iki konumdan alınan iki rakamı karşılaştırıp "sunucu yavaşladı" demek yanlıştır.

Bunu ayırmak için curl çıktısındaki tcp_baglanti değerine bakın: bu, sunucuya erişmenin saf ağ maliyetidir ve sunucunun iş yüküyle ilgisi yoktur. tcp_baglanti 0,15 sn, ilk_bayt_ttfb 0,20 sn ise sunucunuz aslında 50 ms'de cevap veriyor demektir; kalan her şey mesafedir. Aynı ölçümü farklı bir ağdan (örneğin mobil veriden) tekrarlayıp iki tcp_baglanti değerini karşılaştırmak, gecikmenin sizin bağlantınızdan mı yoksa sunucudan mı geldiğini net biçimde gösterir.

Cihaz farkı da aynı ölçüde gerçektir. Masaüstünde 1 saniyede çalışan bir JavaScript paketi, birkaç yıllık bir Android telefonda 4-5 saniye sürebilir. "Müşterilerim yavaş diyor ama bende iyi" cümlesinin arkasında neredeyse her zaman bu vardır.

Müdahale Sırası: Önce Hangisi#

Teşhis konduktan sonra sıra önemlidir, çünkü bazı müdahaleler diğerlerinin etkisini ölçmeyi imkânsızlaştırır. Önerdiğim sıra şudur:

1. Ölçümü kaydedin. Müdahaleden önceki curl çıktısını bir yere yazın. Karşılaştıracak bir başlangıç noktanız yoksa "iyileşti" demeniz sadece bir histir.
2. Tek seferde tek değişiklik yapın. Aynı gün hem önbellek eklentisi kurup hem PHP sürümünü değiştirip hem CDN açarsanız, hangisinin işe yaradığını asla bilemezsiniz — ve biri sorun çıkarırsa hangisi olduğunu da bulamazsınız.
3. Sunucu tarafındaysanız sırayla: sayfa önbelleği → PHP sürümü → OPcache → veritabanı temizliği.
4. Tarayıcı tarafındaysanız sırayla: en büyük üç görsel → gereksiz eklenti/script → geç yükleme (lazy load) → font sadeleştirme.
5. Her adımdan sonra tekrar ölçün. Ölçüm yapmadan geçilen her adım, sonraki adımın sonucunu kirletir.

Geç yüklemeyi uygularken tek bir istisnayı unutmayın: ilk ekranda görünen ana görsele geç yükleme koymayın. O görselin ertelenmesi ilk izlenimi iyileştirmek yerine doğrudan kötüleştirir.

Paket Yükseltmesi Ne Zaman Gerçekten Çözümdür#

Paket yükseltmek bazen gerçekten doğru cevaptır ve bunu ayırt etmenin ölçülebilir işaretleri vardır. Sunucu üretim süreniz gündüz saatlerinde 1,5 saniyeye çıkıp gece 300 ms'ye düşüyorsa, önbellek zaten açıksa, PHP güncelse ve veritabanı bakımlıysa — evet, kaynak sıkışması yaşıyorsunuz. Aynı şekilde site içi arama, sepet, üyelik paneli gibi önbelleğe alınamayan sayfalarınız yoğunsa, iş yükünüz paylaşımlı ortamın doğasına aykırıdır.

Bu tabloya uyuyorsanız, kaynakları izole eden bir yapıya geçmek gerçekten kalıcı bir kazançtır. Uymayan durumda ise yükseltme, 6 MB'lık kapak görselini 0,2 saniye daha erken indirmenizi sağlar; o kadar. Hangi barındırma modelinin hangi yüke uygun olduğunu web hosting türleri yazısında karşılaştırmalı olarak anlattık. Site tamamen açılmıyorsa bu bir hız değil erişim sorunudur; o durumda site açılmıyor ne yapmalı yazısındaki adımlar daha uygundur.

Sıkça Sorulan Sorular#

Sitem yavaş açılıyor, ilk olarak neye bakmalıyım#

İlk bakılacak şey sunucunun ilk baytı kaç saniyede gönderdiğidir. curl -o /dev/null -s -w "%{time_starttransfer}\n" https://siteniz.com/ komutunu çalıştırın; sonuç 1 saniyenin üzerindeyse sorun sunucu tarafında, 0,3 saniyenin altındaysa tarayıcı tarafındadır. Bu tek rakam, yapılacak işler listesini ikiye böler ve yanlış tarafa harcanacak emeği ortadan kaldırır. Ölçümü peş peşe üç kez tekrarlayıp ortalamasına bakın, çünkü tek ölçüm anlık bir dalgalanmayı yakalayabilir.

Hosting mi yavaş yoksa sitem mi yavaş nasıl anlarım#

Sunucunun ürettiği HTML'in ilk baytı hızlı geliyorsa hosting suçlu değildir. Ölçümde time_starttransfer değerinden time_pretransfer değerini çıkarın; kalan süre sunucunun sayfayı üretmek için harcadığı zamandır. Bu fark 200 ms civarındaysa sunucu işini yapıyor demektir ve yavaşlık indirilen görsellerden, script'lerden veya temadan geliyordur. Aynı sunucudaki boş bir HTML dosyasını ölçüp karşılaştırmak da net bir kontrol sağlar.

Hız testi her seferinde farklı sonuç veriyor, hangisi doğru#

Farklı sonuç vermesi normaldir ve tek bir ölçüm doğru kabul edilmemelidir. Test aracının ölçüm yaptığı konum, o andaki ağ trafiği, sunucunun o an başka bir işle meşgul olup olmaması ve önbelleğin ısınmış olup olmaması sonucu değiştirir. Doğru yaklaşım, aynı koşullarda üç-beş ölçüm alıp ortancasına bakmak ve asıl karşılaştırmayı müdahale öncesi ile sonrası arasında yapmaktır. Mutlak rakamın peşine düşmek yerine kendi geçmiş ölçümünüzle kıyaslayın.

Görselleri sıkıştırmak gerçekten fark eder mi#

Çoğu sitede en büyük tek kazanç görsellerden gelir. Doğru boyuta indirilmemiş bir fotoğraf 4-6 MB olabilirken, aynı görselin gösterildiği genişlikte ve modern formatta karşılığı 60-100 KB civarındadır; bu, sayfa ağırlığında onlarca kat azalma demektir. Özellikle mobil ziyaretçilerde indirme süresi doğrudan bekleme süresine dönüştüğü için etkisi hemen hissedilir. Sıkıştırmadan önce mutlaka boyutlandırma yapın, çünkü 4000 piksellik bir görseli sıkıştırmak onu hâlâ gereğinden büyük bırakır.

CDN kullanmak yavaş siteyi hızlandırır mı#

CDN yalnızca statik dosyaların coğrafi mesafesini kısaltır, sunucunuzun sayfa üretim süresini kısaltmaz. Ziyaretçileriniz sunucunuza uzaksa ve sayfanız çok sayıda görsel/CSS/JS içeriyorsa gözle görülür fayda sağlar. Ancak sorun yüksek sunucu üretim süresiyse, CDN devreye girdiğinde ilk bayt hâlâ aynı gecikmeyle gelir ve neredeyse hiçbir şey değişmez. Bu yüzden CDN kararı, ölçümden önce değil sonra verilmelidir.

Eklenti sayısı azaltmak siteyi hızlandırır mı#

Eklenti sayısının kendisi değil, eklentilerin ne yaptığı belirleyicidir. Ön yüze CSS ve JavaScript ekleyen, her sayfa yüklemesinde veritabanı sorgusu çalıştıran veya dışarıya istek gönderen eklentiler ölçülebilir maliyet yaratır; yalnızca yönetici panelinde çalışan bir eklentinin ziyaretçiye maliyeti sıfıra yakındır. Doğru yöntem, eklentileri teker teker devre dışı bırakıp her seferinde ölçüm almak ve süreyi gerçekten değiştireni bulmaktır. Toplu şekilde "yarısını sildim" demek, hangi kazancın nereden geldiğini asla göstermez.

Paket yükseltmeden önce hangi kontrolleri yapmalıyım#

Yükseltmeden önce sayfa önbelleğinin açık, PHP sürümünün güncel, veritabanının bakımlı ve görsellerin optimize edilmiş olduğundan emin olun. Bu dördü tamamsa ve sunucu üretim süreniz hâlâ yoğun saatlerde belirgin biçimde yükseliyorsa, gerçekten kaynak sıkışması yaşıyorsunuz demektir. Yükseltme kararını destekleyen en güçlü kanıt, aynı sitenin gece ölçümü ile gündüz ölçümü arasındaki büyük farktır. Bu fark yoksa, daha güçlü bir paket aynı yavaşlığı daha pahalıya sunar.

Kapanış#

Site hızlandırma işi teknik bir konu gibi görünse de aslında bir teşhis disiplinidir. Elinizde curl'ün beş satırlık çıktısı varsa, "sitem yavaş açılıyor" belirsiz bir şikâyet olmaktan çıkıp ölçülebilir bir soruna dönüşür: ya sunucu geç düşünüyordur, ya tarayıcı çok şey indiriyordur. Bu ikisi aynı anda da olabilir, ama hangisinin ne kadar payı olduğunu bilmeden yapılan her müdahale kumar olur. Ölçün, tek değişiklik yapın, tekrar ölçün — bu üç adım, bu işte okuyabileceğiniz bütün ipucu listelerinden daha değerlidir.

Ölçüm sonucu sunucu tarafını işaret ediyorsa ve mevcut ortamınız yükünüzü kaldırmıyorsa, kaynakları izole eden bir yapıya geçmek kalıcı çözümdür; VDS sunucu ve performans sunucu paketleri tam olarak bu ihtiyaç için var. WordPress tarafında önbellek, PHP ve veritabanı bakımıyla tek tek uğraşmak istemiyorsanız WordPress hosting paketleri bu ayarları hazır getirir; ölçüm ve iyileştirme sürecini tamamen devretmek isterseniz sunucu yönetimi hizmeti bu işi üstlenir.