Brotli ve Gzip Sıkıştırma Ayarları: Nginx, Apache ve LiteSpeed’de Core Web Vitals İçin Doğru Konfigürasyon

Brotli ve Gzip Sıkıştırmanın Core Web Vitals’a Etkisi

Core Web Vitals skorlarınızı iyileştirmek için genelde ön yüz optimizasyonu, resim boyutları veya CDN ayarları konuşulur; ama çoğu projede sunucu tarafında çok basit bir ayar eksik kalır: doğru yapılandırılmış Brotli ve Gzip sıkıştırma. Aynı HTML, CSS ve JavaScript dosyasını, yalnızca birkaç satır konfigürasyonla %20–%40 daha küçük gönderebiliyorsanız, LCP (Largest Contentful Paint) ve FCP (First Contentful Paint) değerlerinizde otomatik olarak kazanım elde edersiniz.

Biz DCHost tarafında onlarca projede şunu görüyoruz: Kaynak kod düzgün, veritabanı fena değil, CDN kullanılıyor ama HTML ve kritik CSS dosyaları hâlâ sıkıştırılmamış veya yanlış MIME türleri hedeflenmiş. Sonuç: özellikle mobil ve zayıf bağlantılarda gereksiz milisaniyeler, hatta tam saniyeler kaybediliyor.

Bu yazıda Brotli ve Gzip sıkıştırma ayarlarını Nginx, Apache ve LiteSpeed üzerinde nasıl doğru kuracağınızı, hangi seviyeleri seçmeniz gerektiğini ve bunların Core Web Vitals metriklerine (özellikle LCP ve TTFB) pratikte nasıl yansıdığını adım adım ele alacağız. Anlatım boyunca hem küçük paylaşımlı hosting siteleri hem de yüksek trafikli VPS / dedicated mimariler için uygulanabilir öneriler vereceğiz.

Brotli ve Gzip Temelleri: Algoritma, Destek ve Farklar

Önce konuyu netleştirelim: Hem Brotli hem Gzip, metin tabanlı içerikleri sıkıştırmak için kullanılan algoritmalardır. Tarayıcı, HTTP isteğinde Accept-Encoding başlığıyla desteklediği sıkıştırma türlerini (genellikle br, gzip, deflate) sunucuya bildirir; sunucu da buna göre içerikleri sıkıştırarak yanıtlar.

Gzip daha eski ve neredeyse tüm tarayıcılarda ve istemcilerde desteklenir. Brotli ise daha yeni, özellikle yüksek sıkıştırma oranı ve modern web senaryoları için tasarlanmış bir algoritmadır. Çoğu modern tarayıcı HTTPS isteklerinde Brotli’yi destekler, bu yüzden doğru kurduğunuzda kritik HTML, CSS ve JS dosyalarınızda ciddi boyut kazanımı elde edersiniz.

Genel gözlem:

• Aynı dosyada Brotli genelde Gzip’ten %15–20 daha iyi sıkıştırma sağlar.
• Karşılığında, özellikle yüksek sıkıştırma seviyelerinde, CPU tüketimi artabilir.
• Tarayıcı Brotli desteklemiyorsa otomatik olarak Gzip veya düz metne geri düşer.

Hangi içerikler sıkıştırılmalı?

Özetle: metin tabanlı her şeyi sıkıştırmak istiyoruz, fakat zaten sıkıştırılmış içerikleri genelde sıkıştırmak istemiyoruz.

Sıkıştırılması önerilen içerikler:

• HTML (text/html)
• CSS (text/css)
• JavaScript (application/javascript, text/javascript)
• JSON (application/json)
• SVG (image/svg+xml)
• XML, RSS, Atom, font dosyaları (WOFF, WOFF2, TTF) vb.

Sıkıştırılması genelde gereksiz veya zararlı olan içerikler:

• JPEG/PNG gibi klasik resimler
• WebP/AVIF gibi modern, zaten agresif sıkıştırılmış görseller
• MP4, WebM gibi video dosyaları
• ZIP, PDF gibi kendi içinde sıkıştırma barındıran formatlar

Görsellerde hız kazanmak için Brotli/Gzip yerine format dönüşümü ve doğru cache stratejileri daha etkilidir. Bu tarafta detaylı bir yol haritası isterseniz, WebP/AVIF’i düzgün sunma stratejilerini anlattığımız rehber ile bu yazıyı birlikte düşünmenizi öneririz.

Core Web Vitals ile ilişki

Brotli ve Gzip’in doğrudan etkilediği metrikler:

• LCP (Largest Contentful Paint): Kahraman görsel veya büyük başlık genellikle HTML ve CSS’in yüklenmesine bağlıdır. Bu dosyalar küçüldükçe LCP kısalır.
• FCP (First Contentful Paint): İlk piksel için gerekli HTML/CSS/JS daha hızlı aktarılır.
• TTFB (Time To First Byte): Sıkıştırma, TTFB’nin “network” kısmını azaltır; ancak çok yüksek sıkıştırma seviyesi CPU’yu zorluyorsa sunucu taraflı gecikmeyle TTFB’yi arttırabilir. Bu yüzden doğru seviye seçimi kritiktir.

Sunucu taraflı optimizasyonların Core Web Vitals’a etkisini daha geniş çerçevede görmek isterseniz, mutlaka Core Web Vitals ve hosting altyapısı ilişkisini detaylı anlattığımız yazıya da göz atın.

Nginx Üzerinde Gzip ve Brotli Konfigürasyonu

Nginx, performans odaklı mimarisiyle sıkıştırma tarafında oldukça esnek. Doğru ayarlarla hem Gzip’i hem Brotli’yi aynı anda kullanabilirsiniz: Tarayıcı Brotli destekliyorsa Brotli, desteklemiyorsa Gzip devreye girer.

Temel Gzip ayarları

/etc/nginx/nginx.conf veya ilgili include dosyanızda http { ... } bloğu içine yerleştirilebilecek örnek bir Gzip konfigürasyonu şu şekilde olabilir:

gzip on;gzip_comp_level 5;gzip_min_length 1024;gzip_proxied any;gzip_vary on;gzip_types  text/plain text/css text/xml application/json application/javascript application/x-javascript application/xml application/xml+rss application/rss+xml image/svg+xml font/ttf font/otf application/vnd.ms-fontobject;

Buradaki kritik noktalar:

• gzip_comp_level 5: 1–9 arası değer alır. 1 çok hızlı ama az sıkıştırır, 9 maksimum sıkıştırma ama CPU’ya yük bindirir. Genelde 4–6 arası iyi dengedir.
• gzip_min_length 1024: Çok küçük yanıtları (örneğin 200–300 bayt) sıkıştırmak çoğu zaman gereksizdir; 1024 bayt ve üzeri için devreye girmesini sağlıyoruz.
• gzip_types: Varsayılan olarak yalnızca text/html sıkıştırılır; diğer MIME türlerini burada tek tek eklemek gerekir.

Nginx’te Brotli modülünü etkinleştirmek

Brotli Nginx’in çekirdeğine gömülü gelmez; paket yöneticiniz üzerinden veya kaynak koddan derleme sırasında eklemeniz gerekir (örneğin ngx_brotli modülüyle). Dağıtıma bağlı olarak:

• Bazı Nginx paketlerinde brotli modülü hazır gelir, yalnızca konfigürasyonla etkinleştirmeniz gerekir.
• Bazılarında ise modülü ayrıca kurmanız veya özel bir Nginx derlemesi kullanmanız gerekir.

Modül hazır olduğunda tipik bir Brotli ayarı şöyle görünür:

brotli on;brotli_comp_level 5;brotli_min_length 1024;brotli_types  text/plain text/css text/xml application/json application/javascript application/x-javascript application/xml application/xml+rss application/rss+xml image/svg+xml font/ttf font/otf application/vnd.ms-fontobject;

Burada da aynı mantık geçerli: brotli_comp_level 4–6 arası çoğu site için iyi dengedir. 9’a çıktığınızda özellikle yoğun trafik alan VPS veya dedicated sunucularda CPU grafiğinizin zıpladığını görebilirsiniz.

Nginx’te TLS 1.3, modern şifre paketleri ve Brotli’yi birlikte kurmak için uçtan uca bir rehbere ihtiyacınız varsa, Nginx’te TLS 1.3 ve Brotli kurulumunu adım adım anlattığımız detaylı yazıya mutlaka göz atın.

Statik vs dinamik sıkıştırma

Nginx tarafında iki ana yaklaşım vardır:

• Dinamik sıkıştırma: Her istekte içerik anlık olarak sıkıştırılır. Konfigürasyonu basittir ama yoğun trafikte CPU’ya yük bindirebilir.
• Statik sıkıştırma: Build sürecinde veya bir cron job ile önceden .gz ve .br dosyaları üretilir. Nginx de bunları doğrudan sunar; CPU’ya neredeyse hiç yük binmez.

Statik sıkıştırma için tipik bir Brotli yapılandırması:

brotli_static on;

Bu, aynı dizinde dosya.css ile birlikte dosya.css.br bulunuyorsa Brotli sıkıştırılmış versiyonun doğrudan sunulmasını sağlar. Benzer şekilde Gzip için de gzip_static on; kullanabilirsiniz.

Özellikle büyük SPA/MPA projelerinde (React, Vue, Angular vb.) build aşamasında statik sıkıştırma üretmek ciddi CPU tasarrufu sağlar ve Core Web Vitals üzerinde daha tutarlı sonuçlar verir.

Apache’de mod_deflate ve mod_brotli ile Sıkıştırma

Apache dünyasında Gzip genelde mod_deflate ile, Brotli ise mod_brotli ile sağlanır. Her iki modül de çoğu modern Linux dağıtımında paketlerle birlikte gelir; yalnızca etkinleştirmek ve doğru konfigüre etmek gerekir.

mod_deflate ile Gzip konfigürasyonu

Sunucu genelinde (/etc/httpd/conf/httpd.conf veya benzeri) ya da sanal host / .htaccess seviyesinde aşağıdaki gibi bir ayar kullanılabilir:

<IfModule mod_deflate.c>  AddOutputFilterByType DEFLATE text/plain text/html text/xml text/css text/javascript application/javascript application/x-javascript application/json application/xml application/rss+xml image/svg+xml  DeflateCompressionLevel 5  # Proxy arkası senaryolar için (varsa)  Header append Vary Accept-Encoding env=REDIRECT_gzip_set  Header append Vary Accept-Encoding env=!REDIRECT_gzip_set</IfModule>

Burada da DeflateCompressionLevel için 4–6 arası değerler çoğu senaryoda yeterlidir. 7–9 seviyeleri küçük dosyalarda kazanç getirmezken CPU tüketimini artırabilir.

mod_brotli ile Brotli konfigürasyonu

Apache 2.4.26 ve sonrası sürümlerde mod_brotli modülü bulunur. Etkinleştirildiğinde tipik bir konfigürasyon şu şekilde olabilir:

<IfModule mod_brotli.c>  BrotliCompressionQuality 5  BrotliWindowSize 16  AddOutputFilterByType BROTLI_COMPRESS text/plain text/html text/xml text/css text/javascript application/javascript application/x-javascript application/json application/xml application/rss+xml image/svg+xml</IfModule>

Önemli noktalar:

• BrotliCompressionQuality: 0–11 arası değer alır. 4–6 arası kalite çoğu sitede tatlı denge noktasıdır. 10–11 yüksek CPU tüketir; yalnızca statik precompression senaryolarında mantıklıdır.
• BrotliWindowSize: Sıkıştırma penceresi boyutunu belirler; genelde 16 iyidir, çok özel durumlar hariç değiştirmeye gerek yok.

.htaccess mi, global konfigürasyon mu?

Paylaşımlı hosting ortamlarında çoğu kullanıcı yalnızca .htaccess üzerinden müdahale edebilir. Bu durumda yukarıdaki <IfModule> bloklarını doğrudan .htaccess’e koymak yeterlidir. Ancak:

• .htaccess her istekte okunduğu için ekstra bir küçük performans maliyeti getirir.
• Mümkünse bu ayarları global konfigürasyonda veya sanal host seviyesinde tutmak daha performanslıdır.

DCHost olarak paylaşımlı hosting altyapımızda Gzip ve (uygulamaya göre) Brotli ayarlarını sunucu seviyesinde optimize edilmiş şekilde tutuyoruz; böylece çoğu kullanıcı hiçbir ek ayar yapmadan, doğrudan daha küçük yanıt boyutlarıyla yayına çıkabiliyor.

LiteSpeed / OpenLiteSpeed’te Gzip ve Brotli

LiteSpeed ekosistemi, HTTP performansına odaklı tasarlandığı için sıkıştırma tarafında da oldukça esnek ve varsayılanları güçlüdür. Hem Gzip hem Brotli’yi destekler, ayrıca WordPress tarafında LiteSpeed Cache eklentisiyle sıkı bir entegrasyon sunar.

Sunucu seviyesinde sıkıştırma ayarları

LiteSpeed WebAdmin konsoluna erişiminiz varsa (genelde 7080 portu):

1. Configuration > Server > Tuning sekmesine gidin.
2. GZIP Compression bölümünde Gzip’i aktif edin ve istenen MIME türlerini ekleyin.
3. Lisans ve sürüme bağlı olarak Brotli Compression için de benzer şekilde on konumuna getirip kalitesini (4–6 arası) belirleyin.

