Vercel, Netlify ve Cloudflare Pages: JAMstack hosting karşılaştırması

JAMstack (JavaScript, API’lar ve Markup) yaklaşımında uygulamanın “çekirdek” kısmı statik dosyalardır; hız, cache ve CDN dağıtımı üzerinden kazanılır. Bu nedenle doğru JAMstack hosting seçimi, yalnızca sayfa yükleme süresini değil; geliştirme sürecini, sürüm/preview yönetimini, maliyeti ve ölçekleme davranışını da doğrudan etkiler. Bu yazıda Vercel, Netlify ve Cloudflare Pages’i; üretimde ve günlük geliştirme akışında kritik olan somut başlıklarla karşılaştıracaksınız.

Aşağıdaki karşılaştırmayı özellikle şu tip siteler/uygulamalar için okumanız daha doğru olur: Next.js/Nuxt/SvelteKit tabanlı projeler, statik blog + serverless fonksiyon gereksinimi olan ürün siteleri, Git ile çalışan otomatik preview (önizleme) isteyen ekipler.

JAMstack’te hosting seçiminde asıl belirleyiciler

JAMstack’te “hosting” genelde statik içerik dağıtımı (CDN) + build (derleme) + gerektiğinde edge/serverless fonksiyon kombinasyonudur. Bu üç parçanın nasıl çalıştığı seçimin temelidir:

Build/pipeline: Git’ten commit alındıktan sonra build’in nerede ve nasıl çalıştığı (cache etkisi dahil).
Dağıtım (CDN/edge): HTML/assetlerin nereden sunulduğu, cache header davranışları.
Serverless/edge fonksiyon: API route’larının çalışma biçimi (edge mi region mu), soğuk başlangıç (cold start) etkisi ve limits.
Preview/branch deploy: Her PR/branch için otomatik URL üretimi, rollback ve gözle görülür hata ayıklama.
Maliyet modeli: Aylık sabit ücret + istek/işlem (invocation), veri transferi, build süreleri gibi kalemler.

Bu noktalar “aynı sayfayı” yayınlıyor gibi görünen platformlarda bile ciddi farklı sonuçlar doğurur.

Vercel vs Netlify vs Cloudflare Pages: net karşılaştırma tablosu

Aşağıdaki tablo, karar vermeyi hızlandırmak için en çok karşılaşılan kullanım senaryolarına göre tasarlanmıştır. (Değerler plan/ürün sürümüne göre değişebilir; yine de mantık ve operasyonel farklılıklar aynıdır.)

| Kriter | Vercel | Netlify | Cloudflare Pages | |---|---|---| | Öne çıkan taraf | Next.js odaklı otomasyon, preview ve hızlı deploy | Geniş site entegrasyonları, kullanıcı dostu ayarlar, yerleşik özellik seti | Cloudflare ağı ve cache/edge performansı, güvenlik/robot kontrol entegrasyonu | | Build cache etkisi | Genelde güçlü; Next.js projelerinde pratik hız | Monorepo ve cache politikaları iyi kurgulanır | Build çıktıları Cloudflare tarafında dağıtılır; edge entegrasyonu avantajlı | | Preview/PR URL | PR başına otomatik preview akışı çok olgun | Preview deploy pratik ve görünür | PR preview destekleri güçlü; Cloudflare ekosistemiyle birleşir | | Edge/serverless yaklaşımı | Vercel’in edge/serverless ürünleri geniş kullanılır | Netlify Functions + edge benzeri yaklaşımlar | Functions for Pages (ve edge tabanlı seçenekler) ekosistemle uyumlu | | CDN kontrolü | Kontrol ve header yönetimi proje ayarlarına bağlı | Kontrol ve yönlendirme seçenekleri güçlü | Cloudflare tarafında cache/security/transformer gibi seçenekler avantaj | | Maliyet mantığı | Invocation/usage odaklı ve ölçekle birlikte artar | İstek ve fonksiyon kullanımına göre değişir | Cloudflare ücretlendirmesi; plan ve kullanım türüne göre belirlenir | | Tipik “en doğru proje” | Next.js (özellikle) ve modern front-end | İçerik + otomasyon isteyen ekipler | Cloudflare altyapısı avantajı isteyen performans/güvenlik odaklı ekipler |

Tabloyu şöyle okuyun: - “Benim proje Next.js ve deploy süreci benim için kritik” diyorsanız Vercel ilk aday çıkar. - “Benim için içerik site yönetimi + otomasyon + hızlı dev döngüsü önemli” diyorsanız Netlify öne çıkar. - “Cache, güvenlik ve edge davranışını Cloudflare ekosistemiyle derin yönetmek istiyorum” diyorsanız Cloudflare Pages güçlü bir tercihtir.

Build ve dağıtım: PR preview hızını belirleyen 6 pratik kontrol

JAMstack’te hız algısını sadece “CDN var” diyerek açıklayamazsınız. PR preview URL’lerinin gelme süresi, gerçek build cache davranışı ve çıktıların boyutu belirler.

1) Build cache’i bozan ayarlar

Şunlar pipeline hızını düşürür: - Sık değişen çevre değişkenleri (env) ile build output’ının tekrar üretilmesi - Her commit’te tüm monorepo’nun yeniden derlenmesi (özellikle pnpm/workspace kullanıyorsanız) - Büyük medya dosyalarının “build aşamasında” kopyalanması

Kontrol önerisi: Aynı branch üzerinde küçük bir HTML değişikliği yapın; PR preview süresini ölçün. Build cache iyi çalışıyorsa, tekrarlı deploy’larda süre belirgin düşmelidir.

2) Statik varlıkların doğru sıkıştırma davranışı

Platformlar otomatik sıkıştırma sağlayabilir; fakat doğru cache header seti ve doğru asset stratejisi gerekir: - Görsel: WebP/AVIF - Font: WOFF2 + doğru preload/font-display - Bundle: Gzip/Brotli kontrolü

Pratik ölçüm: Aynı sayfada “Asset yükleme zamanları” karşılaştırın. Sadece ilk HTML değil, JS/CSS ve görsel sayısı da toplam gecikmeyi belirler.

3) HTML cache (Edge cache) davranışı

Statik sayfalarda HTML’in cache’lenmesi performansı ciddi artırır. Ancak kullanıcıya göre değişiyorsa (kişiselleştirme, A/B test vb.) cache kurgusu değişir.

Öneri: Kişiselleştirmeyen landing sayfalarında HTML cache daha agresif planlanmalıdır. Kişiselleştirilmiş sayfalarda ise kısa TTL veya “no-store” mantığı gerekir.

4) Routing ve fallback (SPA) stratejisi

SPA kullanıyorsanız 404/route fallback doğru ayarlanmazsa uygulama tarayıcı tarafında bozulur. Bu, özellikle client-side router kullanan projelerde en sık “prod sürprizi” çıkaran konulardan biridir.

Kontrol listesi: - deep link (ör. /pricing/teir-2) direkt açınca sayfa geliyor mu? - 404 gerçekten 404 mü yoksa index’e mi dönüyor?

5) Preview ortamında doğru environment

Preview URL’de kullanılan env değerleri (API endpoint, feature flag) üretimle aynı olmalı ya da netçe ayrılmalıdır. Aksi halde “preview çalışıyor ama prod bozuk” senaryosu çıkar.

6) Fonksiyon (serverless) kullanırken cold start etkisi

Edge tabanlı davranışlar soğuk başlangıcı azaltabilir; ama kullanım türü (her istek fonksiyon mu, yoksa statik mi?) maliyeti de etkiler.

Kural: Mümkünse sayfanın “render ettiği” veriyi statik/edge cache ile çözün. Kritik API çağrıları zorunluysa fonksiyona taşıyın.

Maliyet modeli: aynı iş yükünde nasıl karşılaştırılır?

Aynı özellik setiyle çalışan üç platformun maliyetini “etiket fiyata” bakarak tahmin etmek doğru değildir. JAMstack’te maliyeti; statik veri + fonksiyon invocation + veri transferi ve build kullanımı belirler.

1) Maliyet karşılaştırması için 3 senaryo belirleyin

Örnek senaryolar: - S1 (Düşük trafik): 10K/月 ziyaret, temel sayfalar + birkaç form gönderimi (fonksiyon) - S2 (Orta trafik): 100K/月, sunucu tarafı render yok, edge/fonksiyon daha sık - S3 (Yüksek trafik): 1M+/ay, ağır görsel/asset + API kullanım yoğun

Her senaryoda şu metrikleri toplayın: - Fonksiyon invocation sayısı - Veri transferi (egress) - Build/derleme sıklığı (özellikle PR preview çoksa)

2) PR preview maliyeti genelde gözden kaçar

Takım her PR için deploy üretirse “build çıktısı” ve “dağıtım” maliyeti artabilir. Platformlar bu süreçte genellikle kullanım sınırlarına göre kademeli etkiler yaratır.

Eylem: PR preview sayısını azaltma kuralı koyun: - Sadece belirli branch’ler için preview - Schedule ile otomatik kapanan preview’ler

3) Veriyi doğru yerde çözün

İsteğe bağlı içerikler: KV/cache/edge kaynakları
Tekrarlı sorgular: sonuçları cache’leyin
Form işlemleri: asenkron iş kuyruğu yerine mümkünse hafif fonksiyon

