Tek Sayfa Site mi Çok Sayfalı Site mi?

Tek sayfa ve çok sayfalı yapı arasındaki tercih teknik değil, mimari bir sorudur

SPA ile MPA tartışması sıklıkla teknik bir çerçeveye sıkıştırılır: hangi framework daha hızlı, hangi yaklaşım daha az sunucu yükü üretir, hangi araç daha kolay bakım gerektirir. Bu sorular önemlidir; ancak mimari kararın önüne geçmemelidir. Mimari soru şudur: bu site türünde içerik nasıl organize edilecek, ziyaretçi nasıl gezinecek ve bu yapı zaman içinde nasıl büyüyecek?

Bilgi mimarisi açısından bakıldığında iki model temelden ayrılır. MPA her sayfayı bağımsız bir bilgi birimi olarak ele alır: kendi URL'i, kendi başlığı, kendi meta verileri ve kendi içeriği olan bir birim. Ziyaretçi sayfalar arasında gezinir; her geçiş bir URL değişimidir. SPA bu bağımsızlığı yumuşatır. İçerik tek bir yükleme çerçevesinde akar; sayfalar arasındaki geçiş çoğu zaman bir URL değişiminden çok bir görünüm değişimidir.

Bu fark soyut değildir. Bir haber sitesinin her haberi ayrı bir URL'de bulunur, arama motorları her haberi bağımsız indeksler, okuyucular doğrudan bir haberin bağlantısını paylaşır. MPA bu yapıya doğal olarak uyar. Bir proje yönetim aracında ise kullanıcı görevler, yorumlar ve ekler arasında sürekli geçiş yapar; her etkileşim için tam sayfa yenilemesi hem yavaş hem de gereksizdir. SPA bu yapıya uyar. Karar, projenin hangi kategoriye girdiğini anlamakla başlar.

Tek sayfa uygulamalar URL yapısını kökten değiştirir

SPA'nın en belirgin mimari etkilerinden biri URL yapısı üzerinde görülür. Geleneksel MPA'da her sayfa kendi URL'ine sahiptir ve bu URL sunucuya bir istek gönderir. SPA'da ise URL genellikle istemci tarafı yönlendirmeyle yönetilir: adres çubuğu değişir ama sunucuya yeni bir belge isteği gitmez. Bu teknik farkın pratik sonuçları vardır.

Birincisi, SPA'da URL yapısı özellikle tasarlanmazsa kolayca ihmal edilir. Hash tabanlı yönlendirme kullanıldığında arama motorları bu URL'leri anlamlı kaynak olarak tanımakta güçlük çekebilir. HTML5 History API ile düzgün kurgulanan SPA URL'leri bu sorunu büyük ölçüde aşar; ancak bu özellikle ele alınması, test edilmesi ve sunucu tarafında desteklenmesi gereken bir çalışmadır.

İkincisi, MPA'da URL yapısı sayfaların hiyerarşisini ve içerik organizasyonunu yansıtır. `/blog/kategori/makale-adi` gibi bir URL hem insana hem de arama motoruna sayfanın site içindeki konumunu söyler. SPA'da bu hiyerarşiyi URL'e yansıtmak mümkündür; ancak genellikle ek konfigürasyon gerektirir ve uygulama büyüdükçe yönetimi güçleşebilir. MPA bu hiyerarşiyi dosya sistemi ya da sunucu yapısıyla doğal olarak kurar.

SEO tek sayfa yapılarda farklı bir yönetim gerektirir

SPA'nın arama motoru optimizasyonu açısından getirdiği zorluklar uzun süredir bilinir. Sorunun özü şudur: arama motorları bir SPA'yı ilk ziyaret ettiğinde genellikle boş ya da minimal bir HTML belgesiyle karşılaşır. Gerçek içerik JavaScript çalıştıktan sonra görünür hale gelir. Arama motorları JavaScript'i çalıştırabilir; ancak bu işlem her URL için ek zaman ve kaynak gerektirir. Tarama bütçesi sınırlı olan büyük sitelerde bu gecikme anlamlı bir sorun oluşturabilir.

