Problem: her ürün fotoğrafı bir istek
Moda e-ticareti fotoğrafla yaşar. Bu mağazanın yalnızca anasayfası 130'dan fazla görsele referans veriyor — 300 KB üstü slider'lar, 50-350 KB civarı ürün çekimleri — kategori ve ürün sayfaları da aynı deseni tekrarlıyor. CDN olmadan her ziyaretçi bu dosyaların her birini origin sunucudan çeker: aynı fotoğraflar, günde binlerce kez, sepet ve ödemeye hizmet etmesi gereken PHP worker'ları ve bant genişliğiyle yarışarak.
Hedef egzotik değildi: tekrarlanan görsel trafiğini origin'den tamamen almak, HTML'i bir mağaza için yeterince taze tutmak ve bunu WordPress temasına dokunmadan yapmak.
Görsel kuralı: bir yıl cache'le, milisaniyelerde servis et
Kurulumun kalbi, görsel uzantılarıyla (jpg, jpeg, png, gif, webp, svg, ico) eşleşen tek bir dağıtım kuralı. Başarılı yanıtları edge'de tam bir yıl cache'liyor, görseller gerektiğinde gömülebilsin diye CORS başlığı ekliyor ve fayda göreni Brotli ve gzip ile sıkıştırıyor.
"Bir yıl" agresif gelir — ta ki ürün görsellerinin gerçekte nasıl değiştiğini hatırlayana kadar: değişmezler. Bir ürün için yüklenen fotoğraf, ürün ölene kadar URL'ini korur; yeniden tasarım, yeni adlarla yeni dosyalar yükler. Uzun TTL, edge'in origin'e neredeyse hiç yeniden sormaması demek — örneklememizde her anasayfa görseli zaten HIT'ti. Bir görselin yerinde değişmesi gereken nadir durum içinse kapsamlı purge tam o girdiyi temizler.
HTML kuralı: bir gün, artı bir kampanya-trafiği numarası
HTML farklı muamele görüyor: anasayfa bir gün cache'leniyor — edge'in anonim trafiğin neredeyse tamamını emmesine yetecek kadar uzun, mağaza düzenlemelerinin aynı gün görünmesine yetecek kadar kısa; acil olan her şeyi purge halleder.
Çalınmaya değer detay query normalizasyonu. Sosyal kampanyalardan gelen trafik izleme parametreleriyle gelir — her Facebook tıklaması benzersiz bir fbclid taşır. Saf cache'lense her tıklama "farklı" bir URL, her kampanya ziyaretçisi bir MISS olurdu ve origin, reklam yükünü en kötü anda tam olarak yerdi. Kural fbclid'i cache anahtarından çıkarıyor; on bin kampanya tıklaması tek cache girdisi. Parametre analitiğe yine ulaşıyor — yalnızca cache'i parçalamayı bırakıyor.
Ne ölçtük
Sayılar canlı siteden, açık internet üzerinden ölçüldü (yani laboratuvar değil, gerçek ağ mesafesi dahil). Cache'lenmiş bir görsel, medyan ~0,15 saniye time-to-first-byte ile yanıtlıyor. Aynı dosyayı edge'e origin'den çektirmek medyanı ~0,54 saniyeye koyuyor — kabaca 3,5 kat yavaş. Brotli sıkıştırmalı cache HIT olarak servis edilen anasayfa HTML'i ~0,27 saniyede gelmeye başlıyor.
Bu farkı sayfa görüntüleme başına 130+ görselle çarpın; algılanan hıza etkisi hiç de ince değil: cache'siz bir kurulum daha ilk fotoğrafları beklerken, tarayıcı ürün fotoğraflarını basmaya başlıyor. Ve her HIT, origin'in hiç görmediği bir istek — kampanya zirvesinde origin'in işi sepetleri servis etmeye küçülüyor.
Yığının kalanı: sıfır ekstra çabayla Redis ve WAF
Cache'in yanında iki parça daha çalışıyor; ikisi de inşa edilmedi, açıldı. Hosting katmanında WordPress'i bir Redis object cache destekliyor: PHP'ye gerçekten ulaşan istekler için tekrarlanan veritabanı okumaları — ayarlar, menüler, ürün metadata'sı — bellek okumasına dönüyor. Önde, hesabın WAF preset'i cache'i servis eden aynı edge'de gelen trafiği inceliyor; yaygın saldırı desenleri origin kuyruğuna girmeden süzülüyor.
Dürüst dipnot: bu müşteri WebP/AVIF görsel optimizasyonumuzu kullanmıyor — yukarıdaki sayılar saf cache ve sıkıştırma. Masada ölçülebilir pay duruyor (modern formatlar fotoğraf ağırlığını genellikle ciddi kırpar); bu, sonucu daha az değil daha çok aktarılabilir yapar: tek başına edge cache'in yaptığı budur.
Kendi mağazanız için kopyalanacaklar
Desen, görsel ağırlıklı her siteye dört pratik kuralla taşınır. Görselleri uzantıya göre uzun TTL ile cache'leyin ve değişimde purge edin — "tedbiren" kısa TTL yerine; tedbirin adı purge'dür. HTML'inizi sıfır değil, saatler ya da bir gün cache'leyin; tazeliği deploy anındaki purge halletsin. İzleme parametrelerini (fbclid, analitiğin izin verdiği yerde utm_*) cache anahtarından bir sonraki kampanyadan ÖNCE normalleştirin — origin eridikten sonra değil. Ve hisle değil ölçümle doğrulayın: cache-buster'lı bir curl ile buster'sız bir curl, edge'in kendi sayfalarınızda ne ettiğini tam olarak söyler.
Sık sorulan sorular
E-ticarette 1 yıllık görsel TTL güvenli mi?
Evet, çünkü ürün görseli URL'leri kararlıdır: yeni ürün yeni dosya adı getirir. Risk senaryosu — aynı URL'de görsel değiştirmek — saniyeler içinde etki eden kapsamlı purge ile çözülür.
Görsele bir yıl verirken anasayfayı neden yalnızca bir gün cache'lemeli?
HTML mağazacılıkla değişir — kampanyalar, fiyatlar, öne çıkan ürünler. Bir gün, edge'in okuma trafiğinin neredeyse tamamını yine emmesi demektir; aynı gün değişiklikler kimse düşünmeden görünür, acil olan tek purge uzaklıktadır.
fbclid'i cache anahtarından çıkarmak fiilen ne yapıyor?
Onsuz her reklam tıklaması benzersiz bir URL, dolayısıyla bir MISS olur — en pahalı trafiğiniz olan ücretli trafik komple origin'e düşer. Onunla tüm tıklamalar tek cache girdisini paylaşır. Parametre analitik script'lerinize değişmeden ulaşmaya devam eder.
WebP/AVIF bunu daha da hızlandırır mıydı?
Transfer boyutlarını daha da kırpardı (fotoğraflarda çoğu zaman %30-70) — bu müşteride kapalı olduğunu tam da bu yüzden not ediyoruz: 3,5 kat rakamı yalnızca cache'in eseri. Görsel optimizasyonunu açmak buradaki her şeyin yerine değil, üstüne eklenir.
Bunların herhangi biri için WordPress temamı değiştirmem gerekir mi?
Hayır. Bu vaka çalışmasındaki her şey — cache kuralları, query normalizasyonu, sıkıştırma, WAF, Redis — dağıtım ve hosting katmanında yapılandırılır. Uygulamaya dokunulmadı.