Next.js ve Nuxt Uygulamaları İçin Hosting: SSR, Statik Export ve Edge Functions Karşılaştırması

Next.js ve Nuxt için doğru hosting mimarisini seçmek neden bu kadar kritik?

Next.js veya Nuxt ile bir proje planlarken, çoğu ekip ilk toplantıda tasarım, bileşen yapısı ve API sözleşmelerini konuşur; hosting mimarisi genelde sona kalır. Sonra canlıya geçişe birkaç hafta kala şu soru gelir: “SSR mi gidelim, statik export mu yapalım, yoksa Edge Functions kullanmak daha mı mantıklı?” Bu soru sadece teknik bir tercih değildir; performans, maliyet, bakım yükü ve ölçeklenebilirlik üzerinde doğrudan etkisi vardır.

Biz DCHost tarafında onlarca Next.js ve Nuxt projesinin paylaşımlı hosting, VPS, dedicated ve colocation senaryolarında nasıl davrandığını gördük. Aynı kod tabanının, farklı mimarilerde bambaşka sonuçlar ürettiğine defalarca şahit olduk. Bu yazıda konsept anlatmaktan öteye geçip, SSR, statik export ve Edge Functions mimarilerini hem teorik hem de gerçekçi hosting senaryoları üzerinden kıyaslayacağız. Amacımız; elinizdeki proje türüne göre hangi yaklaşımı seçmeniz gerektiğini, hangi durumda hangi DCHost altyapısının mantıklı olduğunu netleştirmek.

Eğer daha önce genel bir bakış okumak isterseniz, Next.js ve Nuxt uygulamaları için doğru hosting mimarisi yazımızı da inceleyebilirsiniz. Bu makalede ise o çerçeveyi derinleştirip, mimarileri birbirine karşı konumlandıracağız.

Next.js ve Nuxt’ta render modelleri: Temeli netleştirelim

Önce aynı dili konuşalım. Next.js ve Nuxt dünyasında sık duyduğumuz kavramlar aslında üç ana eksende toplanıyor:

• SSR (Server-Side Rendering): Her istekte sayfa sunucu tarafında render edilir.
• Statik Export (SSG / Static Generation): Sayfalar build anında oluşturulur, sonrasında düz HTML olarak sunulur.
• Edge Functions: Kullanıcıya en yakın edge düğümünde çalışan hafif fonksiyonlar/middleware’ler.

Bunların yanında CSR (Client-Side Rendering) ve hibrit yaklaşımlar da var, ancak hosting mimarisini esas etkileyen üç ana başlık yukarıdakiler. Kısaca farklara bakalım.

SSR’de, kullanıcı bir sayfa istediğinde Next.js veya Nuxt uygulamanız sunucuda React/Vue bileşenlerini çalıştırır, ortaya çıkan HTML’i istemciye gönderir. Yani her istek CPU, RAM ve Node.js runtime demek. Bu, hosting tarafında sürekli çalışan bir Node süreç havuzu, reverse proxy (Nginx gibi) ve ölçekleme stratejileri gerektirir.

Statik export’ta (SSG) ise sayfalar derleme esnasında üretilir ve ortaya düz HTML, CSS, JS dosyaları çıkar. Bu dosyalar basit bir web sunucusundan veya CDN’den servis edilebilir. Hosting cephesinde bu, “sadece statik dosya” mantığıyla, çok daha basit ve düşük maliyetli bir mimari anlamına gelir.

Edge Functions ise bu iki dünyanın arasına konumlanır: Ana HTML çoğunlukla statik veya SSR ile üretilirken, auth kontrolü, yönlendirme, AB testi, ülkeye göre içerik gibi küçük ama kritik işler kullanıcıya en yakın ağ noktasında çalışır. Böylece TTFB’yi ve algılanan hızı ciddi şekilde iyileştirebilirsiniz.

SSR mimarisi: Güçlü ama maliyetli bir silah

SSR nasıl çalışır, hosting tarafında sizden ne ister?

SSR, Next.js ve Nuxt’un en çok bilinen gücü. Next.js’te getServerSideProps veya App Router’daki server component’ler, Nuxt’ta server-side data fetch mekanizmaları ile her istekte:

• API’lere istek atılır,
• veri işlenir,
• React/Vue bileşenleri sunucuda render edilir,
• ortaya çıkan HTML istemciye gönderilir.

Bu iş her kullanıcı isteğinde tekrarlandığı için, hosting katmanında şu ihtiyaçlar doğar:

• Node.js’in stabil çalıştığı bir ortam (VPS, dedicated veya container tabanlı yapı),
• PM2 veya systemd gibi süreç yöneticileri,
• Ön tarafta Nginx/Apache gibi bir reverse proxy,
• Uygun CPU/RAM ve concurrency limiti planlaması,
• Load balancer veya ölçekleme senaryoları.

Bu yüzden SSR tabanlı Next.js/Nuxt projelerini paylaşımlı PHP hostingte canlı tutmak gerçekçi değildir; burada tipik olarak DCHost tarafında VPS veya dedicated sunucu senaryolarına yöneliyoruz.

SSR’in güçlü olduğu alanlar

SSR özellikle şu durumlarda parlıyor:

• Dinamik, kişiselleştirilmiş sayfalar: Kullanıcıya göre değişen dashboard’lar, profil sayfaları, abonelik bilgileri.
• Hep taze olması gereken veri: Borsa, kripto, dinamik fiyatlandırma, stok durumu, canlı skor panoları.
• SEO kritik liste sayfaları: Büyük filtreli listelemeler, sürekli değişen ürün katalogları.

Örneğin orta ölçekli bir B2B SaaS panelini düşünün. Kullanıcı giriş yaptığında onlarca API isteği, yetki kontrolü, kullanıcıya özel menüler devreye giriyor. Bunu tamamen statik export ile çözmek hem zor, hem de güvenlik açısından riskli olur. SSR ise burada hem güvenli hem de esnek bir çözüm sunar.

SSR’in dezavantajları: TTFB, maliyet ve karmaşıklık

Zayıf tarafı ise oldukça net:

• Her istek sunucu CPU’su tüketir; trafik arttıkça maliyet ve scaling ihtiyacı yükselir.
• TTFB, statik export’a göre neredeyse her zaman daha yüksektir.
• Karmaşık caching stratejileri (page cache, micro cache, API cache) gerektirir.
• Bakım, güncelleme, dağıtım pipeline’ı daha sofistike olmak zorundadır.

Özellikle Core Web Vitals hedefleriniz iddialıysa, SSR kullandığınız projelerde TTFB ve LCP metrikleri için hem uygulama hem sunucu tarafında ince ayar yapmanız gerekir. Bu noktada Core Web Vitals’ı hosting tarafında iyileştirme rehberi yazımızı mutlaka öneriyoruz; oradaki prensipler SSR projeler için doğrudan uygulanabilir.

Statik export (SSG/ISR): Basitlik, performans ve maliyet avantajı

Statik export tam olarak ne yapar?

Statik export yaklaşımında Next.js ve Nuxt, build aşamasında tüm (veya çoğu) sayfa için HTML çıktı üretir. Next.js tarafında getStaticProps ve opsiyonel olarak revalidate (ISR) kullanılır; Nuxt tarafında da benzer generate mekanizmaları vardır. Sonuçta elinizde şunlar olur:

• Önceden üretilmiş HTML dosyaları,
• bundled JS/CSS asset’leri,
• görseller ve diğer statik içerikler.

Bu çıktıları DCHost üzerinde:

• Basit bir paylaşımlı hosting hesabında,
• VPS üzerindeki Nginx/Apache ile,
• veya object storage + CDN kombinasyonuyla

son derece verimli şekilde servis edebilirsiniz. Sunucu tarafında Node.js çalıştırma zorunluluğu yoktur; sadece statik dosya dağıtımı yapılır.

Jamstack ve statik hosting’in avantajları

Bu yaklaşım Jamstack mantığının da temelini oluşturur. Statik HTML + JS’i CDN’e koyar, dinamik ihtiyaçları ise API’lere bırakırsınız. Böylece:

