Frontend Development

Ön Uç Performans Bütçelemesi: CI/CD'de Paket Boyutu ve Çalışma Zamanı Metrikleri İçin Sınırların Uygulanması

Moder web ekosisteminde kullanıcı sabrı neredeyse hiç yoktur. Sayfa yükleme süresindeki sadece birkaç yüz milisaniyelik gecikme, terk oranları ve dönüşüm metrikleri üzerinde önemli etkilere sahip olabilir. Geliştiriciler genellikle kodu manuel olarak optimize ederken, insan hatası ve kapsam kayması kaçınılmaz olarak performans geri regresyonlarına yol açar. İşte tam da burada Performans Bütçelemesi, sadece bir iyi uygulama olmaktan çıkıp sağlam bir CI/CD pipeline'ının kritik bir bileşeni haline gelir.

Performans bütçelemesi, uygulama varlıklarınızın boyutu ve performansı üzerinde belirli sınırlar belirleme sürecidir. Bu sınırları build pipeline'ınıza entegre ederek, bu eşikleri ihlal eden her çekme isteğinin (pull request) hemen işaretlenmesini ve performans borcunun birikmesini önlersiniz.

Performans Bütçelerinizi Tanımlama

Araçları uygulamadan önce, spesifik kullanım durumunuz için "sağlıklı" bir uygulamanın ne anlama geldiğini tanımlamanız gerekir. Genellikle bütçeler iki kategoriye ayrılır: Paket Boyutu ve Çalışma Zamanı Metrikleri.

  • Paket Boyutu Bütçeleri: Bunlar, JavaScript, CSS ve diğer varlıklarınızın toplam ağırlığını sınırlar. Mobil öncelikli uygulamalar için yaygın bir kural, başlangıç JavaScript yükünün sıkıştırılmış (gzipped) halde 200KB altında tutulmasıdır.
  • Çalışma Zamanı Metrikleri: Bunlar, En Büyük İçeriksel Boyutlandırma (LCP), İlk Girdi Gecikmesi (FID) ve Birikimli Düzen Kayması (CLS) gibi Çekirdek Web Vital'lerine odaklanır. Örneğin, LCP'nin asla 2.5 saniyeyi aşmamasını sağlayabilirsiniz.

Webpack Paket Analizci ve CI ile Paket Boyutu Kontrollerini Otomatikleştirme

En yaygın sorunlardan biri JavaScript şişkinliğidir. webpack-bundle-analyzer gibi araçlar bağımlılık ağacınızı görselleştirebilir, ancak bunları bir CI ortamına entegre etmek farklı bir yaklaşım gerektirir. Çıktının belirli bir eşiği aşması durumunda build'i başarısız kılacak bir betiğe ihtiyacımız var.

Aşağıda, sıkı bir bütçe uygulamak için webpack ve size-limit paketini kullanan bir örnek bulunmaktadır. İlk olarak gerekli bağımlılıkları yükleyin:

npm install --save-dev size-limit @size-limit/webpack-time

Ardından, bütçelerinizi tanımlamak için package.json'inizi yapılandırın. Bu yapılandırma, gerekli polyfiller ve çalışma zamanı ek yükleri dahil olmak üzere toplam paket boyutunun 50KB'yi aşmaması gerektiğini araca söyler.


{
  "name": "my-performance-budget-app",
  "scripts": {
    "build": "webpack --mode production",
    "analyze": "webpack-bundle-analyzer stats.json"
  },
  "size-limit": [
    {
      "name": "JS Bundle",
      "path": "dist/main.js",
      "limit": "50 KB"
    }
  ]
}

CI/CD pipeline'ınıza (örneğin GitHub Actions veya Jenkins'te) npm run size-limit ekleyerek, paket boyutu belirtilen limiti aşarsa build başarısız olur. Bu, geliştiricilerin kodu birleştirmeden önce büyük bağımlılıkları incelemelerini veya kod bölme stratejilerini düşünmelerini zorlar.

Lighthouse CI ile Çalışma Zamanı Metriklerini Uygulama

Paket boyutu önemlidir ancak her zaman algılanan performansla doğrudan ilişkili değildir. Önbelleğe alındığında büyük bir paket hızlı yüklenebilirken, karmaşık düzen kaymaları nedeniyle küçük bir paket yavaş render edilebilir. Bunu ele almak için Lighthouse CI kullanarak çalışma zamanı metriklerini uygulayabiliriz.

Lighthouse CI, üretim build'leriniz veya staging URL'leriniz üzerinde denetimler çalıştırmanıza olanak tanır. Çekirdek Web Vital'ler için sıkı eşikler belirlemek amacıyla bir .lighthouserc.js yapılandırması tanımlayabilirsiniz.


module.exports = {
  ci: {
    collect: {
      url: ['http://localhost:3000'], // Yerel build'iniz
      settings: {
        skipAudits: ['uses-rel-preconnect', 'uses-rel-preload'],
      },
    },
    assert: {
      assertions: {
        'categories:performance': ['error', { minScore: 0.9 }],
        'largest-contentful-paint': ['error', { maxNumericValue: 2500 }],
        'cumulative-layout-shift': ['error', { maxNumericValue: 0.1 }],
      },
    },
  },
};

Bu yapılandırmada, pipeline genel performans kategorisi puanının en az 0.9, LCP'nin 2.5 saniyenin altında ve CLS'nin 0.1'in altında olduğunu doğrular. Herhangi bir metrik başarısız olursa, CI işi sonlanır ve hangi spesifik metriğin geri regresyona neden olduğunu belirten net geri bildirim sağlar.

Uygulama İçin En İyi Uygulamalar

Performans bütçeleri uygulamak "ayarla ve unut" çözümü değildir. Uzun vadeli başarıyı sağlamak için aşağıdaki stratejileri göz önünde bulundurun:

  1. Metrikleriniz için Taban Oluşturun: Rastgele sayılarla başlamayın. Mevcut uygulamanızda başlangıç denetimleri çalıştırın ve bunları başlangıç bütçeleriniz olarak kullanın. Optimize ettikçe bunları kademeli olarak sıkılaştırın.
  2. Sadece Başarısızlıkları Değil, Trendleri İzleyin: Performans trendlerini zaman içinde takip etmek için Lighthouse CI veya WebPageTest gibi araçlar tarafından sağlanan panoları kullanın. Sürekli bir düşüş, ani bir yükselişten genellikle daha tehlikelidir.
  3. Ekip Eğitimi: Performans bütçeleri kısıtlayıcı gelebilir. Geliştiricilerin bu sınırların kullanıcı deneyimini korumak için rehberler olduğunu, bürokratik engeller olmadığını anlamasını sağlayın. Bütçelemenin daha hızlı yükleme süreleri ve daha yüksek dönüşümlere yol açtığı olumlu vaka çalışmalarını paylaşın.

Sonuç

Performans bütçelemesi, performansı bir düşünce biçiminden (afterthought) temel bir gereksinime taşıyan güçlü bir disiplindir. Paket boyutu ve çalışma zamanı metrikleri için otomatik kontrolleri CI/CD pipeline'ınıza entegre ederek, geri regresyonları erken aşan bir güvenlik ağı oluşturursunuz. Bu proaktif yaklaşım sadece kullanıcı deneyimini iyileştirmekle kalmaz, aynı zamanda teknik borcu da azaltarak uygulamanız ölçeklendikçe hızlı, erişilebilir ve güvenilir kalmasını sağlar. Küçük başlayın, net metrikler tanımlayın ve ağır işi CI/CD pipeline'ınıza bırakın.

Share: