.htaccess ile Tarayıcı Önbelleği ve Gzip Sıkıştırma Açma

PageSpeed Insights raporunu açtınız ve "Fırsatlar" bölümünde iki satır sizi bekliyor: "Metin sıkıştırmayı etkinleştirin" ve "Statik öğeleri verimli bir önbellek politikasıyla sunun". Yanlarında da tahmini kazanç yazıyor: 1,2 saniye ve 0,8 saniye. Toplamda iki saniye, üstelik tek bir satır PHP kodu yazmadan.

Bu iki uyarının ortak noktası, ikisinin de uygulama katmanıyla ilgisi olmamasıdır. Ne temanızda ne eklentinizde bir sorun var; web sunucusu, tarayıcıya yanıt verirken iki şeyi yapmıyor: içeriği sıkıştırmıyor ve "bu dosyayı bir daha isteme, sende dursun" demiyor. Apache tabanlı bir paylaşımlı hostingteyseniz ikisini de .htaccess dosyasına eklenecek iki blok çözer.

Bu yazıda önce kopyalayıp yapıştırabileceğiniz eksiksiz bloğu vereceğiz, sonra her satırın ne yaptığını açıklayacağız. Ardından asıl önemli kısma geçeceğiz: dosya türüne göre süreyi nasıl seçeceğiniz, yaptığınız değişikliğin gerçekten çalıştığını yanıt başlıklarından nasıl doğrulayacağınız ve sunucunuz Apache değil de LiteSpeed veya nginx ise neyin değişeceği. Sonunda tarayıcı geliştirici araçlarına bakmadan, tek bir komutla kazancınızı ölçebiliyor olacaksınız.

Kopyala Yapıştır: Tam .htaccess Bloğu#

Aşağıdaki bloğu public_html/.htaccess dosyanızın en üstüne ekleyin. WordPress kullanıyorsanız # BEGIN WordPress satırının üzerine koyun; WordPress kendi bloğunu zaman zaman yeniden yazar ve kendi işaretçileri arasındaki her şeyi silebilir.

Değişiklik yapmadan önce mevcut dosyanın bir kopyasını alın. Dosyanın konumu, izinleri ve yedekleme yöntemi konusunda emin değilseniz .htaccess dosyası oluşturma yazısı bu adımı ayrıntılı anlatıyor.

# ---------- 1) SIKIŞTIRMA (mod_deflate) ----------
<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css
    AddOutputFilterByType DEFLATE application/javascript application/x-javascript
    AddOutputFilterByType DEFLATE application/json application/xml application/rss+xml
    AddOutputFilterByType DEFLATE image/svg+xml application/vnd.ms-fontobject
    AddOutputFilterByType DEFLATE font/ttf font/otf application/x-font-ttf

    # Zaten sıkıştırılmış dosyaları tekrar sıkıştırma
    SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|webp|avif|ico|zip|gz|rar|7z|mp3|mp4|webm|pdf|woff2?)$ no-gzip dont-vary

    # CPU / kazanç dengesi: 1 en hızlı, 9 en yüksek oran
    DeflateCompressionLevel 6
</IfModule>

# ---------- 2) TARAYICI ÖNBELLEĞİ (mod_expires) ----------
<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresDefault                          "access plus 1 week"

    # HTML asla uzun süre önbelleklenmez
    ExpiresByType text/html                 "access plus 0 seconds"

    # Sürümlenen varlıklar: uzun ömür
    ExpiresByType text/css                  "access plus 1 year"
    ExpiresByType application/javascript    "access plus 1 year"
    ExpiresByType application/x-javascript  "access plus 1 year"

    # Görseller
    ExpiresByType image/jpeg                "access plus 6 months"
    ExpiresByType image/png                 "access plus 6 months"
    ExpiresByType image/webp                "access plus 6 months"
    ExpiresByType image/avif                "access plus 6 months"
    ExpiresByType image/svg+xml             "access plus 6 months"
    ExpiresByType image/x-icon              "access plus 1 year"

    # Yazı tipleri
    ExpiresByType font/woff2                "access plus 1 year"
    ExpiresByType font/woff                 "access plus 1 year"
    ExpiresByType application/font-woff2    "access plus 1 year"

    # Beslemeler ve manifest
    ExpiresByType application/rss+xml       "access plus 1 hour"
    ExpiresByType application/manifest+json "access plus 1 week"
</IfModule>

# ---------- 3) BAŞLIK İNCE AYARI (mod_headers) ----------
<IfModule mod_headers.c>
    <FilesMatch "\.(css|js|woff2?|ttf|otf|eot)$">
        Header set Cache-Control "public, max-age=31536000, immutable"
    </FilesMatch>

    <FilesMatch "\.(jpe?g|png|gif|webp|avif|svg|ico)$">
        Header set Cache-Control "public, max-age=15552000"
    </FilesMatch>

    <FilesMatch "\.(html|htm|php)$">
        Header set Cache-Control "no-cache, must-revalidate"
    </FilesMatch>

    Header append Vary Accept-Encoding
</IfModule>

Blok bu haliyle çalışır, ama körlemesine bırakmayın: özellikle immutable satırı, dosya adlarınız sürümlenmiyorsa size ters teper. Nedenini birazdan göreceğiz.

Sıkıştırma Bloğu Satır Satır Ne Yapıyor?#

mod_deflate, Apache'nin yanıt gövdesini istemciye göndermeden önce gzip ile sıkıştıran modülüdür. Tarayıcı isteğinde Accept-Encoding: gzip başlığını gönderir, sunucu destekliyorsa sıkıştırılmış sürümü ve Content-Encoding: gzip yanıt başlığını döner. Sıkıştırma açma işini tarayıcı, kullanıcı hiçbir şey fark etmeden yapar.

AddOutputFilterByType DEFLATE ... satırları, hangi içerik türlerinin sıkıştırılacağını belirler. MIME türüne göre çalışır, dosya uzantısına göre değil. Bu ayrım önemlidir: PHP tarafından üretilen bir sayfanın uzantısı .php olabilir ama gönderdiği Content-Type başlığı text/html olduğu için doğru kurala takılır.

Sıkıştırmadan gerçek kazanç metin tabanlı dosyalarda gelir. Kabaca beklenebilecek oranlar:

SetEnvIfNoCase Request_URI ... no-gzip dont-vary satırı işte bu son üç satır için var. Zaten sıkıştırılmış bir dosyayı tekrar sıkıştırmak boyutu düşürmez, hatta bazen birkaç bayt büyütür; buna karşılık her istekte CPU harcar. Paylaşımlı hostingte bu, kaynak limitine dayanmanın sessiz sebeplerinden biridir.

DeflateCompressionLevel 6 sıkıştırma agresifliğini belirler. 1 en hızlı ve en zayıf, 9 en yavaş ve en güçlüdür. Ölçtüğünüzde 6'dan 9'a çıkmak dosya boyutunda genellikle yalnızca %2-4 kazandırır ama CPU maliyetini belirgin biçimde artırır. Yoğun trafikli bir sitede 6 dengeli seçimdir; direktifi hiç yazmazsanız zlib'in varsayılanı zaten bu civarda çalışır.

Header append Vary Accept-Encoding ise ara önbellekler (CDN, vekil sunucu) içindir. Bu başlık olmadan bir ara önbellek, sıkıştırılmış yanıtı gzip desteklemeyen eski bir istemciye servis edebilir; sonuç bozuk görünen bir sayfadır.

cPanel kullanıyorsanız aynı sıkıştırmayı Software → Optimize Website ekranından tıklamayla da açabilirsiniz; arayüzün ne yaptığı ve hangi türleri seçmeniz gerektiği cPanel Optimize Website yazısında ayrıntılı anlatılıyor. İki yöntemi aynı anda kullanmayın; ikisi de aynı .htaccess dosyasına yazar ve çakışan bloklar üretir.

Önbellek Bloğu: Expires ile Cache-Control Farkı#

Burada iki farklı mekanizma var ve karıştırılması yaygın bir hata.

Expires başlığı, HTTP/1.0 döneminden kalma mutlak bir tarih verir: "bu dosya 12 Şubat 2027 saat 10:00'a kadar geçerlidir". Sunucu ve istemci saatleri arasındaki fark bu yöntemi kırılgan yapar.

Cache-Control: max-age ise göreli bir süre söyler: "bu yanıtı aldığın andan itibaren 31536000 saniye boyunca tekrar sorma". Saat farkından etkilenmez ve modern tarayıcıların tamamı bunu Expires başlığına tercih eder.

mod_expires her ikisini birden üretir; ExpiresByType text/css "access plus 1 year" yazdığınızda hem Expires hem de Cache-Control: max-age=31536000 yanıta eklenir. Yani üçüncü bloktaki mod_headers satırları teknik olarak zorunlu değildir — ama iki şey eklerler:

• public: yanıtın yalnızca tarayıcı tarafından değil, aradaki paylaşımlı önbellekler tarafından da saklanabileceğini söyler.
• immutable: "bu dosya süresi dolana kadar asla değişmeyecek" taahhüdüdür. Bu başlığı gören tarayıcı, kullanıcı sayfayı yenilediğinde bile dosyayı doğrulamak için sunucuya 304 sorgusu göndermez. Yenileme başına düzinelerce gereksiz istek ortadan kalkar.

immutable güçlü ama koşulludur ve koşulu şudur: dosya adı sürümlenmiş olmalıdır. app.7f3c9a1.css gibi içerik özetini adında taşıyan bir dosya için idealdir. Buna karşılık düz style.css için immutable koymak, temanızı güncellediğinizde bazı ziyaretçilerin bir yıl boyunca eski CSS'i görmesi anlamına gelir. Emin değilseniz bloktan immutable kelimesini çıkarın; geri kalan her şey aynı kalır.

Hangi Dosya Türüne Ne Kadar Süre Vermeli?#

Süre seçimi teknik değil, editoryal bir karardır: bu dosyayı ne sıklıkla değiştiriyorum?

Pratik kural: HTML'e asla uzun süre vermeyin. En sık yapılan ve en pahalıya patlayan hata budur. ExpiresDefault satırını text/html istisnası olmadan bırakırsanız, sitenizde yaptığınız her değişiklik ziyaretçilerin bir bölümüne haftalarca ulaşmaz — üstelik tarayıcı önbelleğini uzaktan temizlemenin bir yolu yoktur.

Öte yandan aşırı temkinli davranıp her şeye birkaç saat vermek de kazancı yok eder. Tekrar eden ziyaretçi oranınız düşük olsa bile, tek bir oturumda gezilen 5 sayfa aynı CSS, JS ve logoyu 5 kez indirmemelidir.

Sıkıştırmanın Gerçekten Çalıştığını Nasıl Doğrularsınız?#

Blok dosyada duruyor olması çalıştığı anlamına gelmez. Modül devre dışı olabilir, sağlayıcı AllowOverride ile bu direktifleri kapatmış olabilir ya da başka bir blok sizinkini eziyor olabilir. Tek doğru kanıt yanıt başlıklarıdır.

curl -sI -H 'Accept-Encoding: gzip, br' https://ornek.com/ \
  | grep -iE 'content-encoding|vary|content-type'

Beklenen çıktı şuna benzer:

content-type: text/html; charset=UTF-8
content-encoding: gzip
vary: Accept-Encoding

content-encoding satırı hiç yoksa sıkıştırma çalışmıyor demektir. Aynı testi bir CSS dosyası için de yapın; HTML sıkışıp CSS sıkışmıyorsa MIME türü listenizde eksik bir satır var.

Kazancı sayıyla görmek isterseniz aynı dosyayı iki kez, sıkıştırmalı ve sıkıştırmasız isteyip inen bayt sayısını karşılaştırın:

URL="https://ornek.com/wp-content/themes/tema/style.css"

echo -n "Sıkıştırmasız: "
curl -s -o /dev/null -w '%{size_download} bayt\n' "$URL"

echo -n "Gzip ile     : "
curl -s -o /dev/null -H 'Accept-Encoding: gzip' -w '%{size_download} bayt\n' "$URL"

İkinci rakam birincinin dörtte biri civarındaysa iş tamamdır. İki rakam birbirine eşitse sıkıştırma uygulanmıyordur.

