JS Code Splitting (Kod Bölme)

Code splitting, bir JavaScript uygulamasının tek bir monolitik bundle yerine birden fazla küçük parçaya (chunk) bölünerek yalnızca ihtiyaç duyulan kodun yüklenmesini sağlayan optimizasyon tekniğidir. 2026 verilerine göre code splitting uygulanan projelerde ilk yükleme JavaScript boyutu ortalama %55 azalmakta ve LCP süresi 1.2 saniyeye kadar düşmektedir. Bu tekniğin doğru uygulanması, hem Core Web Vitals performansını hem de botun render süresini doğrudan belirler.

Monolitik Bundle Sorunu ve Performans Darboğazı

Modern JavaScript uygulamaları, yüzlerce bileşen, onlarca kütüphane ve binlerce satır uygulama kodu içerir. Build aracı bu kodun tamamını tek bir JavaScript dosyasına (bundle) birleştirdiğinde, kullanıcı herhangi bir sayfayı ziyaret ettiğinde uygulamanın tüm kodunu indirmek zorunda kalır. Ana sayfayı görüntülemek isteyen bir kullanıcı, hiç ziyaret etmeyeceği hesap ayarları, ödeme formu ve yönetim paneli kodlarını da indirir.

Bu monolitik yapı, ağ transferi, parse süresi ve JavaScript execution süresi olmak üzere üç ayrı darboğaz oluşturur. 3G bağlantıda 2 MB'lık bir JavaScript bundle'ının indirilmesi 6-8 saniye, parse edilmesi 2-3 saniye, çalıştırılması ise 1-2 saniye sürer. Toplam 10 saniyeyi aşan bu süre, kullanıcının sayfayla etkileşime geçebilmesini ve botun render işlemini tamamlamasını doğrudan geciktirir.

Code Splitting Mekanizmasının Temel Çalışma Prensibi

Code splitting, build aracının (Webpack, Vite, Rollup) ürettiği çıktıyı birden fazla dosyaya bölmesini ifade eder. Bu bölme işlemi üç seviyede gerçekleşir: entry point bazlı bölme, dinamik import bazlı bölme ve vendor (üçüncü parti kütüphane) bazlı bölme. Her seviye farklı bir optimizasyon amacına hizmet eder ve birlikte uygulandığında maksimum verim sağlanır.

Bölme sonucunda oluşan her parçaya "chunk" denir. Ana sayfa için gereken kod main.js chunk'ında, ürün sayfası için gereken kod product.[hash].js chunk'ında, ödeme sayfası kodu ise checkout.[hash].js chunk'ında yer alır. Tarayıcı, kullanıcının ziyaret ettiği sayfaya göre yalnızca ilgili chunk'ları indirir. Bu mekanizma, gereksiz kod transferini ortadan kaldırır ve ilk yükleme süresini dramatik biçimde kısaltır.

Route Bazlı Code Splitting ve Sayfa Düzeyinde Bölme

Route bazlı code splitting, uygulamanın her URL yolu (route) için ayrı bir chunk oluşturulmasını sağlar. Bu yaklaşım, code splitting'in en temel ve en etkili uygulama biçimidir. Kullanıcı /urunler sayfasına girdiğinde yalnızca ürün listesi bileşeninin kodu indirilir; /blog sayfasının kodu bu aşamada yüklenmez.

React'ta route bazlı code splitting, React.lazy ve dinamik import() ile uygulanır:

    
import { lazy, Suspense } from 'react';

const ProductPage = lazy(() => import('./pages/ProductPage'));
const BlogPage = lazy(() => import('./pages/BlogPage'));
const CheckoutPage = lazy(() => import('./pages/CheckoutPage'));

function App() {
  return (
    <Suspense fallback={<div>Yükleniyor...</div>}>
      <Routes>
        <Route path="/urunler" element={<ProductPage />} />
        <Route path="/blog" element={<BlogPage />} />
        <Route path="/odeme" element={<CheckoutPage />} />
      </Routes>
    </Suspense>
  );
}        
    

Bu yapıda Webpack, her import() çağrısı için ayrı bir chunk dosyası üretir. Tarayıcı, route değiştiğinde ilgili chunk'ı asenkron olarak indirir ve render eder.

