SPA ve SSR Performans Karşılaştırması

"SPA mı yapalım SSR mı" tartışması genellikle yanlış zeminde yürür: taraflar kendi favori çerçevesini savunur, karar da teknik tercihle biter. Oysa bu ikisi arasındaki fark bir zevk meselesi değil, maliyetin nereye kaydırıldığı meselesidir. SPA, işi kullanıcının cihazına yükler; SSR ise sunucunuza. Hangisinin daha hızlı olduğu, sitenizin ne yaptığına ve kullanıcılarınızın hangi cihazlarda olduğuna bağlıdır.

Bu yazıda SPA ve SSR performans karşılaştırmasını somut metrikler üzerinden yapacağım: ilk yükleme, sonraki gezinmeler, sunucu maliyeti, SEO ve sosyal paylaşım. Ardından ikisinin arasındaki hibrit yaklaşımlara ve hangi proje türünde hangisinin doğru seçim olduğuna geleceğim. Amacım bir kazanan ilan etmek değil; kendi projenizde hangi tarafın maliyetini ödemeye razı olduğunuza bilinçli karar verebilmeniz.

İki Mimari Aslında Ne Yapıyor#

SPA (Single Page Application) yaklaşımında sunucu neredeyse boş bir HTML iskeleti gönderir; içinde genellikle tek bir kök öğe ve bir JavaScript paketine bağlantı vardır. Tarayıcı bu paketi indirir, ayrıştırır, çalıştırır, gerekli veriyi API'den çeker ve sayfayı kendi çizer. Sonraki gezinmelerde tam sayfa yeniden yüklemesi yoktur; yalnızca gereken veri çekilir ve arayüzün ilgili kısmı güncellenir.

SSR (Server-Side Rendering) yaklaşımında ise sunucu, HTML'i içeriğiyle birlikte üretip gönderir. Tarayıcı ilk yanıtta zaten okunabilir bir sayfa alır. Modern SSR kurulumlarında bunun ardından "hidrasyon" adı verilen bir adım gelir: aynı JavaScript tarayıcıda da çalışır ve statik HTML'e olay dinleyicilerini bağlayarak sayfayı etkileşimli hale getirir.

Aradaki farkı en net gösteren şey, ilk HTTP yanıtının içeriğidir. Kendi sitenizde şu komutla test edebilirsiniz:

# Sunucudan gelen HAM HTML'i getir (JavaScript çalıştırmaz)
curl -s https://firmaniz.com/ | head -40

# İçerikte gerçek metin var mı, yoksa boş bir kök öğe mi?
curl -s https://firmaniz.com/ | grep -o 'id="root"[^>]*' 
curl -s https://firmaniz.com/ | wc -c

Dönen HTML birkaç kilobayt ve içinde hiç metin yoksa SPA'sınız; onlarca kilobayt ve içinde başlıklar, paragraflar varsa SSR ya da statik üretim kullanıyorsunuz demektir. Bu tek komut, mimarinizi anlamanın en hızlı yoludur.

İlk Yükleme: Metrik Metrik Karşılaştırma#

İlk yükleme, SSR'ın açık ara kazandığı alandır ve sebebi basittir: SPA'da kullanıcının içerik görebilmesi için bir zincirin tamamının tamamlanması gerekir.

SPA'da zincir şudur: HTML gelir → JavaScript indirilir → ayrıştırılır ve çalıştırılır → API isteği atılır → veri gelir → arayüz çizilir. Beş adımın hepsi seri çalışır ve her biri gecikme ekler. SSR'da ise zincir çok kısadır: HTML içeriğiyle birlikte gelir → tarayıcı çizer.

Dikkat edilmesi gereken bir incelik var: SPA'nın TTFB'si genellikle daha iyidir, çünkü sunucu sadece statik bir dosya gönderir. Bu, panellerde yanıltıcı bir "hızlı" izlenimi yaratır. Ama kullanıcının umursadığı şey TTFB değil, içeriği ne zaman gördüğüdür; yani LCP. SPA'da düşük TTFB ile yüksek LCP bir arada görmek çok yaygındır ve bu kombinasyon "sunucum hızlı ama sitem yavaş" tablosunun ta kendisidir.

Farkın büyüklüğü cihaza göre değişir. Güçlü bir masaüstünde SPA'nın JavaScript'i ayrıştırması 200 ms sürerken, orta segment bir telefonda aynı iş bir saniyeyi aşabilir. Yani SPA'nın ilk yükleme dezavantajı mobilde kat kat büyür. Kullanıcılarınızın çoğunluğu mobildeyse bu tek başına belirleyici olabilir; konunun mobil tarafı için mobil hız optimizasyonu yazısına bakabilirsiniz.