Tarayıcıdan bakmayı tercih ederseniz geliştirici araçlarında Network sekmesini açın; "Size" sütununda üstteki değer inen boyutu, alttaki ise açılmış boyutu gösterir. Sayfa geneli ölçüm için GTmetrix ile hız testi gibi araçlar, sıkıştırılmamış dosyaları tek tek listeleyerek eksik MIME türlerini bulmayı kolaylaştırır.

Önbelleğin Çalıştığını Doğrulama ve 304 Yanıtları#

Önbellek tarafında iki şeyi ayrı ayrı kontrol edeceğiz.

Başlıklar doğru mu?

curl -sI https://ornek.com/wp-content/themes/tema/style.css \
  | grep -iE 'cache-control|expires|etag|last-modified'

cache-control: public, max-age=31536000 görüyorsanız kural uygulanmıştır.

Tarayıcı gerçekten tekrar indirmiyor mu? Bunu If-Modified-Since ile taklit edebilirsiniz. Önce dosyanın last-modified değerini alın, sonra o tarihi geri gönderin:

curl -sI -H 'If-Modified-Since: Mon, 04 Aug 2026 09:12:00 GMT' \
  https://ornek.com/wp-content/themes/tema/style.css | head -1

Yanıt HTTP/2 304 ise sunucu "dosya değişmedi, sendekini kullan" diyor ve gövdeyi hiç göndermiyor demektir. Bu, önbelleğin ikinci savunma hattıdır: max-age süresi dolduğunda bile dosya değişmediyse yalnızca birkaç yüz baytlık bir başlık trafiği oluşur.

Bazı yapılandırmalarda ETag başlığı ile max-age birlikte sorun çıkarır; özellikle yük dengeli çoklu sunucu kurulumlarında her sunucu farklı ETag üretir ve önbellek sürekli geçersizleşir. Tek sunuculu paylaşımlı hostingte bu bir sorun değildir, ama isterseniz Last-Modified yeterli olduğu için ETag'ı kapatabilirsiniz:

FileETag None
<IfModule mod_headers.c>
    Header unset ETag
</IfModule>

Dosya Değişince Önbellek Nasıl Kırılır?#

Uzun süreli önbelleğin tek bedeli şudur: bir dosyayı güncellediğinizde, süre dolana kadar geri dönen ziyaretçiler eski sürümü görür. Çözüm dosya adını değiştirmektir — buna cache busting denir.

En basit yöntem sorgu parametresi eklemektir:

/assets/style.css?v=20260818

Sürüm numarasını her yayında artırırsanız tarayıcı bunu yeni bir adres sayar ve dosyayı tekrar indirir. WordPress bunu wp_enqueue_style() fonksiyonunun dördüncü parametresiyle zaten yapar:

wp_enqueue_style(
    'tema-ana',
    get_stylesheet_directory_uri() . '/style.css',
    array(),
    '2.4.1'      // bu değeri her güncellemede değiştirin
);

Daha sağlamı, adı doğrudan değiştirmektir: style.a91f3c.css. Bazı CDN ve vekil sunucular sorgu parametreli adresleri önbelleklemekte tutarsız davranır; ad değişikliği bu belirsizliği tamamen ortadan kaldırır. Derleme aracı kullanan projelerde bu zaten varsayılan davranıştır ve immutable başlığını güvenle kullanabileceğiniz senaryo tam olarak budur.

Acil bir durumda tüm ziyaretçileri tazelemek istiyorsanız — örneğin bozuk bir CSS yayınladıysanız — süreyi geçici olarak kısaltıp bir gün sonra geri almak, yanlış dosyayı adres adres kovalamaktan hızlıdır.

LiteSpeed, nginx ve Cloudflare'de Ne Değişir?#

.htaccess bir Apache dosyasıdır, ama karşılığı olan üç yaygın senaryo var.

