SvelteKit Performans Avantajı Gerçekte Ne Kadar?

"Sıfır runtime" ifadesinin teknik karşılığı

React bir sayfayı tarayıcıda görüntülemek için gzip sonrası yaklaşık 40 KB civarında runtime kodu yükler; bu kod virtual DOM, reconciler ve event sistemi gibi parçaları içerir. Svelte bu yapıyı derleme aşamasında ortadan kaldırır: bileşenler doğrudan DOM güncellemelerine dönüştürülen imperatif JavaScript'e derlenir, runtime kütüphane minimize edilmiş hâliyle birkaç KB'ın altında kalır.

Bu fark, küçük projelerde ya da içerik ağırlıklı sayfalarda hissedilir biçimde öne çıkar. Bir belgelendirme sitesi veya haber sayfası için toplam JavaScript yükü, React tabanlı eşdeğerine kıyasla çoğu durumda önemli ölçüde düşer. Ne var ki uygulama büyüdükçe, eklenen her bileşen ve üçüncü taraf kütüphane bu başlangıç avantajını törpüler. Yüklü bir analitik paketi, bir ödeme widget'ı veya harita bileşeni eklendiğinde framework overhead farkı büyük resimde küçülür; belirleyici olan artık framework değil, uygulama yük bileşimidir.

Bundle avantajı mutlak değil, oransal bir başlangıç farkıdır. Bileşen sayısı arttıkça bu oran daralır, ancak derleme çıktısının ürettiği kod her bileşen için hâlâ daha kompakt kalır.

TBT ve INP: Ana iş parçacığı yükü nerede farklılaşıyor

TBT, kullanıcı etkileşimini geciktiren uzun görevlerin toplam süresini ölçer; INP ise her etkileşimin gerçek gecikmesini yakalar. SvelteKit bu iki metrikte iki ayrı yoldan katkı sağlar.

İlki, hidrasyon (hydration) maliyetidir. React, sunucudan gelen HTML'i tarayıcıda yeniden işlerken bir hidrasyon süreci yaşar ve bu süreç ana iş parçacığını geçici olarak meşgul eder. Svelte'nin ürettiği kod bu adımı farklı biçimde işler: derleme çıktısı daha az JavaScript çalıştırdığı için hidrasyon sırasındaki uzun görev sayısı azalır. Etkileşim yoğun sayfalarda, özellikle ilk yükleme sonrasındaki birkaç saniyede kullanıcı tıklama veya yazma girişiminde bulunuyorsa, bu TBT farkı INP'ye doğrudan yansır.

İkincisi, event bağlama yaklaşımıdır. React global event delegation (olay devri) kullanırken Svelte doğrudan DOM element bağlantıları üretir. Çok sayıda interaktif öğe içeren sayfalarda bu mimari fark zaman zaman ölçülür - ancak modern React sürümleri bu açığı büyük ölçüde kapatmıştır.

Pratik sınır nettir: TBT ve INP kazanımı en çok etkileşim yoğun, bileşen ağırlıklı sayfalarda ortaya çıkar. İçerik ağırlıklı, az interaktif sayfalarda ise bu iki metrik büyük ölçüde sunucu hızına ve ağa bağlıdır; framework seçimi ikincil kalır ve fark ölçümde kaybolur.

LCP'de hangi değişken gerçekten belirleyici

LCP genellikle bir hero görseli veya büyük metin bloğunun ekrana ulaşması olarak gerçekleşir. Framework seçiminin bu metriğe doğrudan katkısı sınırlıdır - ama mimari kararlar farklı bir yoldan LCP'yi etkiler.

SvelteKit varsayılan olarak SSR (sunucu taraflı render) sunar ve +page.server.js aracılığıyla veri çekimi doğrudan sunucuda tamamlanır. Bu yapı, istemcide JavaScript çalışmasını beklemeden HTML'in hazır gelmesini sağlar; bir istemci taraflı SPA'sına kıyasla LCP adayının erken görünmesini mümkün kılar. Ancak TTFB'yi belirleyen asıl etkenler sunucunun konumu, veritabanı sorgu süresi ve CDN yapılandırmasıdır. SvelteKit bu değişkenleri optimize etmez, yalnızca SSR'ı daha kolay erişilebilir kılar.

Bir projeyi istemci taraflı SPA'dan SvelteKit SSR'a taşıdığınızda LCP'deki iyileşmenin büyük bölümü framework değiştirmekten değil, istemci fetch'inden sunucu render'ına geçmekten kaynaklanır. Aynı geçiş başka bir SSR çerçevesiyle de yapılabilir ve benzer LCP sonuçları alınır.

Ölçüm bunu doğrular. Görselde fetchpriority="high" ve doğru <link rel="preload"> kullanımı, LCP üzerinde framework seçiminden çoğu durumda daha belirleyicidir; bu optimizasyonlar yapılmadan framework geçişiyle LCP'yi düzeltmeye çalışmak yanlış katmana müdahaledir.

SSR, SPA ve kısmi hidrasyon seçiminin metrikler üzerindeki rolü

SvelteKit'in belirgin güçlerinden biri, aynı uygulama içinde farklı render stratejilerini sayfa düzeyinde seçmeye izin vermesidir. Bir sayfa tamamen statik export edilirken başka bir sayfa SSR ile sunulabilir; üçüncü bir sayfa ise yalnızca istemci taraflı render'a alınabilir. Bu esneklik, TBT ve LCP için ayrı optimize edilmiş sayfalar üretmeyi mümkün kılar.

Kısmi hidrasyon konusunda SvelteKit, 2024 sonrasında gelen "runes" ve reaktivite modelindeki değişikliklerle daha ince kontrol imkânı sunmaya başladı. Yalnızca etkileşim gerektiren bileşenleri hidratlayıp geri kalanı statik bırakmak, doğru mimaride TBT'yi anlamlı biçimde düşürebilir. Yanlış mimaride ise tüm sayfa yine de tam hidrasyon yüküne girer ve fark ortadan kalkar.

Seçim şu soruya dayanır: sayfanın hangi kısmı interaktif? Büyük formlar, gerçek zamanlı güncellemeler veya kullanıcı oturumu gerektiren içerik varsa SvelteKit'in reaktivite modelinden tam verim alınır. Yalnızca metin ve görselden oluşan, etkileşimi minimal olan sayfalar içinse statik export tercih edilmeli; bu durumda hidrasyon maliyeti sıfıra yaklaşır ve INP zaten sorun olmaktan çıkar.

Melez yapı mümkündür. Aynı SvelteKit uygulamasında pazarlama sayfaları statik, hesap paneli SSR, gerçek zamanlı özellik istemci render - üçü bir arada çalışabilir ve her sayfa kendi performans profiline göre yapılandırılabilir.

Gerçek fark yaratan senaryolar - ve yaratmayanlar

İçerik yönetim sistemiyle beslenen bir blog veya belgelendirme sitesi için SvelteKit avantajı en somut biçimde bundle boyutunda görülür. JavaScript yükü düşer, TBT düşük kalır, sayfa hafif hissettirir. Ama bir statik site jeneratörü de benzer sonuçlar verir; SvelteKit'in özgün katkısı, bu sadeliği dinamik özelliklerle bir arada sunabilmesidir.

E-ticaret veya SaaS gibi karmaşık, etkileşim yoğun uygulamalarda tablo farklılaşır. Çok sayıda bileşen, üçüncü taraf script ve özellik katmanları eklendiğinde başlangıç JavaScript avantajı büyük ölçüde erir. INP'nin sorunlu olduğu bu senaryolarda asıl suçlu genellikle framework değil, kontrolsüz büyüyen uygulama mantığı, analitik paketleri ve reklam scriptleridir. Framework'ü değiştirmek bu yükü ortadan kaldırmaz.

Düşük güçlü mobil cihazlar ayrı bir değişken olarak devreye girer. Bu ortamlarda JavaScript yürütme maliyeti masaüstüne kıyasla belirgin biçimde artar; Svelte'nin ürettiği daha sıkıştırılmış kod nispi bir avantaj sağlar. Ancak yavaş ağ koşullarında kaynak boyutu - JavaScript değil, görseller ve fontlar - metrikler üzerinde çok daha baskındır ve framework seçiminin etkisini gölgeler.

Bir durum özellikle dikkat ister: mevcut uygulamanız zaten iyi optimize edilmiş bir React/Next.js SSR kurulumuysa, SvelteKit geçişinden beklenen TBT veya LCP kazanımı çoğu durumda geçişin getirdiği yeniden yazım maliyetini karşılamaz. Gerçek kazanımlar ham bir SPA'dan ya da eski, optimize edilmemiş yapılardan yapılan geçişlerde görülür.

Ölçüm olmadan verilen kararın değeri

SvelteKit'in nerede fark yarattığını anlamanın tek güvenilir yolu kendi projenizi ölçmektir. Genel karşılaştırmalar referans noktası sunar; kesin cevap vermez. Chrome DevTools'taki Performance sekmesindeki Long Tasks görünümü ve web-vitals.js ile toplanan alan verisi (field data) size framework değil, kendi uygulamanızın profilini gösterir.

Bir geçiş veya yeniden yazım düşünüyorsanız önce mevcut TBT ve INP dağılımını alın. Ana iş parçacığını meşgul eden uzun görevlerin kaynağı nerede - framework runtime mı, üçüncü taraf scriptler mi, yoksa kendi uygulama kodunuz mu? Cevap üçüncü taraf scriptlerse, SvelteKit geçişi bu metriği anlamlı ölçüde iyileştirmez ve çaba yanlış yere gider.

LCP söz konusu olduğunda SSR stratejisi kritiktir, ancak sunucu konumu ve görsel optimizasyonu da en az o kadar önemlidir. Yalnızca LCP için bir geçiş planlıyor ve şu anda zaten SSR kullanıyorsanız, beklediğiniz kazanım gelmeyebilir. Kazanım daha büyük olasılıkla, SPA mimarisinden SSR'a geçen projelerde ortaya çıkar - ve bu geçişin yararı, kısmen seçilen framework'ten bağımsızdır.