Performans Bütçesi (Performance Budget) Belirleme

Her site aynı hikâyeyi yaşar: lansmanda hızlıdır, altı ay sonra yavaştır. Kimse "sitemizi yavaşlatalım" diye karar vermez; sadece bir analitik betiği, bir canlı destek widget'ı, bir A/B test aracı ve üç yeni yazı tipi eklenir. Her biri tek başına "sadece 40 KB" olduğu için hiçbiri reddedilmez. Yavaşlama tek bir kararın değil, kırk küçük kararın toplamıdır ve hiçbir aşamada alarm çalmaz.

Performans bütçesi tam olarak bu alarmı kurar. Sayfanızın ağırlığı, JavaScript miktarı ve LCP süresi için önceden sayısal bir üst sınır belirlersiniz; sınırı aşan her değişiklik, üretime çıkmadan önce görünür hale gelir. Bu rehberde bütçe türlerini, başlangıç eşiklerini nereden alacağınızı, bütçeyi Lighthouse ile nasıl otomatik denetleyeceğinizi ve sınır aşıldığında ne yapılacağını anlatacağım. Amaç bir kereye mahsus hızlanma değil, hızı kalıcı kılan bir süreç kurmak.

Performans Bütçesi Nedir ve Neden İşe Yarar#

Performans bütçesi, sitenizin belirli metriklerinin aşmaması gereken sayısal sınırlar kümesidir. Mali bütçeyle aynı mantıkla çalışır: harcayabileceğiniz miktar sabittir, yeni bir kalem eklemek istiyorsanız başka bir yerden kısmanız gerekir. "Bu widget'ı ekleyelim mi?" sorusu, bütçe varken "evet ama JavaScript bütçemizde 60 KB yerimiz kaldı, bu widget 140 KB" cevabına dönüşür ve tartışma zevk meselesi olmaktan çıkıp ölçülebilir bir karara indirgenir.

Bütçenin asıl faydası teknik değil, örgütseldir. Performans, sahibi olmayan bir konudur: pazarlama takip kodu ekler, tasarım yeni bir yazı tipi ister, geliştirici bir kütüphane çeker ve hiçbiri sonucun tamamından sorumlu hissetmez. Bütçe bu sorumluluğu somutlaştırır. Ayrıca "yavaş" gibi öznel bir şikâyeti "ana sayfa JavaScript bütçesini %38 aşıyor" gibi üzerinde çalışılabilir bir cümleye çevirir.

İkinci fayda regresyon korumasıdır. LCP iyileştirme çalışması yapıp sayfanızı 4.2 saniyeden 1.9 saniyeye indirdiğinizi düşünün. Bütçe yoksa bu kazanım birkaç sürüm sonra sessizce geri alınır. Bütçe varsa, kazancı yiyen değişiklik daha birleştirilmeden (merge) fark edilir.

Üç Bütçe Türü ve Hangisiyle Başlanmalı#

Pratikte üç tür bütçe kullanılır ve en güçlü sonucu üçünü birlikte kullandığınızda alırsınız.

Nicelik bütçesi (quantity budget) en somut olanıdır: kaç KB JavaScript, kaç KB görsel, toplam kaç istek. Ölçmesi kolaydır ve tartışmaya yer bırakmaz. Geliştiricinin doğrudan kontrol edebildiği tek bütçe türüdür.

Zamana dayalı bütçe (timing budget) kullanıcının gerçekte hissettiği şeyi ölçer: LCP, INP, TTFB, Speed Index. Kullanıcı deneyimiyle en ilgili olan budur ama ağa, cihaza ve sunucuya bağlı olduğu için gürültülüdür.

Kural tabanlı bütçe (rule-based budget) ise bir puanı hedefler: "Lighthouse performans skoru 90'ın altına düşmeyecek". Yönetime anlatması kolaydır ama tek bir sayının arkasındaki nedeni gizlediği için sorun çözmede en zayıf olanıdır.

Başlamak için önerim şudur: bir nicelik bütçesi (JavaScript boyutu) ve bir zamana dayalı bütçe (LCP) ile başlayın. İkisi birlikte hem sebebi hem sonucu kapsar. Puana dayalı bütçeyi yalnızca raporlama için kullanın, kapı olarak değil.

Başlangıç Eşiklerini Nereden Almalı#

Bütçe rakamlarını havadan uydurmak, bütçeyi ilk hafta anlamsız kılar. Üç sağlam kaynak vardır.

Birincisi: mevcut durumunuz eksi bir pay. Ana sayfanız şu an 340 KB JavaScript gönderiyorsa, bütçeyi 300 KB koyup üç ayda 220'ye indirmeyi hedefleyin. Ulaşılabilir bir sınır, ihlal edildiğinde ciddiye alınır; ulaşılamaz bir sınır ilk gün görmezden gelinmeye başlar.

