Web Sitesi Neden Yavaş? Teşhis ve Çözüm Yolları

Bir kullanıcının sayfanızı terk etmesine neden olan performans kayıpları nadiren tek bir hatadan doğar. Çoğu senaryoda web sitesi yavaş açılıyor şikayetinin arkasında yüksek sunucu yanıt süresi (TTFB), optimize edilmemiş görsel varlıkları, tarayıcıyı kilitleyen üçüncü taraf JavaScript dosyaları ve yetersiz yapılandırılmış önbellek mekanizmaları birlikte yer alır. Sorunu kalıcı olarak çözmenin ilk adımı, tahmin yürütmek yerine performans darboğazının kaynağını somut verilerle ölçmektir.

Hızlı Çözüm / Özet Adımlar (TL;DR)
1. Ölçüm Yapın: PageSpeed Insights veya WebPageTest üzerinden sitenizi test ederek ilk bayt süresi (TTFB) ile görsel yükleme sürelerini birbirinden ayırın.
2. Medya ve Kod Yükünü Hafifletin: Görsellerinizi yeni nesil WebP/AVIF formatlarına dönüştürün, harici script'leri defer veya async ile erteleyin.
3. Önbelleği ve CDN'i Devreye Alın: Sayfa düzeyinde sunucu önbelleği (page caching) ve statik varlıklar için küresel bir CDN ağı kurarak sunucu üzerindeki PHP/veritabanı yükünü sıfırlayın.

Yavaşlığı Ölçmeden Önce Doğru Metrikleri Anlayın

Performans iyileştirme sürecine girmeden önce, tarayıcının bir web sayfasını nasıl işlediğini ve hangi metriğin hangi aşamayı temsil ettiğini bilmek gerekir. Google'ın Core Web Vitals standartları, kullanıcı deneyimini üç temel eksende değerlendirir: yükleme hızı, görsel kararlılık ve etkileşim gecikmesi.

• TTFB (Time to First Byte): Tarayıcının sunucuya gönderdiği ilk HTTP isteği ile sunucudan gelen ilk veri baytı arasındaki süredir. Doğrudan barındırma kalitesini, DNS çözümlemesini ve arka uç (backend) verimliliğini yansıtır. İdeal olarak 800 ms altında, tercihen 200–400 ms aralığında olmalıdır.
• LCP (Largest Contentful Paint): Sayfadaki en büyük görsel veya metin bloğunun ekranda görünür hale gelme süresidir. Google standartlarına göre iyi bir kullanıcı deneyimi için LCP değerinin 2,5 saniye veya altında kalması hedeflenir.
• CLS (Cumulative Layout Shift): Sayfa yüklenirken öğelerin beklenmedik şekilde yer değiştirmesini ölçer. Reklamların sonradan yüklenmesi veya boyutları belirtilmemiş görseller bu değeri bozar. Kabul edilebilir sınır 0,1 veya altıdır.
• INP (Interaction to Next Paint): Kullanıcının sayfadaki bir düğmeye basması veya bir formu doldurması sonrasında tarayıcının bir sonraki kareyi ekrana çizme süresidir. 200 ms altında olması gerekir.

Google PageSpeed Insights ve Google Search Console üzerindeki Core Web Vitals raporlarını incelerken "Laboratuvar Verileri" (simüle edilmiş ortam) ile "Alan Verileri" (Chrome kullanıcılarından toplanan gerçek 28 günlük veri) arasındaki farkı gözetmelisiniz. Bu değerlerin teknik hesaplama detayları ve eşik sınırları hakkında daha kapsamlı bilgi edinmek için LCP ve CLS değerleri rehberi içeriğimizi inceleyebilirsiniz.

Sunucu Kaynaklı Yavaşlık: TTFB Neden Yüksek?

Tarayıcı bir adresi talep ettiğinde, sunucu işletim sistemi düzeyinde bu isteği karşılar, web sunucusu (Nginx/Apache) aracılığıyla PHP işlemcisine aktarır, PHP gerekli veritabanı sorgularını MySQL/MariaDB üzerinden çalıştırır ve nihai HTML çıktısını derleyip istemciye geri gönderir. Bu zincirin herhangi bir halkasında yaşanan tıkanıklık yüksek TTFB olarak karşımıza çıkar.

Paylaşımlı hosting paketlerinde CPU ve RAM kaynakları yüzlerce farklı web sitesiyle ortak kullanılır. Komşu bir sitenin aşırı kaynak tüketmesi, sizin sitenizin PHP isteklerinin kuyrukta beklemesine yol açar. Benzer şekilde, eski bir PHP sürümü (örneğin PHP 7.4) kullanmak, modern PHP 8.2 veya 8.3 sürümlerine kıyasla işlem başına iki kata varan bellek tüketimi ve işlem süresi kaybı yaratır.

Veritabanı katmanında ise yıllar içinde biriken revizyon kayıtları, temizlenmemiş geçici veriler (transients), yetersiz indekslenmiş tablolar ve optimize edilmemiş sorgular ana darboğazı oluşturur. Tek bir sayfa yüklemesinde 150 farklı SQL sorgusu çalışıyorsa, donanım ne kadar güçlü olursa olsun sunucu yanıtı gecikir. Bu noktada Object Cache (Redis veya Memcached) devreye girer. Object Cache, sık tekrarlanan veritabanı sorgu sonuçlarını doğrudan RAM bellekte tutarak disk okuma operasyonlarını ve CPU yükünü ortadan kaldırır. Sayfa önbelleği (page cache) ise dinamik PHP çıktısını statik bir HTML dosyası olarak saklar; böylece sunucu her yeni ziyarette PHP motorunu yeniden çalıştırmak zorunda kalmaz.

Görsel ve Medya Yükü

Web sayfalarının toplam bayt ağırlığının büyük kısmını medya dosyaları oluşturur. Doğrudan fotoğraf makinesinden veya stok sitelerinden indirilen 3000 piksel genişliğinde ve 4-5 MB boyutundaki JPEG dosyalarını sayfaya yüklemek, mobil ağlarda ciddi bir bant genişliği darboğazı yaratır.

Görsellerin modern sıkıştırma standartlarına sahip WebP veya AVIF formatlarına dönüştürülmesi, görsel kalitesinde gözle görülür bir kayıp olmadan dosya boyutunu %30 ile %70 arasında düşürür. Bunun yanında görsel optimizasyonunda şu teknik gereksinimler uygulanmalıdır:

• Lazy Load (Gecikmeli Yükleme): Ekranın ilk açılış alanında (above-the-fold) yer almayan tüm görsellere loading="lazy" niteliği atanmalıdır. Böylece tarayıcı, kullanıcı sayfayı aşağı kaydırmadıkça bu varlıkları indirmez. Ancak LCP öğesi olan ana banner veya manşet görseline kesinlikle lazy load uygulanmamalı, aksine fetchpriority="high" ile önceliklendirilmelidir.
• Boyut Nitelikleri (Width & Height): HTML içerisinde <img> etiketlerine genişlik ve yükseklik değerleri açıkça girilmelidir. Boyutları tanımlanmamış görseller yüklendiği anda sayfa düzenini aşağı iterek CLS skorunu doğrudan kırmızıya çeker.
• Duyarlı Görseller (srcset): Mobil cihaz kullanan bir ziyaretçiye masaüstü çözünürlüğündeki 1920px genişliğindeki görseli göndermek yerine, ekran genişliğine uygun varyasyonları srcset niteliğiyle sunmak veri transferini minimize eder.

JavaScript, CSS ve Üçüncü Taraf Scriptler

Bir web tarayıcısı HTML belgesini yukarıdan aşağıya doğru okurken harici bir <script> veya <link rel="stylesheet"> etiketiyle karşılaştığında, bu dosyayı indirip çalıştırana kadar DOM inşasını durdurur. Bu durum render-blocking (oluşturmayı engelleyen) kaynaklar olarak adlandırılır.

