Performans bütçesi nasıl kurulur.

Performans bütçesi, bir sayfanın aşamayacağı sayısal sınırlar kümesidir ve bir belgede değil bir testte yaşadığında bütçe olur.

Performans çalışmasının en büyük sorunu, iyileştirmenin kalıcı olmamasıdır. Bir tur optimizasyon yapılır, metrikler düzelir, üç dağıtım sonra eski hâline döner. Sebep kötü niyet değil, görünmezlik: bir kütüphane eklenir ve kimse toplam ağırlığa bakmaz.

Bütçe bu görünmezliği kapatıyor. Sınır bir teste bağlıysa, aşım dağıtım anında görünür ve bir tartışma başlar: bu özellik o kadar bayta değer mi? Tartışmanın kendisi değerlidir — bütçesiz bir projede o soru hiç sorulmaz.

Neyi ölçmeli

Bütçe kalemleri iki aileye ayrılıyor: kaynak bazlı ve metrik bazlı. İkisi birlikte kullanılmalı çünkü ayrı şeyleri yakalıyorlar.

1. 01Kaynak bazlı — toplam JavaScript, toplam CSS, toplam görsel, yazı tipi ailesi sayısı, istek sayısı. Hızlı ölçülür, sebebi doğrudan gösterir.
2. 02Metrik bazlı — LCP, INP, CLS, ilk bayt süresi. Kullanıcı deneyimini gösterir ama sebebini söylemez.
3. 03Kaynak bazlı avantajı — dağıtımdan önce, tarayıcı açmadan ölçülebilir.
4. 04Metrik bazlı avantajı — gerçekten önemli olanı ölçer.
5. 05İkisi birlikte — kaynak bütçesi erken uyarı, metrik bütçesi son kontrol.

Kaynak bütçesi özellikle değerli çünkü ucuz: bir dosya boyutunu ölçmek milisaniyeler sürer ve her derlemede koşabilir. Metrik ölçümü tarayıcı gerektirir, yavaştır ve daha seyrek koşar.

Sayı nereden gelir

Bütçe rakamı keyfi olmamalı ama mükemmel de olmak zorunda değil. İşe yarayan üç türetme yöntemi var.

Birincisi hedeften türetme: hedef cihaz ve hedef ağ belirlenir, o koşullarda istenen sürede indirilebilecek bayt miktarı hesaplanır. En sağlam yöntem ama en çok emek isteyen.

İkincisi mevcut durumdan türetme: bugünkü değer ölçülür ve bütçe onun biraz altına konur. Böylece bütçe bir hedef değil bir gerileme nöbetçisi olur — ve gerileme nöbetçisi, çoğu proje için en değerli olandır.

Üçüncüsü eşikten türetme: Google'ın iyi eşikleri alınır ve altında bir pay bırakılır. Bu sitede bütçe böyle konmuş — LCP eşiği 2,5 saniye iken bütçe 1,8; düzen kayması eşiği 0,1 iken bütçe 0,05.

Pay bırakmanın gerekçesi ölçüm gürültüsü ve gelecek yük: tavana yapışık bir bütçe, ilk küçük eklemede kırılır ve o noktada karar acele verilir. Boşluk, kararı sakin verme imkânı sağlıyor.

Bütçe resmî eşiğin altında tutulur ki gerileme, eşiğe çarpmadan önce görünsün.

Nerede yaşamalı

Bütçenin bir belgede yazılı olması hiçbir şey garanti etmiyor; belgeler okunmuyor. Bütçe bir testte yaşamalı ve o test dağıtım sürecinde koşmalı.

Bu sitede bütçe kalemleri doğrulama süitinin bir bloğunda duruyor: JavaScript ham boyutu, düzen kayması, LCP ve yazı tipi ailesi sayısı. Süit her koşumda ölçüyor ve aşım olduğunda kırmızı veriyor.

Ölçülen değerler tavanın altında: vendor kütüphaneleri gzip sonrası 55,7 kilobayt, kendi kod 28 kilobayt, stil dosyası 12,4 kilobayt. Toplam yaklaşık 96 kilobayt ve tavan 150.

Son bir tasarım kararı: bütçe aşımı bir uyarı değil bir hata olmalı. Uyarılar birikir ve görmezden gelinir; hatalar durdurur ve karar aldırır. Bir bütçenin gerçekten bütçe olup olmadığının testi, aşıldığında ne olduğudur.

Bütçe ihlali olduğunda

Bütçenin işlemesi için aşım anında ne olacağının önceden kararlaştırılmış olması gerekiyor. Aksi hâlde ilk aşımda bir tartışma başlıyor, tartışma uzuyor ve genelde bütçe yükseltilerek bitiyor — o noktada bütçe ölmüş oluyor.

Sağlıklı bir kural şu: aşım dağıtımı durdurur ve üç seçenek sunar. Özellik küçültülür, başka bir yerden yer açılır, ya da bütçe bilinçli olarak ve gerekçesiyle yükseltilir. Üçüncüsü meşrudur — ama bir karar olarak, bir kaçış olarak değil.

1. 01Küçült — özelliği daha az kodla yapmanın yolu var mı?
2. 02Yer aç — artık kullanılmayan bir kütüphane çıkarılabilir mi?
3. 03Ertele — özellik ilk yüklemede gerekli mi, yoksa etkileşimde mi gelebilir?
4. 04Bütçeyi yükselt — gerekçeyle, kayıtla ve ölçülmüş bir etki tahminiyle.
5. 05Özelliği iptal et — en az sevilen ama bazen doğru olan seçenek.

Beşinci maddenin masada olması, bütçenin gerçekten bütçe olup olmadığını belirliyor. Hiçbir özelliğin iptal edilemediği bir projede bütçe bir temenniden ibarettir.

Bu sitede bütçe kalemleri süitin bir bloğunda ve aşım doğrudan kırmızı veriyor — uyarı değil hata. Uyarılar birikiyor ve görmezden geliniyor; hatalar durduruyor ve karar aldırıyor.

Pratik kontrol listesi

Bu sayfanın anlattıklarını bir denetim adımına çevirmek gerekirse, bütçe kurulumunu için bakılacaklar şunlar. Liste kısa tutuldu çünkü uzun listeler yürünmüyor; altı madde bir oturumda tamamlanabilir.

1. 01Kalemler sayısal mı — «az tutalım» bir bütçe değil.
2. 02Hem kaynak hem metrik bazlı kalem var mı?
3. 03Rakam nereden türedi — hedef, mevcut durum ya da resmî eşik?
4. 04Eşiğin altında pay bırakıldı mı?
5. 05Bütçe bir testte mi yaşıyor?
6. 06Aşım dağıtımı durduruyor mu — yoksa yalnız uyarı mı veriyor?

Altıncı madde bir bütçenin gerçekten bütçe olup olmadığının tek testi. Uyarılar birikiyor ve görmezden geliniyor; hatalar durduruyor ve karar aldırıyor.

Bir bütçenin gerçekten bütçe olup olmadığının testi, aşıldığında ne olduğudur.

Son bir çerçeve: bütçe bir kısıt gibi görünüyor ama pratikte bir karar aracı. Bütçesiz bir projede her yeni özellik sessizce ekleniyor ve maliyeti hiç konuşulmuyor; bütçeli bir projede aynı özellik bir tartışma başlatıyor ve o tartışma çoğu zaman daha iyi bir çözüm üretiyor. Kısıtın değeri, engellediği şeyden çok zorladığı düşüncede.

Bir de kültürel boyut var ve teknik olandan zor: bütçe, ekibin tamamı tarafından sahiplenilmediğinde tek bir kişinin dayattığı bir engel gibi görünür ve ilk baskıda çöker. Sahiplenmenin yolu, bütçenin gerekçesini paylaşmaktan geçiyor — sayı nereden geldi, kimi koruyor, aşıldığında kim ne yaşıyor. Bu üç sorunun cevabı bilindiğinde bütçe bir kısıt olmaktan çıkıp ortak bir standarda dönüşüyor.