JavaScript bütçesi.
JavaScript bütçesi, bir sayfanın indirebileceği ve çalıştırabileceği kod miktarına baştan konulan ve aşılamayan bir üst sınırdır.
JavaScript, bir sayfanın en pahalı kaynağıdır ve pahalılığı boyutuyla bitmiyor. Bir görsel indirilir ve çözülür; bir betik indirilir, ayrıştırılır, derlenir ve çalıştırılır. Aynı bayt sayısında betik, görselden kat kat fazla işlemci zamanı tüketir — ve o zaman ana iş parçacığında, yani kullanıcı arayüzünün donduğu yerde harcanır.
Bu asimetri, bütçenin neden özellikle JavaScript için konulduğunu açıklıyor. Bir sayfa iki megabayt görselle yavaş ama kullanılabilir olabilir; iki megabayt betikle kullanılamaz hâle gelir.
Bütçe nasıl konur
Bütçenin işe yaraması için üç özelliği olmalı: sayısal, ölçülebilir ve pazarlık dışı. «JavaScript'i az tutalım» bir bütçe değildir; «sıkıştırılmış toplam 150 kilobaytı geçemez» bir bütçedir.
- Birim seç — sıkıştırılmış boyut mu, ham boyut mu, çalıştırma süresi mi? Üçü ayrı ayrı ölçülebilir.
- Sınır belirle — rakam, hedef cihaz ve hedef ağdan türetilmeli; rakiplerin ortalamasından değil.
- Payları ayır — vendor kütüphaneleri ne kadar, kendi kodun ne kadar?
- Teste bağla — bütçe bir belgede yazıyorsa değil, bir testte yaşıyorsa bütçedir.
- Aşımı engelle — testin kırmızı vermesi yetmez; dağıtımı durdurmalı.
Bu sitede bütçe şöyle: toplam 150 kilobayt gzip, içinde vendor kütüphaneleri yaklaşık 56 kilobayt ve kendi kod 60 kilobaytın altında. Ölçülen gerçek değerler — vendor 55,7 kilobayt, kendi kod 28 kilobayt — tavanın epey altında ve doğrulama süiti her koşumda kontrol ediyor.
Bütçenin resmî hedefin altında tutulması bilinçli. Tavana yapışık çalışan bir bütçe, ilk küçük eklemede kırılır ve o noktada ya bütçe yükseltilir ya da acele bir optimizasyon yapılır. Boşluk bırakmak, kararı acele vermek zorunda kalmamayı sağlıyor.
Envanter: neyin gerçekten gerektiği
Bütçe aşıldığında ilk refleks optimizasyon olur — kod bölme, tembel yükleme, ağaç sallama. Oysa çok daha büyük kazanç genelde bir adım geride duruyor: bu kütüphane gerçekten gerekli mi?
Tipik bir sitede yüklenen kodun kayda değer bir bölümü tek bir özellik için oradadır ve o özellik ya çok az kullanılıyordur ya da yerel araçlarla yapılabilirdir. Tarih biçimlendirme, animasyon, form doğrulama ve ikon kümeleri bu kategorinin klasik üyeleridir.
Bu sitede vendor listesi beş modülle sınırlı ve her biri gerçekten kullanılan bir özelliği taşıyor. Liste bir tercih değil bir kısıt: yeni bağımlılık eklemek proje kurallarında açıkça yasaklanmış ve harici host içerik güvenlik politikası tarafından zaten engelleniyor.
En iyi kod bölme stratejisi, hiç yüklenmeyen kütüphanedir.
Üçüncü taraf betikleri
Bütçenin en sık kırıldığı yer, geliştiricinin yazmadığı koddur: analitik, sohbet balonu, reklam, A/B test, ısı haritası. Bunlar genelde pazarlama tarafından ekleniyor, teknik ekip haberdar bile olmayabiliyor, ve toplamları çoğu sitede kendi kodun kat kat üstüne çıkıyor.
Sorun yalnız boyut değil kontrol: üçüncü taraf betiği ne zaman güncelleneceğini size sormaz ve bir gün ağırlaşabilir. Bütçeniz o betiğe bağlıysa, bütçeniz sizin kontrolünüzde değildir.
Pratik yaklaşım üç adımlı: her üçüncü taraf betiğinin ana iş parçacığına maliyetini ayrı ölçün, ölçüm karşılığında ne kazandığınızı sorun, ve kalanları etkileşim sonrasına geciktirin. Bir sohbet balonunun sayfa yüklenirken var olması gerekmiyor; kullanıcı ona tıkladığında yüklenmesi yeterli.
Bu sitede üçüncü taraf betiği yok ve gizlilik metni çerez kullanılmadığını söylüyor; doğrulama süiti bunu her koşumda ölçüyor. Karar performans kadar gizlilik kararı — ve ikisi burada aynı yöne bakıyor.
Kod bölme ve gerçek kazanç
Envanter tamamlandıktan ve gereksiz bağımlılıklar çıkarıldıktan sonra kalan kod için kod bölme devreye giriyor: her sayfa yalnız kendi ihtiyacı olan kodu yüklüyor. Klasik yaklaşımda tek bir büyük paket her sayfaya iniyor ve kullanıcı hiç görmeyeceği özelliklerin kodunu da indiriyor.
Bölmenin doğal sınırı var: çok fazla parçaya bölmek istek sayısını artırır ve her parçanın kendi ek yükü olur. Pratik denge, rota bazında bölmek ve gerçekten büyük olan bileşenleri ayrıca ayırmaktır.
İkinci teknik gecikmeli yükleme: bir özellik yalnız kullanıcı ona ihtiyaç duyduğunda yükleniyor. Bir modal içeriği, bir grafik kütüphanesi ya da bir metin editörü — hiçbiri sayfa yüklenirken gerekmiyor.
Bu sitede bölme gerekmedi çünkü toplam zaten küçük: kendi kod gzip sonrası 28 kilobayt ve hareket katmanı tüm sayfalarda kullanılıyor. Bölmenin karmaşıklığı, bu boyutta bir kazanç üretmiyor — ve gereksiz karmaşıklık da bir maliyettir.
Bütçenin bir de iletişim tarafı var ve teknik tarafından zor. Yeni bir özellik isteyen ekip, o özelliğin kaç kilobayt getireceğini genelde bilmiyor ve bilse bile o sayının ne anlama geldiğini bilmiyor. Bütçeyi işler kılan şey, sayıyı deneyime çevirebilmek: «bu kütüphane orta segment bir telefonda sayfayı yarım saniye geciktirir» cümlesi, «kırk kilobayt ekler» cümlesinden çok daha ikna edici.
Bu çeviriyi yapabilmek için ölçüm gerekiyor: özellik bir dalda uygulanır, etkisi yavaşlatılmış bir cihaz simülasyonunda ölçülür ve karar o sayıyla verilir. Süreç yavaş görünüyor ama bir kez kurulduğunda her özellik için tekrarlanabiliyor — ve tartışmayı fikirden ölçüme taşıyor.
Kapanışta bir sınır: bütçe bir üst sınır koyar, mimariyi düzeltmez. Yanlış bir mimari seçim — gereksiz bir istemci tarafı çerçevesi gibi — bütçeyi sürekli baskı altında tutar ve her yeni özellik bir tartışmaya dönüşür. Bütçe o durumda semptomu gösteriyor demektir; asıl karar bir katman yukarıda verilmelidir.
Pratik kontrol listesi
Bu sayfanın anlattıklarını bir denetim adımına çevirmek gerekirse, JavaScript yükünü için bakılacaklar şunlar. Liste kısa tutuldu çünkü uzun listeler yürünmüyor; altı madde bir oturumda tamamlanabilir.
- Toplam gzip boyutu ne — kendi kod ve vendor ayrı ayrı.
- Kaç bağımlılık var ve her biri hangi özellik için?
- Kullanılmayan kütüphane var mı — envanter, optimizasyondan önce gelir.
- Üçüncü taraf betikleri toplamı ne — genelde kendi kodun üstünde çıkar.
- Uzun görevler var mı — elli milisaniyeyi aşan her görev sayfayı dondurur.
- Bütçe bir testte mi yaşıyor, bir belgede mi?
Bu sitede ölçülen değerler: vendor gzip sonrası 55,7 kilobayt, kendi kod 28 kilobayt, üçüncü taraf sıfır. Toplam 83,7 kilobayt ve tavan 150 — pay bilinçli bırakılmış.