Partial Hydration ve Island Architecture: Performans Kazancı Gerçekte Ne Kadar?

Island modelinin temeli: statik gövde, izole bileşen

Geleneksel tam hidrasyon modelinde tarayıcı, tüm sayfayı sunucu tarafında HTML olarak alır ve ardından aynı bileşen ağacını istemci tarafında yeniden oluşturur. React'ın hydrateRoot çağrısı bunu tetikler; Vue, Svelte ve diğer framework'lerin eşdeğerleri de aynı ilkeyi izler. Bu süreç, sayfanın herhangi bir yerinde etkileşim olmasa bile tüm bileşen kodunu yükler, ayrıştırır ve çalıştırır.

Island modeli bu sorunu kökten farklı biçimde çözer. Sayfa varsayılan olarak statik HTML'dir; JavaScript yalnızca açıkça etiketlenmiş bileşenlere eklenir. Astro'da bu etiketleme client:load, client:idle, client:visible, client:media ve client:only direktifleriyle yapılır. Bir bileşen hiç etiketlenmemişse sıfır JavaScript gönderir, sadece HTML çıktısı üretir; kodu istemciye hiç ulaşmaz.

Bileşenler arasındaki izolasyon da yapının temel özelliklerinden biridir. Her ada bağımsız bir uygulama gibi yüklendiğinden, büyük bir adanın hidrasyonu diğerlerini bekletmez. Tarayıcı ana iş parçacığını (main thread) bir adanın işlemi için bloke ettiğinde, diğer adalar bu süreçten etkilenmez. Klasik tam hidrasyonda ise tek büyük ağaç her şeyi sırayla işler; uzun bir JavaScript paketi tek seferde uzun görevler (long tasks) oluşturabilir.

Statik kabuk anında görünür olur. Sunucu HTML'yi eksiksiz gönderdiğinden, tarayıcı JavaScript indirmeden önce tüm içeriği ekrana çizer. Etkileşimli adalar hazır olmadan önce bile kullanıcı metni okuyabilir, görüntülere bakabilir, sayfa içinde kaydırma yapabilir; bu gecikme, kullanıcının bakış açısından sayfa "çalışmaya başladı" izlenimini çok daha erken verir.

Hangi metrikler değişir: TBT, INP ve LCP ilişkisi

Total Blocking Time (TBT), ana iş parçacığını 50 milisaniyeden uzun süre bloke eden görevlerin toplamını ölçer. Büyük bir hidrasyon paketi tek seferde çalıştığında TBT doğrudan yükselir; ada mimarisinde ise her adanın işleme süresi küçüktür ve uzun görev eşiğini geçmeyebilir. TBT'nin düşük kalması, Interaction to Next Paint (INP) için de önkoşuldur; çünkü ana iş parçacığı meşgulken gelen kullanıcı girdisi gecikir ve INP yükselir.

LCP (Largest Contentful Paint) ile ilişki daha dolaylıdır. Ada mimarisi LCP öğesini doğrudan iyileştirmez; LCP zaten sunucu tarafında render edilen HTML ve görsel yükleme hızına bağlıdır. Ancak JavaScript yükü azaldığında ağ bant genişliği ve CPU sırası boşalır, dolayısıyla LCP öğesinin önündeki bant genişliği yarışması azalır. Bu dolaylı kazanç, yavaş ağ ve düşük güçlü cihazlarda daha belirgindir.

Cumulative Layout Shift (CLS) ada modelinden neredeyse hiç etkilenmez. CLS'nin nedenleri boyutsuz görseller, dinamik içerik eklemeleri veya web fontlarının geç yüklenmesidir; hidrasyon stratejisi bu faktörleri değiştirmez. Bileşenler sunucuda tam HTML olarak render edildiğinden, istemci tarafında bir yer tutucu sonradan bileşenle değiştirilmez ve layout kayması tetiklenmez.

Sayısal beklenti kurarken dikkatli olmak gerekir. Yüksek JS yüklü bir sayfada TBT yüzlerce milisaniye düşebilir; buna karşın zaten optimize edilmiş, az etkileşimli bir sayfada kazanç onlarca milisaniyeye iner. Hangi metriğin öncelikli olduğunu bilmek, geçişin değerini önceden tahmin etmenin tek güvenilir yoludur.

Astro'da yükleme direktifleri ve ne işe yararlar

Astro'nun direktif sistemi, ada yükleme zamanlamasını bileşen başına kontrol eder. client:load sayfa yüklenir yüklenmez hidrasyonu başlatır; tüm etkileşim anında gerekli olmayan bileşenler için tercih edilmemelidir, çünkü yükleme sürecinin kritik yoluna girer. Kaydırmayla görünür hale gelen içerik için client:visible daha uygundur: bileşen yalnızca görüntü alanına (viewport) girdiğinde hidrasyon başlar ve kullanıcı o bölgeye hiç ulaşmazsa JavaScript hiç çalışmaz.

client:idle tarayıcı boşta olduğunda, yani requestIdleCallback fırsatı bulduğunda hidrasyonu tetikler. Önemli ama acil olmayan bileşenler - bildirim çanı, kullanıcı menüsü, okuma listesi - için iyi bir tercih oluşturur. client:media ise yalnızca belirli bir medya sorgusu eşleştiğinde hidrasyonu başlatır; örneğin masaüstü gezinme çubuğu, mobil cihazlarda hiç JavaScript almaz.

Bu direktiflerin birbirini dışlamadığını hatırlamak gerekir. Tek bir sayfada birden fazla direktif türü bir arada kullanılabilir. Kritik arama çubuğu client:load alırken, sayfa altındaki yorum formu client:visible alabilir. Hangi bileşenin hangi direktifi alacağı kararı, sayfanın etkileşim haritasını çıkarmayı gerektirir; bu harita olmadan direktifler rastgele atanır ve kazanç rastlantısala döner.

Ne zaman anlamlı kazanç, ne zaman gereksiz karmaşıklık

Island mimarisinin en belirgin performans etkisi, yüksek JS yüklü ve büyük ölçüde statik içerikten oluşan sayfalarda görünür. Blog, belge sitesi, pazarlama sayfası, portfolyo: bu tür sayfalarda etkileşim bir veya iki bileşenle sınırlıdır. Arama çubuğu, abonelik formu veya tema değiştirici dışındaki her şey saf HTML olarak gönderilebilir. Böyle bir sayfada tam hidrasyon modelinden ada modeline geçmek, JavaScript paket boyutunu ve hidrasyon süresini doğrudan azaltır.

Gereksiz karmaşıklık ise ağır etkileşimli uygulamalarda ortaya çıkar. Gerçek zamanlı ortak düzenleme aracı, çok adımlı sipariş süreci, zengin metin editörü veya borsacı pano gibi uygulamalarda sayfanın büyük bölümü zaten JavaScript gerektirir. Ada mimarisi burada da uygulanabilir, ancak adaların sayısı ve büyüklüğü artıkça yönetim maliyeti yükselir. Adalar arası durum paylaşımı - sinyal tabanlı kütüphaneler veya nano-store'lar aracılığıyla çözülebilse de - ekstra bir mimari katman gerektirir ve bu katman her ekip için kolay olmaz.

Ters etki riski de vardır. Yanlış yapılandırılmış client:load direktifleri, zaten tam hidrasyonla yapılabilecek olanı daha kötü bir organizasyonla tekrar üretir. Onlarca client:load bileşeni olan bir Astro sayfası, optimize edilmiş bir Next.js sayfasından daha yavaş olabilir. Asıl karar şudur: sayfanın statik ve dinamik kısımları birbirinden yeterince ayrı mı? Bu ayrım yoksa ada modeli kazanç sağlamaz, yalnızca geliştirme sürecine yük ekler.

Mevcut bir uygulamayı taşımak mı yoksa sıfırdan mı başlamak? Mevcut bir React uygulamasını Astro'ya taşımak, çoğu durumda tam yeniden yazımı gerektirir. Bileşen mantığı korunabilse de yönlendirme, veri çekme, durum yönetimi ve build sistemi değişir. Bu maliyet büyük projeler için hesaba katılmalıdır; yeni projeler veya içerik ağırlıklı siteler için ise başlangıçta doğru çerçeveyi seçmek dönüştürme maliyetini sıfırlar.

Fresh ile sunucu-merkezli yaklaşım: fark nerede

Fresh, Deno üzerinde çalışır ve derleme adımı gerektirmez. Her istek sunucuda işlenir, bileşenler varsayılan olarak sıfır JavaScript gönderir ve yalnızca islands/ dizinindeki bileşenler istemciye kod taşır. Bu yapı, Astro'nun direktif sisteminden daha kısıtlayıcıdır: Fresh'te bir bileşen ya tam ada'dır ya da tamamen statiktir, aradaki ince ayar direktifi yoktur.

Fresh'in avantajı daha az konfigürasyon gerektirmesidir. Dosya sistemine dayalı yönlendirme ve ada/statik ayrımı otomatik olarak uygulanır; geliştirici yanlışlıkla bir bileşeni hidrasyona dahil etmek için ekstra adım atmak zorunda kalır. Ancak bu kısıtlama aynı zamanda esneklik kaybıdır: client:idle veya client:visible gibi gecikmeli yükleme stratejileri doğrudan desteklenmez ve özel kod gerektirir.

Ekosistem farkı da göz ardı edilmemelidir. Astro npm ekosistemiyle tam uyumludur; mevcut React, Vue veya Svelte bileşenlerini minimal değişiklikle kullanabilir. Fresh ise Deno ve JSR ekosistemini kullanır; büyük npm paketlerinin çoğu Deno uyumlu değildir veya ek uyumluluk katmanı gerektirir. Ekibin mevcut bağımlılık yığını bu seçimi doğrudan etkiler.

Kazancı ölçmek: lab ve alan verisi nasıl yorumlanır

Ada mimarisine geçiş kararını verirken önce mevcut sayfanın TBT ve INP değerlerini ölçmek gerekir. Chrome DevTools Performance paneli, hidrasyon sürecini zaman çizelgesinde gösterir; uzun görevleri ve bunların hangi script'ten kaynaklandığını açıkça raporlar. Hidrasyon kaynaklı uzun görevler yoksa geçiş TBT'ye dokunmaz.

Lab verisi tek başına yeterli değildir. Chrome DevTools ve Lighthouse, genellikle hızlı bir masaüstü makinesini ya da sınırlı bir emülasyon profilini baz alır. Gerçek kullanıcı verisi (RUM) ise düşük güçlü Android cihazlarda ve yavaş ağlarda gerçek koşulları yansıtır. Alan verisinin TBT veya INP değerleri iyi görünüyorsa mimari değişiklik acil değildir; alan verisi kötüyse ve lab testleri hidrasyon kaynaklı uzun görevler gösteriyorsa ada mimarisi somut bir çözüm haline gelir.

Geçiş sonrası doğrulama için A/B testi mümkün değilse aynı URL'in eski ve yeni sürümünü karşılaştırmak gerekir. Bunu yaparken üçüncü taraf script yükünü, reklam sistemlerini ve analytics betiklerini sabit tutmak önemlidir; aksi halde gözlenen değişiklik ada mimarisinden değil başka faktörlerden kaynaklanabilir. Aynı test koşullarını koruyarak yapılan ölçüm, kazancı yalıtır.

INP ölçümünde dikkat edilmesi gereken bir nokta şudur: INP, en kötü etkileşimin yüzde 98'lik dilimini raporlar. Ada mimarisi yüklenmeyi hızlandırır ama tıklama sonrası işlem süresi ada'nın kendi koduna bağlıdır. Hidrasyon bitti, ada yüklendi; ama ada'nın click handler'ı yavaşsa INP yine kötü kalır. Yükleme optimizasyonu ile çalışma zamanı optimizasyonu birbirinin yerine geçmez.

Mimari sınırlar ve geliştirici tuzakları

Ada modeli, adalar arası paylaşılan durumu (shared state) doğrudan çözmez. İki bağımsız ada aynı veriyi göstermesi gerektiğinde klasik seçenekler şunlardır: URL parametreleri, localStorage/sessionStorage üzerinden sinyaller veya küçük bir global store. Astro bu sorunu nanostores gibi kütüphanelerle çözmeyi önerir; Fresh benzer durumlar için Deno KV veya sinyal tabanlı yapılar kullanır. Durum paylaşımının karmaşıklığı artıkça ada modeli avantajı azalır, çünkü her ada için ayrı ayrı senkronizasyon mantığı yazmak gerekmez.

SEO açısından ada modeli avantajlıdır. İçerik sunucu tarafında tam HTML olarak render edildiğinden, SEO tarama botları JavaScript çalıştırmaya gerek duymadan içeriği okuyabilir. Bu durum tam hidrasyon modelinden farklı değildir - SSR yapan her framework zaten HTML üretir - ama istemci tarafı render (CSR) kullanan uygulamalardan belirgin şekilde üstündür.

Build zamanı da bir faktördür. Astro, statik sayfaları derleme sırasında üretir; sayfa sayısı binleri aştığında build süresi uzayabilir. Incremental build desteği ve sayfa bazlı önbellekleme bu sorunu hafifletir, ancak çok büyük içerik sitelerinde dikkat gerektirir. Fresh'te build adımı olmadığından bu sorun yoktur; her istek sunucuda işlenir, bu da ölçekleme gereksinimlerini farklılaştırır.

Hata izolasyonu. Bir ada çökerse diğerleri etkilenmez; React'ın Error Boundary mekanizması her ada için ayrı ayrı uygulanabilir. Tam hidrasyonla yazılmış büyük bir uygulamada bir bileşen hatası tüm sayfayı bloke edebilir, oysa ada modelinde kalan statik içerik her koşulda görünür kalır.

Hangi projede ada mimarisi seçilmeli

İçerik ağırlıklı, az etkileşimli siteler bu modelin doğal hedefidir: belge portalları, blog platformları, pazarlama siteleri, fiyatlandırma sayfaları, açılış sayfaları. Bu tür projelerde etkileşim bir avuç bileşenle sınırlıdır ve sayfanın geri kalanı için JavaScript göndermek gereksizdir. Başlangıçtan Astro ile kurulan bu tür bir proje, ileride optimize etme gerekliliğini büyük ölçüde ortadan kaldırır.

E-ticaret katalog sayfaları da iyi bir eşleşmedir. Ürün listesi ve açıklama statik HTML olarak sunulurken sepet, favoriler ve boyut seçici gibi bileşenler ada olarak işaretlenir. Bu yapı, LCP'yi etkileyen ürün görselinin erken yüklenmesini kolaylaştırır ve sepet bileşeninin hidrasyonunu kritik yolun dışına çıkarır. Ağır dinamik bir ürün sayfasında - örneğin gerçek zamanlı stok göstergesi, canlı fiyat değişimi - adaların kapsamı genişler ve kazanç azalır ama yine de anlamsız değildir.

Yüksek etkileşimli uygulamalar için farklı bir değerlendirme gerekir. Proje yönetim aracı, kod editörü, gerçek zamanlı analiz panosu gibi uygulamalarda sayfanın neredeyse tamamı JavaScript gerektirir. Ada modeli uygulanabilir ama kazanç sınırlıdır; bu durumda React Server Components veya sinyal tabanlı reaktivite gibi alternatif optimizasyon yolları daha verimli olabilir.

Ekip deneyimi de karar faktörüdür. Ada modelini destekleyen araçlar farklı mental modeller ve dosya yapıları gerektirir. Mevcut bir React ekibi Astro'yu öğrenebilir, ancak bu öğrenme süreci geçici bir yavaşlama yaratır. Kazancın bu maliyetin üstünde kalıp kalmadığı, proje süresine ve sayfanın mevcut performans durumuna göre değişir.