Bir kullanıcı İstanbul'dan Frankfurt'taki bir sunucuya istek gönderdiğinde, paketin gidip gelmesi için en az 30-40 milisaniye gerekir; bunun üstüne veritabanı sorgusu, uygulama işleme ve kuyruktaki diğer istekler eklendiğinde TTFB (Time to First Byte) 300 milisaniyeyi rahatlıkla aşar. Kullanıcı henüz sayfanın tek baytını almadan geçen bu süre, Core Web Vitals değerlendirmesinde hem LCP'yi hem genel deneyim puanını doğrudan etkiler.

Edge functions bu tabloya farklı bir seçenek sunar: kodu merkezi bir veri merkezinde değil, kullanıcıya coğrafi olarak yakın ağ düğümlerinde çalıştırmak. Cloudflare Workers, dünya genelinde 300'ü aşkın lokasyonda isteği karşılayabilir; Vercel Edge Functions ise Next.js projelerinde route bazlı bir edge çalışma ortamı sunar. Ağ gecikmesinin önemli bir kısmı ortadan kalktığında TTFB de düşer, ancak bu basit denklem her senaryo için geçerli değildir.

Hangi içerik edge'e taşınabilir, hangisi taşınamaz, ne zaman taşımak performans yerine karmaşıklık üretir: bu üç soruyu yanıtsız bırakırsanız, altyapıyı yeniden mimarlandırıp aynı TTFB ile kalabilirsiniz.

TTFB'nin Anatomisi: Gecikme Nereden Kaynaklanır?

TTFB üç bileşenden oluşur: DNS çözümleme, TCP ve TLS el sıkışması, sunucunun yanıt hazırlama süresi. İlk ikisi ağ katmanına aittir; edge functions doğrudan bu katmanı kısaltır. Üçüncüsü ise uygulamanın içindedir: veritabanı sorgusu, kimlik doğrulama, şablon render.

Sunucu Frankfurt'ta, kullanıcı Tokyo'daysa, ağ gecikmesi (round-trip time) tek başına 200-250 milisaniyeye çıkar. Bu sayıyı uygulama hiçbir şey yapsa da sıfıra indiremezsiniz; ağ fiziği böyle çalışır. Edge fonksiyon Tokyo yakınındaki bir PoP'ta çalıştığında aynı RTT 5-15 milisaniyeye iner. Fark net ve ölçülebilir.

Ancak şunu da hesaba katmak gerekir: edge ortamları genellikle sınırlı çalışma zamanı sunar. V8 Isolate tabanlı Cloudflare Workers, Node.js'in tam API yüzeyini sunmaz; dosya sistemi erişimi yoktur, bazı native modüller çalışmaz. Bu kısıtlamalar, uygulamanın her katmanını edge'e taşımanın önündeki gerçek engeldir.

Edge Functions Hangi İstekleri Karşılamalı?

Edge'e en çok değer kazandıran içerik türleri açık bir örüntü izler: yanıt önceden hesaplanabilir ya da çok az veriyle üretilebilir.

Statik ama kişiselleştirilmemiş yanıtlar bu kategorinin başında gelir. Bir blog yazısının HTML'i, ürün açıklama sayfası, dokümantasyon - bunlar build zamanında üretilebilirse edge cache'de saklanıp milisaniye içinde servis edilir. Geleneksel CDN'den farkı, edge fonksiyonun cache miss durumunda orijin sunucuya request atmak yerine basit bir mantık çalıştırarak yanıtı oluşturabilmesidir.

A/B test yönlendirmesi ve coğrafi içerik farklılaştırması ikinci güçlü kullanım alanıdır. Kullanıcının IP adresinden ülkesini tespit edip doğru sayfaya yönlendirmek, merkezi sunucuya gitmeden edge'de tamamlanır; yönlendirme gecikmesi request zincirini uzatmaz. Auth token doğrulaması da benzer biçimde çalışır: JWT'yi edge'de verify edip yetkisiz istekleri orijine iletmeden reddetmek, hem güvenliği hem performansı aynı anda iyileştirir.

Sık değişmeyen API yanıtları, ülke listesi, para birimi kodu, kategori ağacı gibi veriler, edge'de önbelleklendiğinde orijin yük azalır ve yanıt süresi kısalır. Hangi veri "sık değişmez" sorusu proje bağlamına bağlıdır; ama saat başı güncelleniyorsa edge cache bu iş için uygundur.

Cloudflare Workers ile Önbellek Katmanı Kurmak

Cloudflare Workers'ta Cache API, caches.default nesnesiyle kullanılır. Bir request geldiğinde önce cache kontrol edilir; bulunursa doğrudan döndürülür, yoksa orijine gidip yanıt hem kullanıcıya hem cache'e yazılır.

export default {
  async fetch(request, env, ctx) {
    const cache = caches.default;
    const cached = await cache.match(request);
    if (cached) return cached;

    const response = await fetch(request);
    if (response.ok) {
      ctx.waitUntil(cache.put(request, response.clone()));
    }
    return response;
  }
};

clone() çağrısı burada zorunludur: Response body bir kez okunduğunda tükenir, bu nedenle cache'e yazmak ve kullanıcıya dönmek için ayrı bir kopya gerekir. Bu detayı atladığınızda Workers sessizce hata verir ve yanıt boş gelir.

Cache süresi Cache-Control header'ı belirler. s-maxage=3600 ayarladığınızda Workers bir saat boyunca orijine gitmeden yanıtlar. stale-while-revalidate=60 eklendiğinde ise süre dolduktan sonra bile 60 saniye boyunca eski yanıt servis edilir, arka planda yeni sürüm çekilir; kullanıcı beklememişken orijin de güncel kalır.

Vercel'de route bazlı edge çalışma ortamı export const config = { runtime: 'edge' } ile aktif edilir; Next.js App Router'da export const runtime = 'edge' yeterlidir. Cache davranışı, fetch çağrılarındaki next.revalidate seçeneğiyle ya da segment düzeyinde revalidate sabiti ile kontrol edilir.

Kişiselleştirilmiş İçeriği Edge'de Ne Kadar İşleyebilirsiniz?

Kişiselleştirme edge'in en zorlu konusudur. Kullanıcıya özel içerik, geçmiş siparişler, kişisel bildirimler, önerilen ürünler, veritabanı çağrısı olmadan üretilemez. Veritabanınız Frankfurt'taysa edge'den sorgu atmak yine Frankfurt'a gitmek demektir; bu durumda TTFB avantajı büyük ölçüde yok olur ve edge katmanı yalnızca ek bir atlama noktasına dönüşür.

Buna rağmen kısmi bir çözüm işe yarar. Sayfanın iskeleti edge'de servis edilir, kişiselleştirilmiş veriler tarayıcı tarafında ayrı bir API çağrısıyla çekilir. Kullanıcı sayfanın HTML yapısını hemen alır; içerik biraz geride gelir. Bu yaklaşım, sayfanın tamamen merkezi sunucudan gelmesine kıyasla algılanan hızı iyileştirir; ilk boya (First Contentful Paint) erken gerçekleşir, sayfanın geri kalanı yüklense de ekran boş görünmez.

Başka bir yol, kullanıcı tercihlerini cookie ya da JWT claim'e gömmektir. Tercih bilgisi az ve şifreleme gerektirmiyorsa, edge'deki fonksiyon token'ı okuyarak hangi içerik grubunu döneceğine karar verir; veritabanına hiç gitmez. "Premium kullanıcılara farklı fiyat göster" gibi ikili ayrımlarda bu yöntem oldukça işlevseldir.

Cloudflare KV Store, yakın PoP'lardan okuma yapar ve düşük gecikme sunar; ancak eventual consistency modeli ile çalışır. Yeni yazılan verinin anında her PoP'ta görünmesi garanti değildir; kullanım senaryonuz tutarlılık gerektiriyorsa bu farka dikkat etmek gerekir.

Edge'e Taşımak Ne Zaman Gereksiz ya da Zararlıdır?

Her şeyi edge'e götürme isteği gerçek bir tuzaktır.

Uygulamanızın kullanıcıları zaten tek bir bölgede yoğunlaşıyorsa, örneğin yalnızca Türkiye'ye hizmet eden bir platform, merkezi sunucu ile kullanıcılar arasındaki mesafe zaten kısadır. Edge'den kazanılan süre çoğu zaman 10-20 milisaniyeyi geçmez; bunu sağlamak için mimariyi yeniden yazmak, hem geliştirme maliyeti hem operasyonel yük açısından anlamsız olur.

Karmaşık veritabanı sorgularına dayanan sayfaları edge'e taşımak, gecikmeyi azaltmak bir yana, artırabilir. Edge fonksiyon doğru PoP'ta çalışıyor olsa da orijin veritabanına giden bağlantı zinciri uzarsa toplam süre kötüleşir. Bağlantı havuzu (connection pool) yönetimi, edge ortamında standart sunuculara kıyasla daha sınırlıdır; her Worker isteği yeni bir izolat içinde çalıştığından kalıcı bağlantı tutmak mümkün değildir.

Gözlemlenebilirlik de zorlaşır. Her PoP'tan log toplamak, dağınık hataları birleştirmek ve hangi lokasyonda sorun çıktığını anlamak ek altyapı ister. Takım bu araçlara hazır olmadan geçiş yapılırsa, production'da çıkan hatayı bulmak gereksiz zaman alır. Yerel geliştirme ortamı ile V8 Isolate arasındaki davranış farkları da hesaba katılmalıdır: wrangler dev ile yerel test ettiğinizde gözükmeyip production'da beliren sorunlar, hazırlıksız yaklaşılan projelerde hata ayıklama sürecini uzatır.

Gerçek Kazanımı Doğrulamak: Hangi Metrikler Okunur?

Edge'e geçişten önce ve sonra aynı metriği ölçmek gerekir. Chrome DevTools Network sekmesindeki "Waiting for server response" süresi, ilk byte'ın alındığı ana kadar geçen zamanı doğrudan gösterir; bu değeri baseline olarak kaydedin.

Lab ortamında tek lokasyondan yapılan ölçüm yanıltıcıdır. Edge'in avantajı coğrafi çeşitlilikte kendini gösterir; tek bir şehirden yapılan test farkı küçük gösterir. Real User Monitoring (RUM) ile farklı bölgelerden gelen kullanıcıların TTFB dağılımını izlemek, asıl tabloyu ortaya koyar.

CrUX (Chrome User Experience Report) verilerinde 75. yüzdelik dilime bakılmalıdır; Core Web Vitals puanı ortanca değerde değil bu eşikte belirlenir. Search Console'daki Sayfa Deneyimi raporu, değişikliği bölge bazında izlemek için kullanılabilir.

Cloudflare Workers'ın kendi analitik paneli, cache hit oranını ve ortalama işlem süresini raporlar. Cache hit oranı yükseliyorsa orijine giden istek sayısı azalmış, dolayısıyla TTFB düşmüş demektir. Bu oran %80'in altında kalıyorsa cache anahtarı yapılandırmasına ya da TTL değerine bakmak gerekir; sorun çoğunlukla orada bulunur.

Edge functions, performans iyileştirmesinin başka yollarla ulaşılamadığı ya da çok pahalıya geldiği noktalarda gerçek değer yaratır. Statik içerik önbelleği, coğrafi yönlendirme ve hafif kimlik doğrulama, makul geliştirme maliyetiyle somut TTFB kazanımı sağlar; bunlar edge mimarisinin güçlü bölgeleridir.

Veritabanı bağımlı, karmaşık iş mantığı içeren sayfalarda ise önce mimariyi sormak gerekir: orijin sunucuyu optimize etmek mi daha kolaydır, yoksa tüm katmanı yeniden yazmak mı? Çoğu durumda sunucu taraflı önbellek, veritabanı indeksi veya connection pooling, edge geçişinden daha az riskle daha büyük kazanım sağlar.

Hangi kararı verirseniz verin, ölçüm olmadan sonuç yoktur. Geçişten önce bir baseline alın, gerçek kullanıcı verisini takip edin ve değişikliği kademeli olarak açın; bölgesel kararlar için bölgesel veriyle çalışın.