İkincisi: rakipleriniz. Kullanıcı sitenizi mutlak bir standartla değil, aynı sektördeki alternatiflerle karşılaştırır. Rakiplerinizin sayfa ağırlığını komut satırından hızlıca ölçebilirsiniz:

# Tek bir kaynağın sıkıştırılmış boyutu ve TTFB'si
curl -s -o /dev/null -w "boyut: %{size_download} bayt | ttfb: %{time_starttransfer}s | toplam: %{time_total}s\n" \
     -H "Accept-Encoding: gzip, br" https://rakip-site.com/

# Sayfadaki tüm script etiketlerini listele (kaç tane harici JS var)
curl -s https://rakip-site.com/ | grep -o 'src="[^"]*\.js[^"]*"' | sort -u | head -20

Hedef, en hızlı rakibinizden %20 daha hafif olmaktır. Bu, ölçülebilir bir rekabet avantajıdır.

Üçüncüsü: cihaz ve ağ gerçekliği. Bu, en dürüst yöntemdir. Türkiye'de mobil trafiğin önemli bir kısmı orta segment Android telefonlardan ve değişken hızlı mobil bağlantılardan gelir. 1.5 saniyede LCP hedefliyorsanız ve bağlantı gerçek dünyada 1.6 Mbps veriyorsa, ilk ekran için harcayabileceğiniz toplam bayt matematiksel olarak sınırlıdır:

1.6 Mbps ≈ 200 KB/saniye
Hedef LCP: 2.5 saniye
Bağlantı kurulumu + TTFB: yaklaşık 0.8 saniye
Kalan indirme süresi: 1.7 saniye
Kritik yol bütçesi: 1.7 × 200 KB ≈ 340 KB

Bu 340 KB'ın içine HTML, kritik CSS, yazı tipleri, LCP görseli ve başlatıcı JavaScript'in hepsi girmek zorundadır. Rakamı bu şekilde türettiğinizde bütçe artık keyfî değil, fizikseldir.

Genel amaçlı bir içerik sitesi için makul bir başlangıç seti:

Bütçeyi Lighthouse ile Otomatik Denetlemek#

Elle takip edilen bütçe, takip edilmeyen bütçedir. Lighthouse bir budget.json dosyasını doğrudan okur ve ihlalleri raporunda ayrı bir bölümde listeler. Dosya şu biçimdedir:

[
  {
    "path": "/*",
    "resourceSizes": [
      { "resourceType": "script",     "budget": 170 },
      { "resourceType": "stylesheet", "budget": 60  },
      { "resourceType": "image",      "budget": 250 },
      { "resourceType": "font",       "budget": 100 },
      { "resourceType": "total",      "budget": 600 }
    ],
    "resourceCounts": [
      { "resourceType": "third-party", "budget": 8 },
      { "resourceType": "total",       "budget": 50 }
    ],
    "timings": [
      { "metric": "largest-contentful-paint", "budget": 2500 },
      { "metric": "cumulative-layout-shift",  "budget": 100  },
      { "metric": "total-blocking-time",      "budget": 300  }
    ]
  }
]

Boyutlar kilobayt, süreler milisaniye cinsindendir. Çalıştırmak için:

npm install -g lighthouse

lighthouse https://firmaniz.com/ \
  --budget-path=./budget.json \
  --preset=desktop \
  --output=html --output-path=./rapor.html

# Mobil (varsayılan) ve yavaş bağlantı benzetimiyle
lighthouse https://firmaniz.com/ --budget-path=./budget.json --view

Asıl kazanç, bunu sürüm hattına (CI) bağlamaktır. Lighthouse CI ile eşiklerin altına düşen bir değişiklik doğrudan başarısız olur:

npm install -g @lhci/cli
lhci autorun --collect.url=https://firmaniz.com/ --upload.target=temporary-public-storage

Yapılandırma dosyasında sıkı eşikler tanımlarsınız:

// lighthouserc.js
module.exports = {
  ci: {
    collect: {
      url: ['https://firmaniz.com/', 'https://firmaniz.com/urunler'],
      numberOfRuns: 3, // gürültüyü azaltmak için üç kez koş, ortancayı al
    },
    assert: {
      assertions: {
        'categories:performance': ['error', { minScore: 0.9 }],
        'largest-contentful-paint': ['error', { maxNumericValue: 2500 }],
        'total-blocking-time': ['error', { maxNumericValue: 300 }],
        'cumulative-layout-shift': ['error', { maxNumericValue: 0.1 }],
        'resource-summary:script:size': ['error', { maxNumericValue: 174080 }],
      },
    },
  },
};

numberOfRuns: 3 satırını atlamayın. Tek koşumluk Lighthouse sonuçları koşudan koşuya kolayca %10 oynar; üç koşumun ortancasını almak yanlış alarmları büyük ölçüde keser. WordPress gibi hazır bir sistem kullanıyor ve CI kurmak istemiyorsanız, GTmetrix ile WordPress hız testi yazısındaki düzenli manuel ölçüm rutini de işinizi görür — önemli olan aracın kendisi değil, ölçümün düzenli olmasıdır.

Bütçe Aşıldığında Ne Yapılır#

Bütçenin işe yaraması için ihlalin bir sonucu olmalıdır. Aksi halde üç ay içinde herkesin görmezden geldiği kırmızı bir uyarıya dönüşür. İhlal durumunda uygulanabilir dört seçenek vardır ve sırayla değerlendirilmelidir:

1. Kaldır. Eklenmek istenen kaynak gerçekten gerekli mi? Analitik araçların üçü birden gerekli mi, ikisi yeterli mi? En ucuz bayt, hiç gönderilmeyen bayttır.
2. Ertele. Kaynak gerekliyse ama ilk ekran için gerekli değilse, etkileşim sonrasına ya da görünürlüğe bağlı olarak yükleyin. Canlı destek widget'ı, sayfa yüklendiği anda değil kullanıcı ilk kez kaydırdığında ya da beş saniye sonra yüklenebilir.
3. Takas et. Bütçe sabitse, yeni kalem için yer açın. 140 KB'lık bir kütüphane ekleniyorsa, kullanılmayan başka bir kütüphane çıkarılmalıdır. Bu, bütçenin en sağlıklı işleyiş biçimidir.
4. Bütçeyi bilinçli olarak yükselt. Bazen doğru karar budur; önemli olan bunun kaza değil, gerekçesi yazılmış bir karar olmasıdır. Yükseltiyorsanız tarihini ve sebebini kaydedin.

Erteleme örneği pratikte şuna benzer:

<script>
  // Üçüncü parti betiği ilk etkileşime ya da 6 saniyeye kadar geciktir
  (function () {
    var yuklendi = false;
    function yukle() {
      if (yuklendi) return;
      yuklendi = true;
      var s = document.createElement('script');
      s.src = 'https://ucuncu-parti.example.com/widget.js';
      s.async = true;
      document.head.appendChild(s);
    }
    ['pointerdown', 'keydown', 'touchstart', 'scroll'].forEach(function (olay) {
      window.addEventListener(olay, yukle, { once: true, passive: true });
    });
    setTimeout(yukle, 6000);
  })();
</script>

Bu kalıp, ölçülebilir bir kazanç sağlar çünkü betik artık ilk yükleme yarışına katılmaz; LCP ve TBT bütçelerinizin ikisini birden rahatlatır.

Sık Yapılan Hatalar#

Tek bir bütçeyi tüm sayfalara uygulamak. Ana sayfa, ürün listesi ve blog yazısı farklı işler yapar; hepsine aynı JavaScript sınırını koymak ya çok gevşek ya çok sıkı olur. budget.json dosyasında path alanıyla sayfa gruplarına ayrı bütçeler tanımlayın.

Sıkıştırılmamış boyutu ölçmek. Kullanıcı sıkıştırılmış baytı indirir, sıkıştırılmamışını değil. Bütçeyi Brotli veya gzip sonrası boyut üzerinden yazın; ama JavaScript'in ayrıştırma ve çalıştırma maliyetinin sıkıştırılmamış boyutla orantılı olduğunu unutmayın. 170 KB sıkıştırılmış JavaScript, orta segment bir telefonda 600 KB'lık kod ayrıştırma işi demektir.

Yalnızca laboratuvar verisine bakmak. Lighthouse benzetim yapar; gerçek kullanıcılarınız farklı cihaz ve ağlardadır. Laboratuvar bütçesini regresyonu yakalamak, saha verisini (Core Web Vitals) gerçeği bilmek için kullanın. İkisi arasında büyük fark varsa, benzetim ayarlarınız gerçek ziyaretçi profilinizi yansıtmıyordur.

Üçüncü partileri bütçenin dışında tutmak. "Bu bizim kodumuz değil, sayılmasın" en sık duyduğum bahanedir. Kullanıcının tarayıcısı böyle bir ayrım yapmaz. Üçüncü parti kaynaklar için ayrı ve daha sıkı bir bütçe koyun; kontrol edemediğiniz kod, kontrol ettiğinizden daha risklidir.

Bütçeyi kimseye duyurmamak. Yalnızca CI'da yaşayan bir bütçe, geliştirici dışında kimseyi etkilemez. Oysa ihlallerin çoğu pazarlama ve tasarım kaynaklıdır. Bütçeyi ekipçe görünür bir yerde tutun ve yeni araç taleplerinde ilk soru "bütçede yeri var mı" olsun.

Sıkça Sorulan Sorular#

Performans bütçesi belirlemek küçük siteler için de gerekli mi#

