SvelteKit ile Next.js arasındaki bundle boyutu tartışması, frontend dünyasında en sık karşılaşılan karşılaştırmalardan biri. İkisi de modern web uygulamaları için güçlü çerçeveler; ancak JavaScript'in tarayıcıya nasıl ulaştığı konusunda birbirinden ayrışan bir felsefeyle tasarlanmışlar. Bu fark yalnızca teknik bir tercih değil, kullanıcının sayfa yükleme hızını doğrudan etkileyen somut bir maliyet meselesi.

Next.js, React üzerine inşa edilmiş ve React runtime'ını her zaman beraberinde taşıyor. Svelte ise derleme aşamasında bileşenleri vanilla JavaScript'e çevirip herhangi bir çalışma zamanı kütüphanesi bırakmıyor. Bu iki yaklaşım arasındaki mesafe küçük projeler için önemsiz kalabiliyor; ancak bileşen sayısı arttıkça ve interaktivite yoğunlaştıkça belirginleşiyor.

Hangisini seçmek gerektiği, yalnızca kilobayt sayısıyla yanıtlanacak bir soru değil. Bundle boyutu önemli; ancak gerçek farkı anlamak için hydration maliyetini, JavaScript işleme süresini ve cache davranışını birlikte değerlendirmek gerekiyor.

Svelte'nin Derleme Modeli: Runtime Neden Paketlenmiyor?

React ve Vue, tarayıcıda sanal DOM (virtual DOM) oluşturmak ve güncellemeleri yönetmek için bir çalışma zamanı kütüphanesine ihtiyaç duyuyor. Bu runtime, sayfa her yüklendiğinde indirilmesi, ayrıştırılması ve çalıştırılması gereken bir JavaScript yükü. React çekirdeği gzip sonrası yaklaşık 6-7 kB, ReactDOM ile birlikte minify+gzip civarında 40-45 kB bandına oturur; production öncesi parse boyutu ise çok daha büyüktür.

Svelte farklı bir yol izliyor. Derleme zamanında bileşenleri doğrudan DOM manipülasyonu yapan vanilla JavaScript kodu haline getiriyor. Tarayıcıya giden pakette Svelte'ye ait bir kütüphane dosyası yok, sadece derleme çıktısı var. Küçük bir bileşen için bu, birkaç kilobaytlık bir JavaScript anlamına gelebiliyor.

Svelte'nin bu derleme süreci, bileşen içindeki reaktif ifadeleri derleme anında analiz ediyor ve yalnızca gerçekten değişen DOM düğümlerini güncelleyen minimal kod üretiyor. Bir değişken atandığında hangi DOM elemanlarının etkileneceğini derleyici zaten biliyor; çalışma zamanında bu analizi yapmak için herhangi bir bellek veya CPU harcaması gerekmiyor. Sanal DOM fark algoritması yerine hedefli DOM güncellemeleri çalışıyor, bu nedenle tarayıcıda gereksiz karşılaştırma döngüsü de bulunmuyor.

Bu yaklaşımın sınırı da var. Uygulama büyüdükçe her bileşen kendi reaktivite kodunu beraberinde taşıyor. Runtime paylaşımı olmadığı için bileşen sayısı arttıkça Svelte'nin boyut avantajı daralıyor. Çok sayıda bileşen içeren büyük bir SPA'da iki framework arasındaki fark düşünülenin altında kalabiliyor; hatta bazı uç senaryolarda Svelte çıktısı toplamda React runtime'ı aşabiliyor.

Next.js'te React Runtime'ının Somut Maliyeti

Bir Next.js sayfası oluşturduğunuzda tarayıcıya giden bundle içinde birkaç katman var: React runtime, ReactDOM, Next.js'in kendi çerçeve kodu ve son olarak uygulama kodu. Saf bir "Hello World" sayfasında bile bu temel yük yaklaşık 80-90 kB gzip sıkıştırılmış boyutuna ulaşıyor.

Sayı tek başına büyük görünmeyebilir. Önemli olan bu paketin her kullanıcı için indirilmesi, JavaScript motorunun bu kodu ayrıştırıp derlemesi ve hydration sürecini tamamlaması. Orta seviye bir Android cihazda bu işleme süresi 300-500 milisaniyeyi bulabiliyor.

