IIS’te Gzip Sıkıştırma ile Sayfa Hızı Optimizasyonu

Yazar:komut.io ekibi IIS Web Sunucusu Kurulum ve Yönetimi
0 Yorum

Performans sorunlarıyla boğuşan bir IIS sunucusunu devreye aldığınızda, ilk bakmanız gereken yerlerden biri sıkıştırma ayarlarıdır. Yıllar içinde gördüğüm kadarıyla, production ortamında düzgün yapılandırılmamış ya da hiç açılmamış Gzip sıkıştırması yüzünden gereksiz bant genişliği harcayan ve yavaş yüklenen siteler bir hayli fazla. Bu yazıda IIS üzerinde Gzip sıkıştırmasını en ince ayrıntısına kadar ele alacağız; hem statik hem dinamik içerik için nasıl yapılandırılacağını, olası tuzakları ve gerçek ortamlarda işe yarayan optimizasyon tekniklerini aktaracağım.

Gzip Sıkıştırma Neden Bu Kadar Önemli?

Sıkıştırma konusunu “zaten CDN kullanıyoruz, gerek yok” diye geçiştirdiğinizde aslında masada para bırakıyorsunuz demektir. CDN kullanıyor olmanız, origin sunucunuzun sıkıştırma yapmaması gerektiği anlamına gelmiyor; aksine CDN edge noktalarına sıkıştırılmış içerik göndermeniz cache verimliliğini de artırır.

Somut bir örnek vermem gerekirse: Ortalama bir kurumsal web sayfası, sıkıştırma olmadan 800 KB ile 1.5 MB arasında veri transfer eder. Gzip sıkıştırmasını devreye aldıktan sonra bu değer HTML, CSS ve JavaScript için yüzde 60 ile 80 oranında düşebilir. Türkiye’deki mobil kullanıcıları düşünürsek, bu fark yalnızca hız değil, veri maliyeti açısından da kullanıcı deneyimini doğrudan etkiliyor.

IIS’in sıkıştırma mimarisini anlamak önemli çünkü Apache veya Nginx’ten farklı çalışıyor. IIS iki ayrı modülle bunu yönetiyor:

  • Statik Sıkıştırma (Static Compression): Değişmeyen dosyaları (CSS, JS, resim olmayan içerikler) sıkıştırarak disk üzerinde önbelleğe alır
  • Dinamik Sıkıştırma (Dynamic Compression): Her request’te anlık olarak sıkıştırma yapar, ASP.NET çıktıları için idealdir

IIS’te Sıkıştırmayı Aktif Etmek

Rol Özelliklerinin Kurulumu

Öncelikle Windows Server’da sıkıştırma modüllerinin yüklü olduğundan emin olmanız gerekiyor. Bu modüller varsayılan IIS kurulumunda gelmiyor, ayrıca yüklemeniz gerekiyor.

Install-WindowsFeature -Name Web-Stat-Compression, Web-Dyn-Compression

PowerShell üzerinden kurulumu yaptıktan sonra IIS Manager’ı yeniden başlatmanıza gerek yok, doğrudan yapılandırmaya geçebilirsiniz. Sunucuda IIS Manager açık kalıyorsa bir F5 basmanız yeterli.

ApplicationHost.config Üzerinden Temel Yapılandırma

IIS’in ana yapılandırma dosyası olan ApplicationHost.config üzerinde çalışmak, GUI’ye tıklamaktan çok daha hızlı ve tekrarlanabilir bir süreç sağlar. Bu dosya genellikle şu konumda bulunur: C:WindowsSystem32inetsrvconfigapplicationHost.config

Sıkıştırma ayarlarını bloğu içinde yönetiyoruz:

# applicationHost.config içindeki httpCompression bloğu örneği
<httpCompression directory="%SystemDrive%inetpubtempIIS Temporary Compressed Files"
                 doDiskSpaceLimiting="true"
                 maxDiskSpaceUsage="100"
                 minFileSizeForComp="2700">
    <scheme name="gzip" dll="%Windir%system32inetsrvgzip.dll" />
    <staticTypes>
        <add mimeType="text/*" enabled="true" />
        <add mimeType="message/*" enabled="true" />
        <add mimeType="application/javascript" enabled="true" />
        <add mimeType="application/json" enabled="true" />
        <add mimeType="application/xml" enabled="true" />
        <add mimeType="*/*" enabled="false" />
    </staticTypes>
    <dynamicTypes>
        <add mimeType="text/*" enabled="true" />
        <add mimeType="message/*" enabled="true" />
        <add mimeType="application/javascript" enabled="true" />
        <add mimeType="application/json" enabled="true" />
        <add mimeType="*/*" enabled="false" />
    </dynamicTypes>
</httpCompression>

Burada dikkat edilmesi gereken bazı parametreler var:

  • minFileSizeForComp: 2700 byte altındaki dosyalar sıkıştırılmaz; küçük dosyaları sıkıştırmak CPU harcar ama anlamlı bir kazanım sağlamaz
  • maxDiskSpaceUsage: Statik sıkıştırma önbelleği için MB cinsinden disk alanı limiti
  • doDiskSpaceLimiting: Disk limitini aktif eder, production’da mutlaka açık tutun

PowerShell ile Sıkıştırmayı Yapılandırma

IIS Administration modülünü kullanarak tüm yapılandırmayı script üzerinden yönetmek, özellikle birden fazla sunucu yönetiyorsanız hayat kurtarır:

# WebAdministration modülünü import et
Import-Module WebAdministration

# Sunucu genelinde statik sıkıştırmayı aktif et
Set-WebConfigurationProperty -Filter "system.webServer/urlCompression" `
    -Name "doStaticCompression" `
    -Value "True" `
    -PSPath "MACHINE/WEBROOT/APPHOST"

# Sunucu genelinde dinamik sıkıştırmayı aktif et
Set-WebConfigurationProperty -Filter "system.webServer/urlCompression" `
    -Name "doDynamicCompression" `
    -Value "True" `
    -PSPath "MACHINE/WEBROOT/APPHOST"

# Sıkıştırma seviyesini ayarla (0-10 arası, 7 genellikle iyi denge noktası)
Set-WebConfigurationProperty -Filter "system.webServer/httpCompression/scheme[@name='gzip']" `
    -Name "staticCompressionLevel" `
    -Value "7" `
    -PSPath "MACHINE/WEBROOT/APPHOST"

Dinamik sıkıştırmada seviye ayarı genellikle 4 ile 6 arasında tutulur çünkü her request’te CPU harcıyorsunuz. Statik içerikler için ise 7 ile 9 arası rahatlıkla kullanılabilir; o dosyalar bir kez sıkıştırılıp önbelleğe alınıyor.

Site Bazında Özelleştirme

Bazen sunucu genelinde ayar yapmak istemezsiniz; belki bir siteniz yoğun API trafiği alıyor ve sıkıştırmayı sadece o site için ayrı yapılandırmanız gerekiyor. Web.config dosyası üzerinden site bazında override yapabilirsiniz:

# Belirli bir site için sıkıştırmayı yapılandır
Set-WebConfigurationProperty -Filter "system.webServer/urlCompression" `
    -Name "doStaticCompression" `
    -Value "True" `
    -PSPath "MACHINE/WEBROOT/APPHOST" `
    -Location "SiteAdi"

Set-WebConfigurationProperty -Filter "system.webServer/urlCompression" `
    -Name "doDynamicCompression" `
    -Value "True" `
    -PSPath "MACHINE/WEBROOT/APPHOST" `
    -Location "SiteAdi"

Aynı yapılandırmayı sitenin web.config dosyasında da tanımlayabilirsiniz. Bu yaklaşım özellikle uygulamayı farklı ortamlara deploy ederken tutarlılık sağlar:

# web.config örneği - system.webServer bloğu içine eklenecek
<system.webServer>
    <urlCompression doStaticCompression="true" doDynamicCompression="true" />
    <httpCompression>
        <dynamicTypes>
            <clear />
            <add enabled="true" mimeType="text/*" />
            <add enabled="true" mimeType="application/json" />
            <add enabled="true" mimeType="application/javascript" />
            <add enabled="false" mimeType="*/*" />
        </dynamicTypes>
        <staticTypes>
            <clear />
            <add enabled="true" mimeType="text/*" />
            <add enabled="true" mimeType="application/javascript" />
            <add enabled="true" mimeType="application/json" />
            <add enabled="true" mimeType="application/xml" />
            <add enabled="false" mimeType="*/*" />
        </staticTypes>
    </httpCompression>
</system.webServer>

satırına dikkat edin. Bu, üst seviyede tanımlanmış MIME type listesini temizleyip kendi listenizi sıfırdan tanımlamanızı sağlar. Bunu yazmadan geçerseniz üst seviyedeki kurallar devrede kalmaya devam eder ve beklenmedik davranışlar görebilirsiniz.

Sıkıştırma Doğrulama ve Test

Yapılandırmayı bitirdikten sonra gerçekten çalışıp çalışmadığını test etmek zorundasınız. Teorik olarak her şeyi doğru yaptığınızı düşünebilirsiniz, ama production’da beklenmedik sürprizler her zaman mümkün.

En hızlı kontrol yöntemi curl kullanmak:

# Gzip sıkıştırma kontrolü - Accept-Encoding header'ı gönder
curl -I -H "Accept-Encoding: gzip, deflate" https://siteniz.com/ornek.js

# Yanıtta şunu görmelisiniz:
# Content-Encoding: gzip
# Vary: Accept-Encoding

Eğer Content-Encoding: gzip göremiyorsanız sıkıştırma çalışmıyor demektir. Bu durumda önce IIS modüllerinin gerçekten yüklü olduğunu kontrol edin.

PowerShell ile daha detaylı bir test yapabilirsiniz:

# PowerShell ile sıkıştırma testi
$request = [System.Net.WebRequest]::Create("https://siteniz.com/ornek.js")
$request.Headers.Add("Accept-Encoding", "gzip, deflate")
$response = $request.GetResponse()

Write-Host "Content-Encoding: $($response.Headers['Content-Encoding'])"
Write-Host "Content-Length: $($response.ContentLength)"
Write-Host "Vary: $($response.Headers['Vary'])"

$response.Close()

Gelişmiş Yapılandırma: Özel MIME Türleri Eklemek

Varsayılan IIS yapılandırması bazı modern içerik türlerini kapsamıyor. Özellikle JSON API’lar kullanıyorsanız veya SVG dosyaları servis ediyorsanız bunları da sıkıştırma listesine eklemeniz gerekiyor:

# Özel MIME türlerini statik sıkıştırmaya ekle
Add-WebConfigurationProperty -Filter "system.webServer/httpCompression/staticTypes" `
    -Name "." `
    -Value @{mimeType="image/svg+xml"; enabled="True"} `
    -PSPath "MACHINE/WEBROOT/APPHOST"

