Kompresi Gzip #

Kompresi gzip mengurangi ukuran response sebelum dikirim ke browser. Untuk konten teks seperti HTML, CSS, dan JavaScript, rasio kompresi bisa mencapai 70-90% — artinya file 100KB bisa jadi hanya 10-30KB di jaringan. Ini langsung berdampak pada waktu loading halaman, terutama untuk pengguna dengan koneksi lambat.

Cara Kerja #

Tanpa kompresi:
  Server → [file 100KB] → Jaringan → Browser

Dengan gzip:
  Server → compress → [file 15KB] → Jaringan → Browser → decompress → tampilkan
           (CPU server)                          (CPU browser)

Trade-off: sedikit CPU di server dan browser, penghematan bandwidth besar

Browser modern semua mendukung gzip — mereka memberitahu server lewat header Accept-Encoding: gzip, deflate, br.

Konfigurasi Dasar #

http {
    gzip on;

    # Kompres response yang lebih besar dari ukuran ini
    # Jangan kompres file kecil — overhead lebih besar dari manfaatnya
    gzip_min_length 1024;   # 1KB

    # Level kompresi: 1 (cepat, kurang kompres) hingga 9 (lambat, kompres maksimal)
    # Level 6 adalah sweet spot: kompresi baik tanpa CPU overhead signifikan
    gzip_comp_level 6;

    # Tipe konten yang dikompres
    # text/html dikompres secara default — tidak perlu disebutkan
    gzip_types
        text/plain
        text/css
        text/javascript
        text/xml
        application/json
        application/javascript
        application/xml
        application/xml+rss
        image/svg+xml
        font/woff2
        font/woff;

    # Tambahkan header Vary: Accept-Encoding agar CDN cache versi gzip dan non-gzip terpisah
    gzip_vary on;

    # Kompres response dari upstream/proxy juga
    # "any" berarti kompres apapun yang diterima dari backend
    gzip_proxied any;

    # Versi HTTP minimum untuk menggunakan gzip
    # HTTP/1.0 punya masalah dengan proxy dan gzip — gunakan 1.1
    gzip_http_version 1.1;
}

Tipe Konten yang Dikompres vs Tidak #

Kompresi gzip paling efektif untuk konten berbasis teks:

KOMPRES (rasio tinggi):
  ✓ text/html           → 70-80% lebih kecil
  ✓ text/css            → 70-80% lebih kecil
  ✓ application/javascript → 60-80% lebih kecil
  ✓ application/json    → 60-80% lebih kecil
  ✓ image/svg+xml       → 50-70% lebih kecil
  ✓ font/woff (bukan woff2 — woff2 sudah terkompresi)

JANGAN KOMPRES (sudah terkompresi atau tidak efisien):
  ✗ image/jpeg, image/png, image/webp, image/gif
  ✗ video/mp4, audio/mp3
  ✗ application/zip, application/gzip
  ✗ font/woff2 (sudah menggunakan kompresi Brotli secara internal)

Mengkompres file yang sudah terkompresi bisa membuat ukurannya sedikit lebih besar dan membuang CPU sia-sia.

gzip_static: Sajikan File .gz yang Sudah Ada #

Jika proses build frontend kamu sudah menghasilkan file .gz (misalnya dengan webpack atau build tool lain), Nginx bisa langsung menyajikan file yang sudah terkompres tanpa harus mengkompres ulang saat request:

http {
    gzip_static on;

    # Jika ada /var/www/app.js.gz → sajikan ini
    # Jika tidak ada → fallback ke /var/www/app.js (dan kompres on-the-fly jika gzip on)
}

/var/www/html/
├── app.js          ← untuk browser yang tidak support gzip
└── app.js.gz       ← disajikan jika browser request Accept-Encoding: gzip

Ini jauh lebih efisien untuk file statis yang sering diakses — tidak ada CPU overhead untuk kompresi, file sudah siap.

Level Kompresi: Trade-off CPU vs Ukuran #

Level 1: sangat cepat, kompresi minimal  (~30-40% lebih kecil)
Level 6: seimbang, default yang baik     (~65-75% lebih kecil)
Level 9: lambat, kompresi maksimal       (~70-80% lebih kecil)

Perbedaan ukuran antara level 6 dan 9 biasanya < 5%
Perbedaan CPU bisa 3-5x lipat

→ Level 6 adalah pilihan terbaik untuk hampir semua kasus
→ Level 1-2 jika server CPU-bound dan butuh kompresi cepat
→ Level 9 tidak praktis untuk real-time compression

Brotli: Alternatif yang Lebih Efisien #

Brotli adalah algoritma kompresi yang dikembangkan Google, lebih efisien dari gzip untuk konten web (rata-rata 15-25% lebih kecil dari gzip pada level kompresi yang setara).

Nginx tidak mendukung Brotli secara bawaan — butuh modul tambahan (ngx_brotli). Jika menggunakan OpenResty atau mengkompilasi Nginx sendiri:

# Dengan modul ngx_brotli
brotli on;
brotli_comp_level 6;
brotli_types text/plain text/css application/json application/javascript text/xml;

# Bisa berjalan bersamaan dengan gzip
# Browser yang support Brotli akan menggunakan Brotli (lebih baik)
# Browser lama yang hanya support gzip akan tetap mendapat gzip
gzip on;

Untuk Nginx standar tanpa modul tambahan, gzip sudah sangat efektif.

Verifikasi Kompresi Aktif #

# Cek apakah response dikompres dengan gzip
curl -H "Accept-Encoding: gzip" -I https://example.com/app.js

# Perhatikan header:
# Content-Encoding: gzip   ← response dikompres
# Vary: Accept-Encoding    ← gzip_vary on

# Bandingkan ukuran dengan dan tanpa gzip
curl -o /dev/null -s -w "%{size_download}\n" https://example.com/app.js
curl -H "Accept-Encoding: gzip" -o /dev/null -s -w "%{size_download}\n" https://example.com/app.js

Ringkasan #

gzip on + gzip_types adalah konfigurasi minimal — tambahkan gzip_vary on dan gzip_proxied any untuk setup yang lengkap.
Level 6 adalah sweet spot kompresi vs CPU — jangan gunakan level 9 untuk kompresi real-time.
Jangan kompres gambar (JPEG, PNG, WebP), video, atau file yang sudah terkompresi — hasilnya bisa lebih besar dan membuang CPU.
gzip_static on menyajikan file .gz yang sudah ada dari build process — lebih efisien dari kompresi on-the-fly.
gzip_vary on wajib jika menggunakan CDN — tanpa ini, CDN bisa menyajikan response yang salah ke browser yang tidak support gzip.

← Sebelumnya: Worker Process Berikutnya: Caching →