JavaScript Framework Seçimi Performans Açısından Nasıl Değerlendirilir?

Hydration maliyeti nedir ve neden ölçülmelidir?

Sunucu tarafında render edilen (SSR) bir sayfa tarayıcıya HTML olarak ulaşır; kullanıcı içeriği hemen görür. Sayfa henüz etkileşime hazır değildir. Framework bu HTML'i "sahiplenip" olay dinleyicilerini bağlamak için JavaScript çalıştırır. Bu aşamaya hydration denir ve ana iş parçacığını bloke eden bir iş yüküdür.

Hydration maliyeti bileşen sayısı ve karmaşıklığıyla büyür. Büyük bir React uygulamasında hydration süreci ana iş parçacığını yüzlerce milisaniye boyunca meşgul edebilir. Bu süre içinde kullanıcının tıklaması kuyrukta bekler; INP değeri doğrudan kötüleşir. Kullanıcı tıkladığını düşünür, sayfa yanıt vermez; bu gecikme, tarayıcı performans araçlarında "long task" olarak görünür.

Sorunu hafifletmek için çeşitli yaklaşımlar geliştirilmiştir. Kısmi hydration (partial hydration) yalnızca etkileşimli bileşenleri canlandırır; statik içerik JavaScript'siz kalır. Adalar mimarisi (islands architecture) bu fikri daha ileri götürür: sayfa büyük ölçüde statik HTML'den oluşur, belirli "ada" bileşenler bağımsız olarak canlandırılır. Qwik ise hydration'ı tamamen ortadan kaldırmayı hedefler; bu yaklaşıma resumability (devam ettirilebilirlik) adı verilir.

Ölçüm için Chrome DevTools'un Performance sekmesinden başlanır. Sayfa yüklenirken "Evaluate Script" ve "Parse HTML" bloklarının büyüklüğü, hydration maliyetini gösterir. Gerçek cihaz verisi için field data vazgeçilmezdir; lab ortamı düşük güçlü cihazları yeterince temsil etmez.

Bundle boyutu: framework çekirdeği ne kadar yer tutar?

Framework'ün kendisinin sıkıştırılmış (gzip) boyutu, ağ maliyetini doğrudan etkiler. Daha küçük bundle daha kısa parse ve compile süresi demektir; bu fark, özellikle orta seviye Android cihazlarda belirginleşir. Masaüstü bilgisayarda fark edilmez olan 50 KB'lık bir fark, 2-3 yıllık bir telefonda 200-300 ms parse süresine dönüşebilir.

Svelte bu eksende en avantajlı noktadadır. Svelte bir runtime framework değildir; bileşenler derleme sırasında vanilla JavaScript'e çevrilir. Uygulamanın bundle boyutu büyük ölçüde yazılan kod miktarına bağlıdır, framework çekirdeği neredeyse sıfırdır. Küçük ve orta ölçekli projelerde bu avantaj net biçimde ölçülebilir.

Solid da benzer bir derleme modeli kullanır; runtime boyutu oldukça küçüktür. React ve Vue'nun gzip boyutu birbirinden çok uzak değildir, ancak React ekosisteminde eklenti ve bağımlılıkların birikimi bundle'ı şişirir. Vue 3 ile Composition API, ağaç sallama (tree-shaking) açısından React'tan daha elverişli bir yapı sunar. Qwik'in kendi çekirdeği nispeten küçüktür, ancak resumability mekanizmasının çalışabilmesi için ek bootstrap kodu gerekir.

Bundle boyutunu izlemek için otomatik raporlama araçları kurulabilir. Next.js projelerinde @next/bundle-analyzer eklentisi bileşen ağırlıklarını görselleştirir; Vite tabanlı projelerde rollup-plugin-visualizer benzer işlevi görür. Önemli olan anlık boyut değil, her PR'da büyüme eğiliminin takip edilmesidir.

React: geniş ekosistem, dikkat isteyen hydration stratejisi

React, bileşen tabanlı UI geliştirmenin fiili standardı haline geldi. Ekosistem derinliği, topluluğun büyüklüğü ve iş ilanlarındaki talep açısından rakipsizdir. Performans açısından ise tablonun iki yüzü vardır.

Klasik React SSR'de tam hydration zorunludur; tüm bileşen ağacı tarayıcıda tekrar çalıştırılır. React 18 ile birlikte gelen Concurrent Features ve Suspense, önce içeriği gösterip hydration'ı parçalara bölen bir yaklaşım sunar. React Server Components ise sunucu bileşenlerinin istemciye hiç JavaScript göndermeden render edilmesini sağlar; bu özellik, doğru uygulandığında hem bundle boyutunu hem de hydration yükünü ciddi ölçüde azaltır.

Yanlış kullanıldığında ters etki yaratır. Gereksiz yere istemci bileşenlerine taşınan mantık, Server Components'ın tüm kazanımını siler. use client direktifini varsayılan olarak koymak yerine "ne kadarını istemciye vermem gerekiyor?" sorusunu sormak, doğru yaklaşımdır. Veriyi sunucuda işleyip yalnızca render sonucunu istemciye göndermek, büyük veri dönüşümlerinin bundle'a eklenmesini önler.

INP açısından React, büyük liste render işlemlerinde dikkat ister. useMemo ve useCallback hatalı kullanılırsa gereksiz hesaplama yaratır; React.memo ise her bileşene eklenmesi değil, gerçekten pahalı render'ların önüne geçmek için hedefli kullanılması gereken bir araçtır.

Vue ve Svelte: derleme zamanı avantajları ve reaktivite modeli

Vue 3'ün reaktivite sistemi, bileşen düzeyinde hassas güncellemelere olanak tanır. React'taki sanal DOM farkı hesaplamalarının aksine, Vue değişen özellikleri izler ve yalnızca ilgili DOM düğümlerini günceller. Bu tasarım, gereksiz yeniden render sayısını azaltır ve INP üzerinde olumlu etki yaratır. Composition API ile yazılan Vue kodu, ağaç sallamaya (tree-shaking) daha uygun bir yapı oluşturur; kullanılmayan reaktivite özellikleri bundle'a girmez.

Svelte'in çalışma modeli Vue'dan temelden farklıdır. Sanal DOM yoktur; framework bir derleyicidir. Svelte bileşenleri, derleme sırasında doğrudan DOM manipülasyonu yapan JavaScript'e dönüşür. Küçük bundle, düşük runtime maliyeti ve anlaşılır sözdizimi Svelte'i içerik ağırlıklı sitelerde, kütüphane projelerinde ve embed widget'larında güçlü bir seçenek yapar.

Svelte'in sınırı ekosistem genişliğidir. Karmaşık form yönetimi, büyük durum yönetimi gereksinimleri ve kurumsal ölçekli projeler için mevcut kütüphane seçenekleri React veya Vue kadar derin değildir. SvelteKit, bu boşluğu bir ölçüde kapatır; ancak proje ölçüsü büyüdükçe ekosistem kısıtı daha belirgin hissedilir. Svelte büyük bir e-ticaret platformu için değil, odaklı bir içerik sitesi veya araç uygulaması için doğru yer bulur.

Solid ve Qwik: ince granüler reaktivite ve hydration'ın ötesi

Solid, React'ın API tasarımını benimser ancak sanal DOM kullanmaz. Bileşenler yalnızca bir kez çalışır; reaktif sinyal (signal) mekanizması değişiklikleri izler ve yalnızca etkilenen DOM düğümünü günceller. Gereksiz yeniden render yoktur; her güncellemede tüm bileşen ağacı yeniden değerlendirilmez. Bu model, özellikle sık değişen veri akışlarında INP'yi belirgin biçimde iyileştirir.

Solid küçük runtime boyutuyla da dikkat çeker. SolidStart ile SSR desteği gelişmeye devam etmektedir; ekosistem olgunluğu React veya Vue kadar derin değildir, ancak teknik performans değerlendirmesinde Solid tutarlı biçimde öne çıkar. Öğrenme eğrisi React'a alışık ekipler için nispeten kısadır; ancak sinyal tabanlı reaktivite zihin modelinin farklılığı ilk birkaç hafta hata kaynağı olabilir.

Qwik ise hydration sorununa en radikal çözümü getirir. Resumability modeli şöyle çalışır: sunucu uygulamanın tam durumunu HTML'e serileştirir; tarayıcı sayfayı başlatırken hiç JavaScript çalıştırmaz. Kullanıcı bir elemana tıkladığında yalnızca o eleman için gerekli kod ağa gönderilir. Başlangıç yükü sıfıra yakındır; TTI (Time to Interactive) son derece kısadır.

Qwik'in ters etkisi, birden çok kullanıcı etkileşiminin art arda gerçekleştiği senaryolarda ortaya çıkar. Her etkileşimde kod yüklenirse toplam ağ maliyeti artar. Aynı zamanda Qwik'in zihin modeli diğer frameworklere göre en yabancı olanıdır; ekip bu modeli özümsemediyse kod tabanı hızla karmaşık bir yapıya dönüşür. Qwik, içerik ağırlıklı, etkileşimin sınırlı olduğu ve düşük güçlü cihaz kullanıcılarının önemli bir kitle oluşturduğu projelerde güçlüdür.

INP profili: etkileşim gecikmesi neden framework bağımlıdır?

INP, bir sayfanın ömrü boyunca kullanıcı etkileşimlerine verilen yanıt sürelerinin büyük çoğunluğunu ölçer. 200 ms altı "iyi", 500 ms üzeri "kötü" sınırındadır. INP'yi olumsuz etkileyen iki temel neden vardır: uzun görevler (long tasks) ve gereksiz yeniden render'lar.

Uzun görevler genellikle hydration, büyük liste işlemleri veya ağır hesaplama fonksiyonlarından kaynaklanır. React'ta tüm ağacı etkileyen bir durum güncellemesi uzun bir görev yaratabilir; Concurrent Mode ile bu iş parçalanabilir ancak bu özelliğin doğru kullanımı dikkat ister. Vue'nun hassas reaktivitesi uzun görev riskini azaltır; Solid ve Svelte bu eksende yapısal avantaja sahiptir.

Gereksiz yeniden render sorunu genellikle framework bağımsız bir kod kalitesi sorunudur, ama framework'ün varsayılan davranışı bu riski artırabilir ya da azaltabilir. React, bir bileşenin durumu değiştiğinde tüm alt ağacı yeniden render etmeye eğilimlidir; bunu önlemenin yolları vardır ancak bilinçli çaba gerektirir. Vue ve Solid bu davranışı varsayılan olarak kısıtlar.

INP profili çıkarmak için Chrome DevTools'un Performance sekmesinde gerçek kullanıcı etkileşimlerini kayıt altına almak ve "Interactions" satırını incelemek gerekir. Field data için RUM (Real User Monitoring) kurulumu değerlidir; lab testleri etkileşim gecikmelerini her zaman doğru yansıtmaz.

Proje tipine göre seçim: ne zaman hangisi işe yarar?

İçerik ağırlıklı blog veya haber sitesi için Svelte veya Astro (adalar mimarisi) ile Svelte/Solid bileşenleri güçlü bir tercihtir. Etkileşim azdır, statik içerik fazladır; küçük bundle ve düşük hydration maliyeti doğrudan ölçülebilir kazanım sağlar. Qwik de bu senaryoda iyi çalışır, özellikle kullanıcı kitlesinin önemli bir bölümü orta seviye mobil cihaz kullanıyorsa.

Karmaşık web uygulaması, iç araç veya SaaS ürünü için React veya Vue tercih edilir. Ekosistem derinliği, bileşen kütüphaneleri, form yönetimi, durum yönetimi çözümleri ve geliştirici topluluğu bu ölçekte belirleyici faktörler olur. React'ta Server Components ve Concurrent Features doğru kullanıldığında performans sorunu yönetilebilir bir seviyede tutulabilir.

Performans kritik e-ticaret veya pazaryeri için seçim, ürün kataloğunun etkileşim yoğunluğuna göre şekillenir. Ana sayfa ve listeleme sayfaları statik veya ISR (Incremental Static Regeneration) ile sunulabilir; ürün detayı ve sepet sayfaları istemci bileşenlerini kullanır. Bu katmanlı yaklaşımda React ve Next.js ya da Vue ve Nuxt, ekosistem desteği nedeniyle öne çıkar. Solid veya Svelte tabanlı meta-framework'ler bu ölçekte henüz daha az sınanmıştır.

Embed widget veya üçüncü taraf bileşen kütüphanesi geliştiriyorsanız Svelte veya Solid neredeyse her zaman doğru seçimdir. React tabanlı bir widget, onu kullanan sayfanın zaten React içerip içermediğine bakılmaksızın React runtime'ını beraberinde getirir; bu durum ciddi bir bundle maliyeti yaratır. Svelte ve Solid, derleme zamanında ürettikleri düz JavaScript ile bu maliyeti sıfıra indirir.