Evet, hatta küçük siteler için daha kolaydır çünkü henüz yozlaşmamış bir başlangıç noktanız vardır. Beş sayfalık bir kurumsal sitede bile bir yıl içinde üç analitik kodu, bir çerez bildirimi ve iki yazı tipi birikir. Tek sayfalık basit bir bütçe (JavaScript sınırı ve LCP hedefi) bile bu birikimi görünür kılar. Karmaşık bir CI kurmanız da gerekmez; ayda bir kez elle Lighthouse çalıştırmak bile başlangıç için yeterlidir.

Bütçe rakamlarını hangi sıklıkla gözden geçirmeliyim#

Üç ayda bir gözden geçirmek makul bir ritimdir. Bütçeyi hiç ihlal etmiyorsanız muhtemelen fazla gevşektir ve sıkılaştırılabilir; sürekli ihlal ediyorsanız ya gerçekçi değildir ya da yapısal bir sorun vardır. Ayrıca büyük bir yeniden tasarım, çerçeve (framework) değişikliği ya da yeni bir ürün hattı eklendiğinde bütçeyi mutlaka yeniden değerlendirin.

Lighthouse skoru ile Core Web Vitals arasındaki fark nedir#

Lighthouse laboratuvar ölçümüdür: belirli bir cihaz ve ağ benzetimi altında, o an, sizin tarafınızdan çalıştırılır. Core Web Vitals ise saha verisidir; gerçek ziyaretçilerinizin gerçek cihazlarından toplanan 28 günlük gerçek ölçümlerdir ve arama sıralamasında dikkate alınan da budur. Lighthouse regresyonu erken yakalar, saha verisi gerçeği söyler. Bütçenizde ikisini de tutun ama karar verirken saha verisine öncelik verin.

JavaScript bütçesi için ideal rakam nedir#

Evrensel bir rakam yok ama sıkıştırılmış 170 KB, orta segment bir mobil cihazda kabul edilebilir ayrıştırma süresi sağladığı için yaygın bir başlangıç eşiğidir. Bir yönetim paneli ya da harita uygulaması bu sınırı doğal olarak aşar; bir blog ya da kurumsal site ise bunun çok altında kalabilmelidir. Kendi sayfa türünüz için hedefi, "en hızlı rakibimden %20 hafif" kuralıyla belirlemek pratikte en işe yarayan yöntemdir.

Bütçe aşıldığında sürümü gerçekten durdurmalı mıyım#

Kritik yol metrikleri için evet, aksi halde bütçe sadece bir tavsiye olur ve tavsiyeler kalabalık bir sürüm gününde göz ardı edilir. Ancak makul bir esneklik payı bırakın: %5'lik bir aşımı uyarı, %20'lik bir aşımı hata olarak işaretleyin. Ayrıca acil bir düzeltmenin bütçe yüzünden bekletilmemesi için açık bir istisna prosedürü tanımlayın — istisnanın kaydı tutulsun ve bir sonraki sürümde kapatılsın.

Görsel bütçesini nasıl kontrol altında tutabilirim#

Görseller neredeyse her zaman sayfa ağırlığının en büyük kalemidir ve iyi haber şu ki en kolay küçültülen kalem de odur. Üç kural yeter: modern format kullanın (WebP ya da AVIF), gerçek görüntüleme boyutunda servis edin (1600 piksel genişliğinde bir görseli 400 piksellik bir alana koymayın) ve ilk ekran dışındaki tüm görselleri tembel yükleyin. Ayrıca yükleme akışına bir boyut denetimi ekleyerek belirli bir eşiğin üstündeki dosyaların hiç yayına çıkmamasını sağlayabilirsiniz.

Kapanış#

Performans bütçesi, hız çalışmasını bir seferlik projeden sürekli bir alışkanlığa çeviren şeydir. Aklınızda kalması gereken dört madde: bütçeyi mevcut durumunuz, rakipleriniz ve gerçek ağ koşullarınızdan türetin; en az bir nicelik (JavaScript boyutu) ve bir zamana dayalı (LCP) sınır tanımlayın; denetimi otomatikleştirin ki kimsenin hatırlamasına gerek kalmasın; ve ihlal edildiğinde kaldır-ertele-takas et sırasını izleyin.

Bütçenizin sunucu tarafındaki bacağı olan TTFB için altyapı da belirleyicidir; yavaş bir sunucuda hiçbir ön yüz optimizasyonu 2.5 saniyelik LCP hedefini kurtaramaz. NVMe diskli web hosting ve WordPress hosting paketlerimiz ilk bayt süresini düşük tutmak için yapılandırılmıştır; daha fazla kontrol isterseniz VDS sunucularında önbellek katmanını kendi ölçülerinize göre kurabilirsiniz. Ayar ve ölçüm tarafını bize bırakmak isterseniz sunucu yönetimi hizmetimiz devrededir.