LiteSpeed / OpenLiteSpeed. Bugün pek çok cPanel sunucusu Apache yerine LiteSpeed çalıştırır. LiteSpeed .htaccess dosyasını okur ve mod_expires, mod_headers, mod_rewrite direktiflerini Apache'ye uyumlu biçimde uygular; yukarıdaki 2. ve 3. bloklar aynen çalışır. Sıkıştırma tarafında ise LiteSpeed'in kendi yapılandırması vardır ve genellikle sunucu düzeyinde zaten açıktır. Bu durumda mod_deflate bloğu zararsızdır ama yeni bir şey kazandırmaz — hatta content-encoding: br görüyorsanız LiteSpeed sizin isteğinizden daha iyisini yapıyor demektir. Doğrulama komutunu çalıştırın: sıkıştırma zaten varsa 1. bloğu eklemeye gerek yoktur.

nginx. nginx .htaccess dosyasını hiç okumaz; dosyayı koymanız hiçbir şey yapmaz. Karşılığını sunucu ya da site bloğuna yazmanız gerekir:

gzip              on;
gzip_comp_level   6;
gzip_min_length   1024;
gzip_vary         on;
gzip_proxied      any;
gzip_types        text/plain text/css text/xml
                  application/javascript application/json
                  application/rss+xml image/svg+xml;

location ~* \.(css|js|woff2)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

location ~* \.(jpg|jpeg|png|gif|webp|avif|svg|ico)$ {
    expires 6M;
    add_header Cache-Control "public";
}

gzip_types listesinde text/html yazmanıza gerek yoktur; nginx onu her zaman sıkıştırır. Brotli desteği ve ince ayarlar için nginx gzip ve Brotli sıkıştırma yazısına bakabilirsiniz.

Cloudflare veya başka bir CDN önde. Bu durumda ziyaretçinin gördüğü başlıklar CDN'in ürettikleridir. Cloudflare metin dosyalarını kendi kenar düğümlerinde zaten sıkıştırır, dolayısıyla content-encoding başlığını görmeniz origin sunucunuzun doğru yapılandırıldığı anlamına gelmez. Origin'i ayrı test etmek için isteği doğrudan sunucu IP'sine gönderin:

curl -sI --resolve ornek.com:443:203.0.113.10 \
  -H 'Accept-Encoding: gzip' https://ornek.com/ | grep -i content-encoding

Ayrıca CDN'in kendi Edge Cache TTL ayarı, sizin max-age değerinizi ezebilir; iki tarafı da kontrol etmeden "önbellek çalışmıyor" sonucuna varmayın.

Sık Yapılan Hatalar ve 500 Hatasından Dönüş#

Site 500 Internal Server Error veriyor. .htaccess dosyasında desteklenmeyen bir direktif varsa Apache tüm siteyi kapatır. En sık sebep, sunucuda bulunmayan bir modüle ait direktifin IfModule sarmalayıcısı olmadan yazılmasıdır. Yukarıdaki blokta üç kısmın da IfModule içinde olması tam olarak bu yüzdendir: modül yoksa blok sessizce atlanır. Yine de hata alırsanız eklediğiniz bloğu silin, sitenin açıldığını doğrulayın, sonra blokları teker teker geri ekleyerek suçluyu bulun. Hatanın kesin satırı için cPanel hata kayıtları ekranındaki error log'a bakın.

Blok var ama hiçbir şey değişmiyor. İki olasılık var. Birincisi, sağlayıcı AllowOverride ayarıyla bu direktifleri kapatmıştır — destek talebiyle sorun. İkincisi, aynı dosyada daha aşağıda başka bir blok sizinkini eziyordur; .htaccess yukarıdan aşağıya işlenir ve aynı türden sonraki kural genellikle kazanır. Dosyanın tamamını okuyup mükerrer ExpiresByType satırı olup olmadığına bakın.

Değişiklik yaptım ama sitede eskisi görünüyor. Kendi tarayıcınız dosyayı önbelleğe almıştır. Test ederken gizli pencere kullanın ya da doğrulamayı curl ile yapın; curl hiçbir zaman önbellek kullanmaz, bu yüzden bu işin en güvenilir aracıdır.

Yönetim paneli bozuldu. WordPress yönetim ekranı, tema düzenleyicisi ya da bir eklentinin AJAX çağrıları no-cache istiyor olabilir. Üçüncü bloktaki FilesMatch kuralları uzantı bazlı çalıştığı için admin-ajax.php gibi dosyalar da .php kalıbına takılır — bu genellikle istenen davranıştır, ama sorun yaşarsanız o satırı kaldırıp mod_expires blokundaki text/html istisnasına güvenin.

