Web sitesi nasıl hızlandırılır? Adım adım hız optimizasyonu

Bir sayfanın açılması birkaç saniye uzadığında ziyaretçilerin önemli bir kısmı beklemeden geri döner. Özellikle mobil veriyle, tren ya da metroda gezinen kullanıcılar için her ek saniye can sıkıcıdır. İyi haber şu: çoğu sitede hız sorununun %80’i birkaç ana nedenden kaynaklanır ve bunları düzeltmek için ileri düzey yazılım bilgisi gerekmez. Önemli olan, tahmin yürütmek yerine önce ölçmek, sonra en büyük kazancı veren işten başlamaktır.

1. Önce ölçün: hangi değerlere bakmalı?

Hız tek bir sayı değildir. Bir sayfanın yüklenmesi birkaç aşamadan oluşur ve her aşamanın ayrı bir ölçüsü vardır:

Ölçüm için site hız testi aracımızı kullanabilir, sonuçları Google PageSpeed Insights ve Chrome DevTools’taki Lighthouse ile karşılaştırabilirsiniz. Üç kural:

• Mobil sonucu esas alın. Google, siteleri mobil sürüme göre değerlendirir ve mobil sonuçlar neredeyse her zaman daha kötüdür.
• Birden fazla sayfayı test edin. Ana sayfa hızlı olabilir; ürün ya da blog sayfası yavaş olabilir.
• Laboratuvar ile saha verisini ayırın. Lighthouse tek bir simülasyondur; Search Console’daki “Core Web Vitals” raporu gerçek ziyaretçilerin deneyimini gösterir. Ayrıntılar için Core Web Vitals rehberimize bakın.

2. En büyük kazanç: görseller

Ortalama bir kurumsal sitede sayfa ağırlığının büyük bölümünü görseller oluşturur. Telefonla çekilmiş 4 MB’lık bir fotoğrafı doğrudan yüklemek, en sık gördüğümüz hatadır.

1. Doğru boyutta yükleyin. 800 piksel genişliğinde gösterilecek bir görseli 4000 piksel yüklemeyin. Resim boyutlandırma ile önce ölçüyü küçültün.
2. Sıkıştırın. Resim sıkıştırma aracıyla görsel kaliteyi gözle fark edilmeyecek ölçüde koruyarak dosyayı genellikle %50–80 küçültebilirsiniz.
3. Modern format kullanın. WebP ve AVIF, aynı kalitede JPEG’den belirgin biçimde küçüktür. WebP dönüştürücü ile dönüştürebilirsiniz.
4. Lazy loading ekleyin, ama ilk ekrandaki ana görsele değil. Ana görsel (genellikle LCP öğesi) hemen yüklenmelidir:

<!-- İlk ekrandaki ana görsel: öncelikli yükle -->
<img src="/img/kapak.webp" width="1200" height="630" fetchpriority="high" alt="Mağaza vitrini">

<!-- Aşağıdaki görseller: gerektiğinde yükle -->
<img src="/img/urun-1.webp" width="400" height="400" loading="lazy" alt="Ürün 1">

width ve height niteliklerini yazmak, görsel yüklenirken yerin ayrılmasını sağlar ve CLS sorununu önler. Daha fazlası için görsel optimizasyonu rehberini okuyun.

3. Önbellek (cache) ve sıkıştırma

Bir ziyaretçi sitenize ikinci kez geldiğinde logo, CSS ve JavaScript dosyalarını yeniden indirmesine gerek yoktur. Bunu tarayıcıya Cache-Control başlığıyla söylersiniz:

location ~* \.(css|js|webp|avif|jpg|png|svg|woff2)$ {
    add_header Cache-Control "public, max-age=31536000, immutable";
}

Dosya adlarında sürüm/hash kullanıyorsanız (app.3f2a1.css) bir yıllık önbellek güvenlidir. HTML sayfaları için ise kısa süre veya no-cache tercih edilir.

Ayrıca sunucunun metin dosyalarını Brotli veya gzip ile sıkıştırdığından emin olun. Çoğu hosting panelinde bu tek tıkla açılır. WordPress kullanıyorsanız bir sayfa önbellek eklentisi, her istekte PHP ve veritabanının çalışmasını engelleyerek TTFB’yi ciddi biçimde düşürür.

