Türkiye merkezli SaaS için CDN, DNS ve gecikme optimizasyonu

Türkiye'deki kullanıcı "site yavaş" dediğinde tek bir latency yoktur. DNS çözümlemesi, TCP/TLS bağlantısı, statik asset transferi, API round-trip ve veritabanı sorgusu ayrı gecikme katmanlarıdır.

CDN neyi çözer?

CDN statik veya cache edilebilir içeriği kullanıcıya yakın noktadan sunabilir. Görsel, JS/CSS, font ve cache edilebilir public response'larda büyük fark yaratabilir. Ancak her request origin database'e gitmek zorundaysa CDN tek başına backend gecikmesini çözmez.

DNS'i ölç

DNS sağlayıcısının global anycast altyapısı ve cache davranışı ilk bağlantı süresini etkileyebilir. Fakat milisaniye tartışmadan önce yanlış TTL, gereksiz CNAME zinciri veya bozuk IPv6 gibi daha temel sorunları temizlemek gerekir.

API bölgesini kullanıcıya ve veriye göre seç

Frontend edge'de, database uzak bir bölgede ve API başka yerdeyse request üç coğrafya dolaşabilir. "Edge kullandım" ifadesi otomatik olarak düşük latency anlamına gelmez.

Cache politikasını bilinçli kur

• Fingerprinted statik asset: uzun cache.
• HTML: deployment ve personalization modeline göre.
• Public API data: kısa TTL + stale-while-revalidate düşünülebilir.
• Kullanıcıya özel veri: yanlış shared-cache kullanımından kaçın.

Türkiye'den gerçek ölçüm

Lighthouse tek lokasyondan yeterli değildir. İstanbul, Ankara, İzmir gibi gerçek kullanıcı ağlarında RUM metrikleri, TTFB ve API p95 değerleri izlenmelidir. Mobil ağ ile fiber aynı davranmaz.

Optimizasyon sırası

DNS zinciri → asset boyutu/cache → origin TTFB → API/database bölgesi → connection reuse → görsel/font stratejisi.

CDN bir mimari sihir değil; doğru cache edilebilen işi doğru yere taşıyan dağıtım katmanıdır.