Tarayıcı ve CDN Önbellekleme Neden Bu Kadar Kritik

{
“title”: “HTTP Cache-Control, ETag ve CDN Önbellek Kuralları: WordPress, Laravel ve SPA Projeleri İçin Uygulamalı Rehber”,
“content”: “

Bir WordPress sitesi, bir Laravel API projesi veya modern bir React SPA uygulaması geliştirirken performans konuşulan her toplantıda şu soru mutlaka gelir: Tarayıcı ve CDN önbelleğini doğru ayarlasak bu site ne kadar hızlanır ve altyapı maliyeti ne kadar düşer? HTTP Cache-Control başlıkları, ETag ve CDN tarafındaki önbellek kuralları doğru kurgulandığında, hem Core Web Vitals skorlarınız iyileşir hem de sunucularınız gereksiz yükten kurtulur. DCHost ekibi olarak sahada en çok gördüğümüz problemlerden biri, bu başlıkların ya gereğinden agresif ya da tamamen kapalı kullanılması. Sonuç; ya eski içerik gösteren sayfalar ya da her istekte sunucuyu yoran dinamik cevaplar oluyor.

n

Bu yazıda HTTP Cache-Control, ETag ve CDN önbellek kurallarını; WordPress, Laravel ve SPA (React, Vue, Angular) projeleri özelinde, gerçekçi senaryolarla ele alacağız. Hangi dosyayı ne kadar süre cachelemek mantıklı, HTML sayfalarda ne kadar agresif olunabilir, API cevaplarında ETag ne işimize yarar, CDN kuralı ile origin sunucu ayarları nasıl uyumlu olmalı tek tek üzerinden geçeceğiz. Anlatım boyunca DCHost altyapısında uyguladığımız pratiklerden, sık gördüğümüz hatalardan ve bunları nasıl düzelttiğimizden bahsedeceğim.

nnn

Önbellekleme, site hızının ve altyapı maliyetinin en büyük kaldıraçlarından biri. Özellikle medya ve statik dosya ağırlıklı projelerde, doğru HTTP başlıkları ile hem son kullanıcının yaşadığı gecikmeyi hem de sunucu CPU ve disk IO tüketimini dramatik biçimde azaltmak mümkün. Bu etkiyi en net şekilde Core Web Vitals metriklerinde görürsünüz. Tarayıcı, CSS ve JS dosyalarını her sayfa yüklemesinde yeniden indirmek zorunda kalmadığında LCP ve FID değerleri belirgin biçimde iyileşir. Bu konuyu daha derinlemesine okumak isterseniz, Core Web Vitals ve hosting altyapısının etkileşimi başlıklı rehberimize göz atabilirsiniz.

n

Diğer tarafta CDN kullanıyorsanız, edge sunuculardaki cache hit oranı doğrudan faturanıza ve origin sunucularınızın stabilitesine yansır. Kötü kurgulanmış Cache-Control başlıkları, CDN katmanının HTML ve API cevaplarını yanlış şekilde cachelemesine, kullanıcı başına kişiselleştirilmiş içeriklerin karışmasına ve login sayfalarının statikmiş gibi saklanmasına neden olabilir. Bu yüzden, tarayıcı önbelleğini düşünürken her zaman CDN ile beraber, uçtan uca bir strateji kurmak gerekiyor. DCHost tarafında, yüksek trafikli WordPress ve Laravel projelerinde mimari tasarım yaparken ilk baktığımız maddelerden biri, HTTP önbellek başlıklarının haritasıdır.

nn

HTTP Cache-Control Direktiflerini Doğru Okumak

n

Cache-Control başlığı, tarayıcının ve ara önbelleklerin (CDN, reverse proxy vb.) içeriği nasıl saklayacağını belirleyen anahtar mekanizma. Temel ve gelişmiş direktifleri netleştirelim.

nn

Temel Cache-Control direktifleri

n

n
• max-age=sek: İçeriğin kaç saniye boyunca taze kabul edileceğini belirtir. Örneğin 86400 bir gün demektir.

n

• s-maxage=sek: Paylaşımlı cacheler (CDN, proxy) için max-age değerini override eder. Tarayıcı farklı, CDN farklı süre kullanabilir.

n

• public: Cevabın, paylaşımlı cacheler tarafından saklanabileceğini söyler. HTML sayfaları için dikkatli kullanılmalıdır.

n

• private: Cevabın sadece tarayıcı tarafında cachelenmesi gerektiğini, paylaşımlı cacheler için uygun olmadığını belirtir. Kullanıcıya özel dashboard ve hesap sayfaları için idealdir.

n

• no-store: İçerik hiç bir şekilde cachelenmesin, disk veya hafızaya yazılmasın demektir. Ödeme sayfaları ve yüksek hassasiyetli veriler için kullanmalısınız.

n

• no-cache: İsim kafa karıştırıcı; aslında cachelemeyi tamamen kapatmak değildir. İçeriğin cachelenebileceğini ancak her kullanımda origin ile yeniden doğrulanması gerektiğini söyler (ETag veya Last-Modified ile).

n

n

Pratikte statik dosyalar için public, max-age yüksek; dinamik HTML ve API cevapları için ise private veya no-store + kısa süreli max-age kombinasyonları kullanılır. Örneğin WordPress ana sayfanız için 60 saniyelik bir mikro cache makul olabilirken, logo PNG için 30 gün cache süresi son derece güvenlidir.

nn

Gelişmiş direktifler: stale-while-revalidate ve stale-if-error

n

Modern tarayıcılar ve CDNler, iki önemli direktifi daha destekliyor:

n

n
• stale-while-revalidate=sek: İçerik aslında süresi dolmuş olsa bile, belirtilen süre boyunca eski versiyonun kullanıcıya gösterilmesine izin verirken arka planda taze versiyonu çekip cachei günceller.

n

• stale-if-error=sek: Origin erişilemez veya hata veriyorsa, belirtilen süre boyunca eski cache içeriğinin kullanılmasına izin verir. Kesintilerde hayat kurtarıcıdır.

n

n

Bu mekanizmalar, özellikle CDN seviyesinde kullanıldığında kesintisiz yayına ciddi katkı sağlar. Bu konuyu daha önce stale-while-revalidate ve stale-if-error direktiflerinin pratik kullanımı başlıklı yazımızda detaylı anlatmıştık. Buradaki fikir şu: Origininiz kısa süreli bir problem yaşasa bile, kullanıcı tarafında çoğu zaman kimse fark etmez.

nn

ETag ve Last-Modified ile Koşullu İstekler

n

Cache-Control ile ne kadar süre cacheleneceğini belirledik. Peki içerik değiştiğinde tarayıcı bunu nasıl anlayacak? Tam burada ETag ve Last-Modified devreye giriyor.

nn

ETag nedir, nasıl çalışır

n

ETag, sunucunun her cevap için ürettiği benzersiz bir içerik etiketi. Genelde dosyanın hash değeri, inode bilgisi veya benzeri bir özet üzerinden oluşturulur. İstemci, ilk istekte ETag değerini response header olarak alır ve sonraki isteğinde If-None-Match başlığı ile geri gönderir. Eğer sunucudaki içerik değişmediyse 304 Not Modified cevabı döner ve veri tekrar indirilmez; sadece headerlar güncellenir.

n

Bu mekanizma özellikle şu durumlarda çok değerlidir:

n

n
• max-age süresi nispeten kısa tutulmak zorundaysa bile gereksiz veri transferini azaltmak

n

• API cevapları için, veri değişmediği sürece network ve CPU maliyetini kısmak

n

• Dinamik HTML sayfalarda, değişiklik olmayan kullanıcılar için daha hızlı yanıt sağlamak

n

nn

Last-Modified ile birlikte kullanım ve CDN etkisi

n

Last-Modified başlığı, içeriğin son değiştirilme zamanını belirtir. Tarayıcı bir sonraki istekte If-Modified-Since ile gelir ve içerik değişmemişse yine 304 döndürülür. ETag ve Last-Modified genelde birlikte kullanılır; bazı durumlarda sadece Last-Modified yeterli olabilir.

n

CDN tarafında ise dikkat edilmesi gereken nokta şudur: Bazı CDNler, ETag başlıklarını manipüle edebilir veya origin ile edge arasında farklılaştırabilir. Ayrıca ETag değeriniz sunucudaki dosyanın inode bilgisinden türetiliyorsa, çoklu sunucu mimarilerinde (örneğin DCHost üzerinde birden fazla web sunucusuna dağıtılmış WordPress clusterı) aynı içeriğe farklı ETagler üretilebilir. Bu da cache isabet oranını düşürür. Bu yüzden, mümkün olduğunca içerik tabanlı hash veya build sürecinde üretilen sabit ETag mekanizmalarını tercih etmek daha sağlıklı olur.

nn

WordPress İçin Doğru Tarayıcı Önbellekleme Stratejisi

n

WordPress ekosisteminde en sık gördüğümüz senaryo şu: Statik dosyalar agresif şekilde cachelenmemiş, HTML sayfalar ise ya tamamen dinamik ya da CDN düzeyinde yanlışlıkla public cachelenmiş. Doğru ayrımı yapmak için WordPressi ikiye bölmek gerekir: Statik varlıklar ve HTML çıktılar.

nn

Statik dosyalar: CSS, JS, görseller ve yazı tipleri

n

WordPress tema ve eklentileriniz çoğunlukla versiyon parametreleri ile cache busting uygular. Örneğin style.css dosyanız şu şekilde çağrılır:

n

/wp-content/themes/tema/style.css?ver=1.4.3

n

Bu sayede dosyaya 1 yıl bile cache süresi verseniz, dosya değiştiğinde versiyon numarası değişeceği için tarayıcı yeni dosyayı indirir. Bu, uzun süreli cache ve güvenli güncelleme kombinasyonunun altın standardıdır.

n

Önerilen ayarlar kabaca şöyle olabilir:

n

n
• CSS, JS, font ve görseller için: Cache-Control public, max-age=2592000 (30 gün) veya daha uzun

n

• immutable direktifini ekleyerek, aynı dosya ismi değişmediği sürece tarayıcının yeniden doğrulama ihtiyacını azaltabilirsiniz

n

n

location ~* .(css|js|png|jpe?g|gif|svg|webp|ico|woff2?)$ {n    expires 30d;n    add_header Cache-Control 'public, max-age=2592000, immutable';n}

n

Görsel optimizasyonu ve CDN tarafındaki ayarlarla birlikte düşünmek isterseniz, WebP, AVIF ve CDN alt alan adları ile görsel SEO stratejileri yazısındaki önerilerle bu ayarları birleştirebilirsiniz.

nn

HTML sayfalar, WooCommerce sayfaları ve kullanıcıya özel içerik

n

HTML tarafında ise biraz daha dikkatli olmak şart. Ana sayfa, kategori sayfaları ve blog yazıları için tam sayfa önbellekleme (server side cache) kullanıyorsanız, tarayıcıya uzun süreli cache süresi vermenize çoğu zaman gerek kalmaz. Burada amaç tarayıcıdan çok, sunucuyu rahatlatan reverse proxy veya uygulama içi cachelerdir. Yine de mikro önbellekleme ile 30 ila 120 saniye arasında bir max-age, özellikle yoğun trafikli haber ve blog sitelerinde oldukça işe yarar.

n

WooCommerce tarafında ise sepet, ödeme ve hesap sayfaları kesinlikle public cachelenmemelidir. Bu sayfalar için:

n

n
• Cache-Control no-store, no-cache, must-revalidate

n

• Pragma no-cache (eski tarayıcılar için)

n

• Vary Cookie veya Authorization gibi başlıklarla CDN seviyesinde de cachelenmesi engellenmelidir

n

n

CDN ve edge kuralları ile HTML cachei yönetmek üzerine daha odaklı bir rehbere ihtiyacınız varsa, WordPress için CDN önbellek kuralları ve WooCommercede HTML cache bypass stratejileri yazımızı da bu makale ile birlikte okumanızı öneririm.

nn

Nginx ve Apache için örnek WordPress ayarları

n

Nginx üzerinde tipik bir WordPress kurulumunda, aşağıdaki gibi bir ayrım yapılabilir:

n

# Statik dosyalar uzun süre cachenlocation ~* .(css|js|png|jpe?g|gif|svg|webp|ico|woff2?)$ {n    expires 30d;n    add_header Cache-Control 'public, max-age=2592000, immutable';n}nn# Dinamik PHP sayfalar için kısa süreli veya hiç cache yoknlocation ~ \.php$ {n    add_header Cache-Control 'private, no-cache, no-store, must-revalidate';n    include fastcgi_params;n    fastcgi_pass php-fpm:9000;n}

n

Tabii ki burada php-fpm havuz ayarları ve OPcache yapılandırmasının da devreye girdiğini unutmayalım. Sunucu tarafı WordPress optimizasyonu için, PHP-FPM, OPcache ve Redis ile WordPress optimizasyon rehberimizi inceleyebilirsiniz. DCHost altyapısında sıkça kullandığımız yapı, tam sayfa cache + uzun süreli statik asset cache kombinasyonudur.

nn

Laravel Uygulamalarında Cache-Control ve ETag

n

Laravel tarafında hem klasik web uygulamaları hem de sadece API sağlayan servisler sıkça karşımıza çıkıyor. Çoğu projede önbellekleme sadece uygulama içi cache mekanizmaları ile sınırlı kalıyor; HTTP seviyesinde ise neredeyse hiç ayar yapılmıyor. Oysa Laravel, bu konuda gayet esnek bir temel sunuyor.

nn

Asset versiyonlama: mix ve vite kullanımı

n

Önce, statik dosyalardan başlayalım. Laravel Mix veya Vite kullandığınızda, derlenen CSS ve JS dosyaları genelde şu formatta üretilir:

n

/build/assets/app.7c3f9a2d.jsn/build/assets/app.19b5c811.css

n

Bu hashli dosya isimleri, agresif tarayıcı ve CDN cachei için biçilmiş kaftandır. Çünkü dosya içeriği değiştiğinde isim de değişir; eski isimli dosyalar cachete kalsa bile yeni versiyon otomatik olarak çağrılır.

n

Bu durumda, Nginx veya Apache seviyesinde şu mantıkla hareket edebilirsiniz:

n

n
• build, public, storage gibi asset dizinleri için public, max-age=31536000, immutable

n

• Sık değişmeyen fakat hashlenmemiş dosyalar için max-age daha kısa

n

n

Bu yapı, özellikle DCHost üzerinde yüksek trafikli Laravel projelerinde CPU yükünü ciddi ölçüde azaltıyor; çünkü her sayfa yüklemesinde tekrar tekrar indirilen ağır JS bundleları devreden çıkmış oluyor.

nn

API cevapları için Cache-Control ve ETag stratejisi

n

Laravel ile yazılmış APIlerde, GET istekleri için ETag ve kısa süreli max-age kombinasyonu çok işe yarar. Örneğin ürün listesini veya sabit referans verileri dönen uç noktalar için şu stratejiyi izleyebilirsiniz:

n

n
• Cache-Control public, max-age=60, stale-while-revalidate=30

n

• ETag başlığı ile içerik değişmediğinde 304 Not Modified döndürmek

n

• Yetkilendirme gerektiren uç noktalar için ise private ve genelde no-store kullanmak

n

n

Laravelde bir response için ETag eklemek oldukça basit:

n

return response($content)n    ->header('Cache-Control', 'public, max-age=60, stale-while-revalidate=30')n    ->setEtag(sha1($content));

n

Tabii gerçek dünyada ETagi sadece içerikten değil, versiyon numaranızdan, güncelleme zamanından veya veritabanı satırlarının checksumlarından da türetebilirsiniz. Önemli olan, içerik değiştiğinde ETagin de değişmesini sağlamak.

n

Laravel prod ortam optimizasyonu ile HTTP cachei birlikte düşünmek isterseniz, Laravel prod ortam optimizasyon rehberi bu yazının iyi bir tamamlayıcısı olacaktır.

nn

SPA Projeleri (React, Vue, Angular) İçin Önbellek Kuralları

n

SPA dünyasında önbellekleme stratejisi WordPress veya klasik Laravel uygulamalarından biraz farklı. Çünkü çoğu zaman tek bir index.html dosyası ve onun referans verdiği büyük JS ve CSS bundleları üzerinden çalışıyorsunuz. Ayrıca API istekleri genelde ayrı bir origin veya alt yol üzerinden servis ediliyor.

nn

index.html için kısa süreli fakat kontrollü cache

n

SPA projelerinde index.html, uygulamanızın giriş noktası ve çoğu zaman çok küçük bir dosya. Bu dosyanın agresif şekilde cachelenmesi, yeni deploylardan sonra kullanıcılara eski versiyonun kalmasını sağlar. Bu yüzden genelde şu yaklaşım tercih edilir:

n

n
• Cache-Control no-cache veya max-age=60 gibi kısa bir süre

n

• ETag veya Last-Modified ile koşullu istek desteği

n

• CDN tarafında HTML cachei devre dışı bırakmak veya çok kısa tutmak

n

n

Böylece kullanıcı sayfanıza her giriş yaptığında en fazla birkaç saniyelik bir gecikmeyle yeni index.html versiyonunu alır ve yeni JS bundlelarına yönlendirilir.

nn

Hashli JS ve CSS dosyaları için agresif cache

n

Build sürecinde üretilen app.7c3f9a2d.js veya vendor.19b5c811.css gibi hashli dosyalar için tam tersine, mümkün olan en agresif cache politikasını uygulamalısınız:

n

n
• Cache-Control public, max-age=31536000, immutable

n

• CDN seviyesinde de aynı veya daha uzun süre

n

• Versiyon değişikliğini sadece dosya ismine bırakarak cache busting sağlamak

n

n

Bu sayede, kullanıcı siteyi tekrar ziyaret ettiğinde büyük JS bundlelarını neredeyse hiç indirmez; sadece index.html ve gerekirse yeni manifest dosyası güncellenir. Bu yaklaşım TTFByi değil ama FCP ve LCPyi ciddi şekilde iyileştirir.

nn

Service Worker, offline cache ve CDN uyumu

n

Eğer PWA özellikleri kullanıyor ve service worker ile offline cache yapıyorsanız, HTTP seviyesindeki Cache-Control kurallarınızla çakışmayacak bir mimari kurmanız gerekir. Genel öneri şu şekildedir:

n

n
• Service worker scripti ve manifest dosyası için kısa süreli cache ve ETag

n

• Service workerın network-first, cache-first veya stale-while-revalidate stratejilerini bilinçli seçmek

n

• CDN tarafında HTML ve service worker için cache bypass kuralları tanımlamak

n

n

SPA projelerini aynı alan adında API ile birlikte yayınlama konusu da cache davranışını etkiler. Bu senaryoyu daha detaylı anlattığımız React, Vue ve Angular SPAleri aynı alan adında API ile host etme rehberinde Nginx yönlendirme ve SSL mimarisine ek olarak, cache key ve path bazlı kurallara da değinmiştik.

nn

CDN ile Origin Önbelleğini Uyumlu Hale Getirmek

n

Tarayıcı ve CDN önbelleği çoğu zaman aynı Cache-Control başlıklarına baksa da, davranışları ve öncelikleri farklıdır. Origin sunucunuzda güzel ayarlar yapıp CDN düzeyinde bunları yanlış override ederseniz, çok kafa karıştırıcı sonuçlarla karşılaşabilirsiniz.

nn

Cache key, cookie ve Vary başlıkları

n

CDNlerin hangi isteği hangi cache girdisi ile eşleştireceğini belirleyen şey cache keydir. Tipik olarak şu parçaları içerir:

n

n
• Host (alan adı)

n

• Path (istek yolu)

n

• Sorgu parametreleri (query string) – hepsi veya seçili olanlar

n

• Bazı headerlar (Accept-Encoding, Authorization vb.)

n

n

WordPress ve WooCommerce sitelerinde en kritik nokta, kullanıcıyı tanımlayan cookie değerlerinin cache keye nasıl dahil edileceğidir. Genellikle login olmuş kullanıcıları ve sepet içeren oturumları cache dışında bırakmak için, belirli cookie adlarına göre bypass kuralları yazılır. Örneğin:

n

n
• wp_logged_in_ ile başlayan cookie varsa HTML cache bypass

n

• woocommerce_cart_hash veya woocommerce_items_in_cart varsa cache bypass

n

n

Benzer şekilde, Laravel tabanlı bir SaaS uygulamasında Authorization headerı içeren isteklerin CDN seviyesinde cachelenmemesini istersiniz. Bunu Vary Authorization başlığı ve CDN tarafında ek kurallarla destekleyebilirsiniz.

nn

Origin ve CDN arasında rol dağılımı

n

DCHost ortamında tipik olarak şu rol dağılımını öneriyoruz:

n

n
• Origin (Nginx, Apache veya uygulama): Doğru Cache-Control, ETag, Last-Modified ve Vary başlıklarını üretir. Statik dosyalar için uzun süreli, HTML ve API için daha kontrollü süreler belirler.

n

• CDN: Bu başlıkları varsayılan olarak takip eder, ancak kritik pathler için istisnai edge kuralları tanımlar. Örneğin wp-admin altındaki tüm yolları kesinlikle cachelememek, login ve checkout sayfalarını HTML cache dışında bırakmak gibi.

n

n

CDN seçimi ve maliyet optimizasyonu tarafında daha derin bir bakışa ihtiyacınız varsa, CDN trafik maliyetlerini kontrol altına alma rehberinde origin pull, cache hit oranı ve bölgesel fiyatlandırma konularını detaylı ele almıştık. Oradaki önerileri, bu yazıdaki HTTP önbellek stratejisi ile birleştirdiğinizde hem performans hem de fatura tarafında dengeli bir yapı kurabilirsiniz.

nn

Tipik DCHost Senaryoları: WordPress, Laravel API ve SPA

n

Sahada en sık gördüğümüz üç senaryoyu, somut önbellek kuralları ile özetleyelim.

nn

1. Klasik blog veya kurumsal WordPress sitesi

n

n
• Statik varlıklar (wp-content, wp-includes altındaki css, js, img, fonts): public, max-age=2592000 veya 31536000, immutable

n

• HTML sayfalar (ana sayfa, yazı, kategori): sunucu tarafında tam sayfa cache 60–300 saniye, tarayıcı tarafında kısa max-age (60–120 saniye) veya no-cache

n

• Yönetim paneli, wp-admin ve wp-login.php: no-store, no-cache, Pragma no-cache ve CDN seviyesinde cache bypass

n

nn

2. Laravel tabanlı API + admin panel

n

n
• Statik assetler (build klasörü): public, max-age=31536000, immutable

n

• Genel GET uç noktaları (ürün listeleri, sabit içerikler): public, max-age=60–300, ETag ile 304 desteği

n

• Auth gerektiren GET uç noktaları: private, no-store, kısa max-age veya tamamen kapalı cache

n

• Admin panel HTML ve JS: private, no-store; CDNde host ediliyorsa path bazlı cache bypass

n

nn

3. SPA frontend + ayrı API sunucusu

n

n
• index.html: no-cache veya max-age=60, ETag desteği

n

• Hashli JS, CSS, font ve imajlar: public, max-age=31536000, immutable

n

• API GET uç noktaları: durumuna göre kısa süreli public cache veya private + ETag

n

• Login ve kullanıcıya özel veri dönen uç noktalar: no-store, Vary Authorization ve CDN cache bypass

n

n

Bu senaryoların tamamında ortak nokta şu: Önbellekleme stratejisi sadece bir header eklemekten ibaret değil. Uygulama katmanı, web sunucusu, CDN ve tarayıcı birlikte düşünülüyor. DCHost ekibi olarak yeni bir proje göçü veya kapasite planlaması yaparken, bu dörtlüyü her zaman beraber masaya yatırıyoruz.

nn

Sonuç: HTTP Önbelleği Doğru Kurulduğunda Ne Kazanırsınız

n

HTTP Cache-Control başlıkları, ETag ve CDN önbellek kuralları doğru kurgulandığında ortaya üç somut kazanım çıkar: Son kullanıcı için belirgin hız artışı, sunucu kaynak kullanımında ciddi azalma ve altyapı maliyetinde gözle görülür düşüş. WordPress tarafında statik varlıkları uzun süreli cacheleyip HTML için akıllı bir tam sayfa cache kurduğunuzda, aynı donanım üzerinde çok daha fazla trafiği rahatlıkla kaldırabilirsiniz. Laravel ve SPA projelerinde ise hashli assetler için agresif cache, index.html ve API cevapları için dengeli bir stratejiyle birleştiğinde, hem yeni deploylarda hem de pik trafikte sistemi ayakta tutmak çok daha kolay hale gelir.

n

Buradan sonra atabileceğiniz en mantıklı adım, mevcut sitenizin HTTP başlıklarını ve CDN kurallarını gözden geçirmek. Tarayıcı tarafında hangi dosya ne kadar süre cacheleniyor, CDN katmanında hangi pathler HTML cacheleniyor, login veya ödeme sayfaları güvenli mi; hepsini tek tek kontrol edin. İsterseniz, DCHost üzerindeki WordPress, Laravel veya SPA projelerinizi incelerken sizin için özelleştirilmiş bir önbellek stratejisi de çıkarabiliriz. Altyapı tarafında NVMe diskli VPS, dedicated sunucu veya colocation seçenekleriyle, doğru HTTP önbellekleme ayarlarını destekleyen güçlü bir temel kurmak mümkün. Kısacası; önce HTTP başlıklarını temizleyin, ardından ihtiyacınıza uygun DCHost altyapısı ile bu stratejiyi güvenle büyütün.

n”,
“focus_keyword”: “HTTP Cache-Control ve ETag”,
“meta_description”: “HTTP Cache-Control, ETag ve CDN önbellek kuralları ile WordPress, Laravel ve SPA projelerinde tarayıcı cacheini doğru kurarak hızı ve ölçeklenebilirliği artırın.”,
“faqs”: [
{
“question”: “HTTP Cache-Control ile ETag arasındaki fark nedir, hangisini ne zaman kullanmalıyım?”,
“answer”: “Cache-Control, içeriğin ne kadar süre ve kimler tarafından (tarayıcı mı, CDN mi) cachelenebileceğini söyleyen politika başlığıdır. Yani tazelik süresi ve cachelenebilirlik kurallarını belirler. ETag ise içeriğin benzersiz bir kimliği gibi çalışır; tarayıcı bir sonraki istekte If-None-Match ile bu değeri gönderir ve içerik değişmediyse sunucu 304 Not Modified döndürür. Pratikte statik dosyalar için uzun max-age ve çoğu zaman ETage ihtiyaç duymadan, hashli dosya isimleriyle cache busting kullanmak en sağlıklı yaklaşımdır. Dinamik HTML ve API cevaplarında ise daha kısa max-age değerleri ile birlikte ETag veya Last-Modified kullanmak, gereksiz veri transferini azaltırken güncel içeriği de garanti altına alır.”
},
{
“question”: “WordPress sitemde hangi dosyaları ne kadar süre cachelemeliyim?”,
“answer”: “WordPress için genel yaklaşım şu olabilir: Tema ve eklenti dosyalarınızın ürettiği CSS ve JS dosyaları, ayrıca görseller ve fontlar genellikle versiyon parametresi veya hashli isimlerle servis edilir. Bu dosyalar için Cache-Control public, max-age=2592000 veya 31536000 gibi uzun süreler ve immutable direktifi oldukça güvenlidir. Çünkü dosya içeriği değiştiğinde isim veya versiyon parametresi de değişir, tarayıcı yeni dosyayı indirir. HTML sayfalar içinse tam sayfa cache kullanıyorsanız sunucu tarafında 60–300 saniyelik mikro cache, tarayıcı tarafında ise kısa max-age veya no-cache tercih edebilirsiniz. WooCommerce sepet, ödeme ve hesap sayfaları için mutlaka no-store ve cache bypass kuralları kullanmak gerekir.”
},
{
“question”: “SPA (React, Vue, Angular) projelerinde index.html ve JS bundleları için nasıl bir önbellek stratejisi izlemeliyim?”,
“answer”: “SPA projelerinde index.html ve JS bundleları farklı davranır. index.html küçüktür ancak yeni deploylarda en güncel versiyonun hızla yayılması çok önemlidir. Bu yüzden index.html için genellikle Cache-Control no-cache veya kısa bir max-age (örneğin 60 saniye) ve ETag veya Last-Modified ile koşullu istek desteği önerilir. JS ve CSS bundleları ise hashli dosya isimleriyle üretilir; bu dosyalar için Cache-Control public, max-age=31536000, immutable gibi agresif bir politika kullanmak en doğrusudur. Böylece kullanıcı siteye tekrar girdiğinde büyük bundleları yeniden indirmek zorunda kalmaz, sadece index.html üzerinden yeni versiyon kontrolü yapılır. CDN kullanıyorsanız, HTML ve service worker dosyaları için ayrıca cache bypass veya kısa TTL kuralları tanımlamayı da unutmayın.”
},
{
“question”: “CDN kullanırken Cache-Control başlıklarını mı yoksa CDN panelindeki kuralları mı esas almalıyım?”,
“answer”: “İdeal senaryoda origin sunucunuzda ürettiğiniz Cache-Control, ETag, Last-Modified ve Vary başlıkları ana kaynaktır, CDN ise bunları varsayılan olarak takip eder. Ancak pratikte, kritik pathler için CDN panelinde istisnai kurallar tanımlamak gerekir. Örneğin wp-admin ve wp-login.php gibi yolları tamamen cache dışı bırakmak, WooCommerce sepet ve ödeme sayfalarını HTML cacheinden muaf tutmak için CDN kuralları şarttır. Statik dosyalar için ise genellikle origin başlıklarına güvenip CDN düzeyinde sadece bazı override ve minimum TTL kuralları koymak yeterlidir. Kısa özetle: Politikanın iskeletini origin üzerinde kurun, CDN kurallarını ise özel durumlar ve güvenlik için tamamlayıcı olarak düşünün.”
}
]
}