İçindekiler
- 1 Neden Landing Page Kampanyaları İçin Özel Bir Hosting Mimarisi Gerekli?
- 2 Landing Page’i Doğru Parçalara Ayırmak: Önce Mimariyi Netleştirin
- 3 CDN ile Trafiği Edge’e Taşımak
- 4 Statik Export Stratejileri: WordPress, Next.js ve Diğerleri
- 5 Otomatik Ölçekleme ve Origin Mimarisi
- 6 Örnek Mimariler: Farklı Kampanya Tipleri İçin Yol Haritaları
- 7 Test, İzleme ve Operasyon: Trafik Gelmeden Önce Hataları Bulun
- 8 DCHost ile Uygulanabilir Yol Haritası
Neden Landing Page Kampanyaları İçin Özel Bir Hosting Mimarisi Gerekli?
Performansı iyi bir kurumsal siteniz olabilir, ama agresif bir reklam kampanyasıyla tek bir landing page’e on binlerce kullanıcıyı aynı anda taşıdığınızda, klasik barındırma kurguları çok hızlı şekilde sınırlarına dayanır. Özellikle sosyal medya ve arama motoru reklamlarında tıklama başına ödeme yaptığınız senaryolarda, her yavaşlayan sayfa yüklenmesi ve her 5xx hatası doğrudan boşa gitmiş bütçe anlamına gelir.
Bu yazıda DCHost ekibi olarak, pratikte en çok işe yarayan üç ana bileşen etrafında net bir mimari çerçeve çizeceğiz: CDN, statik export (tam veya hibrit statik yayın) ve otomatik ölçekleme. Amacımız; sadece “hızlı olsun” demek değil, aynı zamanda maliyeti kontrol altında tutan, yönetilebilir ve kampanya dönemi dışında da sürdürülebilir bir altyapı modeli önermek.
Anlatacağımız yaklaşımlar; WordPress tabanlı kampanya sitelerinden, Next.js/Nuxt veya tamamen özel yazılım landing page’lere kadar geniş bir yelpazede uygulanabilir. Daha önceki yoğun trafikli kampanyalar için hosting ölçeklendirme rehberi yazımızda genel stratejiyi ele almıştık; bu yazıda ise odağımızı özellikle landing page kampanyalarına ve bu üç bileşenin bir arada nasıl çalışacağına daraltıyoruz.
Landing Page’i Doğru Parçalara Ayırmak: Önce Mimariyi Netleştirin
Teknik çözümlere geçmeden önce, iyi bir landing page mimarisinin en önemli adımı; sayfanın hangi kısımlarının statik, hangilerinin dinamik ve hangilerinin üçüncü taraf servislerle ilişkili olduğunu ayırmaktır. Çünkü CDN, statik export ve otomatik ölçekleme kararlarının tamamı bu ayrım üzerinde yükselir.
1. Statik içerik katmanı
Şu öğelerin tamamı ideal olarak statik olmalıdır:
- HTML iskeleti (kampanya metinleri, başlıklar, görsellerin yerleşimi)
- CSS ve JavaScript dosyaları
- Logonuz, ikon setleriniz, arka plan görselleriniz
- Önceden bilinen, sık değişmeyen bileşenler (fiyat tabloları, özellik listeleri vb.)
Bu katman, mümkün olan en yüksek oranda CDN üzerinden ve tercihen statik export ile sunulursa, kampanya trafiğinin büyük kısmı zaten dinamik altyapıya uğramadan karşılanmış olur.
2. Dinamik işlemler katmanı
Şu öğeler ise genellikle dinamiktir ve backend veya üçüncü taraf servislerle iletişim kurar:
- Form gönderimleri (lead toplama, demo talebi, kayıt formları)
- Gerçek zamanlı fiyatlandırma veya stok bilgisi
- Giriş yapmış kullanıcılara özel içerikler
- Kişiselleştirilmiş A/B test varyantlarının sunumu
Bu katman, hem ölçeklendirme hem de güvenlik açısından ayrı düşünülmeli, mümkünse API veya küçük, odaklı backend servisleri şeklinde tasarlanmalıdır. Böylece landing page’in kendisi çok agresif cache’lenirken, dinamik kısım için daha kontrollü bir ölçekleme politikası uygulanabilir.
3. Üçüncü taraf entegrasyonları
Analytics, piksel kodları, heatmap araçları, canlı sohbet widget’ları gibi üçüncü taraflar, sayfa performansını ciddi biçimde etkileyebilir. Bu nedenle:
- Bu script’leri async/defer ile yüklemek,
- Özellikle AB test ve izleme kodlarının kritik içerikten sonra yüklenmesini sağlamak,
- Mümkün olan yerlerde self-hosted alternatifleri değerlendirmek (örneğin Matomo gibi self-hosted analytics çözümleri)
hem hız hem de veri kontrolü açısından büyük avantaj sağlar.
CDN ile Trafiği Edge’e Taşımak
Landing page kampanyalarında en hızlı ve en ucuz performans kazanımı neredeyse her zaman CDN kullanımı ile gelir. Özellikle global reklam kampanyalarında, ziyaretçiye fiziksel olarak yakın edge noktalarından içerik sunmak; TTFB’yi (Time To First Byte) düşürür, Core Web Vitals metriklerini iyileştirir ve backend yükünü dramatik biçimde azaltır.
CDN kavramına aşina değilseniz, önce CDN nedir, ne zaman gerekir? yazımıza göz atmanızı öneririz. Burada ise doğrudan landing page odaklı CDN stratejilerine girelim.
Hangi içerikler mutlaka CDN üzerinden gitmeli?
Yüksek trafikli kampanya dönemlerinde aşağıdaki dosya tiplerinin tamamı CDN’e taşınmalıdır:
- HTML (özellikle tam statik veya SSG üretilmiş landing page’ler)
- CSS ve JS paketleri (bundle’lar)
- Görseller (özellikle hero görselleri, arka planlar ve ürün fotoğrafları)
- Font dosyaları (mümkünse self-hosted web font yaklaşımı ile)
- Video yoksa da hero video poster’ları ve küçük animasyonlar
Statik dosyaları doğrudan DCHost üzerindeki origin’den sunmak yerine, CDN önbelleği sayesinde “sıcak” durumda tutmak, özellikle anlık trafik patlamalarında sunucu kaynaklarını ciddi şekilde rahatlatır.
Cache-Control, sürümleme ve cache busting
CDN’in faydasını en üst seviyeye çıkarmak için HTTP cache başlıklarını doğru kullanmak şarttır:
- CSS/JS/Görseller için:
Cache-Control: public, max-age=31536000, immutablegibi uzun süreli cache başlıkları ve dosya adında sürüm parametresi (ör.app.v3.4.1.js). - HTML için: Kampanya süresine göre daha kısa ama yine agresif sayılabilecek
max-agedeğerleri (ör. birkaç dakika) ve gerektiğinde purge / cache bypass mekanizmaları. - Kritik güncellemelerde, dosya adını veya query string değerini değiştirerek cache busting stratejileri uygulamak.
Bu sayede, kampanya ortasında tasarım güncellerken eski dosyaların bazı kullanıcılarda “takılı kalması” sorununu yaşamaz, aynı zamanda CDN hit oranını yüksek tutarsınız.
stale-while-revalidate ve stale-if-error ile kesintiye dayanıklılık
Landing page’ler için çok faydalı bir diğer mekanizma da stale-while-revalidate ve stale-if-error gibi direktiflerdir. Detaylı olarak stale-while-revalidate ve stale-if-error yazımızda anlattığımız gibi:
- Origin kısa süreli sorun yaşasa bile, CDN kenarda tuttuğu “eski ama yeterince yeni” kopyayı sunmaya devam eder.
- Bu da özellikle TV reklamı, influencer kampanyası gibi yoğun trafiğin tek bir anda patladığı senaryolarda hayat kurtarır.
CDN tarafında bu başlıkları etkinleştirmek, landing page kampanyalarını gerçek anlamda “kesintiye dayanıklı” hale getirmenin basit ama etkili yollarındandır.
Statik Export Stratejileri: WordPress, Next.js ve Diğerleri
CDN tek başına büyük kazanım getirir, ancak landing page’in kendisini de statik export</strong ile sunabildiğinizde etki katlanarak artar. Çoğu kampanya sayfasında; sayfanın iskeleti, metinleri ve görselleri kampanya süresince çok nadir değişir. Bu nedenle bu içeriği her istekte PHP veya Node.js üzerinden yeniden üretmek aslında gereksiz maliyettir.
WordPress tabanlı landing page’ler için statik yaklaşım
WordPress ile hazırladığınız bir kampanya sayfasını, yayın öncesinde statik HTML’e export eden eklentiler veya CI/CD akışları kullanmak oldukça etkilidir:
- Canlı WordPress kurulumu yönetim, içerik girişi ve revizyonlar için kullanılır.
- Yayın aşamasında yalnızca ilgili landing page (veya küçük bir sayfa grubu) statik HTML + asset’ler halinde build edilir.
- Bu statik çıktı, DCHost üzerindeki bir statik hosting ya da hafif bir web sunucusu (Nginx/Apache) ve CDN kombinasyonu ile servis edilir.
WordPress’i tamamen statik kullanma fikri size yakın geldiyse, statik site hosting rehberi yazımızdaki Jamstack ve CDN odaklı yaklaşımları da incelemenizi öneririz.
Next.js, Nuxt ve modern framework’lerde SSG/ISR
Next.js, Nuxt gibi framework’ler, zaten statik site üretimi (SSG) ve incremental static regeneration (ISR) gibi mekanizmaları çekirdeklerinde barındırır. Zaten yayınladığımız Next.js ve Nuxt için doğru hosting mimarisi rehberimizde bu konuyu detaylandırdık. Landing page kampanyaları özelinde özetle şunları önerebiliriz:
- Landing page URL’lerini SSG ile üretin: Build aşamasında HTML çıktıları oluşturulup CDN’e dağıtılabilir.
- ISR kullanın: Çok sık güncellenmeyen ama yine de ara sıra değişen içerikler için arka planda re-generate mekanizması kullanmak, hem performans hem de içerik tazeliği sağlar.
- Form ve dinamik aksiyonları API route’lara taşıyın: Böylece sayfa tamamen statik kalırken, yalnızca POST istekleri backend’e veya üçüncü taraf servislere gider.
Formlar, A/B testleri ve kişiselleştirme için hibrit yaklaşım
“Her şeyi statik yapmak istiyoruz ama form gönderimleri, A/B test ve kişiselleştirme ne olacak?” sorusu çok doğal. Burada tipik yaklaşım:
- Sayfanın gövdesini ve görsel bileşenleri tamamen statik tutmak,
- Form gönderimlerini, hafif bir backend API veya üçüncü taraf form servisine yönlendirmek,
- A/B testleri için edge-side include, cookie tabanlı varyant seçimi ya da client-side render gibi yöntemleri tercih etmek,
- Kişiselleştirme gerektiren senaryolarda, yalnızca kritik kısımları dinamik yükleyen küçük JS modülleri kullanmak.
Böylece landing page’in %90’ı CDN’den ve statik export’tan gelirken, yalnızca gerçekten zorunlu olan ufak bir bölüm dinamik origin’e ihtiyaç duyar.
Otomatik Ölçekleme ve Origin Mimarisi
CDN ve statik export, origin (asıl sunucu) üzerindeki yükü büyük ölçüde alır. Ancak dinamik aksiyonlar, API istekleri ve yönetim panelleri için yine de güçlü ve doğru tasarlanmış bir origin katmanına ihtiyacınız vardır. İşte burada devreye otomatik ölçekleme ve doğru sunucu seçimi girer.
Paylaşımlı hosting mi, VPS mi, dedicated mı?
Landing page kampanyalarında genellikle şu model daha sağlıklıdır:
- Küçük ölçekli, yalnızca birkaç bin ziyaretçi beklenen kampanyalar için güçlü bir paylaşımlı hosting veya giriş seviyesi VPS yeterli olabilir.
- Orta ve büyük çaplı kampanyalarda ise, en azından landing page origin’i ve API katmanı için özel VPS tercih etmenizi öneririz.
- Çok büyük bütçeli, TV reklam destekli kampanyalarda ise dedicated sunucu ya da birden çok VPS’ten oluşan ölçekli bir küme daha gerçekçidir.
Bu noktada dedicated sunucu mu VPS mi? karşılaştırma yazımız, hangi eşiğe geldiğinizde hangi mimariye geçmeniz gerektiğini netleştirmenize yardımcı olabilir.
Otomatik ölçekleme için altyapı prensipleri
Gerçek anlamda otomatik ölçekleme (auto scaling) uygulayabilmek için, uygulamanızın şu özelliklere sahip olması gerekir:
- Stateless uygulama katmanı: Kullanıcı oturumları, cache ve yük yüklenmiş dosyalar tek bir sunucuya bağlı olmamalı; Redis, veritabanı veya object storage gibi dış sistemlerde tutulmalı.
- Veritabanı ile uygulamanın ayrılması: Uygulama katmanı yatay olarak çoğalırken, veritabanı ayrı bir sunucuda (veya çoğaltılmış yapıda) çalışmalı.
- Otomatik deploy ve versiyonlama: Yeni bir VPS eklendiğinde, kodu otomatik olarak çeken ve environment değişkenlerini alan bir pipeline olmalı.
- Health-check ve load balancer: Trafiği birden fazla VPS veya sunucuya dağıtacak bir load balancer ve sağlık kontrolleri (health-check) gereklidir.
DCHost tarafında; ölçeklenebilir VPS kümeleri, load balancer kurguları ve gerektiğinde dedicated sunucu + VPS hibrit mimarileriyle bu gereksinimleri birlikte tasarlayabiliyoruz. Önemli olan; kampanya başlamadan önce sınırları görmek ve trafik patlaması geldiğinde değil, gelmeden önce planlamayı bitirmiş olmak.
Örnek Mimariler: Farklı Kampanya Tipleri İçin Yol Haritaları
Senaryo 1: Orta ölçekli, dijital ağırlıklı kampanya
Örneğin yalnızca sosyal medya ve arama motoru reklamları ile günde 10–30 bin ziyaretçi beklenen bir kampanya düşünelim. Burada efektif ve maliyet kontrollü bir mimari şöyle olabilir:
- Landing page: Next.js ile SSG üretilmiş, DCHost üzerinde statik olarak host edilen ve global CDN ile dağıtılan HTML/asset’ler.
- Form gönderimleri: Küçük bir DCHost VPS üzerinde çalışan hafif bir API servisine (örneğin Node.js veya PHP) POST edilir.
- Veri saklama: Aynı VPS üzerindeki veritabanında veya harici bir CRM entegrasyonunda tutulur.
- Otomatik ölçekleme: Trafik artarsa, API VPS’lerini çoğaltıp bir load balancer arkasına almak üzere hazırlıklı bir mimari kurulur.
Bu senaryoda, kampanya bütçesiyle uyumlu, ama gerektiğinde kolayca yukarı çekilebilen bir yapı elde etmiş olursunuz.
Senaryo 2: TV reklamı destekli, yüksek hacimli kampanya
Bu kez, prime time’da TV reklamı yayınlanan ve birkaç dakika içinde on binlerce eşzamanlı kullanıcı bekleyen agresif bir kampanyayı ele alalım:
- Landing page: Tamamen statik export + CDN. HTML, CSS, JS, görsellerin tamamı edge’lerde önbellekte hazır.
- Form gönderimi: En az 2–3 adet DCHost VPS’ten oluşan bir API katmanı. Uygulama stateless, session’lar Redis gibi dış bir store’da tutuluyor.
- Veritabanı: Ayrı bir veritabanı sunucusu (VPS veya dedicated), mümkünse read-replica ile yüksek okuma yüküne dayanıklı.
- Load balancer: API VPS’leri arasında oranlı dağıtım yapan, health-check’li bir load balancer katmanı.
- CDN ayarları: HTML için
stale-while-revalidate, asset’ler için uzun süreli cache, agresif optimizasyon.
Böyle bir yapıda, TV reklamı ile birlikte gelen ani trafik dalgasının büyük kısmı CDN tarafından karşılanır; geriye kalan nispeten küçük dinamik yük ise ölçeklenebilir VPS kümesi tarafından karşılanır.
Senaryo 3: WordPress ile hızlı hazırlanan, kısa ömürlü kampanya
Ajansların ve pazarlama ekiplerinin çok sevdiği senaryo: “Dün akşam karar verildi, iki hafta sonra kampanya başlıyor.” WordPress bu tip durumlar için pratik bir çözüm sunar, ancak doğru mimari kurulmazsa kampanya günü sorun çıkarabilir.
- Ön hazırlık: Landing page WordPress üzerinde hazırlanır, testler staging ortamında yapılır (bkz. WordPress staging ortamı kurma rehberi).
- Yayın: Kampanya yayına alınmadan hemen önce landing page statik export ile HTML+asset paketi olarak alınır ve DCHost üzerindeki statik hosting origin’ine deploy edilir.
- Form: Sadece form gönderimi için küçük bir PHP endpoint’i veya harici bir form servisi kullanılır.
- WordPress: Yönetim ve yeni versiyon hazırlıkları için kapalı devre veya parolalı bir subdomain’de tutulur.
Böylece WordPress’in esnekliğini kaybetmeden, kampanya süresince neredeyse Jamstack benzeri bir performans elde edilmiş olur.
Test, İzleme ve Operasyon: Trafik Gelmeden Önce Hataları Bulun
Doğru CDN, statik export ve otomatik ölçekleme kurgulandıktan sonra bile, gerçek dünyada her zaman sürprizler olabilir. Bu yüzden kampanya başlamadan önce mutlaka yük testi ve izleme kurgusunu tamamlamanız gerekir.
Load test ile sınırlarınızı görün
Gerçek trafik gelmeden önce, kurguladığınız mimarinin nerede zorlanacağını görmek için sentetik testler yapmak çok değerlidir. Bunun için k6, JMeter veya Locust gibi araçlarla trafik patlamasından önce load test uygulamanızı öneririz.
- Önce yalnızca landing page HTML + asset’ler için CDN hit oranını test edin.
- Daha sonra form gönderimlerini ve API uç noktalarını farklı senaryolarla zorlayın.
- Her adımda CPU, RAM, disk IO ve veritabanı sorgu sürelerini izleyin.
Bu testler sonucunda; daha fazla VPS mi, daha güçlü bir dedicated sunucu mu, yoksa veritabanı optimizasyonu mu gerektiğini somut verilerle görürsünüz.
İzleme (monitoring) ve alarm mekanizmaları
Kampanya sırasında “her şey yolunda mı?” sorusunun cevabını görmek için, en azından şu metrikleri izlemenizi öneririz:
- CDN tarafında: Cache hit oranı, edge konumlarına göre yanıt süreleri, 4xx/5xx hata oranları.
- Origin tarafında: CPU, RAM, disk IO, network bant genişliği, aktif bağlantı sayıları.
- Veritabanı: Sorgu süresi ortalamaları, yavaş sorgu (slow query) sayısı, bağlantı havuzu doluluk oranı.
- Uygulama içi: Hata logları, istisnalar, form gönderim başarısızlık oranları.
DCHost altyapısı üzerinde; uptime izleme, temel kaynak izleme ve log analizi için kurabileceğiniz sistemleri detaylı şekilde anlattığımız web sitesi uptime izleme ve alarm kurma rehberi de bu aşamada yol gösterici olacaktır.
DCHost ile Uygulanabilir Yol Haritası
Teoride her şey güzel görünebilir; asıl zorluk, bu mimariyi gerçek bir kampanya takvimi içinde hayata geçirmektir. DCHost olarak burada yaklaşımımız, tek bir “sihirli paket” satmak yerine; projeyi ve hedef trafiği birlikte analiz ederek adım adım bir yol haritası çıkarmak yönünde.
Tipik bir çalışma akışını şöyle özetleyebiliriz:
- Hedeflerin ve trafik senaryolarının netleştirilmesi: Beklenen günlük/ani trafik, kampanya süresi, pazarlama kanalları.
- Mevcut altyapının analizi: Şu anki hosting, CMS/framework, veritabanı ve bağımlılıklar.
- CDN ve statik export planı: Hangi URL’ler statik olacak, hangileri dinamik kalacak, cache politikaları nasıl kurgulanacak.
- Origin ve otomatik ölçekleme tasarımı: Kaç VPS, gerekirse hangi ölçekte dedicated sunucu, load balancer, veritabanı mimarisi.
- Load test ve ince ayar: Kampanya başlamadan önce sınırların görülmesi ve son düzeltmeler.
Elinizde WordPress, Laravel, Next.js veya tamamen özel geliştirilmiş bir landing page projesi olabilir; prensipler aynı, sadece uygulama detayları değişiyor. DCHost ekibi olarak; domain, hosting, VPS, dedicated sunucu ve gerekirse colocation tarafındaki tüm bileşenleri, kampanya takviminize uygun şekilde birlikte tasarlayıp devreye alabiliriz.
Eğer yakında büyük bir landing page kampanyası planlıyorsanız ve “Bu trafik load’ını kaldırır mıyız?” sorusu aklınızı kurcalıyorsa, en doğru zaman inceleme ve planlama aşamasıdır. Mevcut altyapınızı ve hedef kampanya senaryonuzu bizimle paylaşırsanız, CDN, statik export ve otomatik ölçekleme odaklı net, uygulanabilir bir mimari önerisini birlikte çıkarabiliriz.
