Makale Başlıkları
Kısaca
Bir web sitesinin yavaş açılmasının arkasında neredeyse her zaman birden fazla neden bulunur: sunucunun ilk yanıt süresi (TTFB), sıkıştırılmamış görseller, kontrolsüz JavaScript ve eksik önbellek en sık karşılaşılanlardır. İyi haber şu ki bu nedenlerin çoğu, doğru tanı konduğunda birkaç saat içinde çözülebilir.
- Yavaşlığın kökeni çoğunlukla sunucuda başlar: TTFB 200 ms altına inmeden sayfa hızını iyileştirmek zordur.
- Görsel optimizasyonu ve önbellekleme, en az emekle en büyük kazancı sağlayan iki adımdır.
- Yavaşlığı tahmin etmeyin, ölçün: her düzeltmeyi önce ve sonra test ederek doğrulayın.
Ziyaretçi sitenizi tıkladı ve beyaz bir ekrana bakıyor. Bir saniye, iki saniye… Üçüncü saniyede parmağı çoktan geri tuşuna gitmiştir. Web performansı üzerine yapılan ölçümler yıllardır aynı acı gerçeği tekrarlıyor: kullanıcıların önemli bir kısmı, açılması iki üç saniyeyi geçen sayfaları terk ediyor. Yani yavaşlık yalnızca bir konfor sorunu değil; doğrudan ciro, dönüşüm ve arama motoru sıralaması kaybı demek.
Peki bir site tam olarak neden yavaş açılır? On yılı aşkın süredir hosting altyapısı yönetiyoruz ve müşterilerimizin bize getirdiği “sitem çok yavaş” şikâyetlerinin büyük çoğunluğu, birbirinden bağımsız görünen ama aslında zincirleme ilerleyen bir avuç nedene dayanıyor. Bu yazıda o nedenleri teker teker açıyoruz ve her birinin yanına uygulanabilir bir çözüm koyuyoruz.
Önce şunu anlayın: yavaşlık nerede başlar?
Bir sayfanın açılması, tek bir olay değil, arka arkaya gerçekleşen bir olaylar dizisidir. Tarayıcı önce alan adını IP adresine çevirir (DNS), sonra sunucuya bağlanır, isteğini gönderir ve sunucunun ilk baytı geri göndermesini bekler. Bu bekleme süresine TTFB (Time to First Byte / İlk Bayt Süresi) denir. Ardından HTML gelir, tarayıcı içindeki CSS, JavaScript ve görselleri indirmeye başlar ve nihayet en büyük içerik parçası ekranda belirir; buna da LCP (Largest Contentful Paint) denir.
Buradaki kritik nokta şu: eğer TTFB 800 milisaniyeyse, LCP değeriniz siz daha hiçbir görsel yüklemeden zaten 800 milisaniye borçlu başlar. Yani sunucu tarafındaki her gecikme, sonraki tüm adımlara faturalanır. Bu yüzden yavaşlığı çözerken doğru sıra “önce sunucu, sonra ön yüz” olmalıdır. Şimdi on nedene tek tek bakalım.
1. Sunucunun ilk yanıt süresi (TTFB) yüksek
En sinsi neden budur çünkü ziyaretçi henüz sitenizin tek bir pikselini görmeden zaman kaybeder. Yüksek TTFB’nin arkasında genellikle aşırı kalabalık paylaşımlı bir sunucu, yetersiz CPU/RAM, yavaş disk giriş-çıkışı veya optimize edilmemiş sunucu tarafı kodu vardır. Ucuz paketlerde onlarca site aynı işlemciyi paylaştığında, orta düzey bir trafik dalgasında bile PHP istekleri kuyruğa girer ve herkes yavaşlar.
Çözüm: Hedefiniz 200 ms altında bir TTFB olmalı. Bunun için diski hızlı (tercihen all-flash NVMe), işlemci gücü yeterli ve komşu yoğunluğu kontrol altında bir barındırma altyapısı gerekir. Alastyr’ın İzmir’deki kendi veri merkezinde barındırdığımız sistemlerde Dell EMC Unity 650F all-flash depolama ve Intel Xeon Gold işlemciler kullanmamızın nedeni tam olarak budur: disk ve CPU darboğazını kaynağında ortadan kaldırmak. Paylaşımlı planlarda ise CloudLinux ile her hesabın CPU ve bellek kaynağı izole edilir; böylece bir komşunun trafiği sizin TTFB’nizi yükseltmez. Kaliteli ve doğru boyutlandırılmış bir hosting paketi ya da yoğun projeler için ayrılmış kaynaklı bir bulut sunucu, çoğu TTFB sorununu tek başına çözer.
2. Sayfa önbelleği (cache) yok ya da yanlış yapılandırılmış
Özellikle WordPress gibi dinamik sistemlerde her ziyaret, sunucunun PHP çalıştırıp veritabanına sorgu atmasını gerektirir. Önbellek yoksa aynı sayfa her seferinde sıfırdan üretilir. Ölçümler önbelleksiz bir WordPress isteğinin 500 ms ile 2000 ms arasında TTFB üretebildiğini, aynı sayfanın önbellekten sunulduğunda ise bu sürenin 10-50 ms bandına indiğini gösteriyor. Aradaki fark, yavaş bir site ile ışık hızında bir site arasındaki farktır.
Çözüm: Tam sayfa önbelleği (full-page cache), nesne önbelleği (object cache) ve opcode önbelleği birlikte kullanılmalıdır. Alastyr sunucularında LiteSpeed web sunucusu ve LSCache ikilisi devrededir; LSCache, sayfaları sunucu seviyesinde önbelleğe alarak PHP’yi devreden çıkarır ve WordPress için özel bir eklentiyle otomatik yönetilir. Buna PHP sürüm seçici üzerinden aktif ettiğiniz OPcache eklendiğinde, dinamik siteler statik siteler gibi hızlanır.
3. Görseller optimize edilmemiş
Sayfa ağırlığının çoğu genellikle görsellerdir. Telefon kamerasından çıkmış 4 MB’lık bir fotoğrafı doğrudan siteye yüklemek, ziyaretçinin her açılışta o dosyayı indirmesi anlamına gelir. Üstelik çoğu zaman o görsel ekranda 400 piksel genişliğinde gösterilirken, tarayıcı 4000 piksellik orijinali indirir.
Çözüm: Modern format kullanın. Görselleri WebP veya AVIF formatına dönüştürmek, kaliteden ödün vermeden dosya boyutunu %40-60 azaltabilir. Ekrandaki gerçek boyuta uygun sürümler sunun, ekranın altındaki görseller için lazy loading (geç yükleme) açın ve en önemli görsele (genellikle LCP öğesine) tarayıcının erkenden ulaşması için öncelik verin. Bu üç adım çoğu sitenin LCP değerini gözle görülür biçimde düşürür.
4. Kontrolsüz ve fazla JavaScript
Tema, sayfa oluşturucu (page builder) ve eklentiler sitenize sürekli JavaScript ekler. Her betik indirilmeli, ayrıştırılmalı ve çalıştırılmalıdır; bu da özellikle mobil cihazlarda işlemciyi meşgul eder. Kullanmadığınız bir slider eklentisinin JavaScript’i, her sayfada boşuna yüklenir.
Çözüm: Kullanmadığınız eklentileri tamamen kaldırın (yalnızca pasife almak yetmez). Kritik olmayan betikleri erteleyin (defer) veya sayfanın altına taşıyın. Birden çok küçük dosyayı birleştirin ve küçültün (minify). Kural basittir: ekranda ilk görünen içeriği çizmek için gerekli olmayan hiçbir betik, o çizimi geciktirmemelidir.
5. Üçüncü taraf betikleri (widget’lar) siteyi boğuyor
Canlı sohbet balonu, ısı haritası, harici yorum widget’ı, birden fazla reklam ve takip kodu… Bunların her biri başka bir sunucuya bağlanır ve o sunucu yavaşsa siteniz de yavaşlar. Kendi altyapınızı mükemmel optimize etseniz bile, kontrol edemediğiniz harici bir betik sizi geri çekebilir.
Çözüm: Gerçekten gerekli olmayan widget’ları kaldırın. Kalanları mümkünse asenkron (async) yükleyin ki sayfanın çizilmesini engellemesinler. Analitik ve etiket yönetimi kodlarını tek bir konteyner üzerinden yönetmek de dağınıklığı azaltır. Her yeni widget eklemeden önce şu soruyu sorun: “Bu, katacağı değerin karşılığında ne kadar hız çalıyor?”
6. Veritabanı sorguları yavaş ya da tablo şişmiş
Zamanla veritabanı büyür; eski gönderi revizyonları, silinmemiş geçici veriler (transient), spam yorumlar ve eklenti artıkları birikir. Optimize edilmemiş bir sorgu ya da eksik bir indeks, tek bir sayfanın yüklenmesini saniyelerce uzatabilir. Bu sorun özellikle e-ticaret ve üyelik siteleri gibi sunucu tarafında çok iş yapan sistemlerde belirgindir.
Çözüm: Veritabanını düzenli olarak temizleyin ve optimize edin. Sık çalışan yavaş sorguları tespit edip indeks ekleyin. Nesne önbelleği kullanarak aynı sorgunun tekrar tekrar veritabanına gitmesini engelleyin. Kaynak yetersizse, ayrılmış kaynaklara sahip bir VPS sunucu ya da fiziksel sunucu veritabanı yükünü rahatlatır.
7. Sunucu coğrafi olarak ziyaretçilerinizden uzak
Veri, ışık hızıyla bile olsa bir mesafe kat eder. Türkiye’deki ziyaretçileriniz varken sunucunuz okyanus ötesindeyse, her istek gidiş-dönüş için fazladan onlarca hatta yüzlerce milisaniye harcar. Bu gecikme (latency) her bağlantıda tekrarlanır ve toplamda hissedilir bir yavaşlığa dönüşür.
Çözüm: Hedef kitleniz Türkiye ise sunucunuz da Türkiye’de olmalı. Alastyr’ın altyapısı İzmir’deki kendi veri merkezinde konumlanır ve RIPE NCC üyesi bağımsız AS3188 ağı üzerinden, Türk Telekom ve TurkNet ile yedekli 40 Gbit kapasiteyle çalışır. Bu, yerel ziyaretçileriniz için düşük gecikme ve kararlı bir bağlantı demektir. Ayrıca Voxility 1 Tbps üzeri anti-DDoS korumasıyla ağ katmanı saldırıları da hız düşüşüne yol açmadan filtrelenir.
8. Gereksiz yönlendirmeler ve DNS gecikmesi
Her yönlendirme (redirect) ziyaretçiye fazladan bir gidiş-dönüş maliyeti çıkarır. “http” adresinden “https”e, oradan “www” sürümüne zincirleme yönlendirmeler yaparsanız, her adım milisaniyeler ekler. Benzer şekilde yavaş bir DNS sağlayıcısı, sayfa daha başlamadan bekleme yaratır.
Çözüm: Yönlendirme zincirlerini tek adıma indirin; nihai adrese doğrudan gidin. HSTS ile tarayıcının doğrudan HTTPS’e gitmesini sağlayın. Hızlı ve güvenilir bir DNS altyapısı kullanın. Alan adınızın yapılandırmasını WHOIS sorgulama ile doğrulayabilir, yeni bir alan adının müsaitliğini domain sorgulama aracıyla kontrol edebilirsiniz.
9. SSL / TLS el sıkışması yanlış yapılandırılmış
SSL bugün pazarlık konusu değil; hem güvenlik hem sıralama için zorunlu. Ancak yanlış yapılandırılmış bir TLS el sıkışması, eski protokoller veya HTTP/2 desteğinin kapalı olması bağlantı kurulumunu yavaşlatır. İyi haber şu ki doğru yapılandırılmış modern TLS, hız kaybı yaratmadan güvenlik sağlar.
Çözüm: Güncel TLS sürümlerini ve HTTP/2 (mümkünse HTTP/3) desteğini açın. Alastyr paketlerinde ücretsiz SSL sertifikası standarttır ve LiteSpeed altyapısı modern protokolleri destekler; e-ticaret gibi genişletilmiş güven gerektiren projeler için ise ayrı bir SSL sertifikası tercih edilebilir. Doğru sertifika, kurulumdan sonra hız üzerinde hissedilir bir yük bırakmaz.
10. Yanlış barındırma tipi seçilmiş
Bazen sorun tek bir ayar değil, temel tercihtir. Günde binlerce ziyaretçi alan bir e-ticaret sitesini, en ucuz paylaşımlı pakete sığdırmaya çalışmak baştan kaybedilmiş bir savaştır. Site büyüdükçe altyapının da büyümesi gerekir; aksi halde her kampanya gününde site çöker ya da sürünür.
Çözüm: İhtiyacınıza uygun barındırma tipini seçin. Küçük ve orta ölçekli WordPress siteleri için LiteSpeed + LSCache optimizasyonlu WordPress hosting çoğu zaman fazlasıyla yeterlidir. Trafik ve kaynak ihtiyacı arttıkça ayrılmış kaynaklı VPS ya da bulut sunucuya, en üst seviyede ise fiziksel sunucuya geçilir. Doğru seçim, sonradan yapılacak onlarca optimizasyondan daha büyük fark yaratır. Kararsızsanız, kullandığınız yazılıma ve trafiğinize göre en doğru planı birlikte belirlemek için 7/24 destek ekibimize danışabilirsiniz.
Nedenleri ve etkilerini bir arada görün
| Neden | Tipik Etki | Çözümün Zorluğu |
|---|---|---|
| Yüksek TTFB (sunucu) | Sayfa başlamadan gecikme | Orta (altyapı/paket) |
| Önbellek yok | Her istekte yeniden üretim | Kolay (LSCache) |
| Optimize edilmemiş görsel | Ağır sayfa, yüksek LCP | Kolay |
| Fazla JavaScript | Mobilde gecikme, donma | Orta |
| Üçüncü taraf widget | Harici sunucuya bağımlılık | Kolay |
| Yavaş veritabanı | Dinamik sayfalarda yavaşlık | Orta |
| Uzak sunucu konumu | Her istekte gecikme | Orta (taşıma) |
| Yönlendirme / DNS | Ekstra gidiş-dönüş | Kolay |
| Yanlış TLS yapılandırması | Bağlantı kurulum gecikmesi | Kolay |
| Yanlış barındırma tipi | Zirvede çökme / genel yavaşlık | Orta (yükseltme) |
Tanı koymadan çözmeye çalışmayın
Buradaki her neden gerçek, ama sizin sitenizde hangilerinin baskın olduğunu ancak ölçerek anlarsınız. Önce mevcut durumu kaydedin: TTFB, LCP, INP ve toplam sayfa ağırlığı. Sonra tek seferde tek bir değişiklik yapın ve tekrar ölçün. Bu disiplin, “iyileştirdim sandığım şey aslında yavaşlatmış” tuzağından sizi korur. Unutmayın, hedefler nettir: LCP 2,5 saniyenin, INP 200 milisaniyenin, CLS ise 0,1’in altında olmalıdır.
Ve en önemlisi: bu on nedenin altısı doğrudan barındırma kalitesiyle ilgilidir. Hızlı disk, yeterli işlemci, izole kaynak, sunucu seviyesinde önbellek ve yerel ağ konumu, siz tek bir eklenti kurmadan sitenizi hızlandırır. Doğru zeminde başlamak, sonradan yapılacak yüzlerce ayarın yerini tutar.
Sıkça Sorulan Sorular
Web sitem neden bazen hızlı bazen yavaş açılıyor?
Bu genellikle paylaşımlı sunucuda komşu sitelerin trafiği ya da kendi trafiğinizin dalgalanmasıyla ilgilidir. Kaynaklar (CPU, PHP işçi sayısı) yoğun anlarda tükeniyorsa istekler kuyruğa girer ve sayfa yavaşlar. Kaynak izolasyonu sağlayan bir altyapı bu dalgalanmayı büyük ölçüde ortadan kaldırır.
TTFB kaç milisaniye olmalı?
İyi bir hedef 200 milisaniyenin altıdır. 200-500 ms arası kabul edilebilir sayılsa da iyileştirilmeye açıktır; 800 ms ve üzeri ise LCP değerinizi baştan olumsuz etkileyeceği için müdahale gerektirir.
Önbellek eklentisi kurmam yeterli mi?
Yardımcı olur ama sunucu seviyesinde önbellek her zaman daha hızlıdır. LiteSpeed + LSCache gibi sunucu düzeyinde çalışan bir çözüm, PHP’yi tamamen devreden çıkararak eklenti tabanlı önbelleklerden daha düşük TTFB üretir.
Görsellerimi WebP’ye çevirmek gerçekten fark eder mi?
Evet, çoğu durumda sayfa ağırlığını %40-60 azaltır. Sayfa ağırlığının büyük kısmı genelde görsellerden geldiği için, bu tek adım bile LCP değerinde gözle görülür bir iyileşme sağlayabilir.
Sunucumun Türkiye’de olması hızı ne kadar etkiler?
Ziyaretçilerinizin çoğu Türkiye’deyse etkisi büyüktür. Her istekte kat edilen mesafe gecikmeye dönüşür; yerel bir sunucu bu gecikmeyi minimuma indirir ve özellikle çok sayıda küçük istek yapan modern sitelerde toplam açılış süresini kısaltır.
Çok fazla eklenti sitemi yavaşlatır mı?
Doğrudan sayı değil, eklentilerin ne yaptığı önemlidir. Her sayfada gereksiz JavaScript, CSS veya veritabanı sorgusu ekleyen eklentiler siteyi yavaşlatır. Kullanmadıklarınızı kaldırmak ve kalanları hafif alternatiflerle değiştirmek çoğu zaman belirgin bir hızlanma getirir.
SSL sertifikası sitemi yavaşlatır mı?
Doğru yapılandırılmış modern TLS ve HTTP/2 ile hız kaybı ihmal edilebilir düzeydedir. Aksine güvenlik ve arama motoru açısından zorunludur. Yavaşlık varsa sorun SSL’in kendisi değil, eski protokol ya da yanlış yapılandırmadır.
Hangi barındırma tipini seçmeliyim?
Küçük ve orta ölçekli siteler için optimizasyonlu paylaşımlı ya da WordPress hosting genelde yeterlidir. Trafik ve kaynak ihtiyacı arttıkça VPS veya bulut sunucuya, en üst düzeyde ise fiziksel sunucuya geçilir. Doğru tipi seçmek, sonradan yapılacak birçok optimizasyondan daha etkilidir.
Sitemi hızlandırmaya nereden başlamalıyım?
Önce ölçün ve darboğazı belirleyin. Ardından sırayla ilerleyin: sunucu/önbellek, görseller, JavaScript ve üçüncü taraf betikleri. Her değişikliği tek tek yapıp önce-sonra ölçerek doğrulayın; böylece neyin işe yaradığını kesin olarak bilirsiniz.
Hızlı zemin, hızlı site demektir
All-flash depolama, LiteSpeed + LSCache önbellek ve İzmir’deki kendi veri merkezimizle sitenizin ilk yanıt süresini kaynağında düşürüyoruz. Ücretsiz SSL, ücretsiz taşıma ve 7/24 destek dahil.