Sonraki Gezinmeler: SPA'nın Asıl Kazancı#

Karşılaştırmayı yalnızca ilk yüklemeyle bitirirseniz SPA'ya haksızlık etmiş olursunuz. Kullanıcı siteye girdikten sonra ikinci, üçüncü, onuncu sayfaya geçtiğinde tablo tersine döner.

Klasik SSR'da her gezinme yeni bir HTTP isteği, yeni bir HTML indirmesi ve tam sayfa yeniden çizimi demektir. Sunucu her seferinde şablonu yeniden üretir. SPA'da ise uygulama zaten belleğe yüklenmiştir; yalnızca yeni verinin JSON'u çekilir ve arayüzün değişen kısmı güncellenir. Aradaki fark tipik olarak şöyledir:

Bu yüzden SPA, kullanıcının uzun süre kaldığı ve çok sayıda ekran arasında gezindiği arayüzlerde — yönetim panelleri, e-posta istemcileri, tasarım araçları, müşteri panelleri — doğru tercihtir. Bir kullanıcı oturumunda otuz ekran değiştiriyorsa, ilk yüklemedeki bir saniyelik gecikme otuz hızlı geçişle fazlasıyla telafi edilir.

Tersine, kullanıcı arama sonucundan gelip tek bir yazıyı okuyup çıkıyorsa SPA'nın gezinme avantajı hiç devreye girmez; yalnızca ilk yükleme cezasını ödemiş olursunuz. Blog, haber, kurumsal tanıtım ve içerik siteleri tam olarak bu profildedir.

Sunucu Maliyeti ve Ölçeklenme#

Performans tartışmasının çoğu zaman atlanan yarısı sunucu tarafıdır. SSR, her istekte sunucuda gerçek iş yapar: veri çeker, bileşen ağacını çalıştırır, HTML üretir. Bu iş CPU tüketir ve doğrudan kapasitenizi belirler.

SPA'da HTML ve JavaScript birer statik dosyadır; bunları bir CDN'e koyduğunuzda sunucunuz trafiğin neredeyse tamamından kurtulur ve geriye yalnızca API yükü kalır. SSR'da ise her sayfa görüntülemesi uygulama sunucunuza dokunur. Bu maliyeti kontrol altına almanın yolu önbellektir: üretilen HTML'i Nginx düzeyinde saklarsanız SSR'ın CPU maliyetini büyük ölçüde ortadan kaldırırsınız.

# SSR çıktısını Nginx'te önbelleğe al (giriş yapmamış kullanıcılar için)
proxy_cache_path /var/cache/nginx/ssr levels=1:2 keys_zone=ssr:10m max_size=1g inactive=60m;

server {
    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_cache ssr;
        proxy_cache_valid 200 10m;
        # Oturum çerezi olanlar önbelleği atlasın
        proxy_cache_bypass $cookie_oturum;
        proxy_no_cache    $cookie_oturum;
        add_header X-SSR-Cache $upstream_cache_status;
    }
}

X-SSR-Cache başlığı sayesinde her isteğin önbellekten mi geldiğini doğrudan görürsünüz:

curl -sI https://firmaniz.com/ | grep -i x-ssr-cache
# X-SSR-Cache: HIT

Bu yapının detayları ve kapasite hesabı için eşzamanlı kullanıcı kapasitesi hesaplama ve Nginx FastCGI cache yapılandırma yazılarındaki yöntemler doğrudan uygulanabilir.

SEO ve Sosyal Paylaşım Farkı#

Arama motorları bugün JavaScript çalıştırabiliyor, dolayısıyla "SPA indekslenmez" cümlesi artık doğru değil. Ama "SPA sorunsuz indekslenir" cümlesi de doğru değil. Fark, tarama bütçesinde ve gecikmede.

Bir SSR sayfasında tarayıcı botu HTML'i alır almaz içeriği görür. SPA'da ise botun sayfayı işleyip JavaScript'i çalıştırması gerekir; bu işlem genellikle ikinci bir aşamada ve gecikmeyle yapılır. Sonuç: içeriğiniz indekslenir ama daha geç indekslenir, sık güncellenen içeriklerde bu gecikme trafik kaybına dönüşebilir.

Sosyal paylaşımda ise durum daha nettir ve burada gri alan yoktur: WhatsApp, X, LinkedIn gibi platformların önizleme botları JavaScript çalıştırmaz. Bir SPA'nın paylaşım kartı, HTML'de statik olarak bulunan varsayılan başlık ve görselden ibaret kalır; hangi sayfayı paylaşırsanız paylaşın aynı kart çıkar. Bunu test etmek kolaydır:

# Bir iç sayfanın ham HTML'inde og etiketleri sayfaya özel mi?
curl -s https://firmaniz.com/urun/ornek-urun | grep -o 'property="og:[^"]*" content="[^"]*"'

Çıktı sayfaya özgü başlık ve görsel yerine genel site bilgilerini gösteriyorsa sorun tam olarak budur. Çözüm ya SSR'a geçmek ya da sayfaları önceden üretmektir; ikinci yolu prerender nedir, SEO'ya etkisi yazısında adım adım anlattım.

Hibrit Yaklaşımlar: İkisi Arasında Seçim Yapmak Zorunda Değilsiniz#

Modern web'in verdiği en pratik cevap, bu ikiliyi tümüyle reddetmektir. Bugün yaygın kullanılan ara çözümler şunlardır:

Statik üretim (SSG). Sayfalar derleme zamanında üretilir ve statik HTML olarak servis edilir. SSR'ın ilk yükleme avantajını, SPA'nın sunucu maliyetsizliğiyle birleştirir. İçeriği sık değişmeyen siteler için genellikle en iyi seçenektir; ayrıntısı statik site üreticilerinin hız avantajı yazısında.

SSR + istemci tarafı gezinme. İlk sayfa sunucudan HTML olarak gelir, sonrasında uygulama devralır ve gezinmeler SPA gibi çalışır. Her iki dünyanın avantajını alır; bedeli, aynı kodun hem sunucuda hem tarayıcıda çalışabilir olmasıdır.

Ada mimarisi (islands). Sayfanın çoğu statik HTML olarak kalır, yalnızca gerçekten etkileşim gereken bileşenler (arama kutusu, sepet düğmesi, form) ayrı ayrı hidrate edilir. Gönderilen JavaScript miktarını çarpıcı biçimde düşürür.

Akışlı (streaming) render. Sunucu HTML'i tek parça beklemek yerine hazır olan kısımları göndermeye başlar; kullanıcı yavaş veri kaynağını beklerken sayfanın üst kısmını çoktan görür.

Bu seçenekleri şöyle sıralayabilirsiniz:

Sık Yapılan Hatalar#

Mimariyi kullanıcı profilini bilmeden seçmek. Trafiğinizin %70'i arama sonucundan gelen tek sayfalık ziyaretse SPA'nın gezinme avantajı hiç kullanılmaz. Analytics'te ortalama oturum başına sayfa sayısına bakın: bu sayı 1'e yakınsa SSR ya da statik, 5'in üstündeyse SPA lehine bir sinyaldir.

SSR'ı önbelleksiz çalıştırmak. SSR'ın CPU maliyeti önbellek olmadan doğrudan sunucu faturanıza yansır ve trafik zirvesinde sitenizi düşürür. Giriş yapmamış kullanıcılar için üretilen HTML'i mutlaka önbelleğe alın.

Hidrasyonu bedava sanmak. SSR yaptınız diye JavaScript maliyetinden kurtulmazsınız; aynı paket yine indirilir ve çalıştırılır. SSR, LCP'yi iyileştirir ama TBT ve INP'yi kendiliğinden iyileştirmez. İkisini birden düzeltmek için gönderilen JavaScript miktarını azaltmanız gerekir; sınırları performans bütçesi belirleme yazısındaki yöntemle koruyun.

Çift veri çekme. SSR sırasında sunucuda çekilen verinin, hidrasyondan sonra tarayıcıda tekrar çekilmesi çok yaygın bir hatadır. Kullanıcı aynı veriyi iki kez indirir ve sayfa bir kez "titrer". Sunucudan gelen veriyi HTML içine gömüp istemcide yeniden kullanın.

Ölçmeden mimari değiştirmek. "SPA yavaş, SSR'a geçelim" kararı bazen doğru olur ama çoğu zaman asıl sorun mimari değil, gönderilen 900 KB JavaScript'tir. Aynı paketi SSR'a taşırsanız LCP biraz düzelir, etkileşim gecikmesi aynı kalır. Önce ölçün, darboğazın gerçekten render stratejisi olduğundan emin olun.

Sıkça Sorulan Sorular#

SPA mı SSR mı daha hızlı#

Tek bir cevabı yok çünkü ikisi farklı anları hızlandırır. SSR ilk yüklemede belirgin biçimde hızlıdır: kullanıcı içeriği JavaScript'i beklemeden görür. SPA ise ilk yükleme tamamlandıktan sonraki gezinmelerde çok daha hızlıdır çünkü yalnızca veri çeker. Kullanıcılarınız tek sayfa görüp çıkıyorsa SSR, uzun oturumlarda çok ekran geziyorsa SPA daha hızlı hissettirir.

SPA sitem Google'da indekslenir mi#

Genellikle evet, ancak gecikmeli. Arama motorları JavaScript çalıştırabiliyor fakat bu işlem ikinci bir aşamada, sıraya girerek yapılıyor; yani içeriğiniz saatler ya da günler sonra indekslenebiliyor. Sık güncellenen içerikte bu gecikme sorun yaratır. Ayrıca sosyal medya önizleme botları JavaScript çalıştırmadığı için paylaşım kartlarınız boş kalır. İkisini birden çözmenin yolu ya SSR ya da sayfaları önceden üretmektir.

SSR sunucu maliyetimi ne kadar artırır#

Önbelleksiz bir SSR kurulumunda her sayfa görüntülemesi sunucuda gerçek CPU tüketir; kabaca dinamik bir PHP sayfası üretmeye benzer bir maliyettir. Ancak giriş yapmamış kullanıcılar için üretilen HTML'i Nginx düzeyinde önbelleğe alırsanız bu maliyetin büyük kısmı ortadan kalkar ve sunucunuz statik dosya servis eder gibi çalışır. Pratikte iyi bir önbellek isabet oranıyla SSR'ın maliyeti yönetilebilir seviyeye iner.

Mevcut SPA'mı SSR'a çevirmeli miyim#

Önce sorunu doğrulayın. Search Console'da indeksleme gecikmesi görüyorsanız, paylaşım kartlarınız boşsa ve mobil LCP değeriniz 2.5 saniyenin üstündeyse geçiş için iyi gerekçeleriniz var demektir. Ama tam SSR'a geçmek büyük bir iştir; ara adım olarak yalnızca herkese açık ve içerik ağırlıklı sayfaları önceden üretmeyi (prerender ya da statik üretim) deneyin. Çoğu vakada bu, tam SSR'ın faydasının büyük kısmını çok daha az riskle verir.

Hidrasyon nedir ve neden yavaş olabilir#

Hidrasyon, sunucudan gelen hazır HTML'in tarayıcıda çalışan JavaScript tarafından "canlandırılması"dır: aynı bileşen ağacı yeniden kurulur ve olay dinleyicileri mevcut HTML'e bağlanır. Sorun şudur ki bu işlem tüm paketi indirip çalıştırmayı gerektirir, dolayısıyla sayfa görünür olduğu halde bir süre tıklamalara cevap vermez. Kullanıcı için en can sıkıcı durum budur; çözüm gönderilen JavaScript'i azaltmak ya da yalnızca etkileşim gereken parçaları hidrate eden ada mimarisine geçmektir.

Küçük bir kurumsal site için hangisini seçmeliyim#

Kurumsal tanıtım siteleri, bloglar ve dokümantasyon siteleri için ne SPA ne de tam SSR gerekir; en iyi sonuç statik üretimle alınır. Sayfalar derleme sırasında bir kez üretilir, sunucu yalnızca hazır HTML dosyası gönderir. Böylece ilk yükleme çok hızlı olur, SEO ve paylaşım kartları sorunsuz çalışır, sunucu maliyeti neredeyse sıfıra iner ve güvenlik yüzeyi daralır. Etkileşim gereken az sayıda yer varsa oraya küçük JavaScript parçaları ekleyebilirsiniz.

Kapanış#

SPA ve SSR arasındaki seçim, hız tercihi değil maliyet yeri tercihidir: SPA işi kullanıcının telefonuna, SSR sunucunuza yükler. Aklınızda kalması gereken dört madde: ilk yüklemede SSR, sonraki gezinmelerde SPA kazanır; SPA'nın düşük TTFB'si sizi yanıltmasın, kullanıcı LCP'yi hisseder; SSR'ı önbelleksiz çalıştırmayın; ve çoğu içerik sitesi için doğru cevap ikisi de değil, statik üretimdir. Kararı vermeden önce ortalama oturum başına sayfa sayınıza ve mobil kullanıcı oranınıza bakın.

Hangi mimariyi seçerseniz seçin, ilk bayt süresi ve önbellek katmanı sunucu tarafında belirlenir. Node tabanlı bir SSR uygulamasını kendi ölçünüzde çalıştırmak için tam root erişimli VDS ve bulut sunucu paketlerimiz uygundur; statik ya da PHP tabanlı bir kurulum için web hosting paketleri yeterlidir. Uygulama sunucusu, ters vekil ve önbellek yapılandırmasını sizin yerinize kurmamızı isterseniz sunucu yönetimi hizmetimiz devrededir.