Add-WebConfigurationProperty -Filter "system.webServer/httpCompression/staticTypes" `
    -Name "." `
    -Value @{mimeType="application/wasm"; enabled="True"} `
    -PSPath "MACHINE/WEBROOT/APPHOST"

Add-WebConfigurationProperty -Filter "system.webServer/httpCompression/dynamicTypes" `
    -Name "." `
    -Value @{mimeType="application/json; charset=utf-8"; enabled="True"} `
    -PSPath "MACHINE/WEBROOT/APPHOST"

WebAssembly (.wasm) dosyalarının özellikle sıkıştırılması önemli çünkü bu dosyalar büyük olabiliyor ve sıkıştırmayla ciddi boyut avantajı sağlanabiliyor. Tabii .wasm dosyalarınız zaten pre-compressed geliyorsa buna gerek yok, ama çoğu IIS ortamında bu durum nadiren düşünülüyor.

Sık Karşılaşılan Sorunlar ve Çözümleri

Sıkıştırma Çalışmıyor: Olası Nedenler

Yapılandırmayı doğru yaptığınızı düşündüğünüz halde sıkıştırma çalışmıyorsa şu noktaları kontrol edin:

  • Modül yüklü değil: Get-WindowsFeature Web-Stat-Compression, Web-Dyn-Compression komutuyla kontrol edin
  • Kernel-mode önbellekleme çakışması: HTTP.sys seviyesindeki önbellekleme bazı durumlarda sıkıştırmayla çakışabilir
  • Antivirus müdahalesi: Geçici sıkıştırma dizinini bazı antivirüs yazılımları tarar ve kilitler; bu dizini exclusion listesine alın
  • Uygulama havuzu kimliği: Sıkıştırma önbellek dizinine yazma izni olduğunu kontrol edin

Çift Sıkıştırma Sorunu

