Site Hızı Optimizasyonu: Uygulamalı Hızlandırma Rehberi

Site hızı tartışmaları genelde yanlış yerden başlar: "hangi eklentiyi kurayım?" Oysa doğru soru şudur — sayfam neden yavaş? Bu sorunun cevabı her sitede farklıdır ve ölçmeden verilemez. Bu rehber, önce teşhis sonra tedavi mantığıyla ilerliyor.

Bir sayfa neden yavaş yüklenir?

Bir sayfanın yüklenmesi sıralı bir zincirdir: tarayıcı sunucuya istek gönderir, ilk baytı bekler, gelen HTML'i okur, içindeki CSS ve JavaScript dosyalarını indirir, düzeni hesaplar, görselleri yükler ve son olarak sayfayı etkileşime hazır hale getirir. Bu zincirdeki her halka bir öncekini bekler.

Bu yüzden optimizasyonun altın kuralı şudur: zincirin en başındaki gecikme, sonraki her adıma eklenir. Sunucu yanıtı 1,5 saniye sürüyorsa, görselleri ne kadar sıkıştırırsanız sıkıştırın o 1,5 saniyeyi geri alamazsınız. Önce baştan başlayın.

1. TTFB ve Sunucu Tarafı

TTFB (Time To First Byte), isteği gönderdikten sonra ilk baytın gelmesine kadar geçen süredir. 200 milisaniyenin altı iyi, 600 milisaniyenin üstü sorunludur.

Yüksek TTFB'nin tipik sebepleri: paylaşımlı ve aşırı yüklü hosting, önbelleksiz sunulan dinamik sayfalar, ağır veritabanı sorguları ve sunucunun kullanıcıdan coğrafi olarak uzak olması. Türkiye'deki bir kitleye hitap ediyorsanız sunucunuzun ya da CDN uç noktanızın yakın olması ölçülebilir fark yaratır.

Çözümler sırasıyla: sayfa önbelleği kurmak (dinamik sayfaları statik hale getirmek), veritabanı sorgularını optimize etmek, hosting paketini yükseltmek ve CDN kullanmak. Statik site üreten mimarilerde bu sorun neredeyse tamamen ortadan kalkar — sunucu hesaplama yapmaz, hazır dosyayı verir.

2. Görseller: En Büyük ve En Kolay Kazanç

Ortalama bir sayfanın ağırlığının yarısından fazlası görsellerden gelir. İyi haber şu ki buradaki iyileştirmeler hem en kolay hem en etkilidir.

• Format değiştirin. WebP, aynı görsel kalitesinde JPEG'e göre belirgin biçimde küçüktür; AVIF daha da küçüktür. Eski tarayıcılar için <picture> etiketiyle yedek sunabilirsiniz.
• Doğru boyutta sunun. 4000 piksel genişliğindeki bir fotoğrafı 800 piksellik alanda göstermek, gereksiz veri indirmektir. srcset ile cihaza uygun boyutu sunun.
• Boyut özniteliklerini verin. width ve height hem CLS'yi önler hem tarayıcının yer ayırmasını sağlar.
• Lazy loading'i doğru uygulayın. Ekranın altındaki görsellere loading="lazy" ekleyin. Üstteki hero görseline eklemek LCP'yi doğrudan bozar — çok yaygın bir hatadır.
• Vektör kullanabildiğiniz yerde kullanın. Logo, ikon ve basit çizimler SVG olarak hem daha küçük hem her çözünürlükte nettir.

3. Yazı Tipleri

Özel fontlar sessiz bir yavaşlatıcıdır. Her font ailesi, her kalınlık ve her stil ayrı bir dosya demektir. Üç kural yeterlidir: yalnızca gerçekten kullandığınız kalınlıkları yükleyin (çoğu site iki kalınlıkla idare eder), font-display: swap ile metnin font gelene kadar yedek fontla görünmesini sağlayın ve font dosyalarını kendi sunucunuzdan sunarak üçüncü taraf bağlantı maliyetini ortadan kaldırın.

Alt küme (subsetting) da önemli bir kazançtır: Türkçe içerik için Latin karakter setine ihtiyacınız varken Kiril veya Yunan alfabesini indirmenin anlamı yoktur.

4. CSS: Render Engelleyen Kaynak

Tarayıcı, CSS dosyasını indirip işlemeden sayfayı çizmez. Bu bilinçli bir davranıştır — aksi hâlde stilsiz bir sayfa görürdünüz — ama gereğinden büyük bir CSS dosyası doğrudan LCP'yi geciktirir.

İki yaklaşım: kritik CSS (ilk ekranı çizmek için gereken kuralları HTML içine satır içi koymak, kalanını sonradan yüklemek) ve kullanılmayan kuralları temizlemek. Hazır tema ve çerçeveler genelde sitenin kullanmadığı yüzlerce kural taşır; geliştirici araçlarının kapsam (coverage) sekmesi bunu somut olarak gösterir.

5. JavaScript: En Pahalı Kaynak

JavaScript, bayt başına en maliyetli kaynak türüdür. Bir görsel indirilir ve gösterilir; bir betik indirilir, ayrıştırılır, derlenir ve çalıştırılır. 100 KB JavaScript, 100 KB görselden çok daha fazla işlemci zamanı harcar — özellikle mobil cihazlarda.

• Kullanmadığınızı kaldırın. Yıllar içinde eklenmiş, artık kullanılmayan kütüphaneler her sitede birikir.
• defer veya async kullanın. Kritik olmayan betikler HTML ayrıştırmasını engellememeli.
• Uzun görevleri bölün. 50 milisaniyeyi aşan her görev kullanıcı etkileşimini bloke eder.
• Dekoratif işleri koşullu çalıştırın. Arka plan animasyonu, parçacık efekti ve kaydırma animasyonları mobilde kapatılabilir; kimse fark etmez, INP puanı fark eder.
• Sekme arka plandayken durdurun. Sürekli çalışan animasyon döngüleri visibilitychange ile duraklatılmalıdır.

6. Üçüncü Taraf Betikleri: Gizli Katil

Kendi kodunuzu kusursuz optimize etseniz bile, tek bir sohbet widget'ı bütün kazancı silebilir. Üçüncü taraf betiklerinin üç ayrı maliyeti vardır: kendi ağırlıkları, kurdukları ek bağlantılar ve genellikle kontrolünüz dışında oldukları için sizin optimize edemeyeceğiniz oluşları.

Yapılması gereken denetim basittir: sayfadaki tüm üçüncü taraf betiklerini listeleyin ve her biri için tek soru sorun — bunun getirdiği değer, maliyetinden fazla mı? Ayda üç kişinin kullandığı bir sohbet widget'ı, her ziyaretçiye 400 milisaniye ekliyorsa cevap hayırdır. Kalanları da mümkün olduğunca geciktirerek, kullanıcı etkileşime girdiğinde yükleyin.

7. Önbellek ve CDN

Aynı ziyaretçinin ikinci ziyaretinde dosyaları tekrar indirmesine gerek yoktur. Statik varlıklar (CSS, JavaScript, görseller, fontlar) için uzun süreli tarayıcı önbelleği tanımlayın; dosya adına sürüm bilgisi ekleyerek güncelleme sorununu çözün. HTML için ise kısa süreli önbellek doğrudur — içerik değiştiğinde kullanıcının eski sayfayı görmesini istemezsiniz.

CDN, dosyalarınızı dünyanın farklı noktalarındaki sunuculara kopyalayarak coğrafi mesafeyi ortadan kaldırır. Yurt dışı kitleye hitap eden veya görsel yoğun sitelerde etkisi belirgindir.

8. Ölçün, Tahmin Etmeyin

Her müdahaleden önce ve sonra ölçüm yapın. Ölçmediğiniz bir iyileştirmenin işe yarayıp yaramadığını bilemezsiniz — ve bazen "optimizasyon" diye yapılan şey durumu kötüleştirir.

Ölçüm yaparken üç kurala dikkat edin: aynı koşullarda test edin (aynı ağ hızı, aynı cihaz profili), birden fazla sayfa şablonu test edin (ana sayfa temsili değildir) ve karar verirken gerçek kullanıcı verisine bakın. Alan verisi ile laboratuvar verisi arasındaki farkı Core Web Vitals rehberimizde ayrıntılı ele aldık.

Nerede Durmalı?

Hız optimizasyonunda azalan verim yasası geçerlidir. LCP'yi 6 saniyeden 2,5 saniyeye indirmek dönüşümünüzü belirgin biçimde artırır; 2,5 saniyeden 2,1 saniyeye indirmek için harcanacak hafta ise büyük olasılıkla aynı sürede yazılacak iki içerikten daha az getiri sağlar.

Pratik durma noktası: üç Core Web Vitals metriği de alan verisinde "iyi" bandına girdiğinde optimizasyonu bırakıp içerik ve otoriteye dönün. Hız bir eşiktir, yarış değil.

Platforma Göre Notlar

WordPress ve benzeri sistemlerde en büyük kazanç genelde eklenti temizliğinden gelir. Her eklenti kendi CSS ve JavaScript dosyalarını her sayfaya yükler — kullanılmayan on eklenti, on gereksiz istek demektir. Önbellek eklentisi kurmadan önce eklenti sayısını azaltın.

E-ticaret sitelerinde ürün görselleri ve filtre betikleri baskın maliyettir. Kategori sayfalarında ilk ekranda görünen ürün görsellerini öncelikli, kalanını lazy yükleyin. Filtre sistemlerinin ürettiği sonsuz URL sorunu için e-ticaret SEO rehberimize bakabilirsiniz.

Statik site mimarilerinde TTFB sorunu neredeyse yoktur; dikkat edilmesi gereken tek şey istemci tarafında çalışan dekoratif JavaScript'tir.

Sonuç

Site hızını iyileştirmenin sırası şudur: önce sunucu yanıtını düzeltin, sonra görselleri optimize edin, ardından render engelleyen kaynakları temizleyin, JavaScript'i hafifletin ve üçüncü taraf betiklerini denetleyin. Her adımda ölçün, eşiği geçtiğinizde durun.

Hız çalışması teknik denetimin bir parçasıdır; bütünü için teknik SEO kontrol listemize bakabilir, sitenizin performans karnesi ve öncelikli müdahale planı için SEO danışmanlığımızdan ücretsiz ön analiz talep edebilirsiniz.

Sık Sorulan Sorular