Web Sitesi CMS Seçiminde Teknik Performans Testleri

Bir CMS (WordPress, Drupal, Joomla, headless/composable, SaaS) seçerken performans; yalnızca “ana sayfa Lighthouse skoru”ndan ibaret değildir. Gerçek performans, gerçek kullanıcı davranışı ve gerçek altyapı koşulları altında, tekrarlanabilir metodlarla ölçülmüş performanstır. Bu nedenle doğru karar, yalnızca “özellik listesi” veya “demo hissi” ile değil; standartlaştırılmış test senaryoları, kabul kriterleri, SLO’lar (Service Level Objective), ölçüm-izleme panoları, yazılı runbook’lar, istatistiksel karşılaştırma ve maliyet etkisiyle verilir.
Bu yazıda bir CMS seçim sürecinde teknik performans testleri için uçtan uca bir çerçeve sunuyoruz: metrik taksonomisi (LCP/INP/CLS/TTFB/P95/P99), RUM ve sentetik test mimarisi, yük/gerilim/kalıcılık testleri, cache katmanları ve CDN etkisi, SSR/SSG/headless farkları, çok dilli ve çoklu site senaryoları, veritabanı ve arama yükleri, üçüncü taraf entegrasyon gecikmeleri, medya boru hattı, coğrafi gecikme, taşıma (migration) etkileri, SEO ve erişilebilirlik ile kesişim, maliyet-performans eğrileri, kabul kapıları (gates) ve raporlama. Her alt bölüm, uygulanabilir checklist, örnek senaryolar, vaka çalışmaları ve müşteri sunumuna girecek formatta sonuç üretmenize yardımcı olacak pratiklerle gelir.
1) Performans Ölçüm Taksonomisi: Hangi Metrik Ne Anlatır?
Amaç: Elma ile armudu kıyaslamamak.
-
Kullanıcı odaklı (field/RUM): LCP (Largest Contentful Paint), INP (Interaction to Next Paint), CLS (Cumulative Layout Shift).
-
Ağ/işlem odaklı: TTFB, P95/P99 yanıt süresi, başarısızlık oranı (5xx/4xx), edge hit ratio.
-
İş odaklı: Form gönderim süresi, ödeme akışı adım süreleri, arama sonuç yanıtı.
Checklist: Proje için hedef metrik listesi + hedef değerler (örn. LCP < 2.5s, INP < 200ms, CLS < 0.1; P95 yanıt < 800ms; 5xx < %0.5).
2) Test Mimarisini Kurmak: RUM + Sentetik, Birlikte
-
RUM (Gerçek Kullanıcı): Gerçekte kim, nereden, hangi cihazla ne hız görüyor? Kritik; ama kontrol edilmesi zor.
-
Sentetik: Kontrollü laboratuvar; “önce/sonra” değişim etkisini net ölçer.
-
Kural: RUM gerçeği gösterir, sentetik sebebi ve düzeltme etkisini kanıtlar.
Uygulama: RUM kitaplığı + Lighthouse/WebPageTest/k6/Playwright ile “ikili yapı”.
3) Kabul Kriterleri (SLO/Olasılık Dağılımı ile)
Amaç: Ortalama yerine P95/P99 ile gerçek kullanıcı kuyruğunu yönetmek.
-
Örnek SLO: P95 TTFB < 600ms (TR, DE), P95 LCP < 2.5s (mobil), 5xx < %0.3, edge hit > %85.
-
Kıyas: Aday CMS’ler aynı senaryo, aynı veri, aynı coğrafya altında ölçülür.
Not: P95 değerlerini ister istemez “outlier temizliği” yapmadan kabul edin; gerçek hayatta uç değerler önemlidir.
4) Test Verisi ve İçerik Modeli: “Boş Sayfa” Yanıltır
-
Gerçekçi seed: 5.000–50.000 içerik, 10–20 içerik türü, 3–5 taksonomi, 1.000+ medya.
-
Sahte kullanıcı ve oturum: Oturumlu/oturumsuz oran; çok dilli içeriklerin dağılımı.
-
URL haritası: Kategori, ürün, arama, filtre, etiket, ana sayfa, içerik sayfası, form.
Checklist: Test öncesi seed raporu: içerik adedi, ortalama belge boyutları, görsel formatları.
5) Senaryo Kütüphanesi: 10 Temel Yol (Critical User Journeys)
-
Ana sayfa ilk yükleme (anonim)
-
İçerik sayfası (anonim)
-
Arama (site içi)
-
Filtreli liste (facet)
-
Form gönderimi (iletişim/kayıt)
-
Giriş (login) ve panel
-
Çok dilli sayfa geçişi
-
Görsel yoğun galeri
-
Sepet/ödeme (varsa)
-
Yönetici içerik oluşturma/kaydetme
Uygulama: Her yol için “başarı ölçütü + zaman hedefi + hata eşiği”.
6) Cache & CDN Stratejisi: Testte Adil Konfigürasyon
-
Edge cache:
stale-while-revalidate
,cache key
normalizasyonu (cookie/parametre etkisi). -
Uygulama cache: Tam sayfa vs. fragman; oturumlu kullanıcıda Dynamic/fragment cache zorunlu.
-
Bypass alanları: Admin, kişiselleştirme, arama sonuçları.
Test: Aynı CDN/aynı kurallar → CMS farkını adil izolasyon.
7) Yük Testi (Load): Hacim mi, Model mi?
-
Hacim (Throughput): İstek/saniye hedefi (RPS), eşzamanlı kullanıcı.
-
Model: Akış karışımı (%60 anonim sayfa, %20 arama, %10 form, %10 giriş).
-
Isınma (warm-up): Cache ısındırılmış ve ısındırılmamış testleri ayrı koşun.
Araç örnekleri: k6/JMeter (modelleme), Gatling; sonuçlar P95/P99 ve hata oranı ile raporlanır.
8) Gerilim (Stress) Testi: Nereye Kadar Dayanıyor?
-
Ramp-up: 5 → 50 → 500 eşzamanlı kullanıcı; saturasyon noktası belirleme.
-
Belirti: 5xx artışı, kuyruk dolumu (PHP-FPM), DB kilitleri, CDN hit düşüşü.
-
Eşikler: Saturasyon öncesi degrade gracefully planı (arama kaplama, görsel kalite düşürme, dinamik kısıtlama).
9) Kalıcılık (Soak) Testi: 4 Saatte Ne Olur?
-
Amaç: Bellek sızıntıları, log birikimleri, cron/kuyruk tıkanması, dosya kilitleri.
-
İzleme: CPU/IO, hafıza, DB bağlantıları, kuyruk uzunluğu, 5xx mikro artışları.
Vaka: 3. saatte kuyruk büyüyor → “zehirli mesaj” (aynı içerik) → idempotent işleyici düzeltildi.
10) Coğrafi ve Mobil Gerçekliği: 3G/4G/5G ve Farklı POP’lar
-
Ağ profilasyonu: 3G (Good)/4G (Typical)/Wi-Fi; packet loss simülasyonu.
-
POP seçimi: TR/DE/US gibi hedef pazarlarda CDN POP metrikleri (TTFB).
-
Cihaz: Düşük/orta segment mobil (CPU throttling) ile Lighthouse.
Rapor: “TR mobil 4G’de P95 LCP: 2.4s, DE Wi-Fi’de 1.8s”.
11) SSR/SSG/SPA/Headless Karşılaştırması
-
SSR (Server-Side Render): TTFB duyarlı; edge cache ile parıldar.
-
SSG (Static Site Generation): Olağanüstü hızlı; fakat içerik tazeleme SLA’sı önemli.
-
SPA + API: İlk boyama geç, etkileşim hızlı; INP kritik.
-
Headless CMS: API gecikmeleri ve çokkademeli cache tasarımı belirleyici.
Test: Aynı içerik akışını farklı mimarilerle ölçerek “ihtiyaç-uyum” analizi yapın.
12) Veritabanı ve Sorgu Profili
-
Slow query log aktif; P95 sorgu süresi, sorgu sayısı/sayfa.
-
İndeks stratejisi: Liste/arama için bileşik indeks; node/term join’leri.
-
Connection pool: Maks bağlantı, timeout, retry politikası.
Checklist: “P95 sorgu < 50ms, toplam sorgu < 40/sayfa, N+1 yok”.
13) Arama (Solr/Elasticsearch/DB) ve Facet Maliyeti
-
Kriter: Arama RTT (round-trip time), facet hesaplama süresi, indeks tazeleme gecikmesi.
-
Soak: Uzun testte heap/GC davranışı; replikasyon gecikmesi.
-
Degrade: Arama down ise “basit arama”ya düşme; kullanıcıya nazik mesaj.
14) Üçüncü Taraf Entegrasyonları: Ödeme, Kimlik, PIM/DAM, Analitik
-
Timeout/backoff: Her entegrasyon için sınır; circuit breaker.
-
Gölgeleme: Testte “gerçek sandbox” kullanın; stub değil.
-
Gecikme bütçesi: Toplam TTFB içindeki harici % pay.
Rapor: “Ödeme geçidi P95 420ms → TTFB’ye katkı %35”.
15) Medya Boru Hattı: Görsel/Video, Dönüştürme ve Teslim
-
Format: WebP/AVIF;
srcset/sizes
,preload
ve boyut sabitleme. -
CDN görüntü işleme: Dinamik kırpma/ölçekleme; orijinal kaynaklar tekilleştir.
-
Video: Adaptive streaming (HLS/DASH), poster görseli, lazy.
Test: Galeri sayfasında LCP/CLS ve veri transferi (KB/MB) kıyaslaması.
16) Core Web Vitals Odak Testleri
-
LCP testi: Hero görsel + kritik CSS;
preload
etkisi. -
INP testi: Tıklama/arama kutusu/filtre; event handler optimizasyonu.
-
CLS testi: Görsel oranları, reklam/3P yerleşim.
Kabul: “Öncesi/sonrası LCP farkı ≥ 400ms ise kabul”.
17) Çok Dilli ve Çoklu Site Senaryoları
-
Hreflang ve switcher etkisi: Ek JS/HTML yükü; INP ve CLS ölçümü.
-
Kopya içerik ve yönlendirme: 301 zinciri TTFB’yi artırır; testte tespit edin.
-
Çoklu site: Paylaşımlı cache anahtarları; yanlış varyant → edge hit düşer.
18) Erişilebilirlik (A11y) ve Performans Kesişimi
-
A11y kontrolleri (semantik başlıklar, odak yönetimi, ARIA) INP/CLS’yi olumlu etkiler.
-
Medya alternatifi ve transkript; ilk yükte şişmeyen UI.
Test: Axe/lighthouse a11y + CWV birlikte rapor.
19) SEO & Tarama Bütçesi ile Performans
-
Robots/sitemap/canonical hijyeni, noindex politikaları.
-
Render bütçesi: Bot’a sunulan sayfa boyutu, kritik JS miktarı.
-
Sayfalama/facet: Parametre patlaması → cache verimsizliği.
Rapor: “Facet parametreleri 4→2 indirildi; edge hit %72→%88”.
20) Test Otomasyonu ve CI/CD Gate’leri
-
Sentetik testler CI aşamasında; eşik aşılırsa dağıtım yok.
-
Görsel regresyon: Tema değişiklikleri.
-
SLA/SLO kontrolü: KR olarak panoya işlenir.
Pratik: “Main branch → Preview → Lighthouse + CWV bütçesi → Pull Request yorumunda sonuç.”
21) Maliyet–Performans Eğrileri (Cost Observability)
-
Birim maliyetler: RPS başına CPU/IO, bant genişliği, CDN egress, görüntü işleme.
-
Edge vs. Origin: Edge’i yükseltmek origin maliyetini nasıl düşürüyor?
-
Trade-off: Saniyede 1000 istek için LCP 300ms iyileştirme neye mal oluyor?
Çıkış: Karar matrisine maliyet/performans grafikleri.
22) Teklif/PoC Aşamasında Aday CMS’leri Kıyaslama
-
Standart “Pepsi Challenge”: Ortak seed içerik, aynı CDN, aynı test seti, aynı coğrafya.
-
Kritik akış A/B/C: Arama, filtre, form.
-
Rapor şablonu: Metrik tablosu + ısı haritası + risk notları + optimizasyon önerileri.
23) Taşıma (Migration) Sonrası Regresyon Testi
-
URL mirası: 1:1 yönlendirme haritası; TTFB/LCP değişimi.
-
Schema/structured data: Rich result kaybı var mı?
-
RUM trendi: 2–4 hafta gözlem; anormallik alarmı.
24) Olay (Incident) Testleri: “Kötü Gün” Provası
-
API yavaşladı → circuit breaker devreye girdi mi?
-
CDN POP çöküşü → otomatik reroute/başka POP?
-
Cache kirlenmesi → targeted purge çalıştı mı?
Runbook tatbikatı: 30 dakikalık masa üstü senaryo.
25) Raporlama: Yönetim Özeti ve Teknik Ek
-
Yönetim özeti: 1 sayfa; “CMS A = %22 daha iyi LCP, %34 daha iyi P95, edge hit +%12, maliyet –%9”.
-
Teknik ek: Test senaryoları, seed verisi, konfig, grafikleri, log bağlantıları.
-
Kapanış: “Hangi optimizasyonlarla bu skorlar daha da artar?” yol haritası.
Sonuç: Performans Testleri, CMS Kararının Bilimsel Dayanağıdır
CMS seçiminde performans testlerini ciddiye almak; “hızlı hissettiren” bir demo yerine, kanıtlanmış ve sürdürülebilir hız vadeden bir platforma karar vermek demektir. Bu yazıda sunduğumuz çerçeve—metrik taksonomisi, RUM + sentetik ikilisi, yük/gerilim/kalıcılık testleri, cache/CDN ve mimari farklar, veritabanı/arama/entegrasyon/medya odakları, coğrafi ve mobil gerçeklik, CWV/SEO/A11y kesişimi, CI kapıları ve maliyet-performans analizi—sayesinde, aday CMS’leri aynı sahne, aynı oyuncular, aynı kurallar ile karşılaştırabilir ve kararınızı istatistiksel güven ile savunabilirsiniz.
Önerimiz: Önce SLO hedeflerinizi yazın; sonra standart senaryo kütüphanesi ve seed veri seti ile “Pepsi Challenge” kurulumunu yapın. RUM + sentetik mimarisini aynı gün devreye alın; yük/gerilim/kalıcılık üçlüsüyle testleri tamamlayın. Son olarak maliyet-performans eğrisini çıkarıp yönetime ısı haritalı rapor sunun. Böylece CMS kararınız, duygu ve alışkanlıklarla değil; ölçü, kanıt ve yöntemle verilir.