4. JavaScript ve CSS’i hafifletin

Yavaş tepki veren (INP’si kötü) sitelerin ana nedeni ağır JavaScript’tir. Sık görülen kaynaklar:

• Kullanılmayan slider, animasyon ve sayfa oluşturucu (page builder) kütüphaneleri
• Birden fazla analiz/izleme kodu (Analytics, Meta Pixel, ısı haritası, canlı sohbet)
• Her sayfada yüklenen ama yalnızca bir sayfada kullanılan eklentiler

Yapılacaklar:

• Kritik olmayan betiklere defer ekleyin: <script src="/js/app.js" defer></script>
• Canlı sohbet gibi araçları kullanıcı etkileşiminden sonra yükleyin.
• Kullanılmayan eklentileri tamamen kaldırın (devre dışı bırakmak yetmeyebilir).
• Web fontlarını sınırlayın: 2 aile ve birkaç ağırlık çoğu site için yeterlidir; font-display: swap kullanın ve WOFF2 formatı tercih edin.

5. Hosting, HTTP/2–3 ve CDN

Sunucu yavaşsa ön yüzde yaptığınız iyileştirmelerin etkisi sınırlı kalır. Hosting’i değerlendirirken şunlara bakın:

• Sunucu konumu: Ziyaretçileriniz Türkiye’deyse, Türkiye’de veya yakın bir Avrupa merkezinde (ör. Frankfurt, Amsterdam) barındırma gecikmeyi azaltır.
• PHP sürümü: Eski PHP sürümleri hem yavaş hem güvensizdir; desteklenen güncel bir sürüm kullanın.
• HTTP/2 veya HTTP/3: Çok sayıda küçük dosyanın paralel yüklenmesini sağlar.
• CDN: Cloudflare gibi bir içerik dağıtım ağı statik dosyaları ziyaretçiye en yakın noktadan sunar ve çoğu küçük site için ücretsiz katman yeterlidir.

Hosting değiştirmeden önce basit bir test yapın: önbellek eklentisi açıkken boş bir sayfanın TTFB değerini birkaç kez ölçün. Değer sürekli 1 saniyenin üzerindeyse sorun büyük olasılıkla sunucu tarafındadır; eklenti ya da görsel ayarlarıyla uğraşmak bu durumda zaman kaybıdır. Değer düşük ama sayfa yine de yavaşsa, sorun ön yüzdedir ve görsel, JavaScript ve font adımlarına odaklanmalısınız.

Sitenizin hangi altyapıyla çalıştığını merak ediyorsanız site altyapı tespit aracı fikir verir.

6. Sık yapılan hatalar

• Üst üste hız eklentileri kurmak. İki önbellek eklentisi birbirini bozar.
• Her şeyi lazy load yapmak. Ana görsel geç yüklenir, LCP kötüleşir.
• Puan için gerçek kullanıcıyı unutmak. Lighthouse’u kandıran hileler saha verisini düzeltmez.
• Yönlendirme zincirleri. http → https → www gibi her ek yönlendirme yüzlerce milisaniye ekler.
• Değişiklikten sonra ölçmemek. Her adımdan sonra tekrar test edin ki neyin işe yaradığını bilin.

Hız optimizasyonu kontrol listesi

• Mobil hız testi yapıldı, LCP/INP/CLS değerleri not edildi
• Tüm görseller doğru boyutta, sıkıştırılmış ve WebP/AVIF formatında
• Ana görselde fetchpriority="high", diğerlerinde loading="lazy"
• Görsellerde width/height tanımlı
• Statik dosyalarda uzun süreli Cache-Control başlığı var
• Brotli/gzip sıkıştırma açık
• Kullanılmayan eklenti ve betikler kaldırıldı, kalanlarda defer
• Font sayısı sınırlı, WOFF2 ve font-display: swap
• TTFB 800 ms altında; değilse hosting/CDN gözden geçirildi
• Değişikliklerden sonra test tekrarlandı

Bu listeyi tamamlayan sitelerin büyük çoğunluğu, kod tarafında köklü bir yeniden yazıma gerek kalmadan “iyi” aralığına ulaşır.