İdeal Sayfa Ağırlığı Ne Olmalı

Sayfa ağırlığı, performans tartışmalarının en somut ama en çok göz ardı edilen ölçüsüdür. Sunucunu iki kat hızlandırabilir, önbelleği kusursuz kurabilir, CDN ekleyebilirsin; ama kullanıcının indirmesi gereken 7 MB veri hâlâ 7 MB'tır ve mobil bağlantıda bunun fiziksel bir süresi vardır. Sunucu tarafındaki iyileştirmeler ilk baytı hızlandırır, sayfa ağırlığı ise ilk bayttan sonraki her şeyi belirler.

Bu yazıda önce sayfa ağırlığının tam olarak neyi kapsadığını netleştireceğim, sonra site türüne göre gerçekçi hedefler ve kaynak türüne göre bir bütçe dağılımı vereceğim. Ardından ağırlığın nereden geldiğini bulmayı, ağırlık ile istek sayısı ve işlemci maliyeti arasındaki farkı ve son olarak bir performans bütçesini pratikte nasıl denetleyeceğini anlatacağım. Amaç sana sabit bir rakam ezberletmek değil; kendi siten için savunulabilir bir tavan belirlemeni sağlamak.

Sayfa Ağırlığı Tam Olarak Nedir#

Sayfa ağırlığı, bir sayfanın tam olarak yüklenmesi için ağ üzerinden aktarılan toplam bayt miktarıdır. Kapsamı sandığından geniştir: HTML belgesi, CSS dosyaları, JavaScript paketleri, görseller, yazı tipleri, videolar, üçüncü taraf betikler ve bunların tetiklediği ek istekler.

Ölçerken iki farklı sayıyla karşılaşırsın ve karıştırılmaları yaygın bir hatadır.

Metin tabanlı kaynaklar (HTML, CSS, JS) gzip ya da brotli ile genellikle üçte bir veya dörtte bir boyuta iner; yani 900 KB'lık bir JavaScript paketi ağda 250 KB görünür. Bu iyi bir haber gibi durur ama yanıltıcıdır: tarayıcı o dosyayı çalıştırmak için açar, ayrıştırır ve derler; işlemci maliyeti açılmış boyutla orantılıdır. Görseller ve videolar ise zaten sıkıştırılmış formatlardır, ek sıkıştırma kazandırmaz.

Bir de ölçümün hangi koşulda yapıldığı meselesi var. İlk ziyaret (boş önbellek) ile tekrar ziyaret (dolu önbellek) arasında ciddi fark vardır. Hedef belirlerken ilk ziyareti esas al; kullanıcının seni ilk kez gördüğü an, kalıp kalmayacağına karar verdiği andır.

Gerçekçi Hedefler ve Bütçe Dağılımı#

Tek bir evrensel rakam yoktur; bir haber portalıyla bir kurumsal tanıtım sitesinin ihtiyaçları farklıdır. Ama aşağıdaki tablo savunulabilir bir başlangıç noktası verir. Değerler aktarılan boyut ve ilk ziyaret içindir.

Toplam rakam tek başına yeterli değildir; asıl işe yarayan, bütçeyi kaynak türüne bölmektir. Aksi hâlde tek bir ağır kalem tüm bütçeyi yer ve nereye müdahale edeceğini bilemezsin. Tipik bir içerik sitesi için makul bir dağılım şöyledir:

JavaScript satırındaki uyarıyı özellikle vurgulayayım: JavaScript, bayt başına en pahalı kaynaktır. 200 KB'lık bir görsel indirilir ve ekrana çizilir; 200 KB'lık bir JavaScript indirilir, açılır, ayrıştırılır, derlenir ve çalıştırılır. Orta seviye bir telefonda bu fark birkaç yüz milisaniyeye kadar çıkar ve doğrudan etkileşim gecikmesi olarak hissedilir.

Ağırlık Nereden Geliyor#

Hedefi aştığını gördün; şimdi kaynağını bulacaksın. Sıralama neredeyse her sitede aynıdır ve şaşırtıcı derecede öngörülebilirdir.