Bu sorunu çözmek için sunucu tarafı render (SSR) ya da statik üretim (SSG) kullanılır. Her ikisi de SPA'nın içeriğini ilk yüklemede HTML olarak sunar. Bu yaklaşımlar işe yarar; ancak bu ek katmanları planlamak ve uygulamak ek bir mühendislik yatırımı gerektirir. MPA bu sorunu yapısal olarak taşımaz: her sayfa sunucudan tam HTML olarak geldiği için arama motorları içeriği doğrudan okuyabilir.

İçerik odaklı projelerde — bloglar, haber siteleri, e-ticaret siteleri, kurumsal siteler — her sayfanın arama motorunda bağımsız bir kaynak olarak indekslenmesi kritik önemdedir. Site haritası planlaması da bu bağlamda MPA için daha doğal işler: her URL bir sayfadır ve site haritasına doğrudan eklenir. SPA'da dinamik içerikler için bu listeleme ek araçlar gerektirir. Hangi yapının daha uygun olduğu, projenin organik arama trafiğine verdiği önem ve indekslenecek URL sayısına göre değişir.

Navigasyon iki modelde birbirinden ayrı biçimde kurgulanır

Kullanıcının site içinde nasıl hareket ettiği, iki mimari arasında belirgin farklar üretir. MPA'da navigasyon sayfadan sayfaya geçişi tetikler; her geçişte tarayıcı yeni bir belge yükler. Bu geçiş sırasında kısa bir yükleme süresi yaşanır. Kullanıcı tarayıcının geri düğmesini kullandığında önceki sayfaya döner; bu davranış web'in temel beklentisiyle örtüşür.

SPA'da navigasyon sayfanın bir bölümünü değiştiren bir etkileşimdir. Yükleme süresi genellikle yoktur ya da çok kısadır; içerik anında güncellenir. Bu akıcılık kullanıcı deneyimi açısından avantajdır — özellikle sık geçiş yapılan, etkileşim yoğun uygulamalarda. Ancak bu akıcılığı sağlamak için tarayıcı geri düğmesi, derin bağlantılar, scroll konumu koruma ve sayfa geçiş animasyonları gibi davranışların ayrıca kurgulanması gerekir. MPA'da bu davranışlar tarayıcı tarafından varsayılan olarak yönetilir.

İçerik sitelerinde kullanıcının navigasyon beklentisi genellikle MPA ile örtüşür. Bir makaleyi okuduktan sonra kategoriye dönmek, arama sonuçlarına gitmek, başka bir sayfayı sekmede açmak — bunların tamamı MPA'da sorunsuz çalışır. SPA'da bu davranışları doğal hissettirmek için ekstra çalışma gerekir. Uygulama bağlamlarında ise tablo, form ve panel geçişleri gibi etkileşimlerde SPA'nın akıcılığı kullanıcıya anlamlı bir fayda sağlar.

Tek sayfa yapının gerçek avantajı etkileşim yoğun projelerde ortaya çıkar

SPA'nın en güçlü olduğu bağlam, kullanıcının sürekli etkileşimde bulunduğu ve içerik değil işlev tükettiği uygulamalardır. Proje yönetim araçları, e-posta istemcileri, gerçek zamanlı dashboard'lar, çevrimiçi editörler — bu uygulamalarda kullanıcı sayfalar arasında değil, uygulama durumları arasında geçiş yapar. Her etkileşim için tam sayfa yenilemesi hem performans hem de deneyim açısından uygunsuz olur.

SPA bu bağlamda belirgin avantajlar sunar. Uygulama durumu tek bir yerde tutulur; kullanıcı form doldurmaya başladığında ya da bir göreve tıkladığında bu durum kaybolmaz. Etkileşimler anında geri bildirim üretir; bekleme süresi asgari düzeye iner. Bileşenler arasında veri paylaşımı ve anlık güncelleme çok daha kolay kurgulanır. Bu avantajlar MPA ile teknik olarak sağlanabilir; ancak SPA bu mimarinin doğal çıktısıdır.

Bir SaaS ürününün uygulama arayüzü için SPA seçmek, bir pazarlama blogu için SPA seçmekten yapısal olarak farklı bir karardır. Birincisinde seçim projenin gerçek ihtiyacıyla örtüşür; ikincisinde ise SPA'nın getirdiği SEO ve navigasyon maliyetleri, sunduğu performans avantajlarını genellikle geçer.

Çok sayfalı yapı içerik odaklı projelerde neden öne geçer?

