1. Performans Regresyonu Nedir?
Regresyon; yeni sürümle birlikte performansın kötüleşmesidir. Kötüleşme bazen sayfa açılışında (LCP), bazen etkileşimde (INP), bazen backend tarafında (TTFB/p95) görünür. En kritik nokta: regresyonu “gerçek kullanıcı etkisi”yle ilişkilendirmek ve “gürültü”yü ayıklamaktır (trafik değişti mi, bot arttı mı, kampanya mı başladı?). Bu yüzden deploy sonrası site yavaşladı sorusu yalnız operasyonel bir şikayet değil, web ve yazılım kalite kontrolünün parçasıdır.
Soru : Performans regresyonu nedir, nasıl tespit edilir?
Cevap: Performans regresyonu, yeni sürümle birlikte TTFB/p95 response veya CWV (LCP/INP) gibi metriklerin anlamlı ölçüde kötüleşmesidir. Tespit için eski sürüm–yeni sürüm kıyası (aynı senaryo) yapılır; ardından prod’da RUM ile doğrulanır.
Ne yapmalıyım?
- • “Hissettim” yerine “metrik” konuş: TTFB/p95/CWV.
- • Kıyas testini aynı senaryoda koş: eski vs yeni.
- • Prod’da RUM ile doğrula; synthetic tek başına yeterli değil.
2. Hangi Metrikleri Takip Etmeliyiz? (TTFB, Response Time, CWV)
Varsayılan metrik seti, hem backend hem frontend’i kapsamalı. Bu yüzden üç katman önerilir:
- •Server: TTFB ve p95 response
- •Client: CWV (LCP, INP; gerekirse CLS)
- •Akış: kritik adım süreleri (search→detail→checkout gibi)
Core Web Vitals tarafında kötüleşmeyi görünür kılmak için CWV regresyon kontrolü yaklaşımıyla hız, crawl sağlığı ve teknik SEO etkisi birlikte okunmalıdır.
Eski ve yeni sürüm karşılaştırmalarını karar verilebilir hale getirmek için performans test sonuçlarının raporlanması standardı kurulmalı; dashboard, release marker ve trend takibi aynı yapıda izlenmelidir.
Pratik eşik (threshold) yaklaşımı (varsayımsal)
Varsayım: Her projenin hedefi farklıdır; aşağıdaki eşikler “başlangıç çerçevesi”dir, trafik/altyapıya göre kalibre edilir.
- •TTFB: yeni sürüm eskiye göre %10’dan fazla kötüleşmesin
- •p95 response: yeni sürüm eskiye göre %15’dan fazla kötüleşmesin
- •LCP/INP: yeni sürüm eskiye göre anlamlı ve sürekli kötüleşmesin (trend + p75 RUM)
Metriklerin “nerede” izlendiği
- •CI/CD aşaması: synthetic ölçümler
- •Staging: kıyas + yük testleri
- •Prod: RUM + server metrics + error rate
Ne yapmalıyım?
- • “Ortalama” yerine p95/p75 gibi kuyruk metriklerine odaklan.
- • CWV’yi release kapısına bağla (SEO/UX etkisi).
- • Eşikler koy; eşik yoksa “regresyon” tanımı muğlak kalır.
3. Otomatik Testler ve Load/Stress Senaryoları
Regresyon test kültürü; bir kere kurulur, sonra otomasyona bağlanır. Burada iki yaklaşım birlikte çalışır: düzenli release öncesi kontrollerin düzenli performans bakım kontrolü olarak bakım planına bağlanması ve yeni sürümlerde yeni sürüm sonrası performans kıyaslaması disiplininin standart hale gelmesi.
- •Synthetic (otomatik kıyas testleri): hızlı, tekrarlanabilir
- •Load/Stress: kapasite ve kırılma noktalarını görür
- •RUM: gerçek kullanıcı etkisini doğrular
Kıyas testi (önceki sürüm vs yeni sürüm) nasıl yapılır?
- •Aynı senaryo, aynı veri seti, aynı ortam koşulu
- •Eski sürüm için baseline alınır
- •Yeni sürüm aynı koşulda ölçülür
- •Fark: yüzde değişimle raporlanır (delta)
Load ve stress senaryoları ne zaman gerekli?
- •Trafik/hacim yüksekse (otel sezon, B2B rapor/export yoğunluğu)
- •Kritik akışlar “bir anda” yükleniyorsa
- •Yeni sürümde cache/DB/index değiştiyse
| Akış | Metrik | Eşik | Araç | Sıklık | Sorumlu |
|---|---|---|---|---|---|
| Otel: arama → oda detay → fiyat → rezervasyon | TTFB, p95 response, LCP, INP | TTFB: %10, p95 response: %15, LCP/INP: trend + p75 RUM | Synthetic + load/stress + RUM | Sezon öncesi + release öncesi | TBD |
| B2B: login → dashboard → filtre → rapor/export | p95 response, INP, long tasks, API latency | p95 response: %15, LCP/INP: trend + p75 RUM | Synthetic + load/stress + RUM | Çeyreklik release öncesi | TBD |
Soru : Load test ve gerçek kullanıcı verisini (RUM) birlikte nasıl kullanırım?
Cevap: Synthetic test ile release öncesi kıyas ve eşik kontrolü yapın; load/stress ile kapasite sınırlarını görün. Prod’da RUM ile p75 LCP/INP ve akış sürelerini izleyerek regresyonun gerçek kullanıcıya etkisini doğrulayın.
Ne yapmalıyım?
- • CI’de “perf gate” koy: eşik aşılırsa build fail.
- • Yük senaryosunu sezon/çeyrek öncesi zorunlu yap.
- • Prod’da release marker ile RUM trendini okunur kıl.
4. Otel ve B2B İçin Örnek Kullanım
Performans testinin değeri; kritik akışları doğru seçmekle başlar. “Her sayfayı test edelim” gerçekçi değildir; en fazla değer üreten akışlar seçilmelidir. Özellikle otel projelerinde load stress test planı sezon öncesi teknik hazırlığın zorunlu parçası olmalıdır.
Otel: rezervasyon/arama adımlarında perf kontrolü
- •Ana sayfa → arama → oda detay → fiyat görüntüleme → rezervasyon motoru yönlendirme
- •Metrikler: TTFB, p95, LCP/INP, redirect süreleri
- •Sezon öncesi: yük senaryosu (yoğun saat simülasyonu)
B2B: dashboard ve rapor/export akışı
- •Login → dashboard → filtre → rapor üretme/export
- •Metrikler: p95 response, INP, long tasks, API latency
- •Çeyreklik release öncesi: stres testi + caching davranışı
Key Statistics / Data Point (yumuşatılmış): Performans regresyon testlerini release sürecine dahil eden kurumlarda, yeni özelliklerin CWV ve kullanıcı deneyimine olumsuz etkisinin daha az raporlanması daha olasıdır; çünkü regresyonlar daha erken yakalanır. Üstelik yavaş sayfaların form, lead ve rezervasyon üzerindeki etkisini yavaşlamanın satış dönüşüm etkisi üzerinden okumak, teknik bulguları iş etkisine çevirmeyi kolaylaştırır.
Ne yapmalıyım?
- • “Kritik akış listesi”ni kilitle (otel: rezervasyon; B2B: rapor/portal).
- • Kıyas testlerini baseline mantığıyla koş.
- • Regresyon aksiyon planını release runbook’ına ekle.
5. Performans Regresyon Testi & Karşılaştırma Şablonunu İndir — Yazılım / Perf Regression (v1.0)
Performans Regresyon Testi & Karşılaştırma Şablonunu İndir — Yazılım / Perf Regression (v1.0)
Bu şablon; kritik akışlar için eski sürüm–yeni sürüm performans kıyasını standartlaştırır, TTFB/p95/CWV metriklerini tek formatta toplar ve eşik aşımlarında aksiyon (optimize/rollback/release durdur) kararını netleştirir. Synthetic + load/stress test ve RUM doğrulamasını aynı plan içinde birleştirerek “hissedilen yavaşlık” tartışmasını veriye çevirir.
Kim Kullanır?
Tech lead + QA/perf sorumlusu + PM (release kapısı için).
Nasıl Kullanılır?
- Kritik akışları seç ve baseline (eski sürüm) ölçümlerini al.
- Yeni sürümde aynı senaryoyu koş; delta ve eşik aşımını raporla.
- Prod’da RUM ile doğrula; gerekiyorsa rollback/optimizasyon planını uygula.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Kritik akış listesi net (otel: arama/rezervasyon; B2B: dashboard/rapor-export)
- ▢ ✅ Baseline sürüm etiketi alındı (v_prev)
- ▢ ✅ Yeni sürüm etiketi alındı (v_new)
- ▢ ✅ Metrikler seçildi: TTFB, p95 response, LCP, INP (opsiyonel CLS)
- ▢ ✅ Eşikler tanımlandı (delta % veya mutlak)
- ▢ ✅ Test türleri seçildi: synthetic + load/stress + RUM doğrulama
- ▢ ✅ Release gate kuralı yazıldı (eşik aşılırsa durdur/rollback)
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
6. Competitor Gap’i Kapatan “Performans Regresyon Modeli”
TR’de performans çoğu zaman PageSpeed “skoru”na indirgenir; oysa regresyon yönetimi, sürüm kıyası ve akış bazlı ölçüm ister. Bu rehberin farkı; TTFB+p95+CWV seti, eski-yeni kıyas yaklaşımı ve RUM vs synthetic birlikteliğini operasyonel bir modele dönüştürmesidir. Bu süreci kalıcılaştırmak için Bakım ve Destek hizmetiyle performans regresyon riskini kontrol edin; uygulama kapsamı ve süreç detayları için Bakım ve Destek hakkında sık sorulan sorular sayfasına da göz atabilirsiniz.
Bir Sonraki Adım
Yeni sürümlerin CWV ve kritik akış performansını bozmadan yayınlamak isteyen otel ve B2B ekipleri için.