Next.js, bu maliyeti azaltmak için çeşitli mekanizmalara sahip. React Server Components (RSC) istemci tarafına gönderilen JavaScript miktarını düşürüyor. app/ dizini yapısıyla sunucu bileşenleri varsayılan hale geldi ve interaktif olmayan içerik için bundle boyutunu belirgin şekilde kısalttı. Bununla birlikte interaktif bileşenler için React runtime her halükarda istemciye gönderilmek zorunda; bu maliyet sıfırlanamıyor.

Dinamik import ve React.lazy ile bileşenleri route bazında bölmek bu maliyeti daha da dağıtıyor. Tüm uygulama kodunu tek bir pakette göndermek yerine, kullanıcının ziyaret ettiği route için gereken bileşenleri yüklemek ilk yükteki JavaScript miktarını düşürüyor. Bu strateji React runtime'ı ortadan kaldırmıyor; ancak uygulama kodunun tarayıcıya ne zaman ve ne kadar ulaşacağını kontrol altına alıyor.

Aynı Sayfa, İki Framework: Rakamlar Nasıl Farklılaşıyor?

Basit bir ürün listeleme sayfası düşünün: birkaç kart bileşeni, basit bir filtre, statik bir başlık. Fark burada çarpıcı.

Bu sayfanın SvelteKit ile üretilen gzip sıkıştırılmış JavaScript çıktısı genellikle 15-25 kB arasında kalıyor. Next.js'in aynı sayfa için çıkardığı başlangıç paketi, React runtime dahil, çoğu durumda 90-120 kB seviyesinde başlıyor. Sayfa içeriği artmadan bile bu temel fark sabit kalıyor.

Sayfa karmaşıklığı arttıkça tablo değişiyor. Onlarca bileşen, form validasyonu ve dinamik state yönetimi gerektiren bir uygulama sayfasında SvelteKit'in avantajı daralmaya başlıyor. Her bileşene düşen kod miktarı arttığında React'ın tek seferlik runtime maliyeti amortize oluyor ve toplam boyutlar birbirine yaklaşıyor. Bu eşik, proje tipine göre büyük ölçüde değişiyor; içerik ağırlıklı sitelerde Svelte lehine, uygulama ağırlıklı yapılarda ise iki framework daha denk seyrediyor.

Hydration Farkı ve JavaScript İşleme Süresi

Bundle boyutu indirilme süresiyle bitmiyor. Tarayıcı JavaScript'i indirdikten sonra ayrıştırıyor, derliyor ve çalıştırıyor; bu aşamalar toplam maliyetin önemli bir bölümünü oluşturuyor. Düşük güçlü cihazlarda veya kısıtlı ağlarda bu fark gözle görülür hale geliyor.

SvelteKit, hydration sürecini de daha sade tutuyor. Svelte bileşenleri doğrudan DOM'u manipüle ettiği için sanal DOM karşılaştırma adımı yok. Bu durum, hydration tamamlanana kadar geçen süreyi kısaltıyor ve Time to Interactive (TTI) değerini öne çekiyor.

Hydration maliyeti ağ hızı iyileştikçe daha görünür oluyor. Paket hızlı indirildiğinde darboğaz JavaScript işleme süresine kayıyor; burada fazladan yüz kilobaytlık kod, yavaş ağda fark edilmeyecek şekilde işleme süresine yansıyor. Orta seviye cihazlarda parse süresi genellikle indirme süresini aşıyor; bu nedenle kilobayt farkı, gerçek kullanıcı deneyimine milisaniye olarak geri dönüyor.

Next.js ile çalışıyorsanız ve TTI hedefinizin üzerindeyse, önce React RSC geçişini değerlendirin. Sunucu tarafında render edilen ve etkileşim gerektirmeyen bileşenlerden "use client" direktifini kaldırmak, istemci bundle'ını ölçülebilir biçimde küçültüyor. Bu değişiklikle elde edilen kazanım, iki framework arasındaki temel boyut farkını kapatabilecek düzeyde olabiliyor; ancak React runtime varlığını koruyor.

