Tecof • 15 Eylül 2026
CDN Nedir? Web Sitesi Hızını Nasıl Artırır?
Kısaca
CDN (Content Delivery Network, içerik dağıtım ağı), sitenizin dosyalarını dünyanın farklı noktalarına dağılmış sunucularda kopyalayıp her ziyaretçiye coğrafi olarak en yakın kopyadan servis eden bir ağdır; origin sunucunuz Frankfurt'ta dursa bile Konya'daki bir ziyaretçi ürün fotoğrafını İstanbul'daki bir edge düğümünden alır, böylece hem ilk bayt süresi kısalır hem de origin sunucunuz aynı dosyayı binlerce kez üretmek zorunda kalmaz. Bir CDN aslında üç işi birden yapar: mesafeyi kısaltır, origin yükünü düşürür ve önüne gelen trafiği filtreleyerek güvenlik katmanı kurar. 2026 itibarıyla soru "CDN kullanmalı mıyım" değil, "hangi içeriği hangi kuralla ve ne kadar süreyle cache'leyeceğim" sorusudur.
Salı akşamı 21.15. Bir ev tekstili mağazası, yeni sezon koleksiyonunu Instagram'da 180 binlik bir hesapla duyurdu. On dakika içinde eşzamanlı ziyaretçi 40'tan 2.300'e çıktı. Sunucu çökmedi, ama kategori sayfasının açılması 1,9 saniyeden 7,4 saniyeye uzadı ve sepete ekleme oranı yüzde 4,1'den yüzde 1,6'ya düştü. Ekip önce "sunucu yetmiyor" deyip paketi iki kat büyüttü; fatura 1.400 TL'den 3.200 TL'ye çıktı, sayfa açılışı 6,1 saniyeye indi. Ertesi sabah ağ sekmesine bakıldığında tablo netti: kategori sayfası 3,8 MB ağırlığındaydı ve bunun 3,3 MB'ı 42 adet ürün görseliydi. Her görsel, her ziyaretçi için tek tek origin sunucudan çekiliyordu.
Sorun sunucunun gücünde değil, aynı dosyanın 2.300 kez aynı yerden gönderilmesindeydi. Bir ürün fotoğrafı günde bir kez değişir, belki hiç değişmez; ama sunucu onu her istekte yeniden okuyup yeniden gönderir. CDN'in çözdüğü problem tam olarak budur: değişmeyen içeriği bir kez üretip kullanıcıya yakın yerde saklamak. Donanım büyütmek bu problemi çözmez, sadece pahalı hale getirir.
CDN Nasıl Çalışır: Origin, PoP ve Cache
Temel kavramlar
CDN konuşmalarında sürekli geçen ve çoğu zaman birbirine karıştırılan terimler şunlardır:
- Origin sunucu: Sitenizin asıl barındığı yer. Veritabanı, uygulama kodu ve dosyaların kaynağı buradadır. CDN, origin'in yerini almaz; önüne geçer.
- PoP (Point of Presence): CDN sağlayıcısının bir şehirde konumlandırdığı sunucu kümesi. İstanbul, Frankfurt, Amsterdam, Sofya gibi. Ziyaretçi, DNS ve anycast yönlendirmesiyle en yakın PoP'a düşer.
- Edge: PoP içindeki, kullanıcıya en yakın noktada duran cache sunucusu. "Edge'den servis edildi" demek, isteğin origin'e hiç ulaşmadığı anlamına gelir.
- Cache hit: İstenen dosyanın edge'de hazır bulunması. Yanıt milisaniyeler içinde döner.
- Cache miss: Dosyanın edge'de olmaması. Edge, origin'e gider, dosyayı alır, kullanıcıya verir ve bir kopyasını saklar. İlk ziyaretçi bu bedeli öder, sonrakiler ödemez.
- TTL (Time To Live): Bir kopyanın edge'de ne kadar süre geçerli sayılacağı. TTL dolduğunda edge, dosyanın hâlâ güncel olup olmadığını origin'e sorar.
- Purge: Süre dolmadan bir kopyayı elle geçersiz kılma. Fiyat değiştiğinde, görsel yenilendiğinde kullanılır.
Mesafe neden bu kadar önemli
İstanbul ile Frankfurt arası kuş uçuşu 1.900 km; gerçek fiber güzergâhı bunun 1,5-2 katıdır. Bir HTTPS isteği TCP el sıkışması, TLS el sıkışması ve asıl istek olmak üzere birkaç gidiş-dönüş gerektirir. Sahada gördüğümüz aralıkta Türkiye'den Frankfurt'a tek yönlü gecikme 35-50 ms, gidiş-dönüş 70-100 ms bandındadır. Bunu üç-dört gidiş-dönüşle çarpınca, dosya daha ilk baytını göndermeden 250-350 ms harcanmış olur. İstanbul PoP'a düşen bir istekte aynı gidiş-dönüş 5-15 ms'dir. Fark, sunucunun hızından değil, mesafenin kendisinden gelir.
CDN'li ve CDN'siz ölçümler
Aşağıdaki tablo, origin'i Frankfurt'ta olan orta ölçekli bir e-ticaret sitesinde sahada tipik olarak gördüğümüz aralıkları özetliyor. Rakamlar mobil 4G bağlantı, önbelleği boş tarayıcı ve ana kategori sayfası içindir.
| Senaryo | TTFB (ms) | LCP (sn) | Toplam sayfa ağırlığı | Origin'e giden istek oranı |
|---|---|---|---|---|
| CDN yok, Frankfurt origin | 310-420 | 4,2-5,6 | 3,8 MB | %100 |
| CDN var, statik cache açık | 90-140 | 2,6-3,4 | 3,8 MB | %12-18 |
| CDN + WebP dönüşümü | 90-140 | 1,9-2,4 | 1,4 MB | %12-18 |
| CDN + WebP + responsive boyut | 85-130 | 1,4-1,9 | 0,8 MB | %10-15 |
| Yalnızca sunucu paketi büyütme | 240-330 | 3,9-5,1 | 3,8 MB | %100 |
Tablodaki son satır önemlidir: donanım büyütmek TTFB'yi bir miktar iyileştirir ama LCP'yi kurtarmaz, çünkü darboğaz işlemci değil mesafe ve bayt sayısıdır.
Statik ve Dinamik İçerik: Neyi Cache'lersiniz, Neyi Asla
Ayrımın mantığı
Basit kural şudur: aynı URL herkese aynı yanıtı veriyorsa cache'lenebilir, kişiye göre değişiyorsa cache'lenemez. Ürün görseli, kategori banner'ı, CSS ve JavaScript dosyaları, fontlar herkese aynıdır. Sepet içeriği, "merhaba Ayşe" yazan üst bar, sipariş takip sayfası, ödeme adımı ve üyelik paneli kişiye özeldir. Arada gri bir bölge vardır: ürün detay sayfasının HTML'i herkese aynı görünür ama stok ve fiyat değişebilir; burada kısa TTL ile çalışılır.
Yanlış kuralın somut bedeli
Bir müşterimizde "hızlansın" diye tüm HTML yanıtları 1 saat TTL ile cache'lenmişti. Sonuç şu oldu: ilk giren kullanıcının sepeti edge'de saklandı ve sonraki 40 dakika boyunca aynı PoP'a düşen herkes o sepeti gördü; üç kişi başkasının sepetiyle ödeme adımına kadar ilerledi. Bu bir hız problemi değil, veri sızıntısı ve KVKK problemidir. İkinci sık hata, oturum çerezinin cache anahtarına dahil edilmemesidir; bu durumda giriş yapmış bir kullanıcının kişisel bilgileri anonim ziyaretçilere servis edilebilir. Üçüncüsü tersidir: her yanıta Cache-Control: no-store konulur, CDN hiçbir şeyi tutamaz ve fatura ödenmesine rağmen kazanç elde edilmez.
İçerik tipine göre kural tablosu
| İçerik tipi | Cache kuralı | Önerilen TTL | Yanlış kuralın sonucu |
|---|---|---|---|
| Ürün görselleri, banner | Edge + tarayıcı cache | 30-365 gün | Gereksiz origin trafiği, yavaş LCP |
| CSS / JS (sürüm damgalı) | Edge + tarayıcı, immutable | 365 gün | Her deploy'da tam yeniden indirme |
| Fontlar | Edge + tarayıcı | 365 gün | Metin geç görünür, CLS artar |
| Kategori sayfası HTML | Kısa edge cache, çerez hariç | 60-300 sn | Stok/fiyat gecikmesi |
| Ürün detay HTML | Kısa edge cache + purge | 60-120 sn | Yanlış fiyat gösterimi |
| Sepet, ödeme, üyelik | Cache yok | 0 (no-store) | Sepet karışması, veri sızıntısı |
| Arama sonuçları | Cache yok veya çok kısa | 0-30 sn | Alakasız sonuç, boş sayfa |
| Sipariş/kargo API yanıtları | Cache yok | 0 | Eski kargo durumu, destek yükü |
Kural yazarken en güvenli yaklaşım "önce her şeyi kapat, sonra tek tek aç"tır. Tersi, yukarıdaki sepet hikâyesine götürür. Entegrasyon tarafında hangi uçların cache'lenemeyeceğini ayrıştırmak için API ve e-ticaret entegrasyonlarının nasıl kurgulandığını gözden geçirmek işe yarar.
Görsel Optimizasyonu: En Büyük Kazanç Burada
Format: WebP ve AVIF
Bir ürün fotoğrafını JPEG olarak 420 KB'ta tutuyorsanız, aynı görsel algılanan kalite farkı olmadan WebP'de 140-180 KB, AVIF'te 90-130 KB civarına iner. Modern CDN'ler bu dönüşümü kaynak dosyayı değiştirmeden, tarayıcının gönderdiği Accept başlığına bakarak yapar: AVIF destekleyene AVIF, desteklemeyene WebP, eski tarayıcıya JPEG gider. Görsel arşivinizi elden geçirmeniz gerekmez, kural bir kez yazılır.
Responsive boyutlar ve lazy loading
Sahada en sık gördüğümüz israf, 2000 piksel genişliğindeki ürün fotoğrafının telefonda 180 piksellik bir kutuya sığdırılmasıdır. Tarayıcı dosyanın tamamını indirir, sonra küçültür. CDN'in görsel yeniden boyutlandırma özelliği bunu URL parametresiyle çözer: aynı kaynak dosyadan 180, 360, 720 ve 1440 piksellik türevler üretilir, srcset ile tarayıcıya hangi genişlikte hangi dosyayı alacağı söylenir. Ekranda görünmeyen görsellere loading="lazy" eklenir; ancak ilk ekranda görünen büyük görsele lazy loading konulmaz, çünkü bu doğrudan LCP'yi geciktirir.
Örnek üzerinden hesap
Girişteki ev tekstili mağazasına dönelim. Kategori sayfasının LCP öğesi, ilk sıradaki 1.240 piksel genişliğinde 680 KB'lık bir nevresim fotoğrafıydı. Üç adımda şu oldu: CDN devreye alındı, görsel Frankfurt yerine İstanbul edge'inden gelmeye başladı ve indirme süresi 1,9 saniyeden 0,9 saniyeye indi. WebP dönüşümü açıldı, dosya 680 KB'tan 210 KB'a düştü, süre 0,4 saniyeye indi. Son olarak mobil için 720 piksellik türev servis edildi, dosya 74 KB oldu. LCP toplamda 5,1 saniyeden 1,8 saniyeye geldi ve kampanya haftası sepete ekleme oranı yüzde 1,6'dan yüzde 3,7'ye çıktı. Bu tür kazanımların satışa nasıl döndüğünü dönüşüm oranı artırma yazısında ayrıntılı ele almıştık.
Core Web Vitals: CDN Neyi Düzeltir, Neyi Düzeltmez
LCP: en çok kazanç burada
LCP (Largest Contentful Paint), ekrandaki en büyük görsel veya metin bloğunun görünür olma süresidir. E-ticarette bu neredeyse her zaman bir ürün görselidir. CDN, hem TTFB'yi kısaltarak hem de görseli küçülterek LCP'ye doğrudan dokunur. Sahada gördüğümüz aralıkta yalnızca CDN + görsel optimizasyonuyla LCP'de yüzde 40-60 iyileşme olağandır. Burada dikkat: LCP görseli preload edilmemişse ve CSS'in arkasında keşfediliyorsa, CDN ne kadar hızlı olursa olsun tarayıcı onu geç bulur.
INP: CDN'in neredeyse hiç dokunmadığı metrik
INP (Interaction to Next Paint), kullanıcının tıklamasına arayüzün ne kadar sürede yanıt verdiğini ölçer. Bu metrik ana iş parçacığında çalışan JavaScript'in ağırlığıyla belirlenir. 900 KB'lık bir JavaScript paketiniz varsa, o paketi edge'den 40 ms'de indirmeniz sorunu çözmez; tarayıcı onu yine ayrıştırmak ve çalıştırmak zorundadır. INP'yi düzelten şey kod bölme, kullanılmayan kütüphaneleri atma, üçüncü parti etiketleri azaltmadır. Burada dürüst olmak gerekir: CDN INP'yi kurtarmaz.
CLS ve sunucu yanıt süresi
CLS (Cumulative Layout Shift), sayfa yüklenirken öğelerin yerinden oynamasıdır. CDN'in dolaylı bir katkısı vardır: fontlar ve görseller hızlı geldiğinde geç yerleşen öğe sayısı azalır. Ama asıl çözüm görsellere width ve height vermek, font yükleme stratejisini font-display: swap ile yönetmek ve reklam/popup alanlarına sabit yükseklik ayırmaktır. Benzer şekilde, dinamik HTML'i üreten kodunuz veritabanında 800 ms harcıyorsa CDN bunu gizleyemez; cache miss durumunda o 800 ms aynen görünür. CDN yavaş kodu hızlandırmaz, sadece hızlı kodun kopyasını yakına taşır. Altyapı seçiminde bu farkı gözden kaçırmak sık rastlanan bir hatadır; e-ticaret altyapısı seçme hataları yazısında aynı konuyu başka bir açıdan ele almıştık.
Güvenlik: CDN'in Az Konuşulan Tarafı
DDoS koruması
Bir CDN, trafiğin tamamını kendi ağından geçirdiği için hacimsel saldırıları origin'e ulaşmadan emebilir. Türkiye'de küçük ve orta ölçekli mağazaların karşılaştığı saldırıların çoğu sofistike değildir; edge katmanı bunları hız sınırlama (rate limiting) ve IP itibar listeleriyle filtreler. Origin sunucunuzun gerçek IP'sini gizlemek de bu korumanın parçasıdır; IP sızarsa saldırgan CDN'i atlayıp doğrudan sunucuya gider, bu yüzden origin güvenlik duvarında yalnızca CDN IP bloklarına izin verilmelidir.
WAF ve bot yönetimi
WAF (Web Application Firewall), gelen isteklerin içeriğine bakıp SQL enjeksiyonu, XSS ve bilinen zafiyet denemelerini engelleyen kural setidir. Bot yönetimi ayrı bir iştir: Googlebot'un girmesi, fiyat kazıyan rakip botunun girmemesi istenir. Pratik kural şudur: arama motoru botlarına izin verin, kazıyıcıları oturum bazlı hız sınırıyla yavaşlatın, giriş ve ödeme uçlarına IP başına daha sıkı limit koyun. Aşırı agresif bot kuralı meşru kullanıcıları CAPTCHA duvarına çarptırıp dönüşümü düşürebilir; kuralları önce "izle" modunda çalıştırıp yanlış pozitifleri sayın.
SSL sonlandırma
CDN, TLS el sıkışmasını kullanıcıya yakın edge'de tamamlar; bu tek başına mobil bağlantılarda 100-200 ms kazandırır. Sertifika yönetimi de sağlayıcıya devredilir, otomatik yenileme sayesinde "sertifika süresi doldu" kaynaklı kesintiler ortadan kalkar. Edge ile origin arasındaki bağlantının da şifreli olması gerektiğini unutmayın; yalnızca kullanıcı tarafını şifreleyen kurulum yarım bir çözümdür. Sertifika türleri ve doğrulama seviyeleri için SSL sertifikası nedir yazısına bakabilirsiniz.
Maliyet ve Plan Seçimi
Ücretsiz katman ne zaman yeter
Aylık 50 bin sayfa görüntülemenin altında, sade bir katalog ve tek ülkeye satış yapan bir mağaza için ücretsiz katman çoğu zaman yeter; statik cache, otomatik SSL ve temel DDoS koruması bu katmanda vardır. Yetmediği yer şurasıdır: görsel dönüştürme genelde ücretli özelliktir, WAF kuralları sınırlıdır, ayrıntılı cache analitiği yoktur ve destek yanıt süresi garanti edilmez. Kampanya günü bir cache kuralı yanlış çalıştığında beklemeye tahammülünüz yoksa, giriş seviyesindeki ücretli plan kendini ödetir.
Bant genişliği ücretlendirmesi
Sağlayıcılar üç modelden birini kullanır: sınırsız bant genişliği + istek başına ücret, GB başına ücret, ya da sabit aylık paket. Türkiye'den gelen trafik bazı sağlayıcılarda "Avrupa" fiyatlandırmasına, bazılarında ayrı bir bölgeye girer; sözleşmede bunu kontrol edin. Pratik bir hesap: ayda 300 bin sayfa görüntülemesi olan ve sayfa başına 1,2 MB servis eden bir mağaza yaklaşık 360 GB trafik üretir. Görsel optimizasyonu bu rakamı 150 GB'a indirirse fatura da aynı oranda düşer; yani optimizasyon sadece hız değil, doğrudan maliyet kalemidir.
Plan karşılaştırması
| Katman | Tipik aylık maliyet | Dahil özellikler | Uygun bant genişliği | Kime uygun |
|---|---|---|---|---|
| Ücretsiz | 0 TL | Statik cache, SSL, temel DDoS | Adil kullanım | Blog, kurumsal site, yeni açılan mağaza |
| Giriş | 700-1.500 TL | Görsel dönüştürme, WAF kuralları, purge API | 500 GB - 2 TB | Aylık 100-500 bin görüntüleme |
| Büyüme | 3.000-9.000 TL | Bot yönetimi, edge kuralları, analitik | 2-10 TB | Kampanya piki yaşayan mağazalar |
| Kurumsal | Teklife bağlı | SLA, özel PoP, log aktarımı, destek | Sözleşmeye bağlı | Çok ülkeli, yüksek ciro |
Kampanya günü senaryosu
11.11 ve Kara Cuma, Türkiye'de trafiğin normal günün 6-12 katına çıktığı iki tarihtir ve 00.00'da başlayan indirimlerde ilk 20 dakika en kritik dilimdir. CDN'i olmayan bir mağazada origin istekleri kuyruğa alır, TTFB 2-3 saniyeye çıkar ve kullanıcıların önemli kısmı sayfa açılmadan çıkar. CDN'li kurulumda ise statik dosyalar edge'den gider, origin yalnızca sepet ve ödeme isteklerini görür — bu genellikle toplam isteklerin yüzde 10-15'idir. Aynı donanım, on kat trafiği bu şekilde taşıyabilir. Tecof'ta kampanya öncesi cache ısıtma ve purge işlemleri tanımlı yetki sınırlarıyla otomatikleştirilebiliyor; e-ticaret altyapısı tarafında bu kontroller panelden yönetiliyor.
Kurulum: DNS, Purge ve Kontrol Listesi
DNS ile yönlendirme
Kurulum iki yoldan biriyle yapılır. Birincisi, alan adının nameserver'larını CDN sağlayıcısına devretmektir; tüm DNS kayıtları oraya taşınır ve proxy anahtarı açılır. İkincisi, mevcut DNS'te yalnızca www ve kök kaydını CDN'in verdiği hedefe CNAME olarak göstermektir. Alan adını yerel bir kayıt firmasından almış mağazalarda ikinci yöntem daha az risklidir, çünkü MX kayıtları ve e-posta akışı yerinde kalır. Geçiş öncesi TTL'i 300 saniyeye düşürün ve geçişi mesai saatinde, kampanya dışı bir günde yapın.
Cache purge disiplini
Purge üç şekilde yapılır: tek URL, etiket (tag) bazlı ve tüm cache. Tüm cache'i temizlemek en kolay ama en pahalı yöntemdir; edge boşalır ve sonraki dakikalarda tüm istekler origin'e giderek tam da kaçınmak istediğiniz yükü oluşturur. Doğru yaklaşım, ürün güncellemelerini etiketlerle ilişkilendirmektir: bir ürünün fiyatı değiştiğinde yalnızca o ürünün detay sayfası, ilgili kategori sayfaları ve görselleri geçersiz kılınır. Fiyat ve stok güncellemeleri Logo veya Mikro gibi bir ERP'den geliyorsa, entegrasyon tarafına purge tetikleyicisi eklenmelidir; aksi halde panelde değişen fiyat sitede 30 dakika eski kalır.
Kampanya öncesi kontrol listesi
- Cache hit oranı: Statik dosyalarda yüzde 90'ın altındaysa kural yanlıştır, kontrol edin.
- Sepet ve ödeme: Bu yolların yanıt başlıklarında cache olmadığını iki farklı tarayıcıyla doğrulayın.
- Görsel formatı: Ağ sekmesinde ürün görsellerinin WebP veya AVIF olarak indiğini görün.
- LCP görseli: İlk ekrandaki büyük görselde lazy loading olmadığından emin olun.
- Purge yolu: ERP'den gelen fiyat güncellemesinin kaç saniyede siteye yansıdığını ölçün.
- Origin güvenlik duvarı: Yalnızca CDN IP bloklarına açık olduğunu doğrulayın.
- Hata sayfası: Origin yanıt vermezse edge'in ne göstereceğini test edin.
- Mobil ölçüm: Testleri masaüstünde değil, 4G bağlantılı gerçek telefonda yapın. Mobil tarafın bütünü için mobil uygulama mı mobil uyumlu site mi karşılaştırması iyi bir başlangıçtır.
30 Günde CDN Kurulumu
1-7. gün: ölçün ve mevcut durumu çıkarın
Hiçbir şey değiştirmeden önce ölçün. En çok trafik alan beş sayfayı seçin; her biri için TTFB, LCP, sayfa ağırlığı ve istek sayısını mobil 4G ve masaüstü olarak ayrı kaydedin. Görsellerin kaç KB olduğunu ve hangi formatta servis edildiğini listeleyin. Origin'in dinamik HTML üretme süresini ayrı ölçün — bu sayı 600 ms'nin üzerindeyse CDN'den önce orada bir iş var. Hafta sonunda elinizde tek sayfalık bir "önce" tablosu olmalı.
8-14. gün: statik cache'i kurun
CDN hesabını açın, DNS'i düşük TTL ile yönlendirin ve yalnızca statik dosyaları cache'leyerek başlayın: görseller, CSS, JS, fontlar. HTML'i bu aşamada cache'lemeyin. Sepet, ödeme, üyelik ve API yollarını açıkça cache dışına alın ve bunu test edin. Cache hit oranını izleyin; statik dosyalarda yüzde 90'ı geçmiyorsa sürüm damgası veya çerez ayarlarında sorun vardır. Hafta sonunda aynı beş sayfayı yeniden ölçün ve farkı "önce" tablosunun yanına yazın.
15-21. gün: görsel optimizasyonunu açın
WebP/AVIF otomatik dönüşümünü etkinleştirin. Ürün listeleme ve detay şablonlarında srcset ile responsive boyutları devreye alın. İlk ekran dışındaki görsellere lazy loading ekleyin, LCP görselinden lazy loading'i kaldırın ve onu preload edin. Kalite ayarını 80-85 bandında tutun; daha düşük değerler tekstil ve mücevher gibi kategorilerde gözle görülür bozulma yapar. Bu haftanın sonunda toplam sayfa ağırlığında yüzde 50-70 düşüş beklemek makuldür.
22-30. gün: güvenlik, izleme ve kampanya provası
WAF kurallarını önce izle modunda açın, bir hafta yanlış pozitifleri sayın, sonra engelleme moduna geçin. Bot yönetimini arama motorlarına izin verecek şekilde yapılandırın, origin güvenlik duvarını yalnızca CDN IP bloklarına kapatın ve cache hit oranı, origin hata oranı ve LCP için uyarı eşikleri tanımlayın. Son olarak kampanya provası yapın: en çok ziyaret edilen 200 URL'yi ısıtın, bir fiyat güncellemesi gönderip purge'ün kaç saniyede tamamlandığını ölçün ve sonuçları "önce" tablosuyla yan yana koyun.
Yarın sabah yapabileceğiniz iş şu: en çok trafik alan kategori sayfanızı telefonunuzda 4G bağlantıyla açın, tarayıcının geliştirici araçlarında ağ sekmesini açıp sayfayı yenileyin ve iki sayıyı not edin — toplam indirilen bayt miktarı ve en büyük üç dosyanın adı. O üç dosya büyük ihtimalle ürün görselidir; boyutlarını ve formatlarını yazın, aynı görselin telefon ekranında kaç piksel genişlikte gösterildiğini ölçün. Aradaki fark, CDN'den alacağınız kazancın ilk ve en dürüst tahminidir.
Sıkça Sorulan Sorular
CDN kullanmak SEO'ya zarar verir mi?
Doğru kurulduğunda tam tersi olur: sayfa hızı ve Core Web Vitals iyileştiği için arama görünürlüğü olumlu etkilenir. Zarar, yanlış kurulumdan gelir — yönlendirme zincirleri, farklı bölgelerde farklı içerik servis edilmesi veya Googlebot'un bot kurallarıyla engellenmesi gibi. Geçişten sonra Search Console'da taranabilirlik ve sayfa deneyimi raporlarını iki hafta izleyin.
Origin sunucumu küçültebilir miyim?
Statik trafik edge'e kaydıktan sonra origin'in CPU ve bant genişliği kullanımı ciddi biçimde düşer, ama karar vermeden önce en az bir kampanya dönemi geçirin. Dinamik istekler (sepet, ödeme, arama) CDN'den geçmez ve pik anında yükü onlar oluşturur.
Cache hit oranım yüzde 60'ta takılı, sebebi ne olabilir?
En sık üç sebep şudur: dosya adlarında sürüm damgası yoktur ve her deploy'da cache boşalır; sorgu parametreleri (utm ve benzeri) cache anahtarına dahil edilmiştir, bu yüzden aynı dosya onlarca kez ayrı ayrı saklanır; ya da uygulama her yanıta oturum çerezi bastığı için CDN içeriği kişiselleştirilmiş sayar. Üçü de yapılandırmayla çözülür.
Türkiye'de PoP'u olan bir sağlayıcı şart mı?
Şart değil ama fark yaratır. İstanbul PoP'u olan bir sağlayıcıda Türkiye içi gecikme 5-15 ms bandındayken, en yakın düğümü Frankfurt veya Sofya olan bir sağlayıcıda bu 30-50 ms'ye çıkar. Trafiğinizin yüzde 90'ı Türkiye'den geliyorsa yerel PoP'un getirisi ölçülebilir; uluslararası satış ağırlıklıysa küresel kapsama daha önemli hale gelir.
Sepet sayfası neden hiç cache'lenemiyor?
Çünkü aynı URL her kullanıcıya farklı veri döndürür. Edge, isteği kimin yaptığını ayırt edecek bir anahtar olmadan yanıtı sakladığında, o yanıt sonraki kullanıcıya gider. Sonuç, başkasının sepetini görmek ve kişisel verinin izinsiz paylaşılmasıdır. Bu yollar için tek doğru ayar cache'i tamamen kapatmaktır.
CDN, yavaş çalışan sunucu kodumu hızlandırır mı?
Hayır. Cache hit durumunda kullanıcı origin'e hiç ulaşmadığı için sorunu görmez, ama her cache miss'te kodunuzun gerçek süresi ortaya çıkar. Veritabanı sorgusu 800 ms sürüyorsa bu süre olduğu gibi yaşanır. CDN yavaş kodu gizler, iyileştirmez; sorgu ve şablon tarafını ayrıca ele almak gerekir.
Görselleri WebP'ye çevirince kalite düşer mi?
Kalite ayarı 80-85 bandında tutulduğunda tipik ürün fotoğraflarında gözle ayırt edilebilir bir fark oluşmaz ve dosya boyutu yüzde 60-70 azalır. Ayrıntılı doku içeren kategorilerde — tekstil, halı, mücevher — birkaç örnek görseli iki formatta yan yana koyup görsel ekiple onaylatmak iyi bir alışkanlıktır.
Kampanya günü cache'i nasıl ısıtırım?
Kampanya başlamadan 1-2 saat önce, en çok ziyaret edilen 200-500 URL'yi bir betikle sırayla çağırın; her istek edge'e bir kopya yerleştirir. Ürün görsellerinin farklı boyut türevlerini de listeye ekleyin. Bu işlem ilk dakikalardaki cache miss dalgasını ortadan kaldırır ve origin'in en kritik 20 dakikada boşta kalmasını sağlar.
Ücretsiz plandan ücretliye ne zaman geçmeliyim?
Üç işaretten biri belirdiğinde: görsel dönüştürme veya yeniden boyutlandırmaya ihtiyacınız olduğunda, WAF kurallarını kendi ihtiyacınıza göre yazmanız gerektiğinde, ya da bir kampanya gününde destek yanıt süresinin garantili olmasını istediğinizde. Aylık 100 bin sayfa görüntülemenin üzerindeki mağazalarda bu eşikler genellikle aynı anda gelir.
CDN kurulumu sitemi kesintiye uğratır mı?
Planlı yapıldığında hayır. DNS TTL'ini geçişten bir gün önce 300 saniyeye düşürün, geçişi mesai saatinde ve kampanya dışı bir günde yapın, ilk bir saat hata oranını izleyin. Sorun çıkarsa DNS'i eski değerine döndürmek birkaç dakika sürer. Riskli olan, TTL'i 24 saatte bırakıp gece yarısı geçiş yapmaktır.