Web sitenizin yavaş olması, “teknik bir detay” değildir. Kullanıcıların büyük bölümü 3 saniyeden uzun açılan bir sayfayı terk ediyor; arama motorları ise hız metriklerini sıralama sinyali olarak kullanıyor. Yani yavaşlık doğrudan trafik ve satış kaybı anlamına geliyor.
Bu rehberde 2026 itibarıyla Core Web Vitals metriklerinin ne anlama geldiğini, sitelerin neden yavaşladığını ve bunu 9 somut adımda nasıl düzeltebileceğinizi anlatıyoruz. Adımların tamamı, gerçek projelerde uyguladığımız yöntemlerden derlenmiştir.
Hız Neden 2026’da Daha da Önemli?
- Dönüşüm: Amazon’un yayınladığı ölçümlere göre 100 ms’lik ek gecikme, dönüşüm oranında yaklaşık %1 kayba karşılık geliyor. E-ticarette bu, ciroda doğrudan görünen bir farktır.
- Arama sıralaması: Google, Core Web Vitals metriklerini “sayfa deneyimi” sinyali olarak kullanıyor.
- Yapay zekâ tarayıcıları: Arama sonuçlarında AI özetlerinin yaygınlaşmasıyla içeriğinizin bu sistemler tarafından okunabilmesi için sunucunun hızlı yanıt vermesi kritik hâle geldi. Yavaş yanıt veren siteler taranmakta zorlanır.
- Mobil: Trafiğin büyük bölümü mobil cihazlardan geliyor ve mobil ağ koşulları masaüstünden çok daha değişken.
Önce Ölçün: LCP, INP ve CLS
Optimizasyona başlamadan önce hangi metriğin bozuk olduğunu bilmek gerekir. 2026 itibarıyla takip edilmesi gereken üç ana metrik şunlardır:
| Metrik | Ne Ölçer? | İyi | İyileştirme Gerekli |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Sayfadaki en büyük görsel öğenin yüklenme süresi | 2,5 saniyenin altı | 4 saniyenin üzeri |
| INP (Interaction to Next Paint) | Kullanıcı etkileşimine tepki süresi | 200 ms altı | 500 ms üzeri |
| CLS (Cumulative Layout Shift) | Sayfa yüklenirken beklenmeyen kaymalar | 0,1 altı | 0,25 üzeri |
| TTFB (Time to First Byte) | Sunucunun ilk baytı gönderme süresi | 0,8 saniye altı | 1,8 saniye üzeri |
Ölçüm için Chrome Lighthouse, PageSpeed Insights ve gerçek kullanıcı verisi sunan CrUX raporları birlikte kullanılmalıdır. Sadece laboratuvar testine bakmak yanıltıcıdır; asıl veri gerçek ziyaretçilerden gelir.
Sitelerin Yavaşlamasının 9 Sık Nedeni ve Çözümleri
1. Eski PHP sürümü ve zayıf sunucu kaynakları
Belirti: TTFB yüksek, sayfa bazen hiç açılmıyor, yoğun saatlerde tıkanma.
Çözüm: PHP 8.1 ve üzerine geçin, OPcache’i etkinleştirin. Sunucu kaynaklarının (CPU, RAM) gerçek trafiğe göre planlandığından emin olun. Aynı sunucuda onlarca servis çalışıyorsa, kaynak açlığı en büyük hız düşmanıdır.
2. Sayfa önbelleği (page cache) olmaması
Belirti: Her ziyaretçide PHP ve veritabanı baştan çalışır, TTFB yüksek kalır.
Çözüm: Sayfa önbelleği ve nesne önbelleği (Redis / Memcached) kurun. Doğru yapılandırılmış bir nesne önbelleği, veritabanı sorgu yükünü ciddi biçimde azaltır.
3. HTML’in CDN kenarında önbelleklenmemesi
Belirti: Sunucu hızlı olsa bile her istek origin’e gider ve gecikme artar.
Çözüm: Cloudflare gibi bir CDN’de HTML için “Cache Everything” benzeri bir kural tanımlayın; oturum açmış kullanıcılar için istisna (bypass) ekleyin. Bu tek değişiklik çoğu sitede en büyük kazanımı sağlar.
4. Optimize edilmemiş görseller
Belirti: Ana sayfa birkaç saniyede açılır ama büyük görsel geç yüklenir (yüksek LCP).
Çözüm: Görselleri WebP veya AVIF formatına dönüştürün, doğru boyutlarda servis edin (srcset), ekran dışı görseller için lazy loading, ilk ekrandaki görsel için ise öncelikli (preload) yükleme kullanın. Tek bir banner görselinin 1 MB’tan 50 KB’a indirilmesi LCP’yi saniyelerce iyileştirebilir.
5. Şişkin CSS ve JavaScript
Belirti: Onlarca CSS/JS dosyası, yüklenmeyen bileşenlerin kodu, kullanılmayan kütüphaneler.
Çözüm: Dosyaları birleştirin, küçültün (minify), kritik olmayan JS’i erteleyin (defer/delay) ve kullanılmayanları kaldırın. Ama dikkat: satır içi (inline) scriptleri de erteleyen agresif ayarlar düzen kaymalarına (CLS) yol açabilir; test etmeden yayına almayın.
6. Kullanılmayan veya çakışan eklentiler
Belirti: Aynı işi yapan iki eklenti (iki analitik, iki önbellek), sürekli artan yükleme süresi.
Çözüm: Eklenti envanterini çıkarın. Aynı işlevi görenleri birleştirin, kullanılmayanları kaldırın. Her eklenti hem hız hem güvenlik yüzeyini büyütür.
7. Şişen veritabanı ve autoload yükü
Belirti: Yönetim paneli yavaş, sayfa oluşturma süreleri dalgalı.
Çözüm: Her istekte otomatik yüklenen (autoload) seçenekleri gözden geçirin, süresi geçmiş geçici kayıtları (transient) temizleyin, revizyon ve spam kayıtlarını sınırlayın. Yönetim panelinde gereksiz eklentileri devre dışı bırakmak da sorgu sayısını ciddi biçimde düşürür.
8. Üçüncü taraf scriptler
Belirti: Sitenin kendi kodu hızlı ama dış kaynaklı scriptler (sohbet widget’ı, harita, font, etiket yöneticisi) render’ı bloke ediyor.
Çözüm: Kritik olmayanları erteleyin, kendi sunucunuzda barındırın (self-host) veya tamamen kaldırın. Her üçüncü taraf script, kontrolünüzde olmayan bir gecikme riskidir.
9. Sunucu kaynaklarının aşırı taahhüdü (oversubscription)
Belirti: Site bazen çok hızlı, bazen cevapsız. Sunucu yük ortalaması (load average) sürekli yüksek, PHP çalışanları (worker) tıkanıyor, loglarda “dead lock” veya zaman aşımı kayıtları.
Çözüm: Sunucudaki servisleri envanterleyin; her birinin gerçek kaynak tüketimini ölçün. PHP çalışan sayısını ve bağlantı limitlerini trafikle uyumlu hâle getirin, gereksiz servisleri kapatın veya ayrı sunucuya taşıyın. Ayrıca zamanlanmış görevleri (cron) kontrolsüz tetiklenen hâle getirmeyin; arka planda çalışan bir görev, ön yüzü kilitleyebilir.
30 Günlük Uygulama Planı
- 1. hafta – Ölçüm: Lighthouse, PageSpeed Insights ve gerçek kullanıcı verisini kaydedin. Mevcut değerleri yazılı hâle getirin; sonraki haftalarda karşılaştırma yapacaksınız.
- 2. hafta – Sunucu ve önbellek: PHP sürümü, OPcache, sayfa önbelleği, nesne önbelleği ve CDN kuralları. En yüksek etkiyi bu adım verir.
- 3. hafta – Görseller ve varlıklar: WebP/AVIF dönüşümü, srcset, lazy loading, CSS/JS birleştirme ve erteleme.
- 4. hafta – Temizlik ve kalıcılık: Eklenti envanteri, veritabanı bakımı, üçüncü taraf scriptler, ardından yeni ölçüm ve raporlama. Bundan sonra aylık kontrol rutini kurun.
Sıkça Sorulan Sorular
Önbellek eklentisi kurmak yeterli mi?
Genellikle hayır. Önbellek, sunucu ve veritabanı tarafındaki darboğazı çözer; ancak optimize edilmemiş bir görsel, şişkin JavaScript veya tıkanmış bir PHP havuzu varsa etkisi sınırlı kalır. Hız çalışması katmanlı yapılmalıdır.
Görselleri toplu olarak nasıl dönüştürürüm?
Güncel eklentiler WebP dönüşümünü otomatik yapabilir. Kritik görsellerde dönüşümü elle doğrulamanızı öneririz; çünkü eski tarayıcılar ve bazı CDN önbellekleri yönlendirmeyi göz ardı edebilir.
Cloudflare ayarlarını değiştirmek riskli mi?
Doğru yapılandırıldığında değil; ancak HTML önbelleği oturum açmış kullanıcılar için istisna içermezse yönetim panelinde ve sepet sayfalarında sorun çıkarabilir. Mutlaka “cookie bypass” kuralı ile birlikte kurulmalıdır.
Yavaşlığın sebebi temam mı, sunucu mu?
Ayırt etmenin en kolay yolu: TTFB yüksekse sorun sunucu/PHP tarafındadır; TTFB düşük ama render süresi yüksekse sorun tema ve varlıklardadır. Ölçüm verisi olmadan yapılan her müdahale tahminden ibarettir.
Sonuç
Hız optimizasyonu tek seferlik bir iş değil, sürdürülebilir bir süreçtir. Doğru ölçüm, doğru sıralama ve disiplinli uygulama ile çoğu sitede LCP’yi saniyeler mertebesinde iyileştirmek ve dönüşümü artırmak mümkündür.
Sitenizin hız ve Core Web Vitals performansını birlikte değerlendirmek isterseniz teklif al sayfamızdan bize ulaşabilirsiniz. ON4NET olarak performans optimizasyonu, teknik SEO, web tasarımı ve e-ticaret çözümleri sunuyoruz.
Bu yazı ON4NET ekibi tarafından hazırlanmıştır.