Aynı işi iki kez yapmak. Bir önbellek eklentisi (LiteSpeed Cache, W3 Total Cache, WP Rocket) zaten kendi .htaccess bloğunu yazıyorsa sizinki ile çakışabilir. Eklenti kullanıyorsanız kuralları elle eklemek yerine eklentinin ayarlarından açın; genel yaklaşım için WordPress hız optimizasyonu yazısına bakın.

Sıkça Sorulan Sorular#

Gzip sıkıştırma sunucuyu yavaşlatır mı?#

Sıkıştırma CPU harcar, ama ölçtüğünüzde kazanç neredeyse her zaman maliyetten büyüktür. Tipik bir HTML sayfasını 6. seviyede sıkıştırmak milisaniyenin küçük bir kesrini alırken, aktarılacak veri üçte birine iner. Asıl risk, zaten sıkıştırılmış görsel ve arşiv dosyalarını da sıkıştırmaya çalışmaktır; bu hiçbir kazanç sağlamadan CPU yakar. Bloktaki no-gzip satırı tam olarak bunu engeller.

Tarayıcı önbelleği açtım, sitede yaptığım değişiklikler görünmüyor. Ne yapmalıyım?#

Muhtemelen HTML'e uzun bir süre verdiniz. ExpiresByType text/html satırının access plus 0 seconds olduğundan emin olun. CSS ve JavaScript dosyaları için çözüm farklıdır: dosya adına sürüm ekleyin ya da adresin sonuna ?v= parametresi koyup her güncellemede değerini değiştirin. Zaten önbelleğe girmiş ziyaretçiler için geriye dönük bir temizleme yöntemi yoktur; yeni adres tek çözümdür.

Sıkıştırmanın çalıştığını anlamanın en kesin yolu nedir?#

Yanıt başlıklarına bakmak. Terminalden curl -sI -H 'Accept-Encoding: gzip' https://siteniz.com/ komutunu çalıştırın ve çıktıda content-encoding: gzip satırını arayın. Bu satır varsa sıkıştırma çalışıyordur, yoksa çalışmıyordur. Online test araçları da aynı bilgiyi verir ama ara katmanlar yüzünden yanıltıcı olabilir; curl doğrudan sunucunun söylediğini gösterir.

Brotli, gzip'ten daha mı iyi? .htaccess ile açabilir miyim?#

Brotli aynı içerikte gzip'e göre genellikle %15-20 daha küçük çıktı üretir ve tüm modern tarayıcılar destekler. Ancak Apache'de Brotli, mod_brotli modülünü gerektirir ve paylaşımlı hostinglerin çoğunda .htaccess üzerinden açılamaz; sunucu düzeyinde etkin olması gerekir. LiteSpeed sunucularda ve Cloudflare arkasında Brotli çoğu zaman zaten devrededir. Yanıtta content-encoding: br görüyorsanız ek bir işlem yapmanıza gerek yok.

max-age değerini bir yıl vermek riskli değil mi?#

Dosya adı sürümlenmişse hiç riskli değildir, standart uygulamadır. Riskli olan senaryo, adı hiç değişmeyen bir style.css dosyasına bir yıl verip immutable eklemektir: temayı güncellediğinizde geri dönen ziyaretçiler eski stili görmeye devam eder. Sürümleme yapmıyorsanız CSS ve JavaScript için bir hafta ile bir ay arası makul bir aralıktır; görseller ve yazı tipleri için uzun süre güvenlidir.

cPanel'deki Optimize Website aracını kullansam yeter mi?#

Sıkıştırma için genellikle yeter; o araç arka planda aynı mod_deflate bloğunu .htaccess dosyanıza yazar. Ancak yalnızca sıkıştırmayı kapsar, tarayıcı önbelleğine hiç dokunmaz. PageSpeed raporundaki "statik öğeleri önbelleğe alın" uyarısı için mod_expires bloğunu yine elle eklemeniz gerekir. İki yöntemi karıştırmayın: araç zaten bir blok yazdıysa siz ikinci bir sıkıştırma bloğu eklemeyin.