Next.js veya Nuxt için hosting seçimi, hangi sayfanın ne zaman üretildiği ve hangi işlemlerin sunucuda kalması gerektiğiyle başlar. Bir ürün sayfası önceden üretilebilirken aynı uygulamanın hesap ekranı kullanıcıya özel veriye ihtiyaç duyabilir. Bu farkı belirlemeden yalnız günlük ziyaretçi sayısına bakarak VPS boyutlandırmak, önbelleğin ve veri tabanının etkisini gözden kaçırır.
Bu rehber render kararını hosting topolojisine çevirir: statik dosya sunumu, tek uygulama sunucusu, ayrı veri tabanı ve birden fazla uygulama kopyası arasındaki geçişi ele alır. Sürüme bağlı export komutları ve dosya kontrolleri için Next.js 16 ve Nuxt 4 statik export doğrulama rehberini kullanabilirsiniz. Buradaki senaryolar kapasite garantisi veya yapılmış müşteri testi değildir.
Önce sayfa ve veri akışını sınıflandırın
SSR, SSG ve CSR içeriğin nerede ve ne zaman üretildiğini anlatır. Edge ise kodun dağıtıldığı ortamla ilgilidir; SSR ile aynı uygulamada kullanılabilir. Serverless da otomatik olarak kullanıcıya yakın çalıştırma anlamına gelmez. Bir fonksiyon tek bölgede çalışabilir, bir CDN ise uygulama kodu çalıştırmadan statik dosya sunabilir.
| Karar | İçeriğin üretimi | Hosting karşılığı |
|---|---|---|
| Statik export | Build sırasında HTML ve istemci dosyaları | Statik origin; dinamik API varsa ayrıca barındırılır |
| İstek anında SSR | Önbellekten karşılanmayan istekte sunucu HTML üretir | Uyumlu sunucu veya dağıtım adaptörü |
| CSR | Arayüzün ilgili kısmı tarayıcıda oluşur | Statik arayüz ve gerektiğinde kimlik doğrulayan API |
| Çalışma zamanında yeniden üretim | Önbellekteki sayfa belirli koşullarla yenilenir | Yenilemeyi çalıştıran runtime ve tutarlı önbellek |
| Edge çalıştırma | Seçilen işlev desteklenen ağ konumunda çalışır | Sağlayıcıya ve adaptöre uygun dağıtım; veri erişimi ayrıca planlanır |
Her rota için dört bilgi kaydedin: herkese açık mı, oturum gerektiriyor mu, kabul edilen içerik yaşı ne ve hangi API/veri tabanına erişiyor? Ardından ilk HTML isteğiyle tarayıcıdaki sonraki API çağrılarını ayırın. Statik bir dashboard kabuğu, kullanıcı verisini yetkili bir API’den alabilir; dinamik veri bulunması tek başına SSR zorunluluğu yaratmaz.
Arama görünürlüğü gereken herkese açık sayfalarda, ilk HTML’in asıl içeriği taşıyıp taşımadığını da kontrol edin. Önceden oluşturulmuş HTML ile yalnız istemcide doldurulan boş bir uygulama kabuğunu aynı çıktı saymayın. Örneğin Nuxt’ta yalnız istemci render’ı seçildiğinde arayüz içeriği JavaScript ile oluşur; bu seçim önceden render etmenin SEO avantajlarını azaltabilir. SSR veya statik üretim seçimi tek başına sıralama garantisi değildir.
Next.js’te getServerSideProps, getStaticProps ve getStaticPaths Pages Router API’leridir. App Router’daki Server Component ise otomatik olarak her istekte SSR demek değildir: uygun bileşenler statik export sırasında build’de çalışabilir. Nuxt’un universal rendering yaklaşımı da önceden oluşturulmuş veya önbelleklenmiş HTML sunabilir. Framework adı üzerinden bütün isteklerin aynı CPU maliyetine sahip olduğunu varsaymayın.
Statik dosya, SSR ve ISR aynı dağıtım değildir
Statik origin neyi üstlenir?
Tam statik export, uygulamanın ilgili arayüzünü HTML, CSS, JavaScript ve diğer dosyalar olarak yayımlar. Paylaşımlı hosting, Nginx/Apache çalışan bir VPS veya uygun object storage origin bu dosyaları sunabilir. Ancak hostun doğru URL–dosya eşlemesini, HTTPS’i, hata durumlarını ve gereken başlıkları desteklemesi gerekir; yalnız klasörü yüklemek bütün dağıtım kontrollerinin tamamlandığı anlamına gelmez.
Statik arayüzden çağrılan arama, form, ödeme veya oturum API’si ayrı bir hizmettir. O hizmetin maliyeti ve kullanılabilirliği devam eder. Build sırasında CMS’ten çekilen içerik ise yeniden build ve dağıtım yapılana kadar eski kalabilir. Statik sitenin işletim sınırları için Jamstack ve statik hosting rehberine, origin seçimi için object storage ve CDN rehberine bakabilirsiniz.
SSR için gereken runtime
Node tabanlı bir dağıtımda reverse proxy isteği uygulama sürecine iletir; uygulama gerekli veriyi alır, HTML’i veya akışı döndürür. Bunun yanında statik dosyalar ve uygun şekilde önbelleklenmiş yanıtlar doğrudan sunulabilir. Her dosya isteği yeni bir SSR işlemi değildir; her SSR isteği de zorunlu olarak veri tabanına aynı sorguları göndermez.
Kendi sunucunuzda Node.js, süreç gözetimi, uygulama güncellemeleri ve loglar sizin sorumluluğunuzdadır. Dedicated sunucu da bir seçenektir; ancak SSR için mutlaka fiziksel sunucu veya VPS gerekir şeklinde genel bir kural yoktur. Uyumlu yönetilen platformlar ve Node desteği bulunan bazı paylaşımlı ortamlar da kullanılabilir. Kararı ürün adına göre değil desteklenen Node sürümü, süreç davranışı, kaynak limitleri ve dağıtım özelliklerine göre verin. Node.js hosting seçenekleri rehberi bu kontrolü genişletir.
Yeniden üretimin önbellek ve güncellik maliyeti
Next.js ISR, statik export’un üzerine dosya sunucusunda açılan bir seçenek değildir. Next.js 16 belgelerinde ISR için Node.js runtime desteği gerekir; output: 'export' ile desteklenmez. Nuxt 4’te nuxt generate çıktısında sunucu bulunmaz; Nitro’nun çalışma zamanındaki swr veya sağlayıcıya bağlı isr davranışı ayrı bir sunucu dağıtımının konusudur.
revalidate süresinin dolması, yeni HTML’in tam o saniyede bütün kullanıcılara ulaştığına dair bir taahhüt değildir. İstek, yeniden üretim süreci, API gecikmesi ve hata durumu sonucu etkiler. Next.js yenileme hatasında son başarılı içeriği sunmaya devam edebilir. Kesin güncellik isteyen stok veya işlem yetkisini, yalnız sayfa önbelleğine emanet etmeyin; işlemi gerçekleştiren API güncel durumu doğrulamalıdır.
Topoloji 1: Tek sunucuyla ölçülebilir başlangıç
Basit bir Node dağıtımında uygulama, reverse proxy ve küçük veri tabanı aynı VPS üzerinde bulunabilir. Bu, tek başına “küçük projeye yeter” sonucu vermez. Aynı bellek ve disk hem uygulama hem veri tabanı hem de işletim sistemi tarafından kullanılır; o hostun arızası bütün rolleri etkiler.
- Reverse proxy TLS sonlandırır; uygulama portuna erişimi ve statik dosya yönlendirmesini yönetir.
- PM2 veya systemd uygulamayı gözetebilir. Süreci yeniden başlatmak uygulama sağlığını ya da kesintisiz yayını tek başına garanti etmez.
- Worker sayısı CPU, süreç başına bellek ve veri tabanı bağlantı havuzuyla birlikte ölçülür. Her projeye 2–4 worker atamak geçerli bir kapasite hesabı değildir.
- Build işlemi CI veya ayrı build ortamında yapılabilir. Canlı sunucuda build yapılacaksa build’in tepe RAM/CPU tüketimi için ayrıca alan bırakılmalıdır.
- Yedekler ve geri yükleme denemeleri aynı hostun kaybını da kapsamalıdır.
Tek sunucunun değeri az sayıda işletim bileşenidir. Sınırı, ölçülen tepe yükte kabul edilen gecikme ve hata oranını sağlayıp sağlamadığıdır. Günlük “binlerce ziyaretçi” ifadesi; cache oranını, istek patlamalarını, sayfa maliyetini veya aynı anda açık bağlantıları söylemediği için yeterlilik kanıtı değildir.
Topoloji 2: Uygulama ve veri tabanını ayırmak
Veri tabanı uygulamayla bellek veya disk için yarışıyorsa, farklı bakım takvimleri gerekiyorsa ya da rollerin hata etkisini azaltmak istiyorsanız ayırmayı değerlendirin. Veri tabanı sunucusunu uygulamadan ayırma rehberi bu kararın ayrıntılarını ele alır. Her büyüyen projede ilk hareketin mutlaka yeni bir veri tabanı sunucusu olması gerekmez; önce yavaş sorgu, indeks, gereksiz çağrı ve bağlantı havuzu sorunlarını inceleyin.
- Uygulama–veri tabanı ağ gecikmesini ve veri transferini ölçün. Uzak veri tabanı, sunucu kaynakları artsa bile SSR yanıtını yavaşlatabilir.
- Bağlantı havuzunu bütün worker ve uygulama kopyaları üzerinden hesaplayın. Kopya sayısı arttıkça toplam bağlantı talebi de büyür.
- Veri tabanını yalnız gerekli uygulama kaynaklarına açın; erişim, şifreleme ve yedeklemeyi topolojiyle birlikte tanımlayın.
- Redis/Memcached gibi ek bir cache katmanını, ortadan kaldıracağı ölçülmüş sorgu veya hesaplama maliyetine göre ekleyin.
Headless WordPress ve Next.js mimarisi de arayüz ile içerik API’sinin ayrıldığı bir örnektir. CMS yönetim ekranının yükü, build sırasındaki toplu içerik çekimi ve ziyaretçi API trafiği farklı iş yükleridir. Bunları tek ortalama istek süresinde birleştirmek darboğazın nerede olduğunu gizler.
Topoloji 3: Birden fazla uygulama kopyası
Bir uygulama kopyası hedef yükü karşılamıyorsa veya bakım sırasında trafik taşımak gerekiyorsa yük dengeleyici arkasında birden fazla kopya çalıştırılabilir. Yalnız kopya eklemek veri tabanını, cache’i veya yük dengeleyiciyi yüksek erişilebilir yapmaz. Her ortak bağımlılığın kapasitesi ve arıza davranışı ayrıca değerlendirilir.
- Aynı release/build çıktısını bütün kopyalara dağıtın. Farklı derlemelerden gelen HTML ve istemci dosyalarının karışmasını önleyin.
- Oturumları veya gerekli uygulama durumunu yalnız bir sürecin belleğinde tutuyorsanız trafik başka kopyaya geçtiğinde ne olacağını belirleyin.
- Next.js’in varsayılan yerel cache’i ayrı kopyalar arasında ortak değildir. ISR/Data Cache için desteklenen ortak cache ve invalidation tasarımını seçin; Redis kurmak kendiliğinden framework entegrasyonu yapmaz.
- Nuxt/Nitro cache deposu ve adaptör davranışını kullanılan sürüm/preset için kontrol edin. Next.js’e ait cache ayarını Nuxt’a aynen taşımayın.
- Sağlık kontrolü, trafikten çıkarma, açık istekleri tamamlama ve geri alma akışını doğrulayın.
Kimliği doğrulanmış hesap, sepet veya kişiye özel yanıtları genel CDN/mikro cache’e almayın. Önbellek anahtarı, cookie/Authorization davranışı ve private/no-store işaretleri birlikte incelenmelidir. Anonim içerik için bile yanlış dil, para birimi veya deney varyantını paylaşmamak gerekir. Yüksek trafikli içerik sitelerinde cache ve veri tabanı ölçeklendirme rehberi bu kararların ilgili işletim bağlamını sunar.
Kapasiteyi ziyaretçi sayısından değil iş yükünden çıkarın
Ölçüm planında sayfa grupları, istek oranları ve kabul sınırları bulunmalıdır. Örneğin anonim cache-hit sayfalarıyla oturum açmış kullanıcının rapor sayfasını ayrı tutun. Aynı URL’nin cache-hit ve cache-miss durumu bile farklı CPU ve veri tabanı yükü yaratır. Client-side gezinme ve arka plan API çağrıları ilk sayfa isteğinin dışında kalabilir.
| Ölçülecek alan | Karardaki rolü |
|---|---|
| Rota başına istek/saniye, cache hit/miss | Origin’e ulaşan gerçek iş miktarı |
| p50/p95/p99 yanıt süresi ve hata oranı | Ortalamanın sakladığı yavaş istekler ve kabul sınırı |
| CPU, event-loop gecikmesi, worker belleği | Hesaplama, bloklama ve süreç sayısı kararı |
| Veri tabanı sorgu süresi, bağlantılar, I/O | Uygulamadan bağımsız darboğaz veya kaynak yarışması |
| Build süresi ve tepe bellek | Dağıtım ortamının ayrı kaynak bütçesi |
| Uzun bağlantılar ve yeniden bağlanma yükü | Bağlantı ömrü ve yeniden dağıtım planı |
Yük testini temsilî veri ve gerçekçi kullanıcı akışlarıyla ayrı test ortamında yapın. Sıcak cache, soğuk cache, bir kopya devre dışı ve yavaş bağımlılık gibi senaryoları ayrı ölçün. Testi yalnız saniyedeki toplam istekle değerlendirmeyin: kullanıcının işini tamamlayabilmesi, hata türleri ve kabul edilen gecikme de kayda geçsin. Burada belirli bir vCPU/RAM paketine atanmış test sonucu bulunmuyor.
Worker eklemek bekleyen bütün istekleri daha hızlı yapmaz. CPU yoğun işlerde CPU sınırı, veri tabanı beklemelerinde sorgu/bağlantı sınırı, bellek sızıntısında ise süreç belleği öne çıkabilir. Uygulama, reverse proxy ve veri tabanı ölçümlerini aynı zaman çizelgesinde birleştirin. Ölçüm sonrası seçilen kapasiteye arıza ve kampanya payı ekleyin; bu payın hangi senaryoyu karşıladığını yazın.
CDN ve edge katmanını veri yoluyla birlikte değerlendirin
CDN, uygun statik ve herkese açık yanıtları origin’e gitmeden sunabilir. Bu durum origin yükünü azaltabilir; fakat LCP yalnız ağ gecikmesi değildir. Görsel boyutu, JavaScript, hydration, istemci cihazı ve veri çağrıları sonucu etkiler. Core Web Vitals LCP, INP ve CLS’dir; TTFB yararlı bir tanılama metriğidir. Hosting tarafında Core Web Vitals rehberi bu ölçümleri ayırmaya yardımcı olur.
Edge kodu için “kullanıcıya yakın” ile “veriye yakın” aynı şey olmayabilir. Her istekte uzak origin API’sine giden fonksiyon ek bir ağ geçişi yaratabilir. Coğrafi dağıtımı, origin çağrı sayısını, cache oranını ve hedef bölgelerden ölçülen yanıt süresini birlikte inceleyin. Edge kullanımının otomatik hız veya daha küçük origin garantisi yoktur.
Next.js Edge Runtime tüm Node.js API’lerini desteklemez ve Next.js ISR bu runtime’da desteklenmez. Nuxt’un Nitro preset’i de hedef ortamın özelliklerine göre seçilir. Sunucudaki bir framework middleware/proxy dosyası kendi başına küresel edge ağı oluşturmaz. Fonksiyon süreleri, ağ bağlantıları, paket uyumluluğu ve uzun bağlantı desteği sağlayıcıya bağlıdır; serverless ve edge için toplu WebSocket yasağı varsaymayın.
Dağıtım ve gözlemlenebilirlik mimarinin parçasıdır
Build’i ayrı release olarak üretin; test, staging ve üretim ayarlarını karıştırmayın. Geliştirme, test ve canlı ortam mimarisi rehberi bu ayrım için temel sağlar. Statik yayında HTML ve hashli dosyaların aynı sürüme ait olduğundan emin olun. Eski sayfası açık kullanıcıların ihtiyaç duyduğu eski dosyaları hemen silmek istemci hataları doğurabilir.
SSR dağıtımında yeni kopyayı sağlıklı olduğu doğrulandıktan sonra trafiğe alın; eskisini yeni isteklerden çıkarıp devam eden işleri uygun süreyle tamamlatın. Veri tabanı değişiklikleri eski/yeni uygulama sürümleriyle uyumlu olmalıdır. GitHub Actions ile VPS dağıtımı rehberindeki akışlar bağlam sağlar, ancak PM2 reload, symlink değişimi veya bir pipeline tek başına kesinti olmayacağını kanıtlamaz.
Uygulama hataları, reverse proxy durum kodları ve bağımlılık gecikmeleri birlikte izlenmelidir. Loglarda oturum tokenı veya kişisel veri taşımadan istekleri ilişkilendirin. Alarmı sadece CPU yüzdesine değil hata oranı, gecikme ve başarısız kullanıcı işlemlerine de bağlayın. Yedekten dönme ve önceki release’e geçme adımlarının sorumlusu belli olsun.
Karar çıktısı: sayfa haritası, topoloji ve ölçüm planı
İçerik sitesi için build süresi ve yayın gecikmesi; SaaS paneli için kimlik doğrulayan API ve oturum davranışı; e-ticaret için fiyat/stok doğrulaması ve kişisel cache sınırları; gerçek zamanlı uygulama için bağlantı ömrü daha belirleyici olabilir. Bu örnekler bütün blogların statik, bütün sepetlerin SSR veya bütün global sitelerin edge olmak zorunda olduğu anlamına gelmez.
Maliyet karşılaştırmasını bütün veri yolu üzerinden yapın. Statik sunumda depolama, istek, transfer, build ve varsa ayrı API maliyetini; SSR’de bunlara ek olarak runtime kapasitesi ve işletim yükünü hesaplayın. Serverless ve edge fiyatlandırmasında istek, çalıştırma ve transfer kalemleri ile sağlayıcının limitlerini kontrol edin. CDN origin işini azaltabilir, ancak kendi maliyetini de ekler. Beklenen trafik profiliyle toplamı karşılaştırın; daha fazla bileşenin otomatik olarak daha ucuz olacağını varsaymayın.
- Her rota grubunun render, veri kaynağı, oturum ve güncellik kararını yazın.
- Statik origin, uygulama runtime’ı ve API/veri tabanı rollerini çizip aralarındaki ağ yolunu belirleyin.
- Kapasite hedefini ölçülebilir yanıt süresi, hata oranı ve temsilî yükle tanımlayın.
- Cache paylaşımı, dağıtım, geri alma ve yedek sorumluluğunu kaydedin.
- DCHost veya başka bir platformdaki ürünün gerekli runtime ve kaynakları gerçekten sağladığını bu listeyle kontrol edin.
Topoloji seçiminin tamamlanmış çıktısı bir sunucu paketi adı değil, hangi işin nerede çalışacağını ve yeterliliğin nasıl ölçüleceğini açıklayan kısa bir işletim kaydıdır. Trafik veya içerik akışı değiştiğinde aynı ölçümleri tekrarlayarak kapasite artırma, rol ayırma veya CDN/edge ekleme kararını güncelleyin.
