Görseller İçin Performans Bütçesi Nasıl Tanımlanır
Bir sayfanın görsellerinden kaynaklanan ağırlık, çoğu durumda toplam sayfa boyutunun yarısını ya da daha fazlasını oluşturur. Ancak bu oran kendi başına bir hedef değildir; hedef, belirli bir yükleme hızına ulaşmak ve bunu tutarlı biçimde korumaktır. Performans bütçesi, bu hedefi sayıya dökmek için kullanılan bir çerçevedir: sayfanın belirli bir bölümüne - örneğin görsellere - ne kadar bayt harcayabileceğinizi önceden tanımlarsınız ve bu sınırı aşan her değişiklik otomatik olarak işaretlenir.
Bütçesiz bir ortamda görsel ağırlığı zamanla siner siner büyür. Bir geliştirici 300 KB'lik bir hero görseli yükler, tasarımcı bir sonraki sprintte bunu 450 KB'lik bir versiyonla değiştirir, pazarlama iki yeni banner ekler; üç ay sonra giriş sayfanız 2,5 MB görsel yükünü taşır ve bunu fark eden olmamıştır. Ölçüm olmadan optimizasyon yapılır, sonra yeniden şişirilir.
Görsel performans bütçesi tanımlamak iki ayrı işten oluşur: önce doğru sayıyı bulmak, sonra bu sayıyı geliştirme sürecine bağlamak. İkincisi olmadan birincisi kağıt üzerinde kalır.
Performans bütçesi nedir ve görsel kotası nasıl belirlenir
Performans bütçesi (performance budget), bir sayfanın yüklenme kalitesine dair ölçülebilir bir sınır kümesidir. Bütçe, bayt cinsinden ifade edilebileceği gibi metrik cinsinden de ifade edilebilir: "toplam görsel ağırlığı 500 KB'ı geçmeyecek" bir bayt bütçesidir; "LCP 2,5 saniyenin altında kalacak" ise metrik bütçesidir. Her ikisi de geçerlidir, ancak farklı şeyleri ölçer ve farklı noktalarda devreye girer.
Görsel kotasını belirlemek için önce toplam sayfa bütçesini netleştirmeniz gerekir. Başlangıç noktası olarak kullanılan yaygın bir yaklaşım, 3G koşullarında sayfa ağırlığını 1 MB'ın altında tutmak ve bu bütçenin görsel payını en fazla yüzde elli olarak tanımlamaktır. Ancak bu rakamlar bağlama göre değişir: bir SaaS ürününün giriş sayfası için rekabetçi bir hedef belirlemek istiyorsanız, rakiplerinizin mevcut değerlerini bir referans noktası olarak kullanmak, soyut bir "iyi pratik" sayısından çok daha somut bir başlangıç sağlar. Bir web sitesini performans aracıyla analiz edip görsel ağırlıklarına bakarsanız ve ortalamanın 300-400 KB arasında olduğunu görürseniz, kendi hedefinizi 250 KB olarak belirlemek rekabetçi bir konum anlamına gelir.
Bayt bütçesi ile metrik bütçesi arasındaki fark pratikte önemlidir. Bayt bütçeleri önceden, kod incelemesinde veya CI sürecinde kontrol edilebilir; görsel dosyaları yüklenip ağ koşullarına bağlı olarak değişmeden önce kural işletilebilir. Metrik bütçeleri ise ancak gerçek ya da simüle edilmiş bir yüklemeden sonra ölçülebilir. Her ikisini birlikte kullanmak, birinin diğerini geçersiz kılmamasını sağlar; yüksek kaliteli görsel yüklüyorsunuz ama CDN önbellek hiti sayesinde hızlı mı yükleniyor? Bayt bütçesini geçmişsinizdir ama LCP hedefini tutturmuşsunuzdur.
LCP ve toplam sayfa ağırlığı arasındaki görsel payı
Largest Contentful Paint (LCP), çoğu sayfa için birincil performans metriğidir ve büyük çoğunlukla bir görsel tarafından tetiklenir. LCP elementinin bir görsel olduğu sayfalarda, bu görselin boyutu ve yükleme önceliği skoru direkt etkiler. Standart hedef 2,5 saniyenin altıdır; bu hedefi tutturmak için LCP görselinin genellikle ilk sunucudan gelen baytları beklemeden başlaması, yani önceden keşfedilmesi ve yeterince küçük olması gerekir.
LCP görselini diğer görsellerden ayrı tutmak performans bütçenizi daha etkili kılar. Tek bir monolitik "görsel bütçesi" yerine iki katmanlı bir yapı işe yarar: LCP görseli için ayrı bir sınır - genellikle 100-150 KB civarı, format ve çözünürlüğe göre değişmekle birlikte - geri kalanı için daha esnek bir toplam. Bu ayrım, LCP dışındaki görsellerin büyük ama lazy-loaded olmasına izin verirken kritik yolu korumanızı sağlar.
Toplam sayfa ağırlığı içinde görsel payını izlemenin pratik yolu, sayfa türü başına referans değerler oluşturmaktır. İçerik sayfası için kabul edilebilir olan, ürün detay sayfasında çok düşük kalabilir. Rakamlar kadar önemli olan bu rakamların zamanla nasıl değiştiğini izlemektir; tek bir ölçüm bir referans noktasıdır, trend ise gerçek veridir.
Sayfa türüne göre bütçe farklılaştırması
Tek bir görsel bütçesini tüm sayfalara uygulamak cazip görünür, çünkü basittir. Gerçekte işe yaramaz.
Giriş sayfası, çok sayıda ziyaretçiyi karşılayan ve genellikle tek bir hero görseli ile birkaç destek görseli içeren bir yapıdadır; burada toplam görsel bütçesini 400-500 KB gibi düşük bir değerde tutmak mantıklıdır. Bir ürün kataloğu veya fotoğraf galerisi içeren sayfa, doğası gereği daha fazla görsel barındırır; burada bireysel görsel boyutunu sınırlamak, toplam ağırlığı sınırlamaktan daha anlamlıdır. Blog yazıları ise büyük çoğunlukla bir ya da iki görsel içerir ve bu sayfalarda toplam görsel ağırlığından çok LCP görseli önceliği kritiktir.
Sayfa türüne göre bütçe tanımlamak şu soruyu yanıtlamayı gerektirir: bu sayfayı kim, hangi cihazdan ve hangi ağ koşullarında ziyaret ediyor? E-ticaret trafiği ağırlıklı olarak mobilden geliyorsa ve kullanıcılar ürün fotoğraflarını sıklıkla inceliyorsa, ürün detay sayfası için daha esnek ama giriş sayfası için çok daha katı bir bütçe belirlemek gerekir. Kullanıcı profiline uymayan bütçe ya çok kısıtlayıcı olup gereksiz sürtüşme yaratır, ya da çok gevşek olup bütçenin var olma amacını ortadan kaldırır.
Pratik bir yaklaşım, her sayfa türü için üç değer tanımlamaktır: hedef - normal koşullarda ulaşılması beklenen değer - uyarı eşiği - geçildiğinde inceleme tetikleyen değer - blok eşiği - geçildiğinde dağıtımı durduran değer. Bu üç katman, tek bir sert sınırdan çok daha az gürültü üretir ve ekibin gerçekten sorunlu değişiklikleri görmesini kolaylaştırır.
CI/CD sürecine bütçe kontrolü entegre etmek
Bütçeyi belgeye yazmak yetmez. Kontrol otomatik değilse zamanla devre dışı kalır; bir sprint sıkışır, sınır aşılır, kimse fark etmez, sonraki sprintte referans değer kayar.
CI/CD entegrasyonunun en yaygın yolu Lighthouse CI'dır. Konfigürasyon dosyasında görsel ağırlığına dair eşikler tanımlanabilir ve bu kontroller pull request açıldığında otomatik çalışır. Lighthouse CI dışında, bayt bütçesi kontrolü için özelleştirilmiş paketler de vardır; bundlesize gibi araçlar belirtilen dizindeki dosyaların boyutunu bir eşikle karşılaştırıp CI çıktısında başarısız sayar.
Lighthouse CI ile temel bir bütçe yapılandırması şöyle görünür:
// lighthouserc.js
module.exports = {
ci: {
assert: {
assertions: {
"resource-summary[image].size": ["error", { maxNumericValue: 512000 }],
"largest-contentful-paint": ["warn", { maxNumericValue: 2500 }],
},
},
},
};
Bu yapılandırma, görsel kaynaklarının toplam boyutunu 500 KB ile sınırlar ve LCP değeri 2,5 saniyeyi geçerse uyarı üretir. Uyarı ile hata arasındaki fark kasıtlıdır: LCP koşula bağlı olduğundan, ağ gecikmesine ve önbellek durumuna göre değişebildiğinden, hard fail yerine uyarı tercih edilir; toplam görsel boyutu deterministik olduğundan hata olarak tanımlanabilir.
Lighthouse'un tüm overhead'ini istemiyorsanız, özel betikler de aynı işi yapar. Özellikle statik site üreticilerinde, derleme çıktısındaki görsel dizinini tarayıp boyutu toplayan ve eşiği aşan dosyaları listeleyen birkaç satırlık bir Node.js betiği daha doğrudan bir çözümdür. Araç seçimi önemli değil; önemli olan kontrolün derleme sürecine bağlı olmasıdır.
Bütçe aşımında uyarı ve blok stratejisi
Her bütçe aşımında dağıtımı durdurmak, ekibin zamanla kuralı atlatma yolları aramasına yol açar. Önce ortama uygun bir strateji belirlemek gerekir.
Uyarı ve blok ayrımının pratikte anlamı şudur: uyarı, geliştiricinin bir şeyin yanlış olduğunu bilmesi ama aciliyet yoksa dağıtımın devam etmesidir; blok, değişikliğin gönderilmeden önce düzeltilmesi gerektiğidir. LCP görseli için belirlenmiş bayt sınırını aşmak blok sebebidir; lazy-loaded galerinin toplam ağırlığının uyarı eşiğini geçmesi ise uyarı sebebidir. Kural koyarken bu farkı netleştirmemek, ya sürekli gürültü üreten bir CI çıktısına ya da kimsenin ciddiye almadığı bir blok mekanizmasına yol açar.
Bir de geri bildirim kalitesi meselesi var. CI çıktısı yalnızca "bütçe aşıldı" diyorsa, geliştirici neyin sorun olduğunu bulmak için ek zaman harcar. İyi bir hata mesajı hangi dosyanın kaç KB olduğunu, hangi eşiği ne kadar aştığını ve olası düzeltme adımını içerir. Bu ayrıntı çoğu zaman aracın konfigürasyonunda değil, özel betik mantığında sağlanır.
Bütçe aşımlarını zaman içinde izlemek de anlamlıdır. Aşımlar sık tekrarlanıyorsa ya bütçe çok sıkı ayarlanmıştır ya da optimizasyon alışkanlıkları yeterli değildir. İkisi aynı görünür ama çözümleri farklıdır: birinde eşiği yükseltmek gerekir, diğerinde geliştirme akışında bir değişiklik.
Görsel performans bütçesinin işe yaramadığı ya da gereksiz kaldığı durumlar
Performans bütçesi her projeye uygun değildir. Görsel dosyaları derleme sürecinde değil kullanıcı yüklemesiyle geliyorsa, CI'daki boyut kontrolü yanlış noktaya odaklanmış demektir; doğru çözüm yükleme sırasında otomatik optimizasyon uygulamaktır. Bir CDN ya da görsel işleme servisi zaten boyut kırpma, format dönüştürme ve sıkıştırma yapıyorsa, kaynak dosyanın boyutunu kısıtlamak anlamsızlaşır.
Prototipler ve tek seferlik içerikler için de bütçe kurulumu orantısız maliyet yaratır. CI entegrasyonu ciddi bir yapılandırma ve bakım gerektirdiğinden, bütçe yönetiminden en çok fayda sağlayan ortamlar uzun vadeli, birden fazla kişinin katkı verdiği ve içeriğin sürekli değiştiği projelerdir. Tek geliştirici ve az sayıda sayfası olan bir sitede, manuel kontrol otomasyondan daha pratik olabilir.
Görsel ağırlığını düşürmek performans sorununu her zaman çözmez. Sayfa yavaş yükleniyorsa ve nedeni analiz edilmemişse, görsel bütçesi belirleyip görsel boyutunu küçültmek yanlış yerde çalışmak olabilir; yavaş TTFB, render-blocking kaynaklar veya büyük JavaScript paketleri aynı semptomu üretir. Performans bütçesi bir önleme aracıdır, teşhis aracı değildir.
Sayıyı doğru belirleyip CI'a bağlamak temel adımdır, ancak asıl değer buradan gelir: bir bütçenin varlığı, görsel kararlarını hız kavramıyla ilişkilendirir. Geliştirici pull request açarken bütçe uyarısı alıyorsa, optimizasyon sonradan düşünülecek bir adım olmaktan çıkar. Bu kültürel değişim, bazen sayının kendisinden daha önemli hale gelir.
Bütçeyi belirledikten sonra zaman zaman gözden geçirin. Kullanıcı kitlesi, cihaz dağılımı ve bağlantı koşulları değiştikçe makul olan eşik de değişir; aylar önce belirlenen bir bütçeyi sorgulamadan uygulamak, ona hiç sahip olmamaktan çok farklı değildir.