Webpack ile Bundle Optimizasyonu

Bundle boyutu sessizce büyür. Bir paket eklersin, bir ikon seti daha, sonra bir gün main.js 2 MB olur. Kullanıcı beyaz ekrana bakar. İyi haber: Webpack'te bu sorunun çözümü büyük ölçüde konfigürasyon işidir. Ölç, böl, tembel yükle.

Aşağıdaki adımları kendi projenizde sırayla uygulayabilirsiniz. Her adımdan sonra build alıp boyutu not edin. Ölçmediğiniz iyileştirme, tahminden ibarettir.

1. Bundle'ı Tanı ve Konfigürasyonu Sağlamlaştır

Optimizasyona kod bölmeyle başlamak yaygın bir hata. Önce içeride ne olduğunu görmek gerekir. Çoğu projede boyutun yarısı, farkında olmadan eklenmiş üç beş bağımlılıktan gelir.

Önce ölç: analiz alışkanlığı

• webpack-bundle-analyzer kur ve plugin olarak ekle. Build sonrası açılan haritada en büyük dikdörtgenleri incele.
• Alternatif olarak --json ile stats dosyası üret, çevrimiçi stats görüntüleyicilerde aç.
• performance.hints ayarını "warning" yap, maxAssetSize için kendine bir sınır koy. Sınır aşılınca build seni uyarır.
• Ölçümü not et: toplam boyut, en büyük chunk, gzip sonrası boyut. Karşılaştırma yapacağın referans bu.

Mode, target ve devtool doğru mu?

• mode: "production" olmadan minify, tree shaking ve birçok varsayılan optimizasyon çalışmaz. Prod build'inde bunu kontrol et.
• Geliştirme ve prod konfigürasyonlarını ayır. Ortak kısmı tek dosyada tut, webpack-merge ile birleştir.
• devtool ayarını prod'da source-map yap, inline varyantlarını kullanma. Inline source map bundle'ın içine gömülür ve boyutu şişirir.
• target ve Babel hedeflerini gereksiz eski tarayıcılara göre ayarlamak, tonlarca polyfill demek. Browserslist listesini gerçekçi tut.

Bağımlılıkları yalınlaştır

• Tarih için tüm bir kütüphaneyi almak yerine küçük ve modüler alternatifleri değerlendir. Locale dosyaları tek başına yüz kilobaytları bulabilir.
• Yardımcı fonksiyon kütüphanelerinde alt yol import'u kullan: paketin tamamını değil, ihtiyacın olan fonksiyonu çek.
• Kendi paketini yazıyorsan package.json içine "sideEffects": false ekle. Tree shaking ancak modülün yan etkisiz olduğunu bildiğinde kullanılmayan kodu atabilir.
• ESM sürümü olan paketleri tercih et. CommonJS modülleri statik analize kapalıdır, tree shaking uygulanamaz.
• Aynı kütüphanenin iki sürümünün birlikte gelmesine dikkat et. Analyzer haritasında iki kez görünen paket varsa lock dosyasını incele.

2. Kod Bölümleme ve Lazy Loading

Temizlik bittiğinde asıl kazanç burada. Amaç, ilk boyamada gerçekten gereken kodu göndermek. Gerisi sonra gelir.

Dynamic import ile webpack code splitting

• Statik import yerine import() kullandığın her yerde Webpack otomatik olarak yeni bir chunk üretir. webpack code splitting'in temeli budur.
• İyi adaylar: yönlendirme (route) bileşenleri, modal içerikleri, grafik ve tablo kütüphaneleri, metin editörleri, harita bileşenleri.
• Chunk'a isim vermek için import içine yorum olarak webpackChunkName yaz. Analyzer çıktısı böylece okunabilir olur.
• webpackPrefetch: true tarayıcıya "boş kalınca indir" der. webpackPreload: true ise mevcut sayfa için gerekli demektir. Prefetch çoğu senaryoda daha güvenli.
• Lazy yüklenen parçalar için bir yükleniyor durumu ve hata yakalama koy. Ağ koptuğunda import() reject olur.

splitChunks ile ortak parçaları ayır

• optimization.splitChunks.chunks: "all" ile başla. Bu tek satır bile senkron ve asenkron kodun paylaşılan kısımlarını ayırır.
• cacheGroups tanımla: node_modules içeriğini "vendors" grubuna al, en az iki chunk'ta kullanılan kendi modüllerini "common" yap.
• Aşırı bölme tuzağına düşme. Yüzlerce küçük dosya istek sayısını artırır. minSize ve maxInitialRequests ile dengele.
• Çok büyük ve sık güncellenmeyen tek bir paket varsa (ör. bir grafik motoru) onu kendi cacheGroup'una ayır. Kalan vendor chunk'ı daha stabil olur.

Cache ve uzun vadeli kazanç