Kritik olmayan JavaScript dosyalarının yürütülmesi iki yöntemle düzenlenir:

1. async: Dosya arka planda indirilir ve indiği anda mevcut HTML ayrıştırması kesilerek script çalıştırılır. Birbirine bağımlı olmayan analiz araçları için uygundur.
2. defer: Dosya arka planda indirilir ancak HTML belgesinin tamamen ayrıştırılması (DOM parsing) tamamlandıktan sonra sırayla çalıştırılır. Sayfa işleyişine müdahale eden kütüphaneler için en güvenli yoldur.

Bunun yanında Google Analytics, Facebook Pixel, Hotjar, harici sohbet araçları (Live Chat) ve Google Fonts gibi üçüncü taraf kaynaklar her ziyaretçide harici DNS çözümlemeleri, SSL el sıkışmaları ve ek HTTP istekleri yaratır.

Aşağıdaki tablo, varlık türlerinin performans üzerindeki etkisini ve teşhis yöntemlerini özetlemektedir:

Önbellek ve CDN Katmanı

Web performansında en hızlı istek, sunucuya hiç ulaşmayan istektir. Önbellekleme stratejisi üç ayrı katmanda çalışmalıdır:

1. Tarayıcı Önbelleği (Browser Cache): HTTP yanıt başlıklarında Cache-Control: max-age=31536000, immutable gibi yönergeler tanımlanarak logo, CSS, JavaScript gibi nadiren değişen statik dosyaların ziyaretçinin cihazında saklanması sağlanır. Tekrar eden ziyaretlerde bu varlıklar yerel diskten yüklenir.
2. Sunucu Düzeyinde Sayfa Önbelleği: Ziyaretçiye sunulan dinamik sayfalar bir kez derlendikten sonra sunucu diskinde veya RAM belleğinde saklanır. Bir sonraki istek doğrudan bu hazır dosya ile karşılanır. Nginx FastCGI Cache, LiteSpeed Cache veya Apache mod_cache bu katmanda yer alır.
3. CDN (Content Delivery Network): Sayfa varlıklarının coğrafi olarak ziyaretçiye en yakın sunucudan dağıtılmasını sağlar. Türkiye'deki bir kullanıcının Almanya veya Amerika'daki bir sunucudan dosya çekmesi fiziksel gecikme (latency) oluşturur. CDN mimarisinin sitenizin güvenlik ve hız mimarisine katkılarını öğrenmek için CDN nedir başlıklı makalemize göz atabilirsiniz.

Adım Adım Teşhis Süreci

Web sitenizdeki hız sorunlarını tespit ederken plansız değişiklikler yapmak yerine, neden-sonuç ilişkisini netleştiren kontrollü bir metodoloji izlemelisiniz:

1. Temel Ölçümü Alın: WebPageTest veya Google PageSpeed Insights kullanarak sitenizin mevcut durumunu belgeleyin. Testi tek bir kez değil, ortalama sapmayı görmek için 2-3 kez tekrarlayın.
2. Sunucu Yanıtını İzole Edin: Ağ şelalesindeki ilk isteğe (doküman isteği) tıklayın. TTFB değeriniz 1 saniyenin üzerindeyse, görselleri optimize etmeden önce barındırma, veritabanı ve sayfa önbelleği sorunlarını çözmeniz gerekir.
3. Ağ Şelalesini (Waterfall) İnceleyin: Kaynakların yükleme sırasına bakın. Yüklemeyi en uzun süre geciktiren uzun çubukları, art arda sıralanan harici yönlendirmeleri ve yanıt vermeyen harici script'leri belirleyin.
4. En Büyük Kaynakları Tespit Edin: Network sekmesini dosya boyutuna göre sıralayın. Toplam boyutu 500 KB'ın üzerinde olan tekil JavaScript veya görsel dosyalarını listeleyin.
5. Tek Değişiklik Yapıp Yeniden Test Edin: Aynı anda hem eklenti silip, hem görsel sıkıştırıp, hem de CSS birleştirmesi yapmayın. Yaptığınız her tekil optimizasyondan sonra önbelleği temizleyip yeni bir test çalıştırın.
6. Önce ve Sonra Metriklerini Karşılaştırın: Yapılan değişikliğin LCP veya INP değerinde oluşturduğu farkı kaydederek ilerleyin.

