Vercel, Netlify ve Cloudflare Pages: JAMstack hosting rehberi

JAMstack ile site dağıtımı söz konusu olduğunda “hangi platform daha iyi?” sorusu, doğru cevap verilmezse kolayca yanlış yönlendirir. Vercel, Netlify ve Cloudflare Pages benzer görünebilir: hepsi statik üretim (static build), CDN dağıtımı ve hızlı yayın sunar. Ancak derleme modeli, CI/CD akışı, cache davranışı, edge fonksiyonları ve gizlilik (privacy) gibi farklar uygulamanın maliyetini, performansını ve güvenliğini doğrudan etkiler. Bu rehberde; her bir platformun JAMstack iş akışını nasıl ele aldığını net ölçütlerle karşılaştırıp, hangi senaryoda hangisinin daha doğru seçim olacağını belirleyeceğiz.

JAMstack hosting’de “doğru” beklenti nedir?

Önce hedefi netleştirelim. JAMstack’te site, çoğunlukla derleme zamanında (build time) üretilir ve son kullanıcıya CDN üzerinden sunulur. Dinamik ihtiyaçlar ise genellikle şu bileşenlerle çözülür: - Edge/Serverless fonksiyonlar (örn. form gönderimi, doğrulama) - Headless CMS veya API tüketimi (client-side fetch) - İsteğe göre revalidate (incremental build/revalidation) - Cache stratejileri (build çıktısı + edge cache)

Dolayısıyla bir JAMstack platformunu değerlendirirken sadece “hız”a bakmak yetmez. Şu sorular kritik: 1. Derleme nasıl tetikleniyor? (push ile otomatik build, webhook, schedule) 2. Üretilen çıktılar nasıl cache ediliyor? (CDN cache süresi, invalidation) 3. Form/endpoint gibi dinamik işlemler edge’de mi, serverless’ta mı çözülüyor? 4. Domain ve TLS (HTTPS) yönetimi nasıl yapılıyor? 5. Güvenlik katmanları neler? (WAF/headers, rate limit, secret yönetimi) 6. Fiyatı hangi bileşen belirliyor? (build sayısı, fonksiyon çağrısı, bant genişliği)

Platform karşılaştırması: Vercel vs Netlify vs Cloudflare Pages

Aşağıdaki tablo, JAMstack kullanımında en çok karşılaşılan seçim kriterlerini yan yana koyar. Not: Özellik adları zaman içinde güncellenebilir; burada değerlendirmeyi yaptıran mantığı esas alıyoruz.

Bu tablo “genel” gibi görünse de asıl farklar, senaryoda ortaya çıkar. Şimdi üç ana senaryoya göre net öneri yapalım.

Senaryo 1: Next.js/React tabanlı proje ve hızlı preview

• Vercel: Next.js ile uyum pratik olduğu için preview environment üretimi ve dağıtım çevrimi tipik olarak en sorunsuz ilerler. Çok sık PR açan ekiplerde previewlerin yönetimi zaman kazandırır.
• Netlify: React/SPA ve statik site üretiminde güçlüdür. Fonksiyon ihtiyacı varsa Netlify tarafında iş akışı kolay kalır.
• Cloudflare Pages: Projenin edge ekosisteminden faydalanması (ör. Workers ile birlikte) bekleniyorsa iyi sonuç verir.

Net tercih ölçütü: PR sayısı yüksekse ve “her PR bir preview olsun, dağıtım otomatik akışla ilerlesin” öncelikse Vercel çoğu ekipte daha az operasyonla çalışır.

Senaryo 2: API entegrasyonlu statik site + edge’de kontrol

• Cloudflare Pages: Cache davranışını header ve edge logic ile daha ayrıntılı yönetmek isteyenler için doğal bir platformdur. Basit SPA ile bile Cloudflare’in edge gücünü arka planda daha çok hissedersiniz.
• Vercel / Netlify: Eğer revalidation ve fonksiyonlar tek bir platform ekosistemi içinde hızlı tüketilecekse avantaj sağlar.

Net tercih ölçütü: “Edge cache kontrolü, özel header’lar, düşük gecikme ve WAF/Access gibi Cloudflare bileşenleriyle uyum” istiyorsanız Cloudflare Pages daha doğru rotadır.

Senaryo 3: Form, webhook, doğrulama gibi dinamik ihtiyaçlar

Her platformta form gibi işlerde genellikle serverless/edge fonksiyon kullanılır. Burada fark yaratan konu “dinamik işlerin maliyeti ve ölçeklenmesi”dir. - Vercel: Fonksiyon çağrısı ve bant genişliği maliyetleri planlara göre değişir. Yoğun form trafiği bekleyen projelerde ölçüm şarttır. - Netlify: Fonksiyonlar ve entegrasyonlar hızlı kurgulanır. Özellikle statik site üretiminde akıcıdır. - Cloudflare Pages: Workers ile dinamik işleri edge’de yürütme imkanı, özellikle küçük fakat yüksek frekanslı işlemlerde verimli olabilir.

Net tercih ölçütü: Dinamik iş hacmi öngörülebilir değilse, önce küçük bir ölçüm/prototip ile fonksiyon çağrı maliyetini hesaplamak gerekir. JAMstack platformunda “sabit hosting bedeli” beklentisi kurmak doğru olmaz.

JAMstack’te performansı belirleyen 7 teknik kontrol

Platform seçmeden önce, performansın hangi bileşenlerle oluştuğunu netleştirelim. Aşağıdaki maddeler, Vercel/Netlify/Cloudflare Pages fark etmeksizin test edilebilir.

1) Derleme türü: static export mu, SSR mi?

• Tam statik (static build): CDN üzerinden en hızlı teslim edilir.
• SSR/ISR benzeri: Daha esnek ama daha fazla cache ve uygulama mantığı gerekir.

Net kontrol: Projeniz “derleme zamanında veri çekebilir mi?” sorusunu yanıtlayabiliyorsa statik yaklaşım daha ucuz ve daha hızlı olur.

2) CDN cache kontrolü (cache-control)

Dinamik endpoint’ler hariç, sayfa çıktılarında uygun cache-control değerleri kritik.

Net kontrol: - Uzun yaşayan sayfalarda max-age mantığı - Sık güncellenen içerikte revalidate/invalidasyon yaklaşımı - Görüntülenen “preview” ortamlarında cache karışmaması

3) Görsel optimizasyonu (image pipeline)

Statik üretim kullanan projelerde görsel boyutları ve formatlar (modern formatlar) belirleyici.

Net kontrol: - Otomatik srcset/resize - WebP/AVIF çıktıları - Lazy-load stratejisi

4) Üçüncü taraf script yönetimi

Tag manager, analytics, chat widget gibi scriptler LCP’yi etkiler.

Net kontrol: - Scriptleri geciktirme (defer/async değil, konuma göre) - Kritik yol (critical path) dışına taşıma - Cookie/consent ile bloklama

5) Edge fonksiyonlarının maliyeti

JAMstack’te “fonksiyon çağrısı” çoğu zaman gerçek maliyet kalemidir.

Net kontrol: - Form submit: her gönderimde 1-2 çağrı mı oluyor? - Middleware: her sayfa isteğinde mi tetikleniyor? - Rate limit uygulanıyor mu?

6) DNS ve domain doğrulama süreci

Domain bağlamak sadece “A kaydı” değildir. Platformun doğrulama yöntemi (CNAME/ALIAS) TLS sertifikası yayınını etkiler.

Net kontrol: - DNS kayıtlarının yayılma süresi - HTTPS’in ne zaman aktif olduğu - Alt domainlerde davranış

7) Güvenlik başlıkları ve uygulama katmanı

Bir JAMstack projesi statik olsa bile güvenlik katmanları önemlidir.

Net kontrol: - CSP (Content-Security-Policy) - HSTS - X-Content-Type-Options - Redirectlerin doğruluğu

Domain + TLS (HTTPS) yönetimi: pratik farklar

JAMstack platformlarının çoğu “otomatik TLS” sağlar. Ancak pratikte farkı oluşturan şey: - TLS ne zaman aktif oluyor (deploy ile senkron mu, DNS sonrası mı) - Redirect zinciri var mı (www/non-www) - Alt path’lerde (örn. /app) cache ve routing davranışı

Net öneri: 1. Mümkünse tek bir standart URL seçin: ör. www.example.com. 2. Platformun redirect ayarlarını kullanarak HTTP -> HTTPS ve non-www -> www dönüşümünü tek adımda tamamlayın. 3. robots.txt ve sitemap güncellemesini yayın akışına bağlayın.

Gizli anahtarlar (secrets) ve ortam (env) ayrımı

JAMstack projelerinde API anahtarları veya webhook secret’ları environment değişkenleriyle tutulur.

Net çalışma kuralı

• Preview environment için ayrı secret kullanın veya erişimi sınırlandırın.
• Prod ile aynı dış servislere (ör. ödeme sağlayıcı) preview’dan istek atmayın.

Test sonucu ne olmalı?

• Preview ortamında test e-postaları gerçekten test alıcılarına gidiyor olmalı.
• Prod gizli anahtarları yalnızca prod branch’inde erişilebilir olmalı.

Bu yaklaşım; platform fark etmeksizin güvenlik riskini düşürür ve beklenmedik maliyetleri engeller.

Fiyatı doğru okumak: “hosting” değil, “kullanım”

Vercel/Netlify/Cloudflare Pages tarzı JAMstack platformlarında maliyet genellikle sabit bir paket gibi görünmez. Şu kalemler bütçeyi etkiler: - Bant genişliği (bandwidth) - Build/preview sayısı (sık PR açan ekiplerde belirginleşir) - Fonksiyon/Workers çağrısı - Add-on’lar (log, cron, form arka uçları, görüntü optimizasyonu)

Net kontrol listesi: - Son 30 günde tahmini aylık trafik (sayfa görüntüleme) - Ortalama sayfa başına KB/MB (resimler, scriptler) - Ortalama fonksiyon çağrısı: ör. form submit = 1 çağrı mı? - Preview kullanımı: PR adedi x preview süresi

Hangi platform hangi projeye daha uygun? (net öneriler)

Aşağıdaki seçim, karar vermeyi kolaylaştırmak için doğrudan eşleştirme yapar.

Vercel seçin, eğer:

• Next.js/React ekosistemi ağırlıklıysa
• PR bazlı preview ve hızlı ekip akışı öncelikse
• Dinamik ihtiyaçlarınızı platformun fonksiyon modeline yakın tutacaksanız

Netlify seçin, eğer:

• Statik üretim + kullanıma hazır iş akışları (CMS entegrasyonları, deploy kolaylığı) arıyorsanız
• Form/webhook gibi dinamik bileşenleri “ekosistem içinde” yönetmek istiyorsanız
• Ekip süreçleri hızlı ayarlanmalı ama çok karmaşık edge mantığı beklenmiyorsa

Cloudflare Pages seçin, eğer:

• Edge kontrolü (cache, header, routing) ve Cloudflare katmanlarından faydalanma hedefiniz varsa
• Workers ile dinamik işlemleri edge’de yürütmeyi planlıyorsanız
• Performans ve güvenlikte (WAF/Access gibi) Cloudflare ekosistemini daha aktif kullanmak istiyorsanız

Sonuç: Kararı testle netleştirin, sonra platformu sabitleyin

Vercel, Netlify ve Cloudflare Pages arasında “tek doğru” yok; farkı belirleyen şey projenizin derleme modeli, dinamik istek hacmi ve cache/edge kontrol ihtiyacı. Aksiyon önerisi: Önce mevcut repo’nuzdan küçük bir sürüm çıkarın, her platformda aynı metrikleri ölçün (LCP/TTFB, fonksiyon çağrı sayısı, preview maliyeti ve cache davranışı). Sonuçlarınız “dinamik işlem çağrısı mı ağırlıkta, yoksa statik teslim mi?” sorusunu netleştirdiğinde, platform seçimi tartışma olmaktan çıkar ve bütçe/perf dengesi oturur.

İsterseniz kullandığınız framework (Next.js, Nuxt, SvelteKit, React SPA), tahmini aylık ziyaret ve dinamik fonksiyon türlerini yazın; bu üç platform için daha net bir seçim kriteri listesi çıkarayım.