Vhost seviyesinde de ek kurallar tanımlayarak yalnızca belirli sitelerde sıkıştırma davranışını özelleştirebilirsiniz. Örneğin büyük dosyalar için minimum uzunluk, belirli içerik türleri için istisnalar gibi.

WordPress ve LiteSpeed Cache ile pratik kullanım

WordPress kullanıyorsanız işiniz daha da kolay. LiteSpeed Cache eklentisi, sayfa önbelleklemenin yanında sıkıştırma ve HTTP başlıklarını da pratik şekilde yönetmenize izin verir. Adımlar özetle şöyle:

1. WordPress’te LiteSpeed Cache eklentisini kurup etkinleştirin.
2. LiteSpeed Cache > Ayarlar > Genel bölümünde önbelleği aktif edin.
3. LiteSpeed Cache > Ayarlar > Gelişmiş sekmesinde Gzip/Brotli seçeneklerini kontrol edin (çoğu zaman sunucu tarafında zaten açıktır; eklenti yalnızca doğrular).

Litespeed tarafında özellikle WooCommerce gibi dinamik siteleri hızlandırmak için nasıl bir bütünsel strateji izleyebileceğinizi, LiteSpeed Cache ile WordPress hızlandırma rehberimizde adım adım anlattık. Brotli/Gzip de bu büyük resmin önemli bir parçası.

Doğru Sıkıştırma Seviyesini Seçmek ve CPU Etkisi

“En yüksek seviye en iyisidir” tuzağı burada da geçerli değil. Core Web Vitals tarafında amaç yalnızca dosyayı en çok küçültmek değil, en kısa toplam yanıt süresini elde etmektir. Bu da network kazancıyla CPU maliyeti arasındaki dengeyi iyi kurmayı gerektirir.

Pratik seviye önerileri

Tecrübelerimize göre çoğu PHP/WordPress/Laravel tabanlı site için iyi başlangıç değerleri şöyle:

• Gzip (Nginx / Apache): 4–6 arası. Genelde 5 tatlı nokta.
• Brotli (Nginx): 4–6 arası. 5 veya 6 ideal; 7+ seviye sadece statik precompression için mantıklı.
• Brotli (Apache mod_brotli): 4–6 arası kalite; 10–11 yalnızca build sürecinde .br dosyası üretmek için kullanılmalı.

Küçük bir hesap yapalım: 100 KB’lık bir JS dosyası düşünün.

• Gzip seviye 5 ile 35 KB’a düşsün.
• Brotli seviye 5 ile 28 KB’a düşsün.

Aradaki 7 KB fark 4G bağlantıda birkaç milisaniyeden fazla bir kazanç sağlamazken, her istekte bu dosyayı 11. seviyede Brotli ile hesaplamak CPU tarafında ciddi yük oluşturabilir. Özellikle yüksek trafikli sitelerde bu fark CPU % kullanımında doğrudan hissedilir.

CPU ve Core Web Vitals ilişkisi

Core Web Vitals raporlarında sadece “ağ” kaynaklı gecikme yoktur; sunucunun isteğe yanıt vermesi için harcadığı süre de (özellikle TTFB) büyük önem taşır. Aşırı agresif sıkıştırma ayarları sonucu:

• PHP-FPM / LSAPI zaten yoğun çalışırken,
• her yanıt için ekstra CPU harcanır,
• özellikle burst anlarında kuyruğa düşen isteklerinizin yanıt süresi artar.

Bu yüzden Brotli/Gzip için orta seviye ayarlar, yüksek traffic + CPU sağlığı dengesini gözeten en gerçekçi yaklaşımdır. VPS veya dedicated sunucularda CPU etkisini görmek için, VPS kaynak kullanımını izlemenizi sağlayan araçları anlattığımız rehber ile bu yazıyı birlikte değerlendirmeniz faydalı olacaktır.

Değişiklikleri Ölçmek: Core Web Vitals ve Test Araçları

Brotli ve Gzip ayarlarını yaptıktan sonra “Hızlandı mı, ne kadar hızlandı?” sorusunun cevabı, hislere değil ölçüme dayanmalı. Bunun için hem laboratuvar (lab) testleri hem de gerçek kullanıcı verisi (field data) kullanmak gerekir.

Hangi araçlarla test etmelisiniz?

• Google PageSpeed Insights: Hem lab hem de gerçek kullanıcı verisini (Chrome UX Report) gösterir. LCP, FID/INP, CLS gibi Core Web Vitals metriklerinin sıkıştırma sonrası nasıl değiştiğini görebilirsiniz.
• Lighthouse (Chrome DevTools): Lokal veya staging ortamında test yapmak için idealdir.
• GTmetrix ve WebPageTest: Farklı lokasyonlardan çok daha ayrıntılı network waterfall grafikleri vererek sıkıştırmanın etkisini net gösterir.

Bu araçları nasıl doğru kullanacağınızı, hangi metriğe bakmanız gerektiğini ve sık görülen yanlış yorumları web sitenizin hızını doğru ölçmek için hazırladığımız rehberde detaylı işledik. Brotli/Gzip değişikliklerinizi yaptıktan sonra oradaki adımları takip ederek önce/sonra karşılaştırması yapın.

Nelere dikkat etmelisiniz?

• Sıkıştırma sonrası toplam aktarım boyutu (Total transferred) düşmeli.
• HTML, CSS ve JS dosyalarının yanıt başlıklarında content-encoding: br veya content-encoding: gzip görmelisiniz.
• LCP değeri belirgin şekilde iyileşmeli; özellikle mobil 3G/4G profillerinde.

Unutmayın: Brotli ve Gzip, Core Web Vitals için tek başına sihirli değnek değildir; ama HTTP/2/HTTP/3, modern TLS ve önbellekleme stratejileriyle birlikte kullanıldığında etkisi katlanarak artar. Bu bütünsel resim için HTTP/2 ve HTTP/3’ün SEO ve Core Web Vitals’a etkisini anlattığımız yazıya da göz atmanızı öneririz.

DCHost Altyapısında Brotli, HTTP/2/3 ve Diğer Optimizasyonların Bütünleşmesi

Teoriyi anlattık; bunu pratikte, özellikle de altyapı tarafında nasıl bütünleştirdiğimizden de kısaca bahsedelim. DCHost olarak hedefimiz, müşterilerimizin Brotli/Gzip gibi teknik detaylarla uğraşmak zorunda kalmadan makul varsayılanlarla yayına başlayabilmesi, sonrasında ise ihtiyaç duydukça ince ayar yapabilmesi.

Bu yüzden altyapımızı şu prensiplerle şekillendiriyoruz:

• Uygun ortamlarda HTTP/2 ve HTTP/3 (QUIC) desteğini aktif tutuyoruz; bu, sıkıştırılmış küçük isteklerin çoklu iletiminde büyük avantaj sağlıyor.
• Nginx, Apache ve LiteSpeed stack’lerinde Gzip ve Brotli için dengeli varsayılan seviyeler kullanıyoruz.
• WordPress, WooCommerce, Laravel gibi yaygın yığınlarda tam sayfa önbellekleme, nesne önbelleği ve sıkıştırmayı birlikte ele alıyoruz.
• VPS ve dedicated sunucu müşterilerimize, CPU ve network profilini birlikte değerlendirerek projeye özel Brotli/Gzip seviye tavsiyeleri sunuyoruz.

Eğer sitenizin Core Web Vitals skorlarıyla boğuşuyorsanız, bu yazıyı mutlaka Core Web Vitals ve hosting altyapısı rehberimiz ve Nginx’te TLS 1.3 + Brotli kurulum yazımız ile birlikte okumanızı öneririz. Böylece sıkıştırma, TLS, HTTP/2/3, cache ve veri merkezi mimarisi gibi tüm katmanları tek bir büyük resmin parçaları olarak görebilirsiniz.

Sonuç olarak, doğru planlandığında Brotli ve Gzip sıkıştırma:

• HTML/CSS/JS boyutlarını hissedilir biçimde azaltır,
• özellikle mobil kullanıcılar için LCP ve FCP’yi iyileştirir,
• trafik maliyetinizi düşürür,
• ve bunların hepsini, doğru seviyelerde kullanıldığında CPU’yu yormadan yapar.

Eğer hangi seviyeleri seçmeniz gerektiği, Nginx/Apache/LiteSpeed konfigürasyonunuzda tam olarak nereye ne yazacağınız veya DCHost üzerindeki planınızda bu ayarların nasıl devreye alınacağını birlikte gözden geçirmek isterseniz, ekibimizle iletişime geçebilirsiniz. Mevcut paylaşımlı hosting hesabınızdan NVMe tabanlı bir VPS’e, oradan da özel ayrılmış dedicated veya colocation mimarilerine kadar, sitenizin ölçeğine uygun ve Core Web Vitals hedeflerinizle uyumlu bir altyapıyı birlikte tasarlayabiliriz.