Boyut Farkı Ne Zaman Önemsizleşiyor?

Her iki framework de HTTP/2 ve cache mekanizmalarından yararlanıyor. React runtime ilk ziyaretten sonra cache'leniyor; sonraki sayfa geçişlerinde yeniden indirilmiyor. Kullanıcılarınızın büyük çoğunluğu tekrar ziyaretçiyse bu ilk yük farkı pratikte görünmez hale gelebiliyor.

Next.js, React runtime'ı ayrı bir chunk olarak servis ediyor. Bu dosya değişmeyen bir bağımlılık olduğu için uzun cache TTL değeriyle sunulabiliyor ve CDN'de tutunuyor. Uygulamanızı güncelleseniz bile bu dosya önbellekte kalmaya devam ediyor; kullanıcı ikinci ziyaretinde sıfır maliyet ödüyor.

Ekip büyüklüğü ve mevcut ekosistem de bu tercihi etkileyen faktörler arasında. Next.js büyük bir kütüphane ve deneyim birikimini beraberinde getiriyor. Svelte ise daha küçük bir topluluğa sahip; kurumsal projelerde üçüncü taraf entegrasyon seçenekleri daha kısıtlı kalabiliyor. Bundle boyutu avantajı bu ekosistem farkıyla birlikte değerlendirilmesi gereken bir denklem.

Bundle Boyutunu Doğru Okumak: Hangi Sayıya Bakmak Gerekir?

Ham dosya boyutu, gzip sıkıştırılmış boyut ve brotli sıkıştırılmış boyut birbirinden farklı rakamlar veriyor. Karşılaştırmayı aynı metrik üzerinden yapmak gerekiyor; aksi halde yanıltıcı sonuçlara ulaşmak kaçınılmaz.

Next.js, next build çıktısında her route için JavaScript boyutunu gzip olarak gösteriyor. SvelteKit ise vite build çıktısında chunk bazında raporluyor. İki çerçeveyi karşılaştırmak için her ikisini de gzip boyutu üzerinden değerlendirin ve paylaşılan (shared) chunk'ları toplam hesabına katın; yoksa SvelteKit'in gerçek yükünü küçümsemek mümkün.

Vite'ın rollup-plugin-visualizer eklentisi veya Next.js için @next/bundle-analyzer bu analizde yardımcı oluyor. Hangi kütüphanenin ne kadar yer kapladığını görmek, framework farkından bağımsız olarak en kolay kazanımları ortaya çıkarıyor. Çoğu zaman bir utility kütüphanesinin ağır sürümünü daha hafif bir alternatifle değiştirmek, iki framework arasındaki temel boyut farkını aşıyor; bu nedenle ölçmeden framework değiştirmek için yola çıkmak verimsiz bir strateji.

Her iki araç da tree shaking'i destekliyor; ancak side effect olarak işaretlenen modüller bu optimizasyonun kapsamı dışında kalabiliyor. package.json içindeki "sideEffects": false ayarını kontrol etmek ve kullanılmayan export'ların bundle'a girip girmediğini doğrulamak, hangi framework seçilirse seçilsin erken yapılması gereken adımlardan biri.

SvelteKit ile Next.js arasındaki bundle farkı gerçek, ölçülebilir ve özellikle içerik ağırlıklı siteler için anlamlı. Ancak bu fark tek başına framework seçimini belirleyecek kadar nadiren belirleyici oluyor. Projenin interaktivite ihtiyacı, hedef kitle cihaz profili ve ekibin mevcut deneyimi bu kararı şekillendiren daha ağır faktörler.

Performans odaklı bir proje başlatıyorsanız ve React ekosistemi zorunluluğunuz yoksa, SvelteKit'in derleme zamanı modeli başlangıç maliyetini düşük tutmanın temiz yollarından birini sunuyor. Next.js kullanıyorsanız, React Server Components'a geçiş bu maliyeti geri kazanmak için hâlâ etkili bir yol; ancak runtime'ı tamamen sıfırlamak mümkün değil. Her iki seçimde de bundle boyutunu düzenli ölçmek ve somut eşiklere göre karar vermek, sezgisel karşılaştırmalardan çok daha güvenilir bir rehber.