JavaScript'in tarayıcıda işlenmesi ücretsiz değildir. Her framework bağımlılığı, her bileşen ağacı ve her hydration döngüsü ayrı ayrı CPU zamanı tüketir; bu maliyet düşük güçlü bir telefonda veya yavaş bir ağ bağlantısında kullanıcıya yavaş açılan sayfa olarak geri döner.

Island architecture (ada mimarisi), içerik ağırlıklı sayfalar için öne çıkan bir yaklaşımdır. Temel fikir şudur: sayfanın statik olan kısmı zaten HTML'dir, onu JavaScript ile yeniden oluşturmak gerekmez. Yalnızca gerçekten etkileşim gerektiren küçük parçalar - adalar - JavaScript ile canlandırılır; geri kalan her şey saf HTML olarak kalır ve tarayıcı bunu sıfır JavaScript maliyetiyle render eder.

Astro ve Fresh bu modeli resmi bir özellik olarak sunar. Hangi projede uygulanabileceği, hangi durumda gereksiz maliyet eklediği ve ne zaman ters etki yaratacağı ise çoğu zaman kaynak belgelerde net biçimde yer almaz. Karar, sayfadaki etkileşimli bileşen oranına iner.

Sayfanın Kaçta Kaçı Gerçekten Etkileşimli?

Island mimarisinin ilk sorusu budur. Bir sayfada başlıklar, paragraflar, görseller, tablolar ve bağlantılar statik içeriktir; kullanıcı davranışına bağlı olarak değişmezler. Etkileşimli alan çoğunlukla çok daha küçüktür: bir arama kutusu, bir sepete ekle düğmesi, bir accordion bileşeni ya da bir yorum formu.

SPA yaklaşımında tüm sayfa istemcide oluşturulur. React ya da Vue tüm bileşen ağacını tarayıcıda kurar; sunucu tarafında render (SSR) yapılsa bile istemci tarafında o ağacı hydrate etmek zorunludur. Sayfanın büyük çoğunluğu hiçbir zaman değişmeyecek olsa da hydration bu alanları da kapsar. Tüm o statik HTML için JavaScript çalışır, ancak sonuç değişmez.

Island mimarisinde oran tersine çalışır. Statik alan HTML olarak gelir ve hiç hydrate edilmez. Etkileşimli ada bileşeni ayrı bir JavaScript parçası olarak yüklenir ve yalnızca kendi DOM düğümünü sahiplenir. Sayfa yükleme sırasında tarayıcının ayrıştırıp işleyeceği JavaScript miktarı doğrudan azalır ve bu azalma, arama kutusunun ya da form bileşeninin çalışmaya başlama süresini kısaltır.

Sayfada etkileşimli alan azaldıkça island mimarisi daha belirgin kazanım sunar. Okuma/yazma oranı yüksek olan projeler - yani kullanıcıların çoğunlukla tükettiği, nadiren etkileşime geçtiği yapılar - bu yaklaşımdan en çok yararlananlar arasındadır.

İçerik Ağırlıklı Projeler ve Kazanım Alanları

Blog, haber sitesi, belgeleme portalı, ürün kataloğu ve kurumsal web sitesi island mimarisinden doğrudan fayda sağlar. Bu sayfa türlerinde içerik büyük çoğunlukla değişmez; etkileşim ise sınırlı sayıda noktada yoğunlaşır.

Bir belgeleme sitesi düşünün. Binlerce sayfa var, her sayfada başlık yapısı, kod örnekleri ve bağlantılar yer alıyor. Etkileşimli olan yalnızca arama kutusu, dil seçici ve bir "kopyala" düğmesidir. Bu yapıyı React ile kurduğunuzda her sayfayı hydrate etmek için birkaç yüz kilobayt runtime göndermeniz gerekir. Astro ile kurduğunuzda yalnızca arama bileşeni için gereken JavaScript yüklenir; bu sayı pratikte 10-15 kilobaytın altında kalabilir.

E-ticaret ürün sayfaları da benzer bir dağılım gösterir. Ürün açıklaması, görseller, teknik özellikler ve müşteri yorumlarının büyük kısmı statiktir. Sepete ekle düğmesi, stok bilgisi ve miktar seçici etkileşimlidir. Yalnızca bu üç bileşeni ada olarak tanımlamak, sayfa başına taşınan JavaScript yükünü kayda değer ölçüde azaltır.

Mobil kullanıcılar bu farkı daha belirgin yaşar. JavaScript ayrıştırma ve yürütme süresi orta segment bir telefonda masaüstü CPU'suna kıyasla 3-4 kat daha uzun sürebilir; hydration geciktikçe etkileşimli bileşenler de geç yanıt verir. Ada mimarisinde bu gecikme yalnızca gerçekten etkileşimli bileşenlerle sınırlı kalır.

Partial Hydration Astro'da Nasıl Çalışır?

Astro, bileşen bazlı bir yapı sunar ancak varsayılan olarak hiçbir şeyi hydrate etmez. Bir Astro sayfasında React, Vue, Svelte veya başka bir framework bileşeni kullanabilirsiniz; fakat bu bileşeni client: direktifi olmadan çağırdığınızda Astro yalnızca sunucuda render eder ve çıktıyı statik HTML olarak gönderir.

Bileşeni etkileşimli yapmak için direktifi açıkça yazmanız gerekir. Bu zorunluluk, yanlışlıkla yapılan hydration'ı engeller ve sayfadaki JavaScript miktarını kontrol altında tutar. Her direktifin farklı bir tetikleyicisi vardır; bu fark yükleme davranışını doğrudan etkiler.

Statik sayfa derlemesi ile istemci hydration bu modelde tamamen ayrıdır. Astro bir sayfayı derleme aşamasında ya da istek anında HTML olarak üretir, ardından yalnızca client: direktifi alan bileşenler için JavaScript bundle oluşturur. İki katman birbirinden bağımsız çalıştığından bileşen sırası ya da sayısı render hızını etkilemez; sunucu çıktısı her zaman hızlıdır ve JavaScript yalnızca adaları ilgilendiren küçük parçalar halinde gelir.

client: Direktifleri ve Yükleme Stratejileri

Astro'da beş temel direktif vardır ve her biri farklı bir öncelik düzeyi tanımlar.

  • client:load - Sayfa yüklenir yüklenmez bileşeni hydrate eder. Kullanıcının hemen göreceği ve etkileşime gireceği bileşenler için uygundur: navigasyon menüsü, açılış sayfasındaki form.
  • client:idle - Tarayıcı boşta kaldığında (requestIdleCallback) hydration başlar. Sayfa ilk yüklendiğinde kritik olmayan bileşenler için tercih edilir: yorum bölümü, paylaş düğmeleri.
  • client:visible - Bileşen viewport'a girdiğinde hydration tetiklenir. Sayfanın alt kısımlarındaki içerik için kullanışlıdır; kullanıcı o alana kaydırmadan JavaScript yüklenmez.
  • client:media - Belirli bir medya sorgusu eşlendiğinde hydrate edilir. Yalnızca mobilde görünen bir menü bileşenini masaüstünde hydrate etmemek için kullanılır.
  • client:only - Sunucu tarafında hiç render edilmez, yalnızca istemcide çalışır. Tarayıcı API'sine bağımlı bileşenler için gereklidir: canvas animasyonu, WebGL sahne.

Direktif seçimi önemlidir. client:load her yere uygulandığında island mimarisinin avantajı ortadan kalkar; sayfa yüklenirken tüm bileşenler sırayla hydrate edilir ve gecikme toplanır. Bileşenin kullanıcı etkileşim akışındaki yerine bakarak hangi direktifin daha uygun olduğunu belirlemek gerekir.

Doğru direktifi seçmek bir test sorusudur. Kullanıcı sayfayı açar açmaz bu bileşenle etkileşime girer mi? client:load. Sayfanın altında mı, yoksa yalnızca belirli senaryolarda görünür mü? client:visible ya da client:idle daha iyi bir başlangıç noktasıdır.

SPA ile Island Mimarisi Arasındaki Asıl Fark

SPA modeli, durumun istemcide yaşadığı, sayfalar arası geçişin JavaScript router üzerinden yönetildiği ve bileşen ağacının sürekli canlı kaldığı bir yapı kurar. Bu model, çok sayıda bileşenin anlık güncelleme gerektirdiği uygulamalarda - dashboard, gerçek zamanlı veri görselleştirme, adım adım formlar - hâlâ doğru tercihtir.

Island mimarisi bu senaryolarda yetersiz kalır. Sayfalar arası paylaşımlı durum, global WebSocket bağlantısı veya sık güncellenen bileşen ağacı gerektiren yapılarda her şeyi adaya bölmek mimariyi karmaşıklaştırır. Adalar arası durum paylaşımı için ek bir mekanizma gerekir; Astro bunu nanostores gibi hafif durum kütüphaneleriyle destekler, ancak karmaşık durum ağaçlarında SPA ekosisteminin sunduğundan uzaklaşmış olursunuz.