Next.js ve Nuxt.js'te Otomatik Code Splitting

Next.js, dosya sistemi tabanlı routing yapısı sayesinde her sayfa bileşeni için otomatik code splitting uygular. pages/ veya app/ dizinindeki her dosya, ayrı bir JavaScript chunk'ı olarak üretilir. Geliştiricinin React.lazy veya dinamik import kullanmasına gerek yoktur; framework bu optimizasyonu varsayılan olarak gerçekleştirir.

Nuxt.js'te de aynı otomatik bölme mekanizması çalışır. pages/ dizinindeki her Vue bileşeni, build aşamasında ayrı bir chunk olarak paketlenir. Bu otomatik yapı, route bazlı code splitting'in en düşük sürtünmeli uygulamasıdır. Ancak dikkat edilmesi gereken nokta, sayfa bileşenlerinin import ettiği alt bileşenlerdir. Bir sayfa bileşeni, büyük bir kütüphaneyi doğrudan import ediyorsa, o kütüphanenin kodu o sayfanın chunk'ına dahil edilir ve chunk boyutu şişer. Bu durumda alt bileşen düzeyinde ek code splitting gerekir.

Bileşen Düzeyinde Code Splitting ve Lazy Loading

Route bazlı bölmenin ötesinde, sayfa içindeki ağır bileşenler de ayrı chunk'lara bölünebilir. Modal pencereler, grafik kütüphaneleri, harita bileşenleri ve zengin metin editörleri gibi elemanlar, sayfa ilk yüklendiğinde görünür alanda değildir. Bu bileşenlerin kodunu ana chunk'a dahil etmek gereksiz yüktür.

React'ta bileşen düzeyinde lazy loading şöyle uygulanır:

    
const HeavyChart = lazy(() => import('./components/HeavyChart'));
const MapComponent = lazy(() => import('./components/MapComponent'));

function ProductDetail() {
  const [showChart, setShowChart] = useState(false);
  return (
    <div>
      <h1>Ürün Detayı</h1>
      <p>Ürün açıklaması...</p>
      <button onClick={() => setShowChart(true)}>İstatistikleri Göster</button>
      {showChart && (
        <Suspense fallback={<div>Grafik yükleniyor...</div>}>
          <HeavyChart />
        </Suspense>
      )}
    </div>
  );
}      
    

Bu yapıda HeavyChart bileşeninin JavaScript kodu, kullanıcı butona tıklayana kadar indirilmez. Sayfa ilk yükleme süresi, ağır bileşenin boyutundan bağımsız hale gelir.

Vendor Chunk Splitting ve Üçüncü Parti Kütüphane Yönetimi

Üçüncü parti kütüphaneler (React, Lodash, Moment.js, D3 gibi) uygulama kodundan ayrı bir chunk'ta paketlenmelidir. Bu ayrımın iki temel gerekçesi vardır. Birincisi, vendor kütüphaneleri uygulama koduna göre çok daha az güncellenir. Ayrı chunk'ta tutulduklarında, uygulama kodu değişse bile vendor chunk'ı tarayıcı cache'inden sunulabilir. İkincisi, vendor chunk'ı birden fazla sayfa tarafından paylaşıldığından, tekrarlanan indirme ortadan kalkar.

Webpack'te vendor splitting, optimization.splitChunks yapılandırmasıyla kontrol edilir:

    
module.exports = {
  optimization: {
    splitChunks: {
      chunks: 'all',
      cacheGroups: {
        vendor: {
          test: /[\\/]node_modules[\\/]/,
          name: 'vendors',
          chunks: 'all',
          priority: 10
        }
      }
    }
  }
};    
    

Bu yapılandırma, node_modules dizininden gelen tüm kodu vendors.[hash].js adlı ayrı bir chunk'ta toplar. Uygulama kodu değiştiğinde vendor chunk'ının hash'i değişmez ve tarayıcı cache'i korunur.

Dinamik Import ve Webpack Magic Comments

Webpack, dinamik import() ifadesinde özel yorumlar (magic comments) aracılığıyla chunk davranışını kontrol etmeye olanak tanır. Bu yorumlar, chunk adlandırma, preloading ve prefetching stratejilerini doğrudan import noktasında tanımlamayı sağlar.

    
const AdminPanel = lazy(() => import(
  /* webpackChunkName: "admin-panel" */
  /* webpackPrefetch: true */
  './pages/AdminPanel'
));   
    

webpackChunkName yorumu, üretilen chunk dosyasının adını belirler. Bu adlandırma, DevTools Network sekmesinde ve build raporlarında hangi chunk'ın hangi bileşene ait olduğunu takip etmeyi kolaylaştırır. webpackPrefetch: true yorumu, tarayıcının boş anlarında bu chunk'ı arka planda indirmesini sağlar. Böylece kullanıcı ilgili sayfaya gittiğinde kod zaten cache'te hazır olur ve geçiş anında gerçekleşir.

Prefetch, Preload ve Eager Loading Stratejileri

Code splitting ile bölünen chunk'ların ne zaman indirileceği, kullanıcı deneyimini doğrudan belirler. Üç farklı yükleme stratejisi mevcuttur. Prefetch, tarayıcının boş anlarında chunk'ı arka planda indirir; düşük önceliklidir. Preload, chunk'ı mevcut sayfa yüklenmesiyle eş zamanlı olarak indirir; yüksek önceliklidir. Eager loading ise chunk'ı ana bundle'a dahil eder ve code splitting'i devre dışı bırakır.

SEO açısından bu stratejilerin etkisi, botun render sürecinde kendini gösterir. Bot, prefetch veya preload direktiflerini işlemez; yalnızca sayfanın render edilmesi için gereken JavaScript dosyalarını sırasıyla indirir ve çalıştırır. Dolayısıyla prefetch ve preload stratejileri kullanıcı deneyimi optimizasyonudur. Bot perspektifinden önemli olan, kritik render yolundaki chunk'ların doğru sırada yüklenmesi ve render'ı engelleyen (render-blocking) JavaScript'in minimize edilmesidir.

Tree Shaking ve Dead Code Elimination ile Chunk Boyutunu Küçültme

Tree shaking, kullanılmayan export'ların build aşamasında bundle'dan çıkarılmasını sağlayan optimizasyon tekniğidir. Bir kütüphaneden yalnızca tek bir fonksiyon import ediliyorsa, kütüphanenin geri kalanı bundle'a dahil edilmez. Bu teknik, ES Module (import/export) sözdizimi gerektirir; CommonJS (require) ile çalışmaz.

Lodash kütüphanesi, tree shaking'in etkisini somutlaştıran klasik örnektir. import _ from 'lodash' ifadesi kütüphanenin tamamını (70 KB gzip) bundle'a dahil eder. import debounce from 'lodash/debounce' ifadesi ise yalnızca ilgili fonksiyonu (2 KB gzip) dahil eder. Tree shaking'in çalışması için kütüphanelerin ES Module formatında import edilmesi zorunludur. package.json dosyasındaki sideEffects: false beyanı, build aracının tree shaking'i güvenle uygulayabileceğini bildirir.

Bundle Analizi ve Chunk Boyut Optimizasyonu

Code splitting'in etkinliğini ölçmek ve optimize etmek için bundle analiz araçları kullanılmalıdır. webpack-bundle-analyzer eklentisi, build çıktısındaki her chunk'ın boyutunu, içerdiği modülleri ve bağımlılık ilişkilerini görsel bir treemap ile sunar. Bu görselleştirme, hangi kütüphanenin ne kadar yer kapladığını ve gereksiz büyüklüklerin nerede olduğunu anında ortaya koyar.

Webpack'te analiz eklentisini etkinleştirmek için:

    
const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;

module.exports = {
  plugins: [
    new BundleAnalyzerPlugin({ analyzerMode: 'static', openAnalyzer: false })
  ]
};   
    

Next.js projelerinde @next/bundle-analyzer paketi aynı işlevi görür. Vite projelerinde ise rollup-plugin-visualizer kullanılır. Analiz sonucunda 500 KB üzerindeki chunk'lar, ek code splitting veya kütüphane alternatifi değerlendirmesi gerektiren bölgelerdir. Moment.js yerine Day.js, Lodash yerine native JavaScript metotları kullanmak gibi kütüphane swap'ları, chunk boyutunu %30-50 oranında küçültebilir.

Critical CSS Inline ve JavaScript Yükleme Sırası

Code splitting yalnızca JavaScript bölmekle ilgili değildir; JavaScript'in CSS ile olan yükleme sırası da performansı doğrudan etkiler. Kritik CSS (above-the-fold içeriğin stillendirilmesi için gereken CSS), HTML içinde inline olarak sunulmalıdır. JavaScript dosyaları ise defer veya async attribute'leriyle yüklenmelidir.

defer attribute'ü, JavaScript dosyasının HTML parse işlemiyle paralel indirilmesini ancak parse tamamlandıktan sonra çalıştırılmasını sağlar. async ise dosyayı paralel indirir ve indirildiği anda, parse'ı durdurup çalıştırır. Code splitting ile üretilen chunk dosyaları genellikle framework tarafından otomatik olarak defer ile yüklenir. Ancak üçüncü parti scriptleri (analytics, reklam) async olarak yüklemek, ana chunk'ların yükleme ve çalışma sırasını bozmamak açısından kritiktir.

Hydration Gecikmesinin Code Splitting ile Azaltılması

Code splitting, hydration gecikmesini azaltmanın en doğrudan yollarından biridir. Monolitik bundle'da tüm bileşenlerin JavaScript'i indirilip parse edildikten sonra hydration başlar. Code splitting ile yalnızca mevcut sayfanın bileşenleri indirildiğinde, parse ve hydration süresi o sayfanın JavaScript boyutuyla orantılı olarak kısalır.

React 18'in <Suspense> bileşeni ile selective hydration, bu optimizasyonu bir adım öteye taşır. Sayfa içindeki bileşenler bağımsız olarak hydrate edilir; ağır bir bileşenin hydration'ını beklemeden, kullanıcının etkileşimde bulunduğu bileşen öncelikli olarak hydrate edilir. Bu mekanizma, INP metriğini doğrudan iyileştirir. Kullanıcı butona tıkladığında, o butonun bulunduğu bileşen öncelikli olarak hydrate edilir ve tepki verilir.

SSR ve Code Splitting Birlikte Kullanımı

SSR mimarilerinde code splitting, istemci tarafındaki JavaScript yükünü azaltırken sunucu tarafındaki render sürecini etkilemez. Sunucu, tüm bileşenleri senkron olarak render eder ve tam HTML üretir. Code splitting yalnızca istemciye gönderilen JavaScript chunk'larını etkiler. Dolayısıyla SSR ile code splitting birlikte uygulandığında, bot tam HTML alır ve kullanıcı minimum JavaScript ile etkileşime geçer.

Ancak SSR ve code splitting birlikte kullanıldığında dikkat edilmesi gereken bir teknik ayrıntı vardır: sunucu tarafında render edilen bileşenin istemci tarafında doğru chunk ile eşleştirilmesi gerekir. Next.js ve Nuxt.js bu eşleştirmeyi otomatik yönetir. Manuel SSR yapılandırmalarında ise loadable-components veya @loadable/server kütüphaneleri, chunk eşleştirmesini ve script etiketlerinin HTML'e doğru sırada eklenmesini sağlar.

Core Web Vitals Metriklerine Chunk Bazlı Etki Analizi

Code splitting'in Core Web Vitals üzerindeki etkisi, her metrikte farklı biçimde kendini gösterir. LCP açısından, ilk yükleme JavaScript boyutunun küçülmesi sayfanın görsel olarak tamamlanma süresini kısaltır. Özellikle JavaScript ile render edilen hero görselleri veya ana içerik blokları, daha küçük chunk sayesinde daha hızlı ekrana gelir.

INP açısından, hydration süresinin kısalması etkileşim tepki süresini doğrudan iyileştirir. CLS açısından ise code splitting, asenkron yüklenen bileşenlerin sayfa düzenini bozma riskini artırabilir. Bu riski yönetmek için lazy loaded bileşenlerin placeholder'ları (Suspense fallback) sabit yükseklik ve genişlik değerlerine sahip olmalıdır. min-height CSS kuralıyla placeholder alanını önceden rezerve etmek, bileşen yüklendiğinde layout shift'i önler.

Vite'ın Code Splitting Yaklaşımı ve Rollup Entegrasyonu

Vite, geliştirme ortamında native ES Modules kullanarak sıfır bundle geliştirme deneyimi sunar. Üretim build'inde ise Rollup üzerinden otomatik code splitting uygular. Vite'ın Rollup entegrasyonu, build.rollupOptions yapılandırmasıyla özelleştirilebilir:

    
export default defineConfig({
  build: {
    rollupOptions: {
      output: {
        manualChunks: {
          'vendor-react': ['react', 'react-dom'],
          'vendor-utils': ['lodash-es', 'date-fns'],
          'vendor-ui': ['@radix-ui/react-dialog', '@radix-ui/react-dropdown-menu']
        }
      }
    }
  }
});  
    

manualChunks yapılandırması, belirli kütüphanelerin hangi chunk'ta gruplanacağını açıkça belirler. Bu gruplandırma, cache verimliliğini artırır. Sık güncellenen UI kütüphaneleri ile nadiren değişen React core'un ayrı chunk'larda tutulması, UI güncellemelerinde React chunk'ının cache'ten sunulmaya devam etmesini sağlar.

Webpack 5 Module Federation ve Mikro Frontend Bağlamı

Module Federation, Webpack 5 ile gelen ve birden fazla bağımsız uygulamanın JavaScript modüllerini runtime'da paylaşmasını sağlayan ileri düzey bir code splitting mekanizmasıdır. Mikro frontend mimarilerinde her alt uygulama kendi chunk'larını üretir ve ana uygulama bu chunk'ları ihtiyaç duyulduğunda uzaktan yükler.

SEO perspektifinden Module Federation, ek karmaşıklık katmanı getirir. Her mikro frontend'in chunk'ları farklı origin'lerden sunulabilir ve bu origin'lerin robots.txt yapılandırmalarının uyumlu olması gerekir. Ayrıca SSR ile Module Federation birlikte kullanıldığında, sunucu tarafında uzak modüllerin çözümlenmesi ek gecikme oluşturur. LinkedIn üzerindeki frontend mühendislik topluluklarında paylaşılan performans verileri gösteriyor ki, Module Federation kullanan mikro frontend projelerinde TTFB değeri, monolitik yapıya göre ortalama 80-120 ms artıyor. Bu artış, SSR render süresindeki uzak modül çözümleme gecikmesinden kaynaklanır.

Chunk Dosya Adlandırma ve Cache Busting Stratejisi

Build araçları, chunk dosya adlarına content hash ekler: main.a1b2c3d4.js. Bu hash, dosya içeriği değiştiğinde otomatik olarak değişir ve tarayıcının eski cache'i kullanmasını engeller (cache busting). İçerik değişmediğinde hash aynı kalır ve tarayıcı dosyayı cache'ten sunar.

Chunk adlandırma stratejisi, cache verimliliğini doğrudan etkiler. Vendor chunk'ının hash'i yalnızca bağımlılık versiyonu değiştiğinde, uygulama chunk'ının hash'i ise uygulama kodu değiştiğinde güncellenmelidir. Webpack'te [contenthash] placeholder'ı bu davranışı sağlar. Yanlış yapılandırma, bir dosyadaki değişikliğin tüm chunk'ların hash'ini değiştirmesine yol açar ve cache'in tamamı geçersiz olur. optimization.runtimeChunk: 'single' ayarı, Webpack runtime kodunu ayrı bir chunk'a izole ederek bu zincirleme hash değişimini önler.

Performans Bütçesi ve Chunk Boyut Sınırları

Code splitting uygulandıktan sonra bile chunk boyutlarının kontrol altında tutulması gerekir. Performans bütçesi, her chunk için maksimum boyut sınırı belirleyerek aşımları build aşamasında tespit eder. Webpack'te bu sınır performance yapılandırmasıyla tanımlanır:

    
module.exports = {
  performance: {
    maxAssetSize: 250000,
    maxEntrypointSize: 400000,
    hints: 'error'
  }
}; 
    

Bu yapılandırmada tek bir asset 250 KB'ı, bir entry point'in toplam boyutu 400 KB'ı aştığında build hata verir. hints: 'error' ayarı, CI/CD pipeline'ında build'in başarısız olmasını sağlar ve büyük chunk'ların fark edilmeden üretime çıkmasını engeller. Performans bütçesi, code splitting'in sürdürülebilirliğini garanti eden zorunlu kalite kapısıdır. Bu kapı olmadan, yeni eklenen kütüphaneler ve bileşenler chunk boyutlarını sessizce şişirir.

Lazy Loading ve SEO Arasındaki Denge Noktası

Code splitting ile lazy loading uygulanan bileşenler, JavaScript çalıştırılmadan DOM'da yer almaz. Bu durum, lazy loaded bileşenin içeriğinin bot tarafından ilk tarama geçişinde görülememesi riskini doğurur. Ürün açıklaması veya ana metin gibi kritik SEO içeriğinin lazy loaded bileşen içinde yer alması, indeksleme kaybına neden olur.

Çözüm, kritik içerik ile tamamlayıcı içerik arasında net bir ayrım yapmaktır. Başlık, ana metin, fiyat bilgisi ve yapısal veri gibi SEO kritik elemanlar hiçbir zaman lazy loaded bileşen içinde olmamalıdır. Bu elemanlar, SSR ile sunucu tarafında render edilmeli veya en azından ana chunk'a dahil edilmelidir. Yorum bölümü, öneri karuseli ve sosyal medya widget'ları gibi tamamlayıcı elemanlar ise güvenle lazy loading ile yüklenebilir. Bu ayrımı enforcing etmek için, SEO kritik bileşenlerin "use client" veya React.lazy ile sarmalanmasını yasaklayan bir lint kuralı tanımlamak etkili bir yöntemdir.

Mobil Ağlarda Code Splitting'in Ölçülebilir Etkisi

Teoride doğru görünen ama pratikte patlayan nokta şudur: masaüstünde fark edilmeyen chunk boyutu sorunları, mobil ağlarda kullanıcı deneyimini çökertiyor. 4G bağlantıda 1 MB JavaScript'in indirilmesi yaklaşık 2 saniye sürerken, ortalama bir 3G bağlantıda bu süre 6-8 saniyeye çıkar. Türkiye'deki mobil kullanıcıların önemli bir kısmı hâlâ kararsız ağ koşullarında gezinmektedir.

Code splitting'in mobil etkisini ölçmek için Chrome DevTools'ta Network sekmesinde "Slow 3G" veya "Fast 3G" throttling profilini etkinleştirin. Lighthouse'u mobil modda çalıştırarak LCP, INP ve Total Blocking Time metriklerini code splitting öncesi ve sonrası karşılaştırın. Bu karşılaştırma, optimizasyonun gerçek dünya etkisini somutlaştırır. Search Console'daki Core Web Vitals raporundaki "Mobil" sekmesi, canlı kullanıcı verileriyle bu ölçümü doğrular.

Code Splitting Denetiminin Sürekli Entegrasyon Döngüsüne Dahil Edilmesi

İşin mutfağında durum farklıdır: code splitting bir kez doğru uygulandığında işin bittiğini varsaymak, birkaç sprint sonra chunk boyutlarının kontrolden çıkmasına yol açar. Her yeni bileşen ekleme, kütüphane güncelleme ve refactoring operasyonu, chunk yapısını etkiler. Bu değişimlerin izlenmesi ve bütçe aşımlarının erken tespit edilmesi, CI/CD pipeline entegrasyonu ile sağlanır.

Her pull request'te webpack-bundle-analyzer veya @next/bundle-analyzer çıktısını otomatik üreten bir CI adımı ekleyin. Chunk boyutlarını önceki build ile karşılaştıran ve belirli bir eşiği aşan değişiklikleri işaretleyen bir script, code review sürecinin parçası olmalıdır. Bu disiplin, code splitting'in uzun vadeli sürdürülebilirliğini garanti eder. Performans bütçesi CI kapısı ile birleştiğinde, büyük chunk'lar üretime ulaşamaz ve teknik borç birikmesi başlamadan engellenir.