• Global ölçekte inanılmaz düşük TTFB değerleri yakalarsınız.
• CPU tüketimi neredeyse yoktur; ölçekleme büyük oranda bant genişliği ve cache hit oranına bağlıdır.
• İnşa ettiğiniz yapı çok daha basit, taşınabilir ve vendor bağımsızdır.

Bu konuyu daha geniş perspektiften görmek için Headless CMS ve Jamstack siteler için hosting rehberi yazımız size iyi bir çerçeve sunacaktır.

ISR: Statik ile dinamiğin ortası

Next.js’in Incremental Static Regeneration (ISR) özelliği, statik export’un en büyük sıkıntısı olan “build süresi ve veri tazeliği” problemini bir ölçüde çözüyor. Özetle:

• İlk istek geldiğinde sayfa gerekirse arka planda yeniden üretiliyor.
• Belirlediğiniz revalidate süresi dolunca, bir sonraki istekte güncel HTML cache’e yazılıyor.

Bu modelde hosting tarafında hala statik ağırlıklı bir yapı kullanabilir, fonksiyonel kısımları için az sayıda Node süreci veya serverless fonksiyonla destek verebilirsiniz. Yani tam SSR’e geçmeden pek çok dinamik ihtiyacı karşılamak mümkün.

Statik export’un parladığı senaryolar

Pratikte statik export şu durumlarda çok güçlü:

• Blog, dokümantasyon, içerik siteleri: İçerik güncellemesi saatlik/günlük ritimdeyse, build süresi makulse statik inanılmaz mantıklı.
• Landing page’ler, kampanya sayfaları: Trafiği yüksek ama kişiselleştirme ihtiyacı düşük sayfalar.
• Katalog ağırlıklı e-ticaret: Ürün detayı büyük oranda sabitse, sepet/ödeme gibi dinamik kısımları ayrı bir API katmanına taşıyabilirsiniz.

Örneğin headless WordPress + Next.js kombinasyonunda, WordPress sadece API ve yönetim paneli; Next.js ise statik front-end olarak çalışabilir. Bunun için Headless WordPress + Next.js hosting mimarisi yazımızdaki örnek mimariyi inceleyebilirsiniz.

Edge Functions: Kullanıcıya en yakın noktada mantık çalıştırmak

Edge Functions neyi çözer?

Edge Functions, klasik anlamda bir “tam sunucu” değil; ağın uç noktalarında çalışan hafif fonksiyonlardır. Genelde:

• HTTP isteği geldiğinde tetiklenen küçük kod parçaları,
• auth token kontrolü,
• ülkeye/dile göre yönlendirme,
• AB testi, deney varyantı seçimi,
• header manipülasyonu, cache kontrolü

gibi işleri yapar. Next.js tarafında middleware ve edge runtime, Nuxt tarafında Nitro + edge entegrasyonları bu mantığın parçasıdır.

Hosting mimarisi açısından edge fonksiyonları, genelde şu şekilde kullanıyoruz:

• Origin: DCHost üzerinde SSR veya statik hosting yaptığınız asıl sunucu.
• CDN/Edge katmanı: Kullanıcıya en yakın noktadan hem statik dosyaları, hem de edge fonksiyonlarını koşturan ağ.

Böylece ağır işlemler hala origin’de (VPS/dedicated/colocation), hafif ve kullanıcıya yakın olması kritik işlemler ise edge’de gerçekleşiyor.

Edge mimarisinin artıları ve eksileri

Artıları:

• Global kullanıcı kitlesinde TTFB’yi dramatik şekilde düşürebilir.
• Auth, AB testi, yönlendirme gibi sık kullanılan operasyonlar için uygulama kodunu sadeleştirir.
• Origin sunucunun üzerindeki yükü azaltır; bazı kararlar yolda verilir.

Eksileri:

• Runtime kısıtlıdır (dosya sistemi erişimi, belirli Node API’leri vb.).
• Debug ve observability, klasik sunucuya göre daha zor olabilir.
• Yanlış kurgulanırsa, uygulamayı gereksiz yere birçok katmana bölebilir (fazla karmaşıklık).

Bu yüzden biz DCHost’ta edge fonksiyonlarını genelde tamamlayıcı bir katman olarak konumlandırıyoruz; tek başına tüm uygulamayı edge’e taşımak çoğu ekip için gereksiz karmaşıklık yaratabiliyor.

SSR, statik export ve Edge Functions: Karşılaştırmayı netleştirelim

Performans perspektifi

Performans deyince üç metrik çok belirgin:

• TTFB (Time To First Byte)
• LCP (Largest Contentful Paint)
• Stabilite (CLS, layout kaymaları)

Genel tablo şöyle:

• Statik export: Doğru CDN ile neredeyse her zaman en düşük TTFB ve LCP değerlerini verir.
• SSR: İyi optimize edilmişse kabul edilebilir, ancak CPU-bound olduğu için yük arttıkça TTFB dalgalanmaları yaşanabilir.
• Edge + statik: Statik HTML + edge mantığı ile hem TTFB’yi düşük tutup hem de kişiselleştirme katmanı ekleyebilirsiniz.

Burada kritik nokta şu: “Her şeyi SSR yapalım” dediğiniz anda, en zayıf halka her zaman sunucu CPU’su olur. Statik export ile çözülebilecek sayfaları statik tutup, gerçekten dinamik olması gereken kısımları SSR veya edge ile çözmek, uzun vadede daha sürdürülebilir bir stratejidir.

Maliyet ve ölçeklenebilirlik

Hosting faturası ve ölçekleme açısından baktığımızda ise:

• Statik export: En ucuz ve en kolay ölçeklenen yaklaşım. Paylaşımlı hosting veya küçük bir VPS + CDN ile çok yüksek trafiği karşılayabilirsiniz.
• SSR: Trafik arttıkça daha güçlü VPS’lere, hatta dedicated sunuculara çıkma ihtimaliniz artar. Aynı anda çalışan istek sayısı arttıkça Node süreçlerinin sayısı da artar.
• Edge Functions: Doğrudan CPU kullanımını değil ama origin’e giden istek sayısını azaltarak dolaylı bir maliyet avantajı yaratabilir.

DCHost tarafında pratikte gördüğümüz şu: Statik ağırlıklı sitelerde bant genişliği faturası artarken CPU çok sakin kalıyor; SSR ağırlıklı projelerde ise bant genişliği görece makul, ama CPU/RAM ve ölçekleme ihtiyacı daha erken karşınıza çıkıyor.

Geliştirme deneyimi ve karmaşıklık

Geliştirici deneyimi konusunda da net bir fark var:

• Statik export: Build pipeline’ı bir kez oturunca çoğu şey “git push → build → deploy” döngüsünde akıyor. Yerel geliştirme ile prod arasındaki fark nispeten küçük.
• SSR: Ortam değişkenleri, uzun süreli Node süreçleri, PM2/systemd ayarları, log rotasyonu gibi operasyonel detaylar işin içine giriyor.
• Edge: Dağıtık bir sistem geliştiriyorsunuz; hem origin, hem edge, hem de tarayıcı tarafını doğru gözlemlemek gerekiyor.

Bu noktada özellikle VPS senaryosuna geçiyorsanız, Node.js uygulamalarını nerede host etmeniz gerektiği ve GitHub Actions ile VPS’e otomatik deploy rehberlerimiz işinizi ciddi anlamda kolaylaştırabilir.

Farklı proje tipleri için mimari önerileri

1. İçerik ağırlıklı blog, dokümantasyon, kurumsal site

Bu tür projelerde genelde:

• İçerikler saatlik/günlük ritimde güncellenir.
• Gerçek zamanlı kişiselleştirme ihtiyacı düşüktür.
• SEO ve hızlı ilk yükleme çok kritiktir.

Burada ideal yaklaşım çoğu zaman statik export + CDN. Next.js veya Nuxt tarafında tüm sayfaları build anında üretip, DCHost üzerinde paylaşımlı hosting veya basit bir VPS ile yayına alabilirsiniz. Global ziyaretçiniz varsa CDN ekleyerek TTFB’yi iyice aşağı çekmek mantıklı.

Eğer headless CMS kullanıyorsanız, CMS’i ayrı bir VPS’te, front-end’i ise tamamen statik olarak konumlandırmak uzun vadede çok rahat ettirir.

2. Orta ölçekli e-ticaret sitesi

E-ticaret dünyasında durum daha karmaşık:

• Ürün detay sayfaları büyük oranda statik görünebilir.
• Fiyat, stok, kampanya koşulları sık değişir.
• Sepet, ödeme, kullanıcı hesabı tamamen dinamik ve güvenlik kritiktir.

Burada tipik strateji:

• Ürün liste ve detayı için SSG + ISR,
• sepet, ödeme, profil için SSR veya API + CSR,
• ülkeye göre fiyat, para birimi gibi işler için Edge Functions.

Hosting tarafında da genelde DCHost üzerinde NVMe diskli bir VPS ile başlamak, trafik arttıkça veritabanı ve önbelleği ayrı sunuculara bölmek, daha sonra da gerekirse dedicated veya colocation’a geçmek şeklinde bir yol haritası kurguluyoruz.

3. SaaS panelleri ve dashboard uygulamaları

SaaS panellerde öncelik çoğu zaman SEO değil, giriş yapmış kullanıcı deneyimidir. Dolayısıyla:

• Marketing ve “public” sayfalar: Statik export + hafif edge mantığı (ülkeye göre yönlendirme vb.).
• Uygulama içi dashboard: SSR veya güçlü bir API + client-side rendering.

Bu yapıyı tasarlarken, multi-tenant (çok kiracılı) bir veritabanı yapınız varsa, küçük SaaS ve API projeleri için multi-tenant veritabanı ve hosting rehberimiz size mimari açıdan önemli ipuçları verecektir.

4. Gerçek zamanlı uygulamalar (chat, canlı skor, streaming)

Bu kategoride ise Next.js/Nuxt çoğu zaman shell görevi görür; asıl gerçek zamanlı iletişim WebSocket veya benzeri protokollerle ayrı bir Node.js servisinde yürür. Burada tipik yaklaşım:

• UI ve SEO için SSR veya SSG,
• gerçek zamanlı veri için ayrı bir Node.js servis (VPS veya dedicated),
• isteğe bağlı olarak edge katmanında rate limiting, auth ön-kontrolü.

Böylece front-end tarafını nispeten sade tutup, gerçek zamanlı yükü arka planda ölçeklenebilir bir servise dağıtabilirsiniz.

DCHost üzerinde pratik dağıtım senaryoları

Senaryo 1: Tam statik Next.js/Nuxt site (SSG)

En basit ve en sık kullandığımız senaryolardan biri:

1. Local’de veya CI/CD pipeline’ınızda next export / nuxt generate ile statik çıktıyı üretirsiniz.
2. Ortaya çıkan out veya dist klasörünü DCHost paylaşımlı hosting hesabınıza veya VPS’inizdeki Nginx root klasörüne kopyalarsınız.
3. Üzerine bir CDN ekleyerek global cache katmanı inşa edersiniz.

Bakım maliyeti düşüktür, taşıması kolaydır, vendor bağımlılığı azdır. Özellikle yeni başlayan projeler için bu senaryoyu öneriyoruz.

Senaryo 2: SSR ağırlıklı Next.js/Nuxt, VPS üzerinde

Biraz daha olgun projelerde ise genelde şu yolu izliyoruz:

1. DCHost üzerinde NVMe SSD’li bir Linux VPS açarsınız.
2. Node.js, PM2 ve Nginx kurulur; example.com alan adınız Nginx üzerinden Next/Nuxt sürecine proxy edilir.
3. CI/CD tarafında, örneğin GitHub Actions ile VPS’e otomatik deploy hattı kurarsınız.
4. Loglama, izleme ve yedekleme politikalarınızı tanımlarsınız.

Böyle bir mimari, hem SSR’in esnekliğini hem de VPS’in size sunduğu tam kontrolü birleştirir. Trafiğiniz arttıkça daha güçlü VPS’e geçmek veya veritabanını ayrı bir sunucuya taşımak da oldukça rahattır.

Senaryo 3: Hibrit mimari – statik front-end + API + edge

Daha büyük projelerde sıklıkla gördüğümüz hibrit yapı şöyle:

• Next.js/Nuxt front-end: Statik export + ISR ile DCHost üzerinde statik hosting.
• API katmanı: Ayrı bir VPS veya dedicated sunucu üzerinde Node.js / PHP / Go mikroservisler.
• Veritabanı: Ayrı bir VPS veya dedicated; yüksek IOPS ihtiyacı varsa NVMe disk ve replikasyon.
• Edge katmanı: Auth, yönlendirme, AB testi gibi hafif mantık.

Bu modeli doğru kurguladığınızda, statik sayfa trafiğini neredeyse sınırsız ölçekleyebilir, ağır iş yükünü ise kontrollü bir şekilde API ve veritabanı katmanına taşıyabilirsiniz. Özellikle headless mimarilerde bu yapı son derece esnek ve geleceğe dönük oluyor.

Karar vermek için pratik bir kontrol listesi

Elinizdeki proje için hangi mimarinin doğru olduğuna karar verirken şu soruları kendinize sorabilirsiniz:

• Sayfalarımın yüzde kaçı gerçek anlamda her istekte dinamik olmak zorunda?
• Build sürem ne kadar? Tüm siteyi kaç dakikada statik üretebiliyorum?
• Global kullanıcı kitlesi var mı? Varsa hangi bölgeler kritik?
• Geliştirici ekibin DevOps deneyimi ne düzeyde? SSR + VPS bakımı kaldırabilir miyiz?
• Önümüzdeki 12 ayda trafiğin nasıl büyüyeceğini tahmin ediyoruz?

Eğer bu sorulara net cevap veremiyorsanız, önce statik ağırlıklı, basit bir mimariyle başlamak, sonra ihtiyaca göre SSR ve Edge katmanı eklemek çoğu zaman daha sağlıklı bir yol. Zaten DCHost tarafında da müşterilerimizin önemli bir kısmı tam olarak bu yoldan geçiyor.

Özet ve DCHost ile sonraki adımlar

Next.js ve Nuxt ekosisteminde SSR, statik export ve Edge Functions arasında seçim yapmak; sadece teknik bir tercih değil, aynı zamanda uzun vadeli altyapı maliyeti, bakım yükü ve ölçeklenebilirlik stratejisi anlamına geliyor. Statik export size inanılmaz bir basitlik ve performans sunarken, SSR dinamik ve kişiselleştirilmiş deneyimler için vazgeçilmez hale gelebiliyor. Edge Functions ise bu iki dünyanın arasında, özellikle global projelerde ciddi bir hız ve esneklik katmanı sağlıyor.

Biz DCHost olarak, bu üç mimariyi de destekleyebileceğiniz esnek bir altyapı sunuyoruz: paylaşımlı hosting, NVMe VPS, dedicated ve colocation seçenekleriyle, projeniz hangi aşamadaysa ona uygun bir basamak mutlaka var. İsterseniz önce basit bir statik Next.js/Nuxt sitesiyle başlayıp, trafik ve ihtiyaçlar büyüdükçe SSR ve edge katmanları ekleyerek mimarinizi adım adım olgunlaştırabilirsiniz.

Eğer projeniz için hangi yolu seçmeniz gerektiğinden emin değilseniz, kısa bir mimari değerlendirme yaparak size en uygun yaklaşımı birlikte netleştirebiliriz. Mevcut sitenizi, trafik verilerinizi ve büyüme planlarınızı analiz ederek; hangi sayfaların statik, hangilerinin SSR, hangilerinin edge katmanına taşınmasının mantıklı olduğunu somut örneklerle ortaya koyuyoruz. Bir sonraki Next.js veya Nuxt projenizde, hosting kararını sona bırakmak yerine, en baştan DCHost ekibiyle birlikte planlamak isterseniz, her zaman buradayız.