Brotli Sıkıştırma Kurulumu ve Ayarları

Sunucunuzdan çıkan her HTML, CSS ve JavaScript baytı kullanıcının bağlantısında zaman harcar; özellikle mobil ağlarda bu, doğrudan bekleme süresi demektir. Brotli sıkıştırma, aynı içeriği gzip'e göre belirgin biçimde daha küçük paketleyerek bu bekleme süresini kısaltır ve kurulumu çoğu sunucuda yarım saatlik bir iştir. Buna rağmen sahada gördüğüm sunucuların önemli bir kısmı hâlâ yalnızca gzip ile çalışıyor ya da hiç sıkıştırma yapmıyor.

Bu rehberde Brotli'nin gzip'ten farkını, sıkıştırma seviyelerinin ne anlama geldiğini, Nginx ve Apache üzerinde nasıl kurulacağını, statik ön sıkıştırmanın neden en verimli yöntem olduğunu ve kurulumu nasıl doğrulayacağınızı anlatacağım. Ayrıca hangi dosya türlerini sıkıştırmamanız gerektiğine ve CDN kullanıyorsanız işin nasıl değiştiğine de değineceğim.

Brotli Nedir, gzip'ten Farkı Ne#

Brotli, Google tarafından geliştirilen ve RFC 7932 ile standartlaştırılmış genel amaçlı bir sıkıştırma algoritmasıdır. HTTP tarafında Content-Encoding: br başlığıyla tanınır. gzip'ten temel farkı, içinde web içeriğinde sık geçen kelimelerden oluşan önceden tanımlı bir sözlük taşımasıdır. Bu sözlük sayesinde küçük dosyalarda bile gzip'in yakalayamadığı örüntüleri bulur ve daha yüksek oran elde eder.

Pratikte ne kadar kazandırdığını görmek için kendi dosyalarınızı test edebilirsiniz:

# Ayni CSS dosyasini gzip ve brotli ile sikistirip boyutlari karsilastir
ORIJ=$(stat -c%s stil.css)
GZIP=$(gzip -9 -c stil.css | wc -c)
BR=$(brotli -q 11 -c stil.css | wc -c)
echo "Orijinal: $ORIJ | gzip: $GZIP | brotli: $BR"

Metin tabanlı dosyalarda tipik olarak şuna benzer bir tablo görürsünüz:

Kazanç oranı içeriğe göre değişir ama metin tabanlı dosyalarda genellikle yüzde 10-20 bandındadır. Kulağa küçük gelebilir; ancak bu tasarruf, indirme süresine doğrudan yansıdığı için özellikle render engelleyen CSS ve JavaScript dosyalarında FCP değerinizi somut biçimde iyileştirir.

Bir diğer önemli fark desteklenme biçimidir. Brotli tarayıcılarda pratik olarak yalnızca HTTPS üzerinden kullanılır; düz HTTP bağlantılarda tarayıcı br istemez. Sitenizde SSL zaten kuruluysa bu bir engel değildir.

Sıkıştırma Seviyeleri ve Doğru Seçim#

Brotli 0 ile 11 arasında bir kalite seviyesi kabul eder (gzip'te bu aralık 1-9'dur). Seviye yükseldikçe dosya küçülür ama sıkıştırma işlemi belirgin biçimde yavaşlar. Buradaki denge kritik: seviye 11 dinamik içerikte kullanılırsa sunucunuz her istekte ciddi işlemci harcar ve TTFB yükselir, yani kazandığınızdan fazlasını kaybedersiniz.

Doğru yaklaşım, dinamik ve statik içeriği ayırmaktır:

Seviye 5 civarı, dinamik içerik için neredeyse her zaman doğru cevaptır: gzip -6 ile benzer işlemci maliyetinde daha küçük çıktı verir. Seviye 11'i yalnızca derleme aşamasında, dosyaları önceden sıkıştırırken kullanın.

Nginx Üzerinde Brotli Kurulumu#

Nginx, Brotli desteğini çekirdekte taşımaz; modül olarak eklenir. Dağıtımınızın deposunda hazır bir Brotli modülü paketi varsa en pratik yol odur; yoksa dinamik modül olarak derlemek gerekir. Derleme yolunda önemli olan, çalışan Nginx'inizle birebir aynı sürümü ve aynı derleme parametrelerini kullanmaktır:

# Calisan surumu ve derleme parametrelerini ogren
nginx -v
nginx -V 2>&1 | tr ' ' '\n' | grep -- '--with'

# Kaynagi ve modulu al
cd /usr/local/src
git clone --recursive https://github.com/google/ngx_brotli.git
# nginx kaynagini calisan surumle ayni olacak sekilde indirin ve acin

# Dinamik modul olarak derle (mevcut configure parametrelerini aynen ekleyin)
cd nginx-KAYNAK-DIZINI
./configure --with-compat --add-dynamic-module=/usr/local/src/ngx_brotli
make modules
cp objs/*.so /usr/lib/nginx/modules/

Modülleri yükledikten sonra ana yapılandırmanın en üstünde çağırın ve http bloğuna ayarları ekleyin:

# /etc/nginx/nginx.conf en ustte
load_module modules/ngx_http_brotli_filter_module.so;
load_module modules/ngx_http_brotli_static_module.so;

http {
    # Dinamik sikistirma
    brotli on;
    brotli_comp_level 5;
    brotli_min_length 256;
    brotli_types
        text/plain
        text/css
        text/xml
        text/javascript
        application/javascript
        application/json
        application/xml
        application/rss+xml
        image/svg+xml
        font/ttf
        application/vnd.ms-fontobject;

    # Onceden sikistirilmis .br dosyalarini kullan
    brotli_static on;

    # gzip'i KAPATMAYIN: Brotli desteklemeyen istemciler icin gerekli
    gzip on;
    gzip_comp_level 5;
    gzip_min_length 256;
    gzip_vary on;
    gzip_types text/plain text/css application/javascript application/json image/svg+xml;
}

Yapılandırmayı test edip yeniden yükleyin:

nginx -t && systemctl reload nginx

brotli_min_length 256 satırı önemlidir: 200 baytlık bir cevabı sıkıştırmak çoğu zaman onu büyütür, çünkü sıkıştırma başlığının kendisi yer kaplar. gzip'i kapatmamak da aynı derecede önemlidir; Brotli desteklemeyen eski istemciler ve bazı ara sunucular için gzip yedek kalmalıdır.

Apache Üzerinde Brotli#

Apache 2.4'ün yeni sürümleri Brotli'yi mod_brotli ile kutudan çıkar hâlde destekler. Modülü etkinleştirip yapılandırmak yeterlidir:

# Debian/Ubuntu tabanli sistemlerde
a2enmod brotli
systemctl restart apache2

# RHEL tabanli sistemlerde modul genelde paket ile gelir
httpd -M | grep brotli

Ardından sanal sunucu yapılandırmasına ya da genel yapılandırmaya şunu ekleyin:

<IfModule mod_brotli.c>
    AddOutputFilterByType BROTLI_COMPRESS text/html text/plain text/xml text/css
    AddOutputFilterByType BROTLI_COMPRESS application/javascript application/json
    AddOutputFilterByType BROTLI_COMPRESS image/svg+xml

    BrotliCompressionQuality 5
    BrotliCompressionWindow 18

    # Onbellek katmanlari icin sart
    Header append Vary Accept-Encoding
</IfModule>

Paylaşımlı hostingte modül yapılandırmasına erişemezsiniz; orada .htaccess üzerinden benzer sonuç alabilirsiniz. Apache tarafındaki sıkıştırma ve önbellek direktiflerinin tamamını .htaccess ile önbellek ve sıkıştırma yazısında ele aldım. LiteSpeed kullanıyorsanız Brotli zaten yerleşiktir ve panelden tek anahtarla açılır; iki sunucu arasındaki farkları LiteSpeed ve Apache karşılaştırmasında bulabilirsiniz.

Statik Ön Sıkıştırma: En Verimli Yöntem#

Dinamik sıkıştırmada sunucu her istekte aynı CSS dosyasını yeniden sıkıştırır. Oysa o dosya değişmiyorsa bu tamamen boşa harcanan işlemci zamanıdır. Statik ön sıkıştırma bu israfı ortadan kaldırır: dosyayı bir kez, en yüksek seviyede sıkıştırıp yanına .br uzantılı ikizini koyarsınız; Nginx brotli_static on sayesinde hazır dosyayı doğrudan sunar.

Derleme sonrası çalıştıracağınız basit bir betik yeterlidir:

#!/usr/bin/env bash
# dist/ altindaki metin dosyalarinin .br ve .gz ikizlerini uret
set -euo pipefail
KOK="/var/www/firmaniz.com/dist"

find "$KOK" -type f \( -name '*.css' -o -name '*.js' -o -name '*.html' \
  -o -name '*.json' -o -name '*.svg' -o -name '*.xml' \) -print0 |
while IFS= read -r -d '' dosya; do
  brotli -q 11 -f -k "$dosya"      # dosya.br
  gzip  -9    -f -k "$dosya"       # dosya.gz
done

echo "On sikistirma tamamlandi."

Bu yöntemin üç avantajı vardır: her istekte işlemci harcanmaz, seviye 11 kullanabildiğiniz için dosyalar en küçük hâlindedir ve TTFB'ye sıfır ek maliyet getirir. Dezavantajı, dosyalar her değiştiğinde betiği yeniden çalıştırmayı unutmamanız gerektiğidir; bu yüzden dağıtım sürecinizin sabit bir adımı hâline getirin.

Neyi Sıkıştırmalı, Neyi Sıkıştırmamalı#

Sıkıştırma yalnızca metin tabanlı içerikte anlamlıdır. Zaten sıkıştırılmış bir dosyayı tekrar sıkıştırmak işlemci harcar, dosyayı çoğu zaman birkaç bayt büyütür ve hiçbir kazanç sağlamaz:

Özellikle WOFF2 yazı tipi dosyalarına dikkat edin: format zaten Brotli ile sıkıştırılmıştır, tekrar sıkıştırmak tamamen israftır. Eski WOFF ve TTF dosyaları ise sıkıştırılabilir; ancak modern bir kurulumda yalnızca WOFF2 sunmanız zaten daha doğrudur.

Bir güvenlik notu: sıkıştırma, cevap gövdesinde gizli bir değer (CSRF belirteci gibi) ile saldırganın kontrol ettiği bir girdi aynı anda bulunuyorsa teorik bir sızıntı yüzeyi yaratabilir. Bu riski pratikte kapatan şey, bu tür belirteçleri her istekte değiştirmek ve sıkıştırmayı yalnızca gerçekten gerekli içerik türlerinde açık tutmaktır.

Kurulumu Doğrulama ve Ölçüm#

Kurulum bittikten sonra tahmin yürütmeyin, ölçün. En hızlı doğrulama curl iledir:

# Brotli isteyip ne dondugune bak
curl -sI -H "Accept-Encoding: br,gzip" https://firmaniz.com/ \
  | grep -iE "content-encoding|content-length|vary"

Beklenen çıktı şuna benzer:

content-encoding: br
vary: Accept-Encoding

Gerçek boyut kazancını görmek için aynı kaynağı iki farklı başlıkla çekip karşılaştırın:

# Sikistirmasiz, gzip ve brotli boyutlarini yan yana koy
for ENC in "identity" "gzip" "br"; do
  BOYUT=$(curl -s -o /dev/null -w "%{size_download}" -H "Accept-Encoding: $ENC" https://firmaniz.com/css/stil.css)
  echo "$ENC: $BOYUT bayt"
done

vary: Accept-Encoding başlığının varlığını mutlaka doğrulayın. Bu başlık olmadan araya giren bir önbellek katmanı, Brotli ile sıkıştırılmış cevabı Brotli desteklemeyen bir istemciye sunabilir ve o istemci bozuk içerik alır. Tarayıcı tarafında ise DevTools Network panelinde bir isteğin "Size" sütununda hem aktarılan hem de açılmış boyutu görürsünüz; bu iki sayı birbirine eşitse sıkıştırma o istek için çalışmıyor demektir. İsteklerin bu şekilde okunmasını waterfall grafiği nasıl okunur yazısında ayrıntılı anlattım.

CDN ve Cloudflare Katmanıyla İlişkisi#

Sitenizin önünde bir CDN varsa sıkıştırma iki yerde yapılabilir ve hangisinin kazandığını bilmek gerekir. Çoğu CDN, kendi kenar sunucularında Brotli uygular; bu durumda kaynak sunucudan gelen içeriği açıp yeniden sıkıştırabilir. Sonuç olarak ziyaretçi Brotli alır ama sizin kaynak sunucunuzdaki ayar görünmez hâle gelir.

Bu, kaynak sunucuda sıkıştırmayı kapatmanız gerektiği anlamına gelmez. Kaynak ile kenar arasındaki trafiği de küçültmek istersiniz, üstelik CDN önbelleğinde olmayan bir istek doğrudan kaynağa gider. Doğru yapılandırma her iki katmanda da sıkıştırmanın açık olmasıdır.

CDN kullanırken doğrulamayı iki noktadan yapın: bir kez kenar üzerinden (normal alan adınızla), bir kez de kaynak sunucunun IP'sine doğrudan giderek. İkisi arasındaki farkı görmek, sorunun hangi katmanda olduğunu anında söyler. CDN'in genel olarak ne kazandırdığını ve ne kazandırmadığını CDN mi daha iyi hosting mi yazısında karşılaştırdım.

Sık Yapılan Hatalar#

En yaygın hata, gzip'i kapatmaktır. "Brotli daha iyi, gzip'e gerek yok" düşüncesi eski istemcileri ve bazı ara sunucuları sıkıştırmasız içerikle baş başa bırakır. İkisi birlikte açık kalmalıdır; sunucu istemcinin desteklediği en iyisini seçer.

İkinci hata, dinamik içerikte seviye 11 kullanmaktır. Her istekte en yüksek seviyede sıkıştırma yapmak TTFB'yi yükseltir ve yoğun trafikte işlemciyi tüketir. Dinamikte 4-6, statikte 11 kuralına sadık kalın.

Üçüncü hata, Vary: Accept-Encoding başlığını unutmaktır. Önbellek katmanları bu başlık olmadan yanlış sürümü sunabilir; sonuç, bazı ziyaretçilerde bozuk görünen sayfalardır ve teşhis edilmesi zordur.

Dördüncü hata, görselleri ve videoları sıkıştırma listesine eklemektir. Kazanç sıfıra yakın, işlemci maliyeti gerçektir. Görsel tarafında kazanç sıkıştırmadan değil, modern format (WebP/AVIF) ve doğru boyutlandırmadan gelir.

Beşinci hata, kurulumu doğrulamadan işi bitmiş saymaktır. Yapılandırmayı yazdınız, servisi yeniden başlattınız ama brotli_types listesine application/javascript eklemeyi unuttuysanız en büyük dosyalarınız hâlâ sıkıştırılmadan gidiyordur. Her tür için ayrı ayrı curl doğrulaması yapın.

Sıkça Sorulan Sorular#

Brotli gzip'ten ne kadar daha iyi#

Metin tabanlı içerikte tipik olarak yüzde 10-20 arası daha küçük çıktı verir; HTML ve JSON gibi kısa, tekrar eden içerikte bu oran daha da yükselebilir. Kazanç dosya içeriğine bağlıdır, o yüzden genel bir yüzde vermek yerine kendi dosyalarınızı brotli -q 11 -c dosya | wc -c ile ölçmek en doğrusudur.

Brotli HTTP üzerinde çalışır mı#

Teknik olarak protokol buna izin verse de tarayıcılar Brotli'yi pratikte yalnızca HTTPS bağlantılarda talep eder. Sitenizde SSL yoksa Brotli devreye girmez. Zaten günümüzde HTTPS bir seçenek değil gerekliliktir; sertifika kurulumunu tamamlamadan sıkıştırmayla uğraşmanın anlamı yoktur.

Paylaşımlı hostingde Brotli açabilir miyim#

Sunucu tarafında modül zaten yüklüyse genellikle evet: .htaccess üzerinden AddOutputFilterByType BROTLI_COMPRESS satırlarıyla ya da hosting panelindeki optimizasyon sekmesinden açabilirsiniz. Modül yüklü değilse sizin ekleme imkânınız olmaz; bu durumda hosting sağlayıcınıza sormak ya da sıkıştırmayı CDN katmanında yapmak gerekir.

Brotli sunucumu yorar mı#

Doğru seviyede kullanılırsa hayır. Seviye 4-6 aralığında işlemci maliyeti gzip'in tipik seviyesiyle benzerdir. Yük yaratan senaryo, dinamik içerikte seviye 9-11 kullanmaktır. Statik dosyalarınızı önceden sıkıştırırsanız çalışma zamanı maliyeti pratikte sıfıra iner.

Sıkıştırmanın çalıştığını nasıl kontrol ederim#

En hızlı yol curl -sI -H "Accept-Encoding: br,gzip" https://firmaniz.com/ komutunun çıktısında content-encoding: br satırını görmektir. Tarayıcı tarafında DevTools Network panelinde bir isteğin aktarılan boyutu ile açılmış boyutunun farklı olması da aynı bilgiyi verir. Her içerik türünü ayrı ayrı kontrol edin; HTML sıkışıyor olsa da JavaScript listeden dışarıda kalmış olabilir.

Zaten CDN kullanıyorum, sunucuda da açmalı mıyım#

Evet, açık kalmalı. CDN önbelleğinde olmayan her istek kaynak sunucunuza gider ve o trafiğin de küçük olması işinize yarar. Ayrıca CDN yapılandırmanız değişirse ya da geçici olarak devre dışı kalırsa, kaynak sunucudaki sıkıştırma yedek olarak devreye girer. İki katmanın birlikte çalışması sorun yaratmaz.

Kapanış#

Brotli, kod tarafında hiçbir şey değiştirmeden bant genişliğinden ve yükleme süresinden kazandıran nadir müdahalelerden biridir. Aklınızda kalması gereken dört alışkanlık: dinamik içerikte 4-6, statikte 11 seviyesini kullanın, gzip'i yedek olarak açık bırakın, Vary: Accept-Encoding başlığını mutlaka gönderin ve kurulumu her içerik türü için ayrı ayrı curl ile doğrulayın.

Modül derlemek, dağıtım betiğine ön sıkıştırma adımı eklemek ya da sunucu genelinde bu ayarları oturtmak için root erişimine ihtiyacınız var; tam kontrol isteyen projeler için VDS ve sanal sunucu paketlerimiz bu esnekliği verir. Sıkıştırma, önbellek ve HTTP/2 ayarları hazır gelen bir başlangıç arıyorsanız web hosting ve WordPress hosting planlarımıza bakabilirsiniz. Sunucu tarafındaki bu yapılandırmaları sizin yerinize kurmamızı isterseniz sunucu yönetimi hizmetimiz tam olarak bunu üstlenir.