Aynı zamanda iki yaklaşım aynı projede bir arada kullanılabilir. Astro bir sayfa düzeninde SPA benzeri bir bölümü ada olarak barındırabilir. İçerik ağırlıklı bir site, yalnızca kendi dashboard sayfasında React ile tam bir uygulama çalıştırabilir; diğer sayfalar statik kalır. Bu hibrit kullanım, her iki modelin güçlü yanlarını korur ve yapay bir kısıtlama getirmez.

Ne Zaman Gereksiz Olur, Ne Zaman Ters Etki Yaratır?

Island mimarisi her proje için uygun değildir. Aşağıdaki durumlar yaklaşımın değil, alternatifin daha uygun olduğuna işaret eder.

Sayfa büyük çoğunlukla etkileşimliyse adaya bölme karmaşıklık ekler, kazanım sağlamaz. Bir rezervasyon akışı, çok adımlı kayıt formu veya gerçek zamanlı mesajlaşma arayüzü sayfanın neredeyse tamamını etkileşimli kılar; bu durumda hydration'dan kaçınılacak alan kalmaz. Tüm bileşenlere client:load eklenmek zorunda kalınan bir yapıda island mimarisinin farkı yalnızca ek yapılandırma yüküdür.

Adalar arası sık durum paylaşımı da bir uyarı işaretidir. Birden fazla adanın aynı veriye anlık erişmesi ve bu verinin değişmesinin zincirleme güncelleme tetiklemesi gerekiyorsa, merkezi bir durum katmanı olmadan yönetmek güçleşir. Küçük projelerde nanostores bu yükü karşılar; büyük projelerde ise mimariyi sürdürülebilir kılmak için ek çaba harcanır.

Ekip deneyimi de hesaba katılmalıdır. Astro'nun direktif modeli küçük projelerde hızla öğrenilir. Büyük bir ekip React'e zaten hakimse ve sayfa içeriği statik bölümlerden çok etkileşimli bileşenlerden oluşuyorsa, island mimarisine geçiş mevcut iş akışını aksatır ve kısa vadede üretkenliği düşürür.

Astro'nun derleme adımı, içerik güncellemelerini canlıya almak için yeniden derleme gerektirebilir. İçerik çok sık değişiyorsa ve derleme süresi uzunsa bu yapı bir fren haline gelir. Gerçek zamanlı içerik için Astro'yu SSR modunda kullanmak ya da farklı bir çözüm aramak daha makuldür.

Fresh ile Island: Deno Ekosistemindeki Karşılık

Fresh, Deno çalışma ortamı için geliştirilmiş bir web framework'üdür ve island mimarisini çekirdek tasarım kararı olarak benimser. Astro'dan farklı olarak Fresh yalnızca Preact bileşenlerini destekler ve adaları ayrı bir islands/ dizininde toplar.

Fresh'in çalışma modeli şöyledir: islands/ dizininin dışındaki her bileşen statik HTML olarak sunulur, JavaScript gönderilmez. Bir bileşeni etkileşimli yapmak için yalnızca o bileşeni islands/ dizinine taşımak yeterlidir. Yapılandırma yerine dizin konvansiyonu kullanmak, daha az yapılandırma dosyası anlamına gelir; ancak esnekliği de sınırlar. Astro'nun sunduğu direktif düzeyinde yükleme stratejisi seçimi Fresh'te varsayılan olarak yoktur; tüm adalar sayfa yükleme sırasında hydrate edilir.

Fresh'in öne çıktığı alan Deno Deploy ile doğal entegrasyonudur. Edge runtime üzerinde çalışmak isteyen ekipler için Astro'nun Node.js ağırlıklı ekosistemiyle kıyaslandığında farklı bir tercih noktası oluşturur. İkisi arasındaki seçim çoğunlukla ekip altyapısına ve runtime tercihine bağlıdır; island mimarisinin kendisi her iki araçta da aynı prensibi izler.

Island mimarisinin sunduğu şey, SPA'nın varsayılan olarak taşıdığı JavaScript yükünü ötelemek ya da tamamen ortadan kaldırmaktır. Projenizde statik içerik etkileşimli içeriğin önündeyse, sayfa açılış hızı önemli bir hedefse ve kullanıcıların önemli bir kısmı yavaş ağ veya orta segment cihaz kullanıyorsa bu yaklaşım somut bir fark yaratır.

Karar, etkileşimli bileşen oranına iner. Kullanıcı eylemini bekleyen parça azsa island mimarisi doğru araçtır. Oran yüksekse mevcut SPA yaklaşımı daha az yapılandırma maliyetiyle aynı sonucu verir; değiştirmek için yeterli neden yoktur.