Görseller çoğu sitede toplam ağırlığın yarısından fazlasıdır ve en kolay kazanç buradadır. En sık görülen üç hata: gerçek gösterim boyutundan çok daha büyük bir görsel yüklemek (2400 piksellik bir fotoğrafı 600 piksellik bir alanda göstermek), eski formatlarda kalmak ve görünmeyen görselleri de baştan indirmek.

# Sayfadaki tüm görsellerin boyutunu tek tek listele
curl -s https://firmaniz.com/ \
  | grep -oE 'src="[^"]+\.(jpg|jpeg|png|webp|avif)"' \
  | cut -d'"' -f2 | sort -u | while read -r u; do
      case "$u" in /*) u="https://firmaniz.com$u";; esac
      boyut=$(curl -sIL "$u" | awk '/[Cc]ontent-[Ll]ength/{b=$2} END{print b+0}')
      printf "%9d bayt  %s\n" "$boyut" "$u"
    done | sort -rn | head -15

JavaScript ikinci sıradadır ve kaynağı genelde tek bir karar değil, zamanla birikmiş eklentilerdir. Bir kaydırıcı kütüphanesi, bir tarih seçici, bir animasyon kütüphanesi ve bunların ortak bağımlılıkları toplanır. En sık rastlanan israf, tüm sitede yalnızca bir sayfada kullanılan bir kütüphanenin her sayfaya yüklenmesidir.

Yazı tipleri sinsi bir kalemdir. Üç aile, her biri dört kalınlık ve italik varyantlarıyla birlikte kolayca 400 KB eder. Çoğu sitede gerçekten kullanılan kalınlık sayısı üçü geçmez.

Üçüncü taraf betikler ise ölçmesi en zor olanıdır çünkü kendi kaynaklarını da çekerler. Bir sohbet widget'ı 80 KB gibi görünür ama açıldığında ek betikler, yazı tipleri ve görseller yükler.

Toplam aktarımı ve istek sayısını hızlıca görmek için:

# Ana belge boyutu (sıkıştırılmış)
curl -s -H "Accept-Encoding: br,gzip" -o /dev/null \
  -w "html_aktarilan=%{size_download} bayt\ntoplam_sure=%{time_total} sn\n" \
  https://firmaniz.com/

# Sıkıştırma gerçekten aktif mi
curl -sI -H "Accept-Encoding: br,gzip" https://firmaniz.com/ | grep -i "content-encoding"

Son komut hiçbir şey döndürmüyorsa sıkıştırma kapalıdır ve bu, tek satırlık bir yapılandırmayla kazanılacak en büyük tasarruftur. Apache tarafında bunun nasıl açılacağını .htaccess önbellek ve sıkıştırma yazısında adım adım anlattım.

Ağırlık mı, İstek Sayısı mı, İşlemci Maliyeti mi#

Sayfa ağırlığına odaklanırken diğer iki boyutu unutmak yaygın bir hatadır. Üçü farklı darboğazları temsil eder.

Toplam ağırlık indirme süresini belirler ve düşük bant genişliğinde baskındır. İstek sayısı ise gecikmeyle çarpılır: her istek bir gidiş dönüş demektir ve yüksek gecikmeli mobil bağlantılarda 100 küçük dosya, aynı toplam boyuttaki 10 dosyadan belirgin biçimde yavaştır. HTTP/2 ve HTTP/3 bu maliyeti azaltmıştır ama sıfırlamamıştır. İşlemci maliyeti ise indirme bittikten sonra başlar ve zayıf cihazlarda çoğu zaman asıl darboğazdır.

Hangisinin senin sitende baskın olduğunu tahmin etme, ölç. Gerçek kullanıcılarının cihaz ve bağlantı dağılımını görmenin tek yolu saha verisidir; bunu nasıl toplayacağını RUM gerçek kullanıcı ölçümü yazısında anlattım. Kullanıcılarının çoğu masaüstünde ve hızlı bağlantıdaysa ağırlık ikinci plana düşer, mobil ağırlıklıysa birinci öncelik olur.

Ağırlığın en görünür sonucu, en büyük içerik ögesinin geç çizilmesidir. Hero görselin 1,5 MB ise LCP değerin hiçbir sunucu ayarıyla kurtarılamaz; düzeltme yöntemleri için LCP nasıl iyileştirilir yazısına bak. Geç yüklenen ve boyutu belirtilmemiş görseller ayrıca düzen kaymasına da yol açar; o tarafı da CLS düzen kayması yazısı ele alıyor.

Performans Bütçesi Kurmak ve Denetlemek#

Bütçe, yazılıp bir kenara konulduğunda işe yaramaz; denetlenmediği sürece ilk aceleci deploy'da aşılır ve bir daha geri dönülmez. Bu yüzden bütçeyi otomatik kontrol edilebilir hâle getir.

Lighthouse bir bütçe dosyasını doğrudan okuyabilir. Şöyle bir dosya hazırla:

[
  {
    "path": "/*",
    "resourceSizes": [
      { "resourceType": "document", "budget": 60 },
      { "resourceType": "stylesheet", "budget": 80 },
      { "resourceType": "script", "budget": 250 },
      { "resourceType": "image", "budget": 800 },
      { "resourceType": "font", "budget": 120 },
      { "resourceType": "third-party", "budget": 200 },
      { "resourceType": "total", "budget": 1500 }
    ],
    "resourceCounts": [
      { "resourceType": "third-party", "budget": 10 },
      { "resourceType": "total", "budget": 60 }
    ]
  }
]

Sonra kontrolü çalıştır:

# Bütçe ihlallerini raporla
npx lighthouse https://firmaniz.com/ \
  --budget-path=./butce.json \
  --only-categories=performance \
  --output=json --output-path=./rapor.json \
  --chrome-flags="--headless --no-sandbox"

# İhlal var mı diye bak
grep -o '"performance-budget".\{0,400\}' rapor.json | head -1

Bunu yayın öncesi bir adım hâline getirirsen, ağırlık artışını canlıya çıkmadan yakalarsın. Otomasyon kuramıyorsan bile ayda bir elle çalıştır ve sonucu bir yere kaydet; trend görmek tek seferlik ölçümden çok daha değerlidir.

Bütçeyi belirlerken bir tuzağa dikkat: mevcut durumunu bütçe olarak kabul etme. "Şu an 3,2 MB, bütçemiz 3,5 MB" demek yalnızca bozulmayı yasallaştırır. Bütçeyi hedefe göre koy, aradaki farkı da bir iyileştirme listesi olarak kabul et.

Sık Yapılan Hatalar#

Görselleri gösterim boyutundan büyük yüklemek. En yaygın ve en pahalı hatadır. 300 piksel genişliğinde görünen bir görsel için 1600 piksellik dosya sunmak, o kalemde beş kat israf demektir. Farklı ekran boyutları için farklı sürümler sun.

Tüm sayfalara aynı JavaScript paketini yüklemek. Yalnızca iletişim sayfasında kullanılan harita kütüphanesinin ana sayfaya yüklenmesi klasik bir israftır. Sayfaya özel yükleme yap.

Sıkıştırmayı unutmak. Gzip ya da brotli kapalıysa metin kaynaklarında üç kat fazla veri gönderiyorsun demektir. Tek satırlık bir ayarla düzelir ve etkisi anında görünür.

Yazı tipi varyantlarını sınırsız eklemek. Her kalınlık ve her italik varyant ayrı bir dosyadır. Gerçekten kullandıklarını belirle ve gerisini kaldır; ayrıca yalnızca ihtiyacın olan karakter aralığını yükle.

Üçüncü taraf betikleri ölçmemek. Kendi kodunu titizlikle küçültüp, sayfaya beş harici betik eklemek tüm kazancı silip süpürür. Her üçüncü taraf eklemesini "bu bize ne kadar ağırlık getiriyor" sorusuyla değerlendir.

Tekrar ziyareti ölçüp memnun olmak. Önbellek dolu hâlde yapılan ölçüm gerçek dışı iyi çıkar. Ölçümü mutlaka gizli sekmede ya da önbellek devre dışıyken yap.

Sıkça Sorulan Sorular#

Bir sayfa kaç MB olmalı#

Kesin bir rakam yok ama pratik bir kural olarak ilk ziyarette 1,5 MB altını hedefle, 2,5 MB'ı üst sınır kabul et. Kurumsal tanıtım siteleri ve bloglar 1 MB'ın altında kalabilir; e-ticaret ürün sayfaları ve haber portalları görsel yoğunluğu nedeniyle daha yukarıda seyreder. Önemli olan mutlak rakamdan çok, bütçeyi kaynak türlerine bölüp her kalemi ayrı takip etmektir.

Sayfa ağırlığı SEO'yu etkiler mi#

Doğrudan bir sıralama faktörü olarak değil, ama dolaylı olarak belirgin biçimde etkiler. Ağır sayfalar Core Web Vitals metriklerini bozar, bu metrikler ise sayfa deneyimi sinyalleri arasındadır. Ayrıca ağır sayfalar arama motoru tarayıcısı için de yavaştır ve tarama verimliliğini düşürür. En somut etki ise kullanıcı davranışındadır: yavaş açılan sayfa terk edilir ve bu davranış zamanla performansına yansır.

Görselleri hangi formatta sunmalıyım#

Fotoğraflar için WebP, destekleyen tarayıcılarda AVIF iyi bir tercihtir; ikisi de aynı görsel kalitede JPEG'e göre belirgin biçimde küçük dosya üretir. Logo, ikon ve düz renkli grafikler için SVG kullan; ölçeklenebilir olduğu için tek dosya her ekran yoğunluğunda keskin görünür. Şeffaflık gereken ve SVG'ye uygun olmayan durumlarda PNG yerine yine WebP tercih edilebilir. Eski tarayıcı desteği için yedek format sunmayı unutma.

JavaScript boyutu neden diğerlerinden daha kritik#

Çünkü JavaScript indirildikten sonra da maliyet üretmeye devam eder: açılır, ayrıştırılır, derlenir ve çalıştırılır. Bu işlemler ana iş parçacığında gerçekleşir ve o sırada sayfa kullanıcı girdilerine cevap veremez. Aynı boyuttaki bir görsel yalnızca indirilir ve çizilir. Bu yüzden 200 KB JavaScript, 200 KB görselden çok daha pahalıdır; özellikle orta ve alt segment telefonlarda fark birkaç kat olur.

Lazy loading her görsele uygulanmalı mı#

Hayır. Ekranın ilk görünen bölgesindeki görsellere, özellikle en büyük içerik ögesi olan hero görseline lazy loading uygulamak zararlıdır; tarayıcının o görseli geç keşfetmesine ve LCP değerinin bozulmasına yol açar. Kural şudur: ilk ekranda görünen görseller normal yüklensin, hatta öncelik verilsin; sayfanın aşağısında kalan görseller lazy yüklensin.

Sayfa ağırlığını nasıl sürekli takip ederim#

En pratik yol bir performans bütçesi dosyası tanımlayıp Lighthouse ile düzenli kontrol etmektir; bunu yayın öncesi bir adıma bağlarsan ağırlık artışı canlıya çıkmadan yakalanır. Otomasyon kuramıyorsan ayda bir aynı sayfaları aynı koşullarda ölçüp sonuçları bir tabloya kaydet. Ayrıca gerçek kullanıcı ölçümünde aktarılan bayt bilgisini de toplayabilirsin; böylece laboratuvar değil saha gerçeğini görürsün.

Kapanış#

Sayfa ağırlığı, üzerinde en çok kontrol sahibi olduğun performans değişkenidir ve sunucu tarafındaki her iyileştirmenin üzerine ekleneceği zemindir. Aklında kalması gereken dört alışkanlık şu: hedefi toplam rakam olarak değil kaynak türü bazında bütçe olarak koy, ölçümü her zaman ilk ziyaret ve boş önbellek koşulunda yap, JavaScript'i bayt olarak değil işlemci maliyeti olarak değerlendir ve bütçeyi otomatik denetlenen bir kurala dönüştür; denetlenmeyen bütçe birkaç ay içinde aşılır.

Ağırlığı düşürdükten sonra kalan darboğaz genellikle sunucu tarafındadır. Önbellek katmanı hazır gelen web hosting ve WordPress hosting paketlerimiz iyi bir başlangıç zemini sunar; görsel yoğun kataloglar ve yüksek eşzamanlılık için e-ticaret hosting ya da izole kaynaklı VDS tarafına geçebilirsin. Bütçeni belirleyip iyileştirme listesini birlikte çıkarmamızı istersen sunucu yönetimi hizmetimiz devreye girer; hedef aktarım hacminin bant genişliğine karşılığını bant genişliği hesaplayıcı aracımızla görebilirsin.