Performans bütçesi:hızın tasarım karşılığı

Bir sayfa tek bir büyük kararla değil, zaman içinde eklenen küçük dosyalarla da yavaşlayabilir. Yeni font, yeni video ve yeni izleme aracı ayrı ayrı makul görünür. Performans bütçesi, bu kararların toplam etkisini görünür kılmak için sınırlar belirler.

Benim için performans bütçesi yaratıcılığı kısıtlayan bir yasak listesi değil, tasarım kararlarını görünür kılan bir anlaşma. Büyük bir görsel veya yeni bir animasyon eklemek istediğimde bunun karşılığında ne yüklendiğini bilmek isterim. Bana kalırsa hız ile görsel kaliteyi birbirine düşman gibi anlatmak sorunu basitleştiriyor. Asıl mesele, hangi öğenin okura yeterince değer kattığına karar verebilmek.

Temel fikir

Bütçe bir dosya boyutu, istek sayısı veya deneyim metriği üzerinden kurulabilir. web.dev bu yaklaşımı performansın proje boyunca korunmasına yardımcı bir araç olarak ele alır. Her siteye uygulanacak tek bir evrensel kilobayt sınırı yoktur; içerik ve kullanıcı koşulları önemlidir.

Bir örnek üzerinden

Bir blog için önce mevcut durumu ölç. Ardından örneğin kapak dosyaları ve başlangıç JavaScript’i için ayrı hedefler belirle. Yeni bir özellik hedefi aştığında otomatik reddetmek yerine ne kazandırdığını tartış. Bir erişilebilirlik özelliğiyle yalnızca süs için eklenen efekt aynı değerde değildir.

Nereden başlamalı?

Ekibin anlayacağı küçük bir tablo tut: ölçüm, hedef, mevcut değer, sorumlu kişi. Sayıları gerçek testten doldur. Bütçe, yaratıcılığı cezalandıran bir kural değil; güzel görünen sayfanın kullanılabilir kalmasını sağlayan ortak anlaşmadır.

Benim yaklaşımım

Bir blog ana sayfasında bütün kapakları ilk anda yüklemek yerine ilk görünen kartları önceliklendirirdim. Yeni bir efekt eklediğimde aynı sayfanın daha sade haliyle karşılaştırırdım. Etki yalnızca tasarım ekranında güzel görünüyorsa ama okumaya bir şey katmıyorsa vazgeçebilirim. Ben bütçeyi tam da bu tercihleri konuşabilmek için kullanmak isterim.