Aksi halde maliyeti fonksiyonlar büyütür; “statik hosting” beklentisini bozar.

Performans: LCP/INP ve TTFB için platform seçiminin etkisi

Platform seçimi tek başına LCP’yi garanti etmez; fakat edge dağıtımı, cache yönetimi ve asset servis davranışı belirgin fark yaratır.

1) TTFB (Time to First Byte) ne kadar önemli?

TTFB, HTML’in ve gerekiyorsa ilk API yanıtının ne kadar erken geldiğini gösterir. JAMstack’te HTML’in edge’den gelmesi TTFB’yi düşürür.

Pratik yöntem: Aynı sayfayı üç platformda da “ilk ziyaret” ve “tekrarlı ziyaret” olarak ölçün. - İlk ziyaret: CDN ısınma ve cache header etkisini görür - Tekrarlı ziyaret: tarayıcı cache ve CDN cache etkisini görür

2) INP (Interaction to Next Paint) fonksiyonlara bağımlı mı?

İnteraksiyon gecikmesi çoğu zaman şu sebeplerle olur: - Kullanıcı tıklayınca hemen API çağrısı yapılıyorsa - JavaScript bundle şişkinse - UI thread bloke oluyorsa

Platformun rolü dolaylıdır: fonksiyon yanıt süresi veya edge gecikmesi INP’yi etkiler. Bu nedenle API’yi fonksiyonda tutuyorsanız yanıt sürelerini ölçün.

3) Cache-Control ve varlık stratejisi

Performans ölçümünde en sık fark yaratan şey şudur: - JS/CSS: uzun cache (content-hash ile) - HTML: daha kısa veya validasyonlu cache

Üç platformda da bu ayarların nasıl yapıldığını kontrol edin. Cloudflare tarafında cache davranışını daha granular yönetme imkânı olduğundan, bazı projelerde daha iyi sonuç alınır.

Güvenlik ve bakım: hangi platform hangi riski azaltır?

JAMstack sitelerinde güvenlik konusu; DDoS, bot yönetimi, rate limit, TLS ve yanlış yapılandırmaya karşı korumalar etrafında şekillenir.

Cloudflare Pages’in öne çıktığı yerler

Cloudflare ekosistemiyle edge güvenlik katmanlarını kolay birleştirme
Bot/robot kontrol, WAF benzeri davranışlar (kullanılan plan ve ayarlara göre)

Ekip “güvenlik politikalarını” merkezi yönetmek istiyorsa Cloudflare Pages avantajlı olabilir.

Vercel ve Netlify tarafında tipik bakım avantajları

Geliştirici deneyimi: preview URL’leri, otomatik deploy, ortam ayrımı
Proje şablonları: framework uyumluluğu

Ekip daha çok “hızlı release” ve “kolay debug” istiyorsa bu iki platform genellikle daha az sürtünme yaratır.

Hangi proje tipi hangi platforma daha uygun? (Net öneriler)

Aşağıdaki eşleştirme, karar sürecini hızlandırmak için net kılavuz niteliğindedir:

Next.js ağırlıklı projeler + sık PR deploy: Vercel
İçerik odaklı site + otomasyon + hızlı ekip içi preview: Netlify
Cloudflare güvenlik/kablosuz edge yaklaşımı + performansı daha “edge davranışı” olarak yönetme: Cloudflare Pages

Bunun dışındaki durumlarda platformdan platforma taşınmak zor değildir; ancak aşağıdaki bağımlılıklar taşıma maliyetini artırır: - Özel build adımları ve eklentiler - Fonksiyon runtime’a bağlı kodlar - Cache/route/config mantığı

Sonuç: 1 günlük testle doğru seçimi yapın

Net bir seçim için en iyi yöntem “dokümana bakıp tahmin etmek” değil, aynı repo ile her platformda ölçmektir. Şu aksiyon planını uygulayın:

Aynı branch’ten test repoyu oluşturun (production ile aynı framework ve asset seti).
Her platformda 2 ölçüm yapın: ilk yük (cold) ve tekrarlı yük (warm).
PR preview süresini ve fonksiyon çağrısı başına gecikmeyi kaydedin.
Trafik senaryonuza göre fonksiyon kullanımını tahmin edin; maliyeti “etiket” değil kullanım kalemi üzerinden hesaplayın.

Bu testin sonunda Vercel, Netlify veya Cloudflare Pages’ten hangisi sizin “deploy hızı + performans + maliyet” dengenize en iyi uyuyor, netleşecektir. İsterseniz NetKıyas formatında sizdeki proje (framework, fonksiyon kullanımı, tahmini aylık istek) ile karşılaştırma için bir kontrol listesi de çıkarabilirim.