Performance Budget Nedir?

Sayı olmadan kural olmaz

Performans bütçesini diğer yaklaşımlardan ayıran şey, belirsizliği tolere etmemesidir. "Site hızlı olsun" bir hedef değildir; "LCP 2,5 saniyenin altında kalsın" bir kuraldır. Sayısallaştırılmamış beklentiler tartışmaya açık kalır: geliştirici bütçenin aşılmadığını düşünür, tasarımcı büyük hero görselinin vazgeçilmez olduğunu savunur, ürün sahibi özelliğin beklenemeyeceğini söyler. Bütçe bu tartışmayı nesnel bir zemine taşır.

"Hızlı" sözcüğü özneldir; "200 KB'ın altında JavaScript" nesneldir. Bu fark, performans kararlarının teknik olmayan paydaşlarla da konuşulabilmesi için şarttır.

Hangi metrikler bütçeye dahil edilir

Performance budget iki farklı ölçüt grubunu kapsayabilir: kullanıcı deneyimi metrikleri ve kaynak metrikleri.

Kullanıcı deneyimi tarafında LCP, INP ve CLS öne çıkar. Bu değerler doğrudan kullanıcının algısını ölçer; Core Web Vitals olarak arama sıralamalarını da etkiler. Kaynak tarafında ise toplam JavaScript boyutu, toplam sayfa ağırlığı, görsel boyutu ve istek sayısı gibi ölçütler yer alır. Kaynak metrikleri doğrudan kullanıcı deneyimini ölçmez ama kontrol edilmesi çok daha kolaydır; build sürecinde statik olarak analiz edilebilir.

Her iki grubu birlikte kullanmak yaygın bir yaklaşımdır. Kaynak metrikleri erken uyarı sistemi gibi çalışır — sorun henüz kullanıcıya yansımadan yakalanır. Deneyim metrikleri ise gerçek etkiyi ölçer.

Bütçe değerini neye göre belirlemek gerekir

Bütçe rakamları havadan belirlenmez. İki yaygın referans noktası vardır: rekabet analizi ve mevcut performans verisi.

Rekabet analizinde hedef kitleyle aynı alandaki sitelerin gerçek dünya performansı incelenir. CrUX (Chrome UX Report) verileri bu iş için kullanılabilir; rakiplerin LCP ve INP değerlerini görmek mümkündür. Mevcut performans verisinde ise sitenin bugünkü durumu başlangıç noktası alınır ve gerçekçi bir iyileştirme hedefi belirlenir.

Core Web Vitals'ın "iyi" eşikleri de pratik bir başlangıç noktası sunar: LCP için 2,5 saniye, INP için 200 ms, CLS için 0,1. Bu değerler sektöre ve sayfa tipine göre farklılaşabilir. Bir e-ticaret ürün sayfasının bütçesi, bir haber makalesi sayfasının bütçesiyle aynı olmak zorunda değildir.

Kaynak türlerine göre ayrım: JS, CSS, görsel

Toplam sayfa ağırlığı tek başına iyi bir bütçe birimi değildir. 1 MB'lık bir sayfa, ağırlığın tamamı görsellerden oluşuyorsa 300 KB JavaScript içeren bir sayfadan çok daha az zararlı olabilir. JavaScript hem indirme hem parse hem de execution maliyeti taşır; görseller yalnızca ağ maliyetinden ibarettir.

Bu yüzden bütçeyi kaynak türlerine göre ayırmak daha sağlıklı sonuç verir. Yaygın bir yapı şöyle kurulabilir: JavaScript için toplam 300–400 KB (sıkıştırılmış), CSS için 50–100 KB, görseller için sayfa başı 500 KB–1 MB, third-party kaynaklar için ayrı bir tavan.

Third-party kaynaklar özellikle dikkat gerektirir. Analytics, chat widget, A/B test aracı gibi eklentiler kolayca bütçeyi tüketir. Bu kaynaklar üzerinde doğrudan kontrol olmadığından bütçede ayrı bir kategori olarak tutulması önerilir.

Lighthouse performance budget desteği

Lighthouse, budget.json adında bir yapılandırma dosyasıyla performans bütçelerini destekler. Bu dosyada kaynak türlerine göre boyut ve istek sayısı limitleri tanımlanabilir. Lighthouse bu limitleri aşan kaynakları ihlal olarak işaretler ve raporun ilgili bölümünde listeler.

Söz dizimi doğrudan Lighthouse CLI'ya iletilebilir: lighthouse --budget-path=budget.json. Raporun "Performance Budget" başlığı altında hangi kaynakların aşım yaptığı ve ne kadar aştığı görünür.

Bu yaklaşımın sınırı, yalnızca dosya boyutunu ölçmesidir. Gerçek kullanıcı deneyimi metriklerini bütçelere bağlamak için Lighthouse'un --assert seçeneği ya da özel CI entegrasyonları gerekir.

CI/CD hattına entegrasyon

Bütçe kurallarının gerçek değeri, yalnızca lokal çalıştırıldığında değil, her kod değişikliğinde otomatik kontrol edildiğinde ortaya çıkar. CI/CD entegrasyonu bu süreci elle yürütme zorunluluğunu ortadan kaldırır.

Lighthouse CI (LHCI) bu iş için tasarlanmış resmi araçtır. GitHub Actions, GitLab CI veya benzeri sistemlere kurulabilir; her pull request'te Lighthouse skoru ve bütçe ihlallerini kontrol eder, belirlenen eşiğin altına düşüldüğünde build'i başarısız olarak işaretler.

Bu noktada önemli bir karar gerekir: bütçe ihlali build'i engellemeli mi, yoksa yalnızca uyarı üretmeli mi? Sıkı bir kural geliştirme hızını yavaşlatabilir; gevşek bir kural zamanla görmezden gelinen uyarılara dönüşür. Çoğu ekip kritik metrikler için engelleme, ikincil metrikler için uyarı modunu tercih eder.

Bütçe aşımında öncelik sıralaması

Bütçe ihlali gerçekleştiğinde iki seçenek vardır: yeni özelliği küçültmek ya da mevcut bir kaynağı kaldırmak. "Bir şey ekliyorsan bir şey çıkar" ilkesi — İngilizce kaynaklarda "one-for-one rule" olarak geçer — bütçeyi sürdürülebilir kılan temel disiplindir.

Pratikte bu bazen zor kararlar gerektirir. Yeni bir analytics aracı eklemek istiyorsanız ve bu araç JavaScript bütçesini aşıyorsa, mevcut araçlardan birinin kaldırılması ya da kısıtlanması gerekir. Bu karar teknik değil, ürün kararıdır. Performance budget bu kararı görünür kılar; kimin ne zaman vereceğini belirlemez ama tartışmayı başlatır.

Hedef ile bütçe arasındaki fark

"LCP'yi iyileştirmek istiyoruz" bir hedef; "LCP 2,5 saniyenin altında olmak zorunda" bir bütçedir. Bu ayrım yalnızca kelime seçimi değil, ekip davranışını doğrudan şekillendirir.

Hedefler zaman içinde ertelenebilir, bağlam değiştiğinde gözden geçirilebilir, ölçülmeden kapatılabilir. Bütçeler ise otomatik kontrol mekanizmasına bağlandığında ihlal bildirimi üretir. Bu fark büyük ekiplerde özellikle belirginleşir: herkes hedefi bilir ama kimse ne zaman ulaşıldığını takip etmez; bütçe ihlalleri ise ilgili kişiyi anında bildirimle bulur.

Kritik sayfa bütçesi ile genel site bütçesi

Tüm sayfalara aynı bütçeyi uygulamak çoğu durumda işlevsizdir. Ana sayfa, ürün sayfası ve blog yazısı farklı kaynak ihtiyaçlarına sahiptir; aynı JavaScript limitini bu üçüne birden uygulamak ya çok kısıtlayıcı ya da çok gevşek olur.

Yaygın yaklaşım, kritik sayfalar için ayrı bütçe tanımlamaktır. Dönüşüm hunisinin en önemli noktaları — ana sayfa, ödeme sayfası, ürün listeleme — en sıkı bütçeyi alır. İçerik sayfaları, yönetim paneli ya da düşük trafikli sayfalar farklı kurallara tabi tutulabilir.

Bu ayrım budget.json içinde URL pattern bazında tanımlanabilir. Belirli path'ler için farklı limitler girilir; Lighthouse ya da LHCI doğru kuralı ilgili sayfaya uygular.

Ekip sürecine yansıması

Performance budget teknik bir araçtan öte, ekip içi anlaşma belgesidir. Rakamlar belirlendikten sonra geliştiriciler, tasarımcılar ve ürün sahipleri aynı referansı kullanır. "Bu özellik performansı nasıl etkiler?" sorusu soyut olmaktan çıkar; "Bu özellik 40 KB JavaScript ekliyor, mevcut bütçemiz yalnızca 15 KB boşluk bırakıyor" gibi somut bir tartışmaya dönüşür.

Bütçe, performansı geliştirici sorumluluğundan çıkarıp ortak sorumluluk haline getirir. Tasarım kararları kaynak maliyeti taşır; içerik kararları görsel boyutunu etkiler. Bütçe bu maliyetleri görünür kılmak için ortak dil sağlar.

Bütçenin ne zaman revize edilmesi gerekir

Performans bütçesi değişmez bir kural değildir. Site büyüdükçe, işlevler arttıkça ya da kullanıcı beklentileri değiştikçe revizyona ihtiyaç duyulabilir.

Revizyon için mantıklı tetikleyiciler şunlardır: önemli bir yeni özellik eklenecek ve bütçenin buna uyarlanması gerekiyor; sektörün genel hız seviyesi yükseldi ve mevcut bütçe rekabetçi olmaktan çıktı; CI/CD entegrasyonunda sürekli ihlaller çıkıyor ve ekip bütçeyi görmezden gelmeye başladı.

Son durum özellikle dikkat çekicidir. Sürekli ihlal eden bir bütçe disiplin değil, gürültü üretir. Bu noktada ya bütçenin gevşetilmesi ya da ihlale yol açan asıl sorunun çözülmesi gerekir — ikisi arasındaki fark önemlidir.

Bütçe olmadan performans çalışmasının sınırı

Ölçüm araçları olmadan performans çalışması yapılabilir; reaktif bir yaklaşımdır ama çalışır. Bütçe olmadan da yapılabilir; JavaScript yükü ya da render blocking kaynaklar gibi sorunlar fark edildiğinde düzeltilir, döngü tekrar eder. Ancak bu yaklaşım sürdürülebilir bir sistem kurmaz.

Bütçe, Lighthouse veya diğer ölçüm araçlarını devre dışı bırakmaz — tam tersine bu araçların üzerine inşa edilir. Fark şudur: araçlar durumu gösterir, bütçe ne zaman harekete geçileceğini belirler. Her ölçüm çalışması, bir bütçeyle desteklendiğinde öncelik kazanır ve tartışılabilir bir çerçeveye oturur.