Blog, haber sitesi, e-ticaret, kurumsal site, portföy — bu projelerin ortak özelliği şudur: içerik tüketimi işlev kullanımından ağır basar. Ziyaretçi okur, gezinir, arar ve karşılaştırır. Her sayfanın kendi URL'i vardır ve bu URL paylaşılabilir, yer imlerine eklenebilir ve arama motorlarında bağımsız olarak sıralanabilir. MPA bu hedefler için yapısal olarak uyumludur.

Arama fonksiyonu, filtreleme ve sayfalama gibi özellikler MPA'da URL parametreleriyle yönetilir. Kullanıcı filtreli bir sayfayı paylaştığında ya da geri tuşuna bastığında filtrelerin korunması doğaldır. SPA'da bu davranışı URL'e yansıtmak için ek çalışma gerekir; aksi halde her yenileme sayfayı başa sıfırlar.

İçerik hacmi büyüdükçe MPA'nın avantajları da genişler. Her yeni sayfa bağımsız bir indeksleme fırsatıdır. Binlerce ürün sayfası, yüzlerce makale, onlarca kategori sayfası — bunların her biri ayrı bir arama görünürlüğü noktasıdır. SPA bu görünürlüğü teknik olarak elde edebilir; ancak içerik ölçeği büyüdükçe yönetim karmaşıklığı da artar. MPA bu ölçeği doğal biçimde taşır; içerik büyümesi mimari maliyete doğrudan dönüşmez.

İki yapı arasındaki karar projenin büyüme senaryosunu da şekillendirir

Mimari seçim başlangıç için değil, projenin varacağı yer için yapılmalıdır. Bugün küçük bir portfolyo sitesi olan bir proje iki yıl içinde yüzlerce içerik sayfasına sahip bir platforma dönüşebilir. Bugün minimal bir SaaS arayüzü olan bir ürün zamanla karmaşık gerçek zamanlı özellikler gerektiren bir uygulamaya evrilebilir. Başlangıçtaki seçimin bu büyümeyle ne kadar uyumlu olduğu, ilerideki yeniden yapılanma maliyetini belirler.

SPA ile başlayan içerik ağırlıklı bir proje büyüdükçe genellikle SSR ya da SSG katmanı eklemek zorunda kalır. Bu geçiş küçük bir kod değişikliği değil, mimari bir yeniden yapılanmadır. MPA ile başlayan ve zamanla etkileşim yoğun özellikler kazanan bir proje ise belirli bölümleri istemci tarafı bileşenlerle zenginleştirebilir. İki yön arasında asimetri vardır: içerik siteleri MPA'dan başlamak, uygulama özellikleri eklemek çoğu durumda daha esnek bir yol sunar.

Hibrit yaklaşımlar bu ayrımı yumuşatır. Next.js, Nuxt ve benzeri framework'ler hem SSR hem CSR hem de SSG'yi bir arada sunar; bazı sayfalar statik, bazıları sunucu tarafından render edilmiş, bazıları tamamen istemci tarafında çalışır. Bu esneklik gerçek bir mimari özgürlük sağlar; ancak bu özgürlüğü kullanmak için projenin hangi sayfalarının hangi stratejiyle sunulacağı önceden planlanmalıdır. Plansız hibrit yapı, her iki modelin sorunlarını bir araya getirir.

SPA mı MPA mı sorusu en doğru yanıtını projenin gerçek ihtiyacından alır. Etkileşim yoğun bir uygulama için SPA; içerik odaklı, SEO'ya önem veren, URL bağımsızlığı gerektiren bir proje için MPA çoğu zaman daha sağlam bir başlangıç noktasıdır. İkisi arasında seçim yapamayacak kadar karma bir yapıda ise hibrit yaklaşım düşünülebilir — ama bu sefer hangi sayfanın hangi stratejiyi takip edeceği baştan belirlenmiş olmalıdır.

Teknoloji tercihi bu kararı vermez; sadece uygular. Mimari tercih öncedir; hangi framework'ün kullanılacağı sorusu bunun ardından gelir. Tersi sırayla ilerlenen projelerde seçilen framework proje gereksinimlerini biçimlendirmeye başlar — bu ise mühendislik kararlarının değil, ihtiyaçların mimariyi yönlendirmesi gerektiğinin tam tersine düşer.