Bu konuda gerçekten dikkatli olmanız gerekiyor. Özellikle bir load balancer veya reverse proxy arkasında çalışıyorsanız, hem proxy hem de IIS sıkıştırma yaparsa istemci tarafında “double encoding” hatası alabilirsiniz. Bunun için IIS’in sıkıştırma yapmasına gerek olmayan durumlarda yapılandırmayı kapatın veya proxy’nin sıkıştırmış olduğu içerikleri yeniden sıkıştırmaktan kaçının.

Bunu tespit etmek için response header’larına bakın. Eğer Content-Encoding: gzip, gzip gibi bir şey görüyorsanız sorun burada.

Statik Dosya Önbelleği Büyüme Sorunu

Uzun süre çalışan IIS sunucularında %SystemDrive%inetpubtempIIS Temporary Compressed Files dizini bazen beklenmedik şekilde büyüyebilir. Bunu izlemek ve periyodik temizlik yapmak için basit bir görev oluşturabilirsiniz:

# Eski sıkıştırma önbelleği dosyalarını temizle
# Bu komutu Scheduled Task olarak ayarlayabilirsiniz
$compCacheDir = "C:inetpubtempIIS Temporary Compressed Files"
$daysOld = 7

Get-ChildItem -Path $compCacheDir -Recurse -File | 
    Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-$daysOld) } |
    Remove-Item -Force

Write-Host "Eski sıkıştırma önbelleği dosyaları temizlendi."

Brotli Sıkıştırma: IIS’te Mümkün mü?

Modern tarayıcılar Gzip’ten daha verimli sıkıştırma sağlayan Brotli algoritmasını destekliyor. Apache ve Nginx’te bunu aktif etmek nispeten kolay, ama IIS’te durum biraz farklı.

IIS için native Brotli desteği yok; ancak üçüncü parti modüller mevcut. IIS Compression adıyla Microsoft’un GitHub’ında yayınladığı ve Brotli desteği sunan bir extension var. Bunu production’a almadan önce kapsamlı test yapmanızı öneririm; Microsoft resmi olarak desteklese de bazı ortamlarda stabilite sorunları yaşanabiliyor.

Eğer Azure App Service kullanıyorsanız Brotli desteği zaten geliyor, ayrıca bir şey yapmanıza gerek yok.

Performans Etkisini Ölçmek

Değişikliklerinizin gerçek etkisini görmek için önce ve sonra ölçüm yapmanız şart. Google PageSpeed Insights veya WebPageTest gibi araçlar genel bir fikir verse de asıl önemli olan kendi altyapınızdaki ölçümler.

IIS’in yerleşik logging özelliğini kullanarak transfer edilen veri miktarını zaman içinde karşılaştırabilirsiniz. W3C format loglarında sc-bytes alanı, sunucudan istemciye gönderilen byte sayısını gösterir. Sıkıştırmayı aktif etmeden önce ve sonra bu değerlerin ortalamasını karşılaştırdığınızda farkı net olarak göreceksiniz.

Pratik bir ölçüm için browser developer tools da yeterli. Network sekmesinde transfer edilen boyutu orijinal boyutla karşılaştırabilirsiniz. Örneğin 250 KB’lık bir JavaScript dosyasının 68 KB olarak transfer edildiğini görüyorsanız sıkıştırma düzgün çalışıyor demektir.

Sonuç

IIS’te Gzip sıkıştırmasını doğru yapılandırmak, sunucuya çok az yük bindiren ama kullanıcı deneyimine ve bant genişliği maliyetlerine ciddi katkısı olan bir adım. Özellikle Türkiye gibi mobil kullanımın yoğun olduğu bir pazarda, sayfa yüklenme hızı hem kullanıcı tutma hem de SEO açısından giderek daha kritik bir faktör.

Yapılandırmayı özetlemek gerekirse: Önce modüllerin kurulu olduğunu doğrulayın, statik ve dinamik sıkıştırmayı ayrı ayrı yapılandırın, sıkıştırılacak MIME türlerini ihtiyacınıza göre genişletin, ve her değişiklikten sonra hem fonksiyonel test hem de performans ölçümü yapın.

Bir de şunu ekleyeyim: Bu yapılandırmayı Infrastructure as Code anlayışıyla ele alın. Her adımı script’e döküp versiyon kontrolüne alın. İleride başka bir sunucuya taşındığınızda ya da bir şeyler bozulduğunda, tam olarak ne yaptığınızı bilmek paha biçilmez bir avantaj sağlar. Ben yıllardır bunu yapıyorum ve ne zaman işe yaradığını gördüm, size de öneririm.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir