Next.js veya Nuxt için hosting seçerken üç soruyu birlikte yanıtlayın: HTML ne zaman üretilecek, istek anındaki kod nerede çalışacak ve dinamik veriyi hangi hizmet yönetecek? Bu rehber SSR, statik export ve edge işlevlerini performans, maliyet ve işletim açısından karşılaştırır; blog, e-ticaret, SaaS ve gerçek zamanlı projeler için seçim ölçütleri sunar. Ardından Next.js 16 ve Nuxt 4 statik çıktısının nasıl doğrulanacağını gösterir.
Buradaki sürüm referansları Next.js v16.0.0 ve Nuxt v4.0.0 kaynak ağacındaki resmî belgelerdir; bunlar eski yama sürümlerini üretime kurma önerisi değildir. Projenizin kurulu yama sürümünü, Node gereksinimini ve adaptörünü kilit dosyasıyla kaydedin; o sürümün güncel düzeltmelerini ayrıca izleyin. Örnekler tam uygulama veya bu projede çalıştırılmış framework build’i değildir.
Altyapı yerleşimi ve kapasite planlamasına ilişkin tamamlayıcı çerçeve için Next.js ve Nuxt uygulamaları için doğru hosting mimarisi rehberine bakabilirsiniz. Aşağıda seçimi proje gereksinimlerine bağlayıp üç dağıtım senaryosunu ve yayın öncesi kabul adımlarını birlikte ele alıyoruz.
SSR, statik export ve edge hangi ihtiyacı karşılar?
SSR ve statik üretim, HTML’in ne zaman hazırlandığını anlatır; edge ise kodun çalıştığı dağıtım katmanıdır. Bu yüzden birbirini dışlayan üç düğme gibi düşünülmemelidir. Aynı projede önceden üretilmiş genel sayfalar, istek anında render edilen özel sayfalar ve edge’de çalışan yönlendirme bulunabilir. İstek anında çalışan özelliklerin tamamını yalnız statik dosyalarla yayımlayamazsınız.
SSR: İstek anındaki veriye erişim ve runtime işletimi
İstek anında SSR, sunucunun gelen isteğe göre HTML üretmesini sağlar. Oturum bilgisi, güncel veri veya sunucu tarafında tutulması gereken bir bağımlılık gerektiğinde kullanılabilir. Next.js Pages Router’daki getServerSideProps bu modele örnektir; App Router’daki her Server Component ise otomatik olarak her istekte render edilmez. Nuxt da HTML’i sunucuda üretebilir veya önceden hazırlanmış bir yanıtı önbellekten sunabilir.
Özel hesap görünümü, dinamik filtreli bir liste veya sık değişen veri için SSR değerlendirilebilir. Ancak kişiselleştirilmiş bir panelin tek çözümü değildir: statik sunulan bir arayüz ve yetkilendiren API de geçerli olabilir. Güvenliği belirleyen, erişim kontrolü ve veri sınırlarıdır; SSR etiketi tek başına güvenli tasarım anlamına gelmez.
- Runtime: Seçilen framework sürümünü ve kullanılan paketleri destekleyen Node veya uygun dağıtım adaptörü gerekir.
- İşletim: Kendi VPS’inizde süreç sağlığı, TLS/reverse proxy, günlükler, güncelleme ve yedekleme sizin sorumluluğunuzdadır; yönetilen platformda sorumluluk sınırını sözleşmeye göre belirleyin.
- Kapasite: Eşzamanlı render, API gecikmesi, veri tabanı bağlantıları ve önbellek davranışını ölçün. Darboğaz her zaman CPU değildir.
- Önbellek: Genel içerik ile kullanıcıya özel yanıtları ayırın; özel veriyi ortak önbelleğe taşımayın. Birden fazla Next.js örneğinde yerel cache’lerin kendiliğinden ortak olmadığını hesaba katın.
Statik export: Dosya dağıtımı ve içerik yenileme bütçesi
Build’de hazırlanabilen HTML, CSS ve JavaScript dosyaları statik host veya CDN’den sunulabilir. Genel blog, dokümantasyon ve kampanya sayfalarında framework render yükünü ziyaretçi isteğinden build aşamasına taşımak yararlı olabilir. Buna karşılık içerik değişikliği yeni build ve yayın gerektirebilir; rota sayısı, build süresi ve kabul edilen güncellenme gecikmesi seçimin parçasıdır.
Dinamik arama, oturum, sepet veya canlı veri ayrı API’den alınabilir. Böyle bir sistemde frontend statik olsa da API, veri tabanı ve kimlik doğrulama işletimi devam eder. ISR, saf statik export’un özelliği değildir; aşağıdaki sürüm bölümünde açıklandığı gibi uygun runtime ve dağıtım desteği ister.
Edge: Seçilmiş işlevler için ek bir çalışma katmanı
Desteklenen bir edge platformunda yönlendirme, dil/bölge seçimi, deney varyantı veya istek başlığı işleme gibi işlevler çalıştırılabilir. Statik ya da SSR origin aynı kalabilir; bütün uygulamayı taşımak zorunlu değildir. Edge’de ön yetki kontrolü kullanmak, origin veya API’nin kendi yetkilendirmesini kaldırmaz.
- Olası yarar: Bazı istekler origin’e gitmeden yanıtlanabilir veya yönlendirilebilir. Kazancı gerçek kullanıcı bölgeleri ve cache durumlarında ölçün.
- Veriye uzaklık: Kullanıcıya yakın kod, uzaktaki tek veri tabanına her istekte gidiyorsa ek ağ gecikmesi yaratabilir; edge her işlemde daha hızlı değildir.
- Uyumluluk: Node API’leri, paketler, süre ve bellek sınırları, bağlantılar ve adaptör özelliklerini seçilen platformda doğrulayın. Next.js Edge Runtime, Node’un bütün API’lerini ve ISR’yi desteklemez.
- İşletim: Tarayıcı, edge, origin ve veri katmanı arasında günlük ve hata takibi gerekir. Fonksiyon ücreti, gözlemleme ve veri aktarımını maliyete ekleyin.
WebSocket için de tek bir edge kuralı yoktur; aşağıdaki bölümde platforma bağlı sunucu bağlantısı desteği ve ortak durum gereksinimleri ayrıca ele alınır.
Performans, maliyet ve geliştirme yükünü karşılaştırın
| Ölçüt | Statik dosya dağıtımı | SSR veya runtime ile hibrit üretim | Edge işlevleri |
|---|---|---|---|
| İlk yanıt ve kullanıcı deneyimi | Önbellekteki dosya hızlı sunulabilir; ağır JavaScript, görseller veya API bekleme yine kullanıcıyı yavaşlatabilir. | Render ve veri erişimi yanıt süresine eklenebilir; cache, streaming ve bağımlılıkların konumu sonucu değiştirir. | Bazı kararlar origin’e gitmeden verilebilir; uzak veri erişimi veya ek katmanlar kazancı azaltabilir. |
| Güncellik ve kişiselleştirme | Build anındaki içerik; değişiklik için yeniden yayın veya ayrı istemci/API akışı gerekir. | İstek anındaki veriyi veya kontrollü yenilemeyi kullanabilir; özel ve ortak cache sınırı açık olmalıdır. | İstek bilgisine göre işlem yapabilir; gerekli durum ve verinin nerede tutulduğu belirlenmelidir. |
| Maliyet ve ölçekleme | Dosya depolama, CDN/aktarım, build süreleri ve ayrı API giderleri birlikte hesaplanır. | Runtime kapasitesi, eşzamanlılık, cache, veri tabanı ve işletim emeği hesaba katılır. | Çağrı/işlem kotaları, durum servisi, loglar ve edge–origin veri aktarımı değerlendirilir. |
| Geliştirme ve bakım | Rota envanteri, build ve bütün release aktarımı gerekir; dış API bağımlılıkları kaybolmaz. | Çalışma zamanı ayarları, süreç sağlığı, rollout, geri alma ve çoklu örnek tutarlılığı gerekir. | Runtime kısıtları ve dağıtık hata takibi gerekir; yerel test ile gerçek platform davranışı karşılaştırılır. |
En ucuz veya en hızlı modeli yalnız mimari adına göre seçmeyin. Aynı kullanıcı akışında sıcak/soğuk cache, beklenen eşzamanlılık, API/veri tabanı gecikmesi, TTFB ve hata oranını karşılaştırın; LCP, INP ve CLS’yi tarayıcıdaki deneyim için ayrıca izleyin. Örneğin gecikmiş bir görsel ya da büyük istemci paketi, hızlı ilk HTML yanıtının yararını sınırlayabilir.
Proje türüne göre mimari seçimi
Blog, dokümantasyon ve kurumsal içerik
Yayınlanan rota sayısı ve içerik güncelleme ritmi build bütçesine uyuyorsa statik export ile başlayabilirsiniz. CMS’i ayrı tutup her içerik değişikliğini yeniden build/yayın akışına bağlayın. Seçim ölçütü yalnız günlük veya saatlik güncelleme değildir: binlerce rotanın üretim süresini ve editörün önizleme ihtiyacını da ölçün. İstek anında önizleme ya da kabul edilenden daha kısa yenileme aralığı gerekiyorsa uygun runtime ile hibrit üretimi değerlendirin.
E-ticaret: Katalog ile işlem verisini ayırın
Ürün açıklamaları ve genel katalog sayfaları statik üretime veya desteklenen runtime üzerinde ISR’ye uygun olabilir. Fiyat, stok, kampanya koşulu ve teslimat kararı daha sık değişebilir; ödeme anında geçerli tutar ve stok yetkili backend’de tekrar doğrulanmalıdır. Sepet, ödeme ve hesap akışları SSR veya API + CSR ile kurulabilir. Bölgeye göre para birimi seçimi edge’de yapılabilse de ücret ve yetki kararını yalnız tarayıcıya ya da cache’lenmiş HTML’e bırakmayın.
Başlangıçta tek bir uygun runtime ve veri tabanı yeterli olabilir. Ayrı API/cache/veri tabanı veya daha güçlü sunucu kararını trafik, sorgu süresi ve izolasyon ihtiyacına bağlayın; her e-ticaret projesi için aynı VPS’ten dedicated’a geçiş zinciri zorunlu değildir.
SaaS panelleri ve kullanıcıya özel dashboard’lar
Genel tanıtım ve yardım sayfaları statik sunulabilir. Oturum açılan uygulamada SSR ile API + CSR’yi ilk ekranın gereksinimleri, tarayıcı yükü ve sunucu bağımlılıklarına göre karşılaştırın. Kullanıcıya özel veriyi build çıktısına veya ortak cache’e koymayın. Çok kiracılı sistemde her API ve veri sorgusu için kiracı sınırı uygulanmalıdır; sayfayı yalnız giriş yapanlara göstermek yeterli değildir.
Chat, canlı skor ve gerçek zamanlı uygulamalar
UI kabuğu SSR veya statik üretilebilir; canlı iletişim için ayrı bir hizmet gerekebilir. Kendi yönettiğiniz Node servisi, yönetilen gerçek zamanlı hizmet veya uygun edge platformu seçeneklerini bağlantı sayısı, mesaj hacmi, ortak durum, yeniden bağlanma ve işletim kapasitesine göre karşılaştırın. İlk HTML’in üretim modeli WebSocket ölçekleme planının yerine geçmez; video yayını gibi farklı trafik türlerinde medya aktarım katmanını da ayrıca planlayın.
Üç pratik dağıtım senaryosu
1. Tam statik frontend: Dosya hostu ve isteğe bağlı CDN
- Uygun Next.js/Nuxt statik build’i üretip bütün beklenen rotaları kontrol edin; sürüme ait komut ve çıktı dizinleri aşağıda verilmiştir.
- Test edilmiş dosyaları statik dosya sunabilen paylaşımlı hosta, VPS web sunucusuna veya uygun depolama/CDN hizmetine bir release olarak aktarın.
- Alt rota, 404, 301, varlık yolları ve gerekiyorsa ayrı API erişimini doğrulayın; içerik değişikliklerini yeniden build hattına bağlayın.
DCHost hizmeti seçilecekse dosya barındırma, TLS, yönlendirme ve yayın yetkilerini ilgili planda teyit edin. Bu senaryoda üretimde Next/Nuxt render süreci çalışmaz; build ortamının Node ihtiyacı ise devam edebilir.
2. SSR veya runtime gerektiren hibrit uygulama
- Gerekli Node sürümünü, sunucu build’ini ve paket uyumluluğunu belirleyin; yalnız export klasörünü kopyalamayın.
- Kendi VPS’inizde uygun süreç yöneticisi, TLS/reverse proxy ve sağlık denetimi kurun; yönetilen platformda bunların hangisini sağlayıcının yürüttüğünü netleştirin.
- API/veri tabanı bağlantılarını, gizli ortam değişkenlerini, genel/özel cache politikasını ve kapasite sınırlarını test edin.
- Aynı build’i tutarlı biçimde yayımlayın; trafik taşıma, açık istekler, günlükler ve geri alma davranışını doğrulayın.
Çoklu uygulama örneğine geçerken cache ve oturum/durum paylaşımını ayrıca tasarlayın. Sadece süreç sayısını artırmak veri tabanı darboğazını çözmez. Next.js’in cache paylaşımı ve Nuxt’un Node sunucu çıktısı için sürüme uygun resmî dağıtım belgelerini kullanın.
3. Statik frontend, ayrı API ve seçilmiş edge işlevleri
- Genel sayfaları statik dosyalarla yayımlayıp dinamik API’nin URL, yetki ve hata sözleşmesini belirleyin.
- API ve veri tabanını iş yüküne uygun runtime üzerinde çalıştırın; ağ erişimi ve kimlik bilgisi kapsamını sınayın.
- Edge’e yalnız gerekli yönlendirme, istek işleme veya deney seçimini ekleyin; origin/API yetkisini koruyun.
- Frontend, API ve edge sürümlerinin birlikte çalışmasını, cache anahtarlarını, log ilişkilendirmesini ve ayrı geri alma yollarını kontrol edin.
Bu model saf statik export + ISR değildir. ISR veya runtime hibrit yenileme gereken sayfalar uygun sunucu/platform dağıtımında kalır. CDN önbelleği ve ayrı API yükü için gerçek kotalar ve trafik maliyetleri vardır; sınırsız ölçekleme varsaymayın.
Seçimden önce cevaplanacak sorular
- Hangi rotalar isteğe veya oturuma göre değişiyor; hangileri build’de üretilebilir?
- İçerik ne kadar eski kalabilir ve bütün rotaların build/yayın süresi bu sınıra uyuyor mu?
- Kullanıcılar ile veri tabanı/API hangi bölgelerde; ek edge katmanı toplam yolu kısaltıyor mu?
- Gizli verinin, yetkilendirmenin ve paylaşılan durumun sorumlusu hangi hizmet?
- Beklenen trafik ve eşzamanlılık için runtime, CDN, build, veri aktarımı ve işletim bütçesi nedir?
- Ekip süreç yönetimi ve dağıtık hata takibini üstlenebiliyor mu; yönetilen seçenek daha uygun mu?
Bu cevaplara göre modeli seçin; gerekli sunucu özelliği varken yalnız daha basit göründüğü için statik export’a zorlamayın. Statik dağıtım uygunsa aşağıdaki framework ve yayın kontrollerini kullanın. SSR veya edge seçildiyse aynı uygulama akışlarına runtime, yetki, kapasite ve geri alma testlerini de ekleyin.
Statik çıktı ile sunucu dağıtımını ayırın
Statik export, üretimde framework sunucusu çalıştırmadan HTML ve istemci dosyalarını sunabilmektir. Build işlemi yine Node.js kullanabilir; uygulama tarayıcıdan harici API’ye de bağlanabilir. Dolayısıyla “statik” ifadesi bütün sistemin sunucusuz veya dinamik verisiz olduğunu söylemez.
| Özellik | Next.js 16 statik export | Nuxt 4 statik üretim |
|---|---|---|
| Build sırasında HTML üretimi | output: 'export' ve next build | nuxt generate veya nuxt build --prerender |
| Varsayılan yayın dizini | out/ | .output/public/ |
| Dinamik rota listesi | App Router’da build sırasında generateStaticParams ile belirlenir | Nitro crawler keşfi ve gerektiğinde açık prerender rota listesi |
| İstek anında SSR/API | Dosya çıktısı bu sunucuyu içermez | Generate çıktısı sunucu endpoint’lerini içermez |
| ISR veya sunucu taraflı hibrit cache | Statik export’ta ISR desteklenmez | Generate ile çalışma zamanında hibrit rendering sağlanmaz |
| İstemciden ayrı API çağrısı | Uygun yetkilendirme ve ağ koşullarıyla mümkündür | Uygun yetkilendirme ve ağ koşullarıyla mümkündür |
Bu ayrım paylaşımlı hosting üzerinde yalnız dosya sunarken özellikle önemlidir. SSR çalıştırmak istiyorsanız ürünün gerçekten uygun Node runtime’ı ve süreç/uygulama desteği olup olmadığını kontrol edin. VPS tek olasılık değildir; yönetilen platformlar veya Node desteği olan paylaşımlı ortamlar da değerlendirilir. Bir PHP hosting hesabının adı, Node desteğinin varlığını veya yokluğunu tek başına kanıtlamaz.
Next.js 16: export yapılandırması ve rota kapsamı
Eski export komutunu taşımayın
next export Next.js 13.3’te kullanımdan kaldırılmaya başlanmış, 14’te kaldırılmıştır. Next.js 16’da statik çıktı için output ayarını kullanın. Aşağıdaki next.config.mjs, mevcut proje ayarlarıyla birleştirilecek küçük bir yapılandırma örneğidir. Projede tanımlı olmayan sayfaları yaratmaz, desteklenmeyen sunucu özelliklerini de dönüştürmez.
const nextConfig = {
output: 'export',
trailingSlash: true,
};
export default nextConfig;
Projenin build script’i next build çalıştırmalıdır. Script bu şekilde tanımlıysa npm run build kullanılır. Bağımlılıkları projenin kilit dosyasına uygun kurun; sırf bu örneği uygulamak için kilit dosyasını silmeyin veya belirsiz bir en son sürüme geçmeyin. Bu ayarlarda varsayılan çıktı out dizinidir.
trailingSlash: true kullanıldığında örneğin /docs/start/ rotasının dosya düzeni docs/start/index.html biçimini alır. Hostun dizin index davranışını doğrulayın. Bu seçeneği kullanmayan projede dosya eşlemesi farklı olabilir; yalnız alan adı açılıyor diye alt rotaların da doğru sunulduğunu varsaymayın.
App Router ve Pages Router sınırları
App Router’daki Server Component, statik export sırasında build’de çalışabilir. Bileşenin sunucuda çalışması, her ziyaretçi için üretim sunucusunda çalışacağı anlamına gelmez. Build’de okunabilen içerikle istek anına ait cookie, oturum veya header bilgisini ayırın. Statik çıktı her ziyaretçiye aynı dosyayı sunduğu için kullanıcıya özel bilgiyi build çıktısına koymayın.
Dinamik App Router yollarında generateStaticParams ile üretilecek parametreleri belirleyin. Örneğin CMS’teki yayınlanmış içerik slug’larını listeleyin; taslakları, silinmiş kayıtları ve sayfalama sınırlarını ayrı kontrol edin. dynamicParams: true veya parametre listesi olmadan istek anında yeni rota üretimi statik export hedefiyle uyumlu değildir.
Pages Router için getStaticProps ve getStaticPaths geçerlidir. getServerSideProps ise istek anında sunucu gerektirir. Statik export’ta fallback: true ve fallback: 'blocking' desteklenmez. Bu API’leri App Router’a taşınmış gibi anlatmak veya yalnız adını değiştirerek kullanmak doğru değildir.
Sunucu özelliğini dosya özelliği sanmayın
Next.js 16 statik export belgelerinde ISR, Server Actions, istek bilgisine bağımlı Route Handlers, cookie okuma, Draft Mode ve Proxy gibi özellikler desteklenmeyenler arasındadır. Pages Router API Routes da bu dosya dağıtımında sunucu olarak çalışmaz. Bunları kullanan bir projede özellik kaldırma, ayrı backend veya sunucu dağıtımı seçeneklerinden biri gerekir.
Bununla birlikte “bütün Route Handler’lar yasaktır” da doğru değildir: build sırasında statik yanıt üretebilen GET handler’ları desteklenebilir. Bunun çıktısı bir dosyadır; POST alan bir API, kullanıcı oturumuna göre cevap veya çalışan veri tabanı servisi değildir. İlgili handler’ın build çıktısında gerçekten oluştuğunu ve beklenen içerik türüyle sunulduğunu kontrol edin.
Next yapılandırmasındaki redirects, rewrites ve headers sunucu özelliklerini dosyaları yükleyerek çalıştırmış olmazsınız. Statik host veya CDN tarafında gerekli eşlemeleri ayrıca tanımlayın. Kalıcı URL değişiminde HTTP 301 gibi doğru durum kodu veren sunucu/CDN kuralını doğrulayın; yalnız tarayıcı JavaScript’iyle başka sayfaya göndermek aynı uygulama değildir.
Görseller ve tarayıcı API’leri
Varsayılan next/image optimizasyon sunucusu statik export’ta bulunmaz. Resmî belgelerde özel image loader ile ayrı görsel servisi kullanımı anlatılır; görüntüleri başka yerde hazırlıyorsanız optimizasyonu devre dışı bırakma seçeneği de değerlendirilir. Seçilen yöntemde gerçek görsel URL’lerini, boyutları ve erişimi kontrol edin; image loader eklemek görüntüleri build’de otomatik optimize ettiği anlamına gelmez.
Client Component olması da modülün her satırının yalnız tarayıcıda çalışacağını söylemez. Bu bileşenler build sırasında önceden render edilebilir. window, localStorage veya navigator erişimini tarayıcıda çalışan yaşam döngüsüne taşıyın. Build hatasını çözmek için bütün sitenin önceden üretilmiş içeriğini gereksiz yere boş bir kabuğa çevirmeyin.
Nuxt 4: crawler, açık rotalar ve public çıktı
Generate hangi sayfaları bulur?
Nuxt 4’te nuxt generate veya nuxt build --prerender statik üretim yoludur. Nitro crawler kök sayfa, uygun sabit yollar ve açıkça belirtilen rotalardan başlayıp HTML bağlantılarını takip eder. Yalnız istemci etkileşimiyle erişilen veya hiçbir keşfedilebilir sayfadan bağlanmayan bir rota otomatik olarak bulunmayabilir.
Nuxt v4.0.0 belgelerindeki aşağıdaki yapılandırma biçimi, örnek bir projede var olduğu varsayılan /docs/start ve /catalog/widget yollarını açık listeye ekler. Kendi projenizde gerçek yayınlanmış yolları kullanın. Bir wildcard kuralı tek başına veri tabanındaki bütün dinamik slug’ları keşfetmez.
export default defineNuxtConfig({
nitro: {
prerender: {
crawlLinks: true,
routes: ['/docs/start', '/catalog/widget'],
},
},
});
Statik hosta yayımlanacak dizin .output/public olur. Sunucu dağıtımı için kullanılan .output/server/index.mjs farklı bir çıktıdır; generate ile yalnız dosya yayımlarken bu Node sunucusunu çalıştırmazsınız. Eski rehberlerdeki dist dizin adını sürüm ve proje ayarını kontrol etmeden kullanmayın.
Önceden üretilmiş HTML ile SPA aynı şey değildir
Nuxt’un varsayılan ssr: true davranışı generate sırasında sayfa içeriğini HTML’e dönüştürebilir. ssr: false ile üretilen statik SPA ise arayüzü büyük ölçüde tarayıcı JavaScript’ine bırakır. İkisinin de statik hostta çalışabilmesi, ilk HTML’in aynı içerikte olduğu anlamına gelmez. İndekslenmesini istediğiniz sayfanın görünür ana içeriğini ilk HTML yanıtında inceleyin.
Nuxt statik üretiminde 200.html ve 404.html fallback dosyaları da bulunabilir. Hangisinin hangi durum koduyla sunulacağı statik host yapılandırmasına bağlıdır. Var olmayan bir URL’ye her zaman ana sayfayı 200 ile döndürmek, gerçek 404 davranışını gizler. İstemci rotası, gerçek içerik rotası ve bulunamayan yol için ayrı kabul testi hazırlayın.
Generate çıktısında çalışan sunucu endpoint’i yoktur. Build sırasında bir endpoint’ten içerik okuyup dosyaya yazabilmek, o endpoint’in üretimde canlı API olarak kalması demek değildir. İstemcinin çağıracağı form, arama veya oturum servisini gerçekten çalışan bir adrese bağlayın.
ISR ve hibrit rendering neden ayrı dağıtım ister?
Next.js’in ISR özelliği, tamamı statik export edilmiş dosyaların kendi kendini yenilemesi değildir. Next.js 16 için Node runtime’lı ve ISR’yi destekleyen dağıtım gerekir. Yenileme aralığını tanımlayan revalidate, statik dosya sunucusuna bir zamanlayıcı eklemez. Next.js Edge Runtime da ISR desteklemez.
Nuxt 4’te swr, sunucu veya uygun reverse proxy üzerinde yeniden doğrulama/önbellek davranışı; isr ise bunu destekleyen dağıtım platformuna bağlı bir davranıştır. nuxt generate ile çalışma zamanında hibrit rendering sağlamış olmazsınız. Bir rotanın build’de önceden üretilmesi ile istekler geldikçe yeniden üretilebilmesi farklı yeteneklerdir.
Build sırasında alınan içerik yayında değiştiyse iki belirgin yol vardır: statik siteyi yeniden build edip yayımlamak veya uygun runtime ile yenileme yapan sunucu dağıtımına geçmek. Seçim; kabul edilen yayın gecikmesi, build maliyeti ve runtime işletimidir. Headless CMS ve Jamstack rehberi ile Headless WordPress ve Next.js mimarisi bu içerik akışlarına bağlam sağlar.
ISR’de aralık dolduğunda her kullanıcının derhal yeni içeriği göreceğini varsaymayın. Yenileme bir istekle başlayabilir ve hata halinde son başarılı çıktı sunulabilir. Kesin güncellik gerektiren işlem kontrolünü, yalnız önbellekteki HTML’in yaşıyla çözmeyin.
Ayrı API ve gerçek zamanlı bağlantı sınırları
Statik arayüzden kimlik doğrulayan bir API’ye bağlanmak geçerli bir tasarımdır. SSR kendiliğinden güvenli, statik arayüz kendiliğinden güvensiz değildir. Hesap verisine erişimi ve işlemlere yetkiyi API uygulamalıdır. İstemcide düğme gizlemek veya rota guard kullanmak sunucu yetkilendirmesinin yerine geçmez.
Tarayıcıya giden HTML, JavaScript ve payload dosyalarını herkese açık kabul edin. Build için kullanılan gizli anahtarın kendisi, dönen özel veri veya dahili bilgiler bu dosyalara taşınmamalıdır. Next.js NEXT_PUBLIC_ değişkenleri build sırasında istemci paketine gömülür; statik hostta ortam değişkenini değiştirmek geçmişte üretilmiş dosyayı yeniden yazmaz.
Ayrı API için HTTPS, kimlik bilgisi gönderimi, cookie kapsamı ve gerekiyorsa CORS davranışını gerçek origin’lerle doğrulayın. CORS bir yetkilendirme mekanizması değildir. Çok kiracılı uygulamada veri erişiminin kiracı sınırını ayrıca denetleyin; multi-tenant veri tabanı ve hosting rehberi bu ayrım için ilgili bağlamı verir.
WebSocket için tek bir edge kuralı yoktur
Statik olarak sunulan bir arayüz, tarayıcıdan WebSocket servisine bağlanabilir; statik dosya hostu kendiliğinden WebSocket sunucusu olmaz. Ayrı bir Node servisi kullanılabilir, ancak bu tek seçenek değildir. Cloudflare Workers’ın resmî WebSockets API’si sunucu taraflı bağlantı kabulünü destekler; bu nedenle “edge veya serverless WebSocket çalıştıramaz” genellemesi yanlıştır.
Bir runtime’da WebSocket istemci API’sinin bulunması da dağıtım adaptörünün uygulamanız için sunucu bağlantısı kabul ettiğini tek başına kanıtlamaz. HTTP upgrade, bağlantı süresi, yeniden bağlanma, mesaj boyutu ve ortak durum gereksinimlerini seçilen sağlayıcıda kontrol edin. Workers belgeleri, çoklu bağlantı koordinasyonu için Durable Objects kullanımını ve istemcinin bağlantı kopmasına hazırlanmasını açıklar.
Test senaryosuna bağlantı kurma, kimlik doğrulama, mesaj alma/gönderme, bağlantı kesilmesi ve yeniden bağlanma ekleyin. Chat odası gibi ortak durum gerekiyorsa farklı bağlantıların aynı durumu nasıl göreceğini tanımlayın. Edge’e bir ön kontrol eklemek origin veya mesaj servisinin yetkilendirmesini kaldırmaz.
Üretilen dosyaları yayınlamadan önce doğrulayın
1. Build kimliğini ve beklenen rota listesini sabitleyin
Kayıtta framework sürümü, Node sürümü, kilit dosyası, commit/build kimliği, build komutu ve hedef dizin bulunsun. CMS’ten beklenen yayınlanmış rotaların listesini çıkarın. Örnekleme yanında tam rota envanterini de karşılaştırın; yalnız ana sayfanın açılması, yüzlerce içerik sayfasının üretildiğini göstermez.
Çıktı dizinini inceleyip beklenen HTML, JavaScript, CSS ve veri dosyalarının mevcut olduğunu doğrulayın. Artık yayımlanmaması gereken eski yolların kalıp kalmadığını kontrol edin. Klasörün adı aynı olsa bile sunucu build’i ile statik build’i karıştırmayın. Nuxt’ta crawler’ın bulamadığı yolları açık listeye ekleyerek yeniden üretin.
2. Statik host üzerinden gerçek HTTP davranışını inceleyin
Çıktıyı geliştirme sunucusu yerine hedefe benzer statik bir test hostunda açın. Ana sayfa, doğrudan alt sayfa isteği, sayfayı yenileme, istemci gezinmesi, görseller ve olmayan rota için durum kodu ile gövdeyi kontrol edin. Uygulama dev sunucusunda çalışan bir fallback, basit dosya sunucusunda bulunmayabilir.
| İstek | Beklenen doğrulama |
|---|---|
| Mevcut içerik URL’si | Doğru içerik, başarılı yanıt ve çalışan varlıklar |
| Doğrudan alt rota ve sayfa yenileme | Dosya/rota eşlemesi; ana sayfaya sessiz dönüş olmaması |
| Var olmayan içerik URL’si | Uygun 404 durum kodu ve hata sayfası |
| Kalıcı taşınmış URL | Tanımlı 301 hedefi ve son URL’de doğru içerik |
| API veya WebSocket | Gerçek hizmete erişim, yetki ve hata davranışı |
| Alt dizinden yayın | Link ve varlık yollarının doğru taban URL’yi kullanması |
CDN varsa aynı kontrolleri CDN üzerinden de yapın. Cache anahtarı, başlıklar ve yönlendirmeler origin davranışını değiştirebilir. Tek bir başarılı istek bütün bölgeler veya önbellek durumları için sonuç vermez; testin hangi host ve cache koşulunda yapıldığını kaydedin.
3. İçerik, SEO ve tarayıcı davranışını kontrol edin
Başlık, meta description, canonical ve varsa hreflang etiketlerinin doğru sayfaya ait olduğunu inceleyin. Sitemap, yayımlanan tercih edilen URL’lerle uyumlu olmalıdır. Statik çıktı kendi başına arama sıralaması garantisi vermez; eksik içerik, yanlış durum kodu veya bütün sayfalara kopyalanan canonical yine sorun yaratabilir.
Tarayıcıda hydration hataları, konsol hataları ve başarısız ağ isteklerini inceleyin. Dinamik API yüklenemediğinde boş ekran yerine anlaşılır hata davranışı bulunmalıdır. İlk HTML’deki ana içerikle JavaScript sonrası görünümü karşılaştırın. Gizli veri kontrolünü yalnız kaynak kodda değil üretilmiş HTML ve payload dosyalarında da yapın.
TTFB, LCP, INP ve CLS’yi aynı kavram sanmayın: Core Web Vitals LCP, INP ve CLS’dir; TTFB yanıtın başlamasını incelemek için kullanılır. Statik export büyük JavaScript paketini veya hatalı görsel boyutlarını otomatik çözmez. Hosting tarafında Core Web Vitals rehberi bu ölçümlerin yorumlanmasına yardımcı olur.
Dağıtım, geri alma ve yeniden build
Statik release’i testten geçen dosyalarla bir bütün olarak yayımlayın. Aktarım yarıda kalırsa eski HTML’in yeni JavaScript’e veya tersine bağlanmaması gerekir. Önce yeni release dizinini hazırlayıp doğrulayın, sonra hostun desteklediği release değiştirme yöntemiyle trafiği taşıyın. Eski release ve gerekli eski varlıkları geri alma/istemci uyumluluğu planına göre tutun.
GitHub Actions ile VPS dağıtımı rehberi bir CI/CD akışına bağlam sağlar. Statik export’ta Node framework süreci yeniden başlatmak gerekmez; dosyalar ve varsa CDN kuralları değişir. API ayrı çalışıyorsa onun dağıtımını ayrıca yönetin. Pipeline’ın yeşil olması kullanıcı akışlarının test edildiği anlamına gelmez.
Sunucu özelliğine ihtiyaç kesinleşirse Node.js hosting seçeneklerini inceleyip VPS veya uygun yönetilen runtime’ı değerlendirin. Gereksinimlere göre dedicated sunucu da kullanılabilir. Buradaki karar statik çıktı klasörünü çalıştırılabilir sunucu gibi kullanmak değil, uygun sunucu build’ine ve dağıtım yöntemine geçmektir.
Bu geçişte GitHub Actions ile dağıtım akışını da yeniden değerlendirin: süreç sağlığı, trafik taşıma ve açık istekler artık kabul planına eklenir. Statik dosya aktarımına ait bir kontrol listesini değiştirmeden SSR dağıtımına uygulamayın.
Kabul kaydını tamamlayın
- Sürüm, build kimliği ve beklenen rota envanteri kayıtlı mı?
- Üretilen klasör gerçekten statik yayın hedefi mi; sunucu ihtiyacı olan özellikler ayrıştırıldı mı?
- Alt rota, 404, 301, görsel ve istemci gezinmesi testleri geçti mi?
- API/WebSocket hizmeti, yetkilendirme ve hata davranışı doğrulandı mı?
- Başlık, canonical, sitemap ve görünür içerik aynı son URL’lerle uyumlu mu?
- Release değiştirme, CDN güncelleme ve geri alma yöntemi belirli mi?
Bu kayıt, yalnız “build başarılı” sonucundan daha kullanışlıdır: statik çıktının hangi işlevleri taşıdığını ve hangi hizmetlere bağımlı olduğunu açıklar. Framework, içerik rotaları veya hosting kuralları değiştiğinde aynı kabul adımlarını yeniden çalıştırın.
Mimari kararını ve kabul ölçütlerini birlikte kaydedin
Son kararda hangi sayfaların statik, hangilerinin istek anında üretileceğini ve edge katmanının hangi somut görevi üstleneceğini yazın. İçerik güncelleme süresi, güvenlik sınırları, beklenen yük, toplam işletim maliyeti ve ekibin sorumlulukları bu kararı desteklemelidir. Tek bir model bütün projeye zorunlu değildir; birlikte kullanılan modellerin bağlantıları ve hata davranışı da tasarımın parçasıdır.
Statik yol için dosya ve rota kabul kaydını, SSR için runtime ve trafik taşıma kontrollerini, ayrı API/edge için yetki ve sürüm uyumluluğu testlerini tamamlayın. Proje büyüdüğünde mimariyi yalnız ürün adını değiştirerek değil, yeni ölçümler ve gereksinimler üzerinden yeniden değerlendirin.