Ne Zaman Profesyonel Destek Gerekir?

Standart optimizasyon adımları basit sitelerde etkili olsa da karmaşık altyapılarda yetersiz kalabilir. Özellikle e-ticaret sitelerinde sepet ve ödeme sayfaları önbelleğe alınamaz; bu sayfalarda çalışan dinamik PHP operasyonları doğrudan veritabanı ve CPU mimarisine dayanır.

Sürekli yüksek seyreden TTFB değerleri, karmaşık eklenti veya modül çakışmaları, özel yazılmış temalardaki hatalı veritabanı sorguları ve çözülemeyen komut dosyası darboğazları profesyonel müdahale gerektirir. Ek olarak, sitenin aniden aşırı yavaşlaması ve kaynak tüketiminin tavan yapması sunucuya sızan zararlı yazılımlardan da kaynaklanabilir; böyle bir şüpheniz varsa WordPress sitem hacklendi mi rehberindeki adımlarla güvenlik taraması yapmanız önemlidir.

Platformdan bağımsız bir yaklaşımla, sitenizin tam yedeği alınarak ve işlem öncesi/sonrası performans raporları hazırlanarak sunulan web sitesi hızlandırma hizmeti, altyapınızdaki darboğazları kökten temizlemeyi amaçlar. Bu profesyonel optimizasyon sürecinde mobilde %80+, masaüstünde %90+ PageSpeed skorları hedeflenir ve çalışmalar genellikle 1-3 iş günü içerisinde tamamlanır.

Sık Sorulan Sorular

Web sitem neden mobilde yavaş açılıyor, masaüstünde hızlı?

Mobil cihazların işlemci kapasitesi masaüstü bilgisayarlara kıyasla çok daha sınırlıdır ve 4G/5G mobil ağlar dalgalı gecikme sürelerine sahiptir. Masaüstünde fark edilmeyen ağır JavaScript dosyalarının ayrıştırılması mobil işlemcileri kilitler; bu da mobil cihazlarda LCP ve INP sürelerinin dramatik biçimde uzamasına yol açar.

Hosting değiştirmek siteyi hızlandırır mı?

Sorunun ana kaynağı sunucu donanımı, yetersiz CPU/RAM sınırları veya yüksek TTFB ise barındırma altyapısını değiştirmek belirgin bir hız artışı sağlar. Ancak optimize edilmemiş 5 MB boyutundaki görseller, yüzlerce harici script veya önbellek yapılandırması eksikliği barındıran bir site, en pahalı sunucuya taşınsa dahi yavaş açılmaya devam eder.

Çok fazla eklenti kullanmak siteyi gerçekten yavaşlatır mı?

Performansı belirleyen temel faktör eklentilerin adedi değil, nasıl kodlandıkları ve sunucuya bindirdikleri yüktür. İyi optimize edilmiş 30 hafif eklenti sisteme yük getirmezken; veritabanında sürekli arka plan görevleri çalıştıran, her sayfaya ağır JavaScript dosyaları ekleyen tek bir kötü yazılmış eklenti tüm sitenin yanıt süresini felç edebilir.

Web sitesi hız testi sonuçları neden her seferinde farklı çıkar?

Hız testi araçları her ölçümde sunucu yükü, anlık ağ trafiği, DNS çözümleme gecikmesi ve önbellek durumu gibi farklı dinamik değişkenlerle karşılaşır. Ayrıca test sunucusunun coğrafi konumu ve laboratuvar ortamının işlemci yoğunluğu da puanlarda dalgalanma yaratır; bu nedenle tekil bir skora odaklanmak yerine birden fazla testin ortalaması alınmalıdır.