Brotli ve Gzip: Nginx, Apache ve LiteSpeed Ayarları

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 sunucu tarafında da önemli bir optimizasyon seçeneği vardır: doğru yapılandırılmış Brotli ve Gzip sıkıştırma. HTML, CSS ve JavaScript dosyalarının aktarım boyutunu küçültmek, ağ aktarımı darboğaz olduğunda LCP (Largest Contentful Paint) ve FCP (First Contentful Paint) sürelerini iyileştirebilir. Kazanç, içerik ve sıkıştırma seviyesinin yanı sıra sunucu yüküne ve bağlantı koşullarına bağlıdır.

Örneğin, kaynak kodu ve veritabanı optimize edilmiş, CDN kullanan bir sitede bile HTML ve kritik CSS dosyaları sıkıştırılmamış veya sıkıştırma ayarlarında yanlış MIME türleri hedeflenmiş olabilir. Böyle bir durumda özellikle mobil ve zayıf bağlantılarda gereksiz veri aktarımı yüklenmeyi geciktirebilir.

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 LCP gibi Core Web Vitals metriklerine ve TTFB gibi yardımcı performans ölçümlerine 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; uygun içerik ve ayarlarla HTML, CSS ve JS dosyalarının aktarım boyutu azaltılabilir.

Genel gözlem:

• Aynı metin dosyasında Brotli, Gzip’ten daha küçük çıktı üretebilir; fark içeriğe ve karşılaştırılan sıkıştırma seviyelerine bağlıdır.
• Karşılığında, özellikle yüksek sıkıştırma seviyelerinde, CPU tüketimi artabilir.
• Brotli kabul edilmiyorsa sunucu, istemcinin kabul ettiği ve sunucuda etkin olan Gzip’i ya da sıkıştırılmamış yanıtı seçebilir.

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

Özetle: yeterli boyuttaki metin tabanlı içerikler sıkıştırma için iyi adaylardır, fakat zaten sıkıştırılmış biçimler ve kullanıcıya özel hassas yanıtlar ayrıca değerlendirilmelidir. TLS üzerinde sırlarla saldırganın etkileyebildiği veriyi aynı sıkıştırılmış yanıtta birleştiren uygulamalar BREACH türü riskler taşıyabilir; yalnız dosya uzantısına bakarak tüm yanıtları kapsayan bir politika kurmayın.

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 ve sıkıştırılmamış fontlar (örneğin uygun TTF/OTF dosyaları). WOFF, font tablolarını isteğe bağlı zlib sıkıştırmasıyla paketler; WOFF2 Brotli kullanır. Bu biçimleri ek kazancı ölçmeden yeniden HTTP sıkıştırmasına dahil etmeyin.

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 gibi sıkıştırılmış arşivler; PDF içeriği değişebildiğinden ek kazanç ayrıca ölçülmelidir

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

Core Web Vitals; LCP, INP ve CLS’den oluşur. Sıkıştırmanın yükleme performansıyla ilişkisini değerlendirirken LCP’nin yanında, Core Web Vitals kapsamında olmayan FCP ve TTFB de izlenebilir:

• 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ın aktarımının hızlanması, kritik yükleme yolundaki gecikmeyi azaltıyorsa LCP’yi iyileştirebilir.
• FCP (First Contentful Paint): İlk metin veya görsel içeriğin çizilmesi için gereken kaynakların aktarımı hızlanabilir.
• TTFB (Time To First Byte): Sıkıştırma esas olarak yanıt gövdesinin aktarım boyutunu azaltır; ilk bayta kadar geçen süreyi kendiliğinden kısaltmaz. Dinamik sıkıştırma sırasında işlem veya tamponlama gecikmesi oluşursa TTFB artabilir. Bu yüzden seviye seçimi sunucu yüküyle birlikte değerlendirilmelidir.

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 etkin tutabilirsiniz; her yanıt için kullanılacak kodlama, istemcinin kabul ettiği kodlamalara ve sunucunun sıkıştırma koşullarına bağlıdır.

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 text/javascript
    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: İzin verilen aralık 1–9’dur. 5 burada ölçerek ayarlanacak bir başlangıç örneğidir; daha yüksek seviye ek CPU maliyetine karşı ne kadar boyut kazandırıyor, test edin.
• gzip_min_length 1024: Eşik yalnız yanıtın Content-Length alanından belirlenir. Uzunluğu bilinmeyen bir yanıt için “1024 bayttan küçükse kesinlikle sıkıştırılmaz” sonucu çıkarılamaz.
• gzip_types: text/html zaten kapsanır; liste diğer MIME türlerini ekler. İstemci, durum ve diğer koşullar da sıkıştırmayı etkiler.
• gzip_proxied any: Nginx bu bağlamda proxy isteğini Via istek başlığıyla belirler; any bu isteklerin sıkıştırılmasına izin verir. Hassas yanıtlar için uygun kapsamı ayrıca belirleyin.

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:

• Statik derlemede nginx -V çıktısı derleme parametrelerini gösterir; bu çıktı tek başına ayrı paketlenmiş bir dinamik modülün yüklendiğini kanıtlamaz.
• Dinamik ngx_brotli için kurulu Nginx ile uyumlu filter/static modülleri gerekir. Paketinizin load_module satırları ana bağlamda, http bloğunun dışında olmalıdır; aynı modülü iki kez yüklemeyin.
• nginx -T disk üzerindeki yapılandırmayı sınayıp dosyaları döker; çalışan işçilerin hangi eski yapılandırmayla başladığını göstermez. Çıktıda gizli değerler bulunabileceğinden yerel inceleyin. nginx -t başarılı olduktan sonra dağıtımınızın kontrollü reload yöntemini kullanın.

Modül hazır olduğunda tipik bir Brotli ayarı şöyle görünür. Bu örnek, yukarıdaki Gzip ayarlarıyla birlikte kullanılacak şekilde düşünülmüştür; ayrı kullanıldığında da ilgili bağlamda gzip_vary on; ayarını koruyun. ngx_brotli, Vary: Accept-Encoding başlığı için Nginx’in bu mekanizmasını kullanır:

brotli on;
brotli_comp_level 5;
brotli_min_length 1024;
brotli_types
    text/plain text/css text/xml text/javascript
    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;

brotli_min_length desteklenen bir ngx_brotli yönergesidir ve yalnız bilinen Content-Length değerine göre eleme yapar. brotli_comp_level aralığı 0–11’dir; örnekteki 5, ölçüm için başlangıçtır. Yüksek seviyelerin CPU maliyetini özellikle yoğun dedicated sunucu ve VPS iş yüklerinde aktarım boyutu ve TTFB ile birlikte karşılaştırın.

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: Sıkıştırmaya uygun yanıtlar istek sırasında sıkıştırılır. Yoğun trafikte bu işlem CPU’ya yük bindirebilir.
• Statik sıkıştırma: Build sürecinde veya bir cron job ile önceden .gz ve .br dosyaları üretilir. Uygun modül ve ayarlar etkin olduğunda Nginx bu dosyaları doğrudan sunabilir; sıkıştırma işi istek anından build veya cron aşamasına taşınır.

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

brotli_static on;

Bu, istemci Brotli’yi kabul ediyorsa ve aynı dizinde dosya.css ile birlikte dosya.css.br bulunuyorsa Brotli sıkıştırılmış versiyonun doğrudan sunulmasını sağlar. Gzip için ngx_http_gzip_static_module kuruluysa gzip_static on; kullanılabilir; bu modül varsayılan derlemeye dahil değildir. Brotli için de static modülü gerekir. on istemci kabulünü gözetir; always kullanmayın. Sıkıştırılmamış özgün dosyaları ve sıkıştırılmış sürümlerini aynı build’den üretip birlikte yayımlayın; eski bir .br/.gz dosyası güncel içerik sayılmaz.

Özellikle büyük SPA/MPA projelerinde (React, Vue, Angular vb.) build aşamasında statik sıkıştırma üretmek, istek başına sıkıştırma maliyetini ortadan kaldırabilir. Bunun Core Web Vitals’a katkısı, sıkıştırma yükünün mevcut darboğazlardan biri olup olmadığına bağlıdır.

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. Modüllerin paketlerle kurulu gelip gelmediği dağıtıma ve kullanılan Apache paketine bağlıdır; yapılandırmadan önce gerekli modüllerin kurulu ve etkin olduğundan emin olun.

mod_deflate ile Gzip konfigürasyonu

Aşağıdaki örnek sunucu veya sanal host yapılandırması içindir. DeflateCompressionLevel bu iki bağlamda geçerlidir; .htaccess içinde kullanılamaz. Önce mod_deflate ve mod_filter modüllerini doğrulayın:

<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
</IfModule>

Gzip seviyesi 1–9 arasındadır; 5 bir başlangıç örneğidir. Daha yüksek seviyenin ek kazancını CPU ve gecikmeyle karşılaştırın. mod_deflate, kodlama seçimi için Vary: Accept-Encoding başlığını kendisi ekler. User-Agent gibi başka bir başlığa göre istisna oluşturuyorsanız bu ek bağımlılığı da Vary politikasında değerlendirin.

mod_brotli ile Brotli konfigürasyonu

mod_brotli Apache 2.4.26 ve sonrasında kullanılabilir; kurulu paketinizde etkin olması gerekir. Bu örnek de sunucu veya sanal host bağlamına aittir:

<IfModule mod_brotli.c>
    BrotliCompressionQuality 5
    BrotliCompressionWindow 18
    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 aralığındadır; Apache belgesindeki varsayılan 5’tir. Yüksek kalite daha fazla işlem ister; dinamik yanıtlar için sonucu ölçün, yüksek maliyetli sıkıştırmayı önceden üretilen statik dosyalarda değerlendirin.
• BrotliCompressionWindow: 10–24 aralığında, 2 üzeri değer bayt büyüklüğünde pencereyi belirtir. Varsayılan 18, 256 KiB’tır; büyütmek bağlantı başına belleği artırabilir.
• Birlikte kullanım: İki modülün yüklü olması tek başına Brotli önceliği sağlamaz. Etkin filtre zincirini, br, gzip ve sıkıştırılmamış yanıtları test edin; aynı yanıtın tekrar sıkıştırılmadığını kontrol edin. mod_brotli de gerekli Accept-Encoding varyasyon başlığını ekler.

.htaccess mi, global konfigürasyon mu?

Yalnız .htaccess yetkiniz varsa yukarıdaki blokları bütünüyle kopyalamayın: sıkıştırma seviye/pencere yönergeleri sunucu veya sanal host içindir. AddOutputFilterByType, mod_filter ve ilgili sıkıştırma modülü etkinse, ayrıca AllowOverride FileInfo veya uygun AllowOverrideList izni varsa kullanılabilir. Sağlayıcının mevcut filtreleriyle çakışmayan, izin verilmiş MIME filtresini uygulayın.

• .htaccess kullanımına izin verildiğinde ilgili dosyaların aranması ve okunması ek dosya arama ve okuma maliyeti getirir.
• Mümkünse bu ayarları global konfigürasyonda veya sanal host seviyesinde tutmak daha performanslıdır.

Paylaşımlı hostingde sunucu yapılandırmasını sağlayıcı yönetebilir. Seçtiğiniz planın kullandığı web sunucusunu, etkin sıkıştırmayı ve izin verilen kullanıcı ayarlarını öğrenin; hazır etkinleştirme veya performans sonucu varsaymayın. Değişiklik öncesi yapılandırmayı saklayın, ilgili Apache yapılandırma testini çalıştırın ve ancak başarıdan sonra kontrollü reload yapın.

LiteSpeed / OpenLiteSpeed’te Gzip ve Brotli

LiteSpeed Web Server ve OpenLiteSpeed sıkıştırma desteği sunar; ancak ayarların kapsamını aynı kabul etmeyin. LiteSpeed belgesi statik ve dinamik yanıtlarda gzip/Brotli kullanımını açıklar. OpenLiteSpeed’in ilgili panel belgesi dinamik GZIP ve statik dosya Brotli ayarlarını ayrı tanımlar. WordPress LiteSpeed Cache ise öncelikle sayfa önbelleği ile uygulama kurallarını yönetir.

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

Yetkili WebAdmin erişiminiz varsa kullandığınız ürün ve sürümün sıkıştırma ekranını açın:

1. LiteSpeed Web Server: Configuration > Server > Tuning içindeki sıkıştırma bölümünde Enable Compression açık olmalıdır. Dinamik sıkıştırma için ilgili dinamik anahtarı da kontrol edin; MIME türlerini ve statik boyut sınırlarını belirleyin.
2. OpenLiteSpeed: Server Configuration > Tuning altında ana sıkıştırma anahtarını, Enable Dynamic GZIP Compression seçeneğini ve Brotli Compression Level (Static File) ayarını ayrı değerlendirin. Bu üründe statik Brotli seviyesi 0, Brotli’yi kapatır.
3. Seviye seçimini örnek dosyaların boyutu, CPU ve yanıt sürelerine göre test edin; kaydetme ve yeniden yükleme adımlarında kurulu sürümün prosedürünü izleyin.

OpenLiteSpeed’te sanal hostun General ayarlarında Enable GZIP Compression ve Enable Brotli Compression ayrı denetlenebilir. Sunucu ana anahtarının kapalı olması sanal host ayarlarını geçersiz kılar. Dizin istisnası gerekiyorsa kullanılan ürünün gerçek context veya rewrite desteğini doğrulayın; sanal hostu kapatmak yalnız bir dizini etkilemez.

WordPress ve LiteSpeed Cache ile pratik kullanım

LiteSpeed Cache eklentisinde sayfa önbelleği ve CSS/JS optimizasyonunu sunucudaki HTTP sıkıştırmasından ayırın. Eklentinin kurulması, Brotli’nin etkin olduğunu kanıtlamaz; önbellek özellikleri de uygun LSCache sunucu bileşenini gerektirir.

1. Sunucunun LSCache desteğini doğrulayın ve eklentiyi bu ortam için yapılandırın.
2. LiteSpeed Cache > Cache ekranındaki önbellek ayarlarını uygulamanıza uygun biçimde değerlendirin; bunlar Gzip/Brotli açma anahtarı değildir.
3. HTTP sıkıştırmasını WebAdmin veya sağlayıcınız üzerinden yönetin. Tarayıcı Network ekranında gerçek GET yanıtının Content-Encoding ve Vary başlıklarını inceleyin.

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

Aşağıdaki değerler ölçerek uyarlanacak örnek başlangıç noktalarıdır; DCHost ölçümü veya her siteye uygun reçete olarak değerlendirmeyin:

• Gzip: Örneğin 4 veya 5 ile başlayıp boyut, CPU ve TTFB’yi karşılaştırın.
• ngx_brotli: Örneğin 4 veya 5 ile başlayın; geçerli aralık 0–11’dir. 7 üzerini yalnız “daha iyi” saymayın; yüksek seviyeleri build süresinin kabul edilebildiği statik dosyalarda değerlendirin.
• Apache mod_brotli: Varsayılan kalite 5’tir. Üretimde dinamik sıkıştırma ve build sırasında önceden sıkıştırma farklı iş yükleridir; kullanılacak seviyeyi ayrı ölçün.

Yalnız açıklama amacıyla, 100 KB’lık bir JS dosyası için şu varsayımsal çıktıları düşünün; bunlar ölçülmüş oranlar değildir:

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

Bu varsayımsal örnekte Brotli çıktısı Gzip’ten 7 KB küçüktür. Bunun süre karşılığı bağlantı hızına, önbelleğe ve kritik yükleme yoluna bağlıdır; tüm 4G bağlantıları için sabit milisaniye sonucu çıkarılamaz. Ek CPU maliyetini ölçün; aynı dosya değişmiyorsa önceden sıkıştırılmış sürümleri üretmek istek sırasındaki işi azaltabilir.

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,
• sıkıştırmaya uygun dinamik yanıtlar için ekstra CPU harcanabilir,
• özellikle yoğun trafik anlarında kuyruğa düşen isteklerin yanıt süresi artabilir.

Bu yüzden Brotli/Gzip için ölçülmüş bir başlangıç seviyesi, aktarım kazancıyla CPU maliyetini birlikte değerlendirmek için uygundur. 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?

• PageSpeed Insights: Laboratuvar sonuçlarını ve yeterli veri varsa CrUX gerçek kullanıcı verilerini gösterir. Güncel Core Web Vitals LCP, INP ve CLS’dir; FCP ve TTFB yardımcı ölçümlerdir.
• Lighthouse: Kontrollü laboratuvar karşılaştırmalarında yararlıdır; tek çalıştırma gerçek kullanıcı deneyiminin tamamını temsil etmez.
• GTmetrix ve WebPageTest: Seçilen test koşullarındaki aktarım boyutlarını ve waterfall zamanlamalarını inceleyin. Önce/sonra testlerde bağlantı, konum ve cache durumunu mümkün olduğunca aynı tutun.

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?

• Aynı URL’nin gerçek GET yanıtında uygun Content-Encoding: br veya gzip ve Vary: Accept-Encoding değerlerini kontrol edin; HEAD isteği dinamik gövdenin gerçekten sıkıştırıldığını kanıtlamaz.
• Aktarılan baytları açılmış içerik boyutuyla karıştırmadan karşılaştırın. Her yanıtın küçülmesi veya sıkıştırılması gerekmez.
• Brotli, Gzip ve sıkıştırılmamış istemci durumlarını deneyin; CDN varsa origin ve CDN yanıtlarını ayrı değerlendirin.
• Mobil profillerde LCP’yi, ayrıca TTFB ve CPU’yu ölçün. Kazanç gösterilemiyorsa seviye veya kapsamı yeniden değerlendirin; önceki ayara dönebilin.

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ımı ölçülmelidir; sonuç sitenin darboğazlarına bağlıdır. Google, Core Web Vitals’ı sıralama sistemlerinde kullanır; iyi puanlar bile üst sıraları garanti etmez. Brotli/Gzip kullanımı da tek başına sıralama garantisi değildir. 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.

Hosting Altyapısında Sıkıştırmayı Diğer Ayarlarla Birleştirmek

Sıkıştırmayı uygulama, önbellek ve aktarım protokollerinden ayrı bir başarı ölçütü olarak görmeyin. Paylaşımlı hostingde izin verilen ayarlar ile yönetim yetkisi bulunan VPS veya fiziksel sunucudaki ayarlar farklı olabilir.

Altyapı seçimi ve değişiklik planında şu başlıkları birlikte değerlendirin:

• İstemci ve sunucu destekliyorsa HTTP/2 veya HTTP/3’ü ölçerek değerlendirin; bunlar sıkıştırmanın ön koşulu değildir.
• Uygulama işlemleriyle sıkıştırmanın paylaşacağı CPU kapasitesini ve yoğun dönemleri izleyin.
• Tam sayfa önbelleği, nesne önbelleği ve sıkıştırmanın farklı işleri çözdüğünü unutmayın; özel kullanıcı verilerini paylaşımlı cache’e taşımayın.
• CDN kodlama ve cache politikasını kontrol edin; origin ayarı tek başına kullanıcıya ulaşan kodlamayı göstermez.

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:

• Uygun HTML/CSS/JS yanıtlarının aktarım boyutunu azaltabilir.
• Kritik aktarım süresi darboğazsa LCP veya FCP’ye katkı sağlayabilir.
• Gerçek trafik ve ücret modeline göre aktarım maliyetini etkileyebilir.
• CPU, bellek ve TTFB üzerindeki maliyeti ölçülerek dengelenmelidir.

Önce mevcut yanıtları ve yapılandırmayı kaydedin; ardından uygun MIME türleri ve örnek seviyelerle küçük bir değişiklik yapın. Yapılandırma testi, gerçek GET yanıtı, kodlama uyumluluğu ve performans karşılaştırması başarılıysa kapsamı genişletin. DCHost üzerindeki planınızın yönetim yetkilerini ve destek kapsamını sağlayıcıyla netleştirin; sunucu örneklerini yetki ve ürün farklarını gözeterek uygulayın.