Bir web sitesi ilk yayımlandığında çoğu zaman hızlı hissedilir. Sayfa sayısı azdır, görseller sınırlıdır ve birkaç küçük bileşen yeterlidir. Zamanla analitik betikleri, sohbet araçları, büyük görseller, yeni yazı tipleri ve etkileşimli bileşenler eklenir. Her değişiklik tek başına makul görünür; fakat toplamda kullanıcı ilk içeriği görmeden önce daha fazla ağ isteği, JavaScript ayrıştırması ve ana iş parçacığı işi bekler.
Performans bütçesi bu birikimi görünür kılar. Bir sayfanın ne kadar hızlı olması gerektiğini genel bir dilek yerine ölçülebilir sınırlar olarak tanımlar: kritik rota için JavaScript boyutu, görsel ağırlığı, üçüncü taraf istek sayısı, başlangıçtaki ağ isteği ve kullanıcıya görünen ya da etkileşime hazır hâle gelen ana aşamalar. Bütçe amaç değil, ürün kalitesini koruyan bir karar aracıdır.
Önce kullanıcı yolculuğunu seçin
Her sayfayı aynı ölçüde optimize etmeye çalışmak verimli değildir. Kullanıcının en sık başladığı veya iş değerinin en yüksek olduğu birkaç rotayı belirleyin: ana sayfa, proje detay sayfası, blog listesi, giriş ya da ödeme akışı. Bu rotalarda kullanıcının ilk anlamlı içeriği ne zaman gördüğünü, kaydırmadan önce neye ihtiyaç duyduğunu ve hangi eylemi yapmasının beklendiğini düşünün.
Portföy veya içerik sitesi için ilk hedef, sayfanın okunabilir bir iskeletle hızlıca görünmesi olabilir. Yönetim aracı için esas hedef, bir kaydın düzenlenebilir hâle gelmesidir. Aynı teknik metrik farklı ürünlerde farklı anlama gelir. Bu nedenle bütçe; “en yüksek puanı al” yerine “kullanıcı bu yolculukta gecikmeden şu işi yapabilsin” düşüncesine bağlanmalıdır.
İlk bütçeyi iddialı ama uygulanabilir tutun. Örneğin ilk rota için indirilen JavaScript, ana görsel ve üçüncü taraf istekleri için ayrı sınırlar belirlenebilir. Tek bir toplam byte sınırı, küçük ama pahalı JavaScript ile büyük ama hızlı çözülen bir görsel arasındaki farkı gizler.
Kritik yolu bulun ve gereksiz işi erteleyin
Bir sayfanın ilk görünümüne katkı vermeyen her kaynak, kritik yolu uzatma adayıdır. Sayfanın altındaki harita, yorum bölümü, detaylı grafik veya nadiren kullanılan düzenleyici; ilk yüklemede herkes için çalışmak zorunda olmayabilir. Bu bileşenleri kullanıcı etkileşimine, görünür alana yaklaşmaya veya sonraki navigasyona ertelemek genellikle daha iyi bir takastır.
React tabanlı uygulamalarda istemci bileşenlerinin sınırı özellikle önemlidir. Sırf küçük bir etkileşim için büyük bir sayfa bölümünü client-side çalıştırmak, kullanıcıya gereksiz JavaScript gönderir. Statik içerik ve sunucuda hazırlanabilen görünüm, mümkün olduğunda daha hafif kalmalıdır. Dinamik parça gerçekten gerektiğinde küçük, bağımsız ve geç yüklenebilir olmalıdır.
Kod bölme yalnızca framework ayarı değildir. Bileşenin nerede yüklendiğini, paylaşılan bağımlılıkların ne kadar büyüdüğünü ve bir ziyaretçinin hiç kullanmayacağı özellik için ne indirdiğini düzenli olarak sorgulamayı gerektirir.
Görselleri içerik stratejisinin parçası sayın
Görseller birçok içerik sitesinde en büyük yükü oluşturur. Bunun çözümü tüm görselleri kaldırmak değil, her görselin rolüne uygun kaynak seçmektir. İlk ekranda görünen başlık görseli için doğru boyut, modern biçim, açık boyut bilgisi ve gerektiğinde öncelikli yükleme gerekir. Sayfanın aşağısındaki görseller için ise lazy loading ve duyarlı kaynak seçenekleri kullanmak daha uygundur.
Aynı yüksek çözünürlüklü dosyayı masaüstü ve küçük ekran için göndermek, özellikle mobil ağlarda gereksiz maliyet yaratır. Genişlik tanımları ve farklı kaynaklar, tarayıcının uygun olanı seçmesini sağlar. Görselin width ve height bilgisini veya eşdeğer alan ayrımını vermek de yükleme sırasında düzen kaymasını azaltır.
Yüklenmeyen dekoratif görseller alternatif metin gerektirmez, fakat anlam taşıyan görseller açıklayıcı alternatif metne ihtiyaç duyar. Performans ve erişilebilirlik aynı tasarım kararında birleşir: Ne gösterildiği, neden gösterildiği ve ne zaman yüklendiği açık olmalıdır.
Fontları ve üçüncü taraf kodu denetleyin
Yeni bir font ailesi veya ağırlığı estetik bir karar olabilir, ancak ağ ve render maliyeti de taşır. Gerçekten kullanılan stilleri sınırlamak, yalnızca gereken karakter setini sunmak ve kritik metnin font gelene kadar görünmesini sağlamak kullanıcı deneyimini korur. Bir sayfada farklı tasarım araçlarından gelen dört font dosyası, çoğu zaman daha iyi bir tipografi değil daha yavaş ilk görünüm demektir.
Üçüncü taraf betikler daha da dikkatli ele alınmalıdır. Analitik, destek widget'ı, A/B test aracı veya sosyal medya yerleştirmesi; kendi ağ isteklerini, JavaScript maliyetini ve gizlilik etkisini getirir. Her entegrasyon için “hangi kullanıcı değerini sağlıyor, ilk yüklemede gerekli mi, başarısız olursa sayfa çalışıyor mu?” sorularını sorun.
Üçüncü taraf kodu mümkün olduğunda kullanıcı etkileşimi sonrası veya ana içerik yüklendikten sonra başlatın. Bir entegrasyonu kaldırmak bazen en etkili optimizasyondur; performans bütçesi bu kararı tartışılabilir hâle getirir.
Önbellek ve statik üretimden yararlanın
Sık değişmeyen sayfalar için statik üretim, istekte sunucu hesaplaması yapmadan CDN üzerinden içerik sunmayı sağlar. HTML, CSS, JavaScript ve görsel varlıkları sürümlü adreslerle önbelleğe almak, yeni yayın geldiğinde yalnızca değişen dosyaların indirilmesine yardım eder.
Önbellek stratejisinde iki uçtan kaçınmak gerekir. Çok kısa süreli önbellek her ziyarette aynı maliyeti üretir; çok uzun ve sürümsüz önbellek ise kullanıcıya eski içerik gösterebilir. Varlık adında içerik hash'i kullanmak ile HTML için daha kontrollü yenileme kuralı, bu dengeyi kurmanın yaygın bir yoludur.
Bütçeyi CI ve gerçek kullanımda kontrol edin
Yerel bilgisayarda hızlı görünen sayfa, düşük güçlü bir cihazda veya zayıf bağlantıda aynı hissettirmeyebilir. Bu nedenle laboratuvar ölçümleriyle gerçek kullanıcı verisini ayrı ama tamamlayıcı kullanın. Laboratuvar testi değişiklikler arasında tekrarlanabilir karşılaştırma sağlar; saha verisi ise gerçek cihaz, ağ ve davranış çeşitliliğini gösterir.
Build veya pull request aşamasında bundle boyutu, rota başına kaynak sayısı ve temel performans ölçümleri için eşik koymak, regresyonu erken yakalar. Bütçe aşıldığında pipeline'ın doğrudan başarısız olması her ekip için doğru olmayabilir; önce uyarı ve gerekçe kaydıyla başlamak daha uygulanabilir olabilir. Önemli olan istisnanın görünür ve geçici olmasıdır.
Performans işi tek seferlik bir temizlik değildir. Her yeni bileşen, görsel ve entegrasyon bütçeden pay alır. Kullanıcı yolculuğuna bağlı açık sınırlar, kritik yolu küçülten mimari kararlar ve düzenli ölçüm sayesinde hızlı web sitesi başlangıçtaki bir şans değil, sürdürülen bir mühendislik özelliği olur.