İşe yarayan performans bütçeleri
Performans bütçesi yazılıp unutulan bir doküman değil. Sınır aşılınca build’i durduran, her PR’da görünen ve ekibin ortak dili haline gelen basit bir kural.
Çoğu ekip performansla bir “iyileştirme haftası”nda ilgilenir. Ürün yavaşlar, birkaç hafta düzeltme yapılır, sonra her şey yavaş yavaş eski haline döner. Performans bütçesi bu döngüyü kırmanın bildiğimiz en basit yolu.
Az ama doğru ölçüm seçin
Her şeyi ölçmeye çalışınca hiçbir şeye bakılmıyor. Biz genelde üç ölçümle başlıyoruz:
- LCP: Sayfanın ana içeriği ne kadar sürede görünüyor?
- INP: Bir düğmeye bastığınızda arayüz ne kadar çabuk tepki veriyor?
- CLS: Sayfa yüklenirken içerik ne kadar kayıyor?
Bunlara ek olarak yayınlanan JavaScript’in boyutuna bir üst sınır koyuyoruz. Kullanıcı tarafındaki ölçümler sorunu geç haber veriyor. Paket boyutu ise sorunu kod birleşmeden yakalıyor.
Bütçeyi görünür yapın
Bütçe sadece birinin aklındaysa işe yaramıyor. Test sürecine eklenmeli ve sınır aşılınca build durmalı:
{ "budgets": { "lcp_ms": 2500, "inp_ms": 200, "cls": 0.1, "js_kb_gzip": 170 }}Her pull request’te bu sayıların nasıl değiştiğini gösteren kısa bir not, tartışmayı “bence yavaşladı”dan “LCP 300 ms arttı”ya taşıyor.
İstisnaları yazın
Bazen sınırı aşmak doğru karardır. Yeni bir özellik gerçekten değer katıyorsa buna değer. Önemli olan bunu bilerek yapmak. Sınırı yükselten her değişikliği gerekçesiyle birlikte not edin.
Hız da bir özellik. Her özellik gibi bir sahibi olmalı.
Bu siteyi de aynı kurallarla yaptık. Sayfalar önceden hazırlanıyor, yazı tipleri kendi sunucumuzdan geliyor ve ağır animasyon kütüphaneleri yerine sadece gereken kod yükleniyor.