Performans Bütçesi Nedir?
Kısa tanım
Performans bütçesi, bir web sitesinin veya sayfa türünün aşmaması gereken performans sınırlarının önceden yazılı olarak belirlenmesidir. Bu sınırlar JavaScript ve görsel boyutu gibi miktarlar, LCP gibi zamanlama metrikleri ya da Lighthouse puanı gibi kural tabanlı skorlar olabilir. Bütçe, yeni bir özellik, kütüphane veya pazarlama etiketi eklenirken hızın bilinçli bir karar olarak tartışılmasını sağlar ve genellikle CI sürecinde otomatik denetlenir.
Diğer adları: performance budget, perf budget, web performans bütçesi, hız bütçesi
Hız neden bütçe ister?
Hiçbir site bir günde yavaşlamaz. Bir sprintte yeni bir slider eklenir, ertesi ay pazarlama ekibi iki takip etiketi ister, sonra bir tarih kütüphanesi gelir. Her biri tek başına makul görünür; birkaç ay sonra mobilde ana içerik bir saniye geç açılır ve kimse hangi değişikliğin sebep olduğunu hatırlamaz. Performans bütçesi bu sessiz birikimi görünür kılar: sınır yazılıdır, aşıldığında bir test kırılır ve ekip “bu özellik o maliyete değer mi?” sorusunu açıkça konuşmak zorunda kalır.
Üç tür bütçe
| Tür | Örnek sınırlar | Güçlü yanı | Zayıf yanı |
|---|---|---|---|
| Miktar tabanlı | Sayfa başına sıkıştırılmış JavaScript ≤ 170 KB, web fontu ≤ 2 dosya, üçüncü taraf istek ≤ 10 | Geliştirici için somut; derleme anında ölçülebilir | Kullanıcı deneyimini dolaylı yansıtır |
| Zamanlama metrikleri | Mobilde LCP ≤ 2,5 sn, INP ≤ 200 ms | Kullanıcının hissettiği şeye en yakın | Ölçüm koşullarına duyarlı; laboratuvarda dalgalanır |
| Kural tabanlı | Lighthouse performans puanı ≥ 90 | Kurması kolay | Bileşik skor; hangi şeyin kötüleştiğini gizleyebilir |
Tablodaki sayılar evrensel standartlar değil, örnektir. web.dev'in performans bütçesi rehberi başlangıç için mobilde kritik yol kaynaklarını sıkıştırılmış halde 170 KB civarında tutmayı örnek olarak verir; doğru değer sitenizin kitlesine ve sayfa türüne göre belirlenmelidir. Pratikte iki türü birlikte kullanmak işe yarar: zamanlama hedefi neyin önemli olduğunu, miktar sınırı ise geliştiricinin günlük olarak neyi kontrol edeceğini söyler.
Gerçekçi bir bütçe nasıl çıkarılır?
- Bugünü ölçün: Ana sayfa, kategori, ürün ve blog gibi her sayfa türünün mevcut değerlerini hem laboratuvarda hem sahada kaydedin.
- Hedefi kullanıcıdan türetin: Core Web Vitals eşikleri ve ziyaretçilerinizin gerçek cihaz/bağlantı dağılımı, zamanlama hedefini belirler.
- Zamanı bayta çevirin: Hedeflenen bağlantı hızında 2,5 saniyede kaç kilobayt kritik kaynak indirilip işlenebileceğini hesaplayın; JavaScript, CSS, font ve görsel payını buna göre dağıtın.
- Sayfa türüne göre ayırın: Etkileşimli bir yapılandırıcı ile bir blog yazısının aynı bütçeye sahip olması gerekmez.
- Takvime bağlayın: Bütçe üç ya da altı ayda bir gözden geçirilmeli; mevcut durum hedeften kötüyse önce “daha kötüye gitmesin” sınırı konup kademeli olarak sıkılaştırılabilir.
CI'da otomatik denetim
Yazılı ama denetlenmeyen bir bütçe kısa sürede unutulur. En yaygın yöntem, bütçeyi CI/CD hattına eklemektir. Lighthouse CI'da sınırlar “assertion” olarak tanımlanır; boyutlar bayt, süreler milisaniye cinsindendir:
{
"ci": {
"assert": {
"assertions": {
"largest-contentful-paint": ["error", { "maxNumericValue": 2500 }],
"resource-summary:script:size": ["error", { "maxNumericValue": 170000 }],
"resource-summary:font:count": ["warn", { "maxNumericValue": 2 }]
}
}
}
}error seviyesindeki bir ihlal pull request'i kırmızıya çevirir, warn yalnızca uyarır. Paketleyicilerin dosya boyutu uyarıları ve paket boyutunu ölçen küçük araçlar da aynı işi derleme aşamasında, tarayıcı açmadan yapar. Laboratuvar ölçümleri çalıştırmadan çalıştırmaya dalgalandığı için zamanlama sınırlarında birkaç ölçümün ortancasını almak gereksiz alarmları azaltır.
Bütçe aşıldığında
Bir bütçe ihlali “yayını durdur” emri değil, bir karar anıdır. Genellikle üç seçenek konuşulur: mevcut kodu optimize ederek yer açmak (ör. code splitting ile yalnızca gereken kodu yüklemek), başka bir şeyi kaldırmak ya da yeni özelliği daha hafif bir yolla yapmak. Bütçenin en büyük faydası teknik değil kurumsaldır: tasarım, pazarlama ve geliştirme ekipleri arasında hızın da bir maliyet kalemi olduğunu ortak bir dille konuşmayı sağlar. Özellikle etiket yöneticisi üzerinden kod deposuna uğramadan eklenen üçüncü taraf betikler CI denetimine hiç takılmaz; bunlar için saha verisini izlemek ve etiket eklemeyi bir onay sürecine bağlamak gerekir.