HTTP sıkıştırması gerçekte nasıl çalışır
Web'de sıkıştırma, her istekte gerçekleşen sessiz bir pazarlıktır. Tarayıcı neyi açabildiğini Accept-Encoding başlığıyla duyurur — modern olanlar gzip ve br gönderir. Sunucu birini seçer, cevap gövdesini sıkıştırır ve tarayıcı nasıl açacağını bilsin diye Content-Encoding ile etiketler. Ne uygulama kodunuz ne HTML'iniz değişir; çeviri tamamen yolda olur.
Getiri büyüktür çünkü metin çok iyi sıkışır. 100 KB'lik bir HTML sayfası Gzip ile genellikle 20 KB olarak yolculuk eder; bir JavaScript paketi çoğu zaman dörtte üç küçülür. Yavaş ya da mobil bağlantıdaki ziyaretçiler için bu fark, yükleme sürenizin görünen kısmıdır — sıkıştırmanın metin için neredeyse bedava ve neredeyse her zaman doğru olan nadir optimizasyon olmasının sebebi budur.
Brotli gerçekte neyi iyileştiriyor
Brotli'nin üstünlüğü iki tasarım kararından gelir: daha akıllı bir format ve web'de sürekli geçen dizgelerin — HTML etiketleri, CSS özellik adları, yaygın JavaScript belirteçleri — gömülü bir sözlüğü. Web metni tam da ayarlandığı şeydir ve sunucuların gerçek zamanda kullandığı seviyelerde Brotli tipik olarak Gzip'ten %15-20 küçük dosyalar üretir.
Yine de dürüst çerçeveyi koruyun: bu, Gzip'in mevcut %70-80'lik azaltmasının ÜSTÜNE %15-20'dir. Bir sayfa gzip'li 20 KB gidiyorsa Brotli onu kabaca 16-17 KB yapar. Sahip olmaya değer — her varlıkta ve her ziyaretçide birikir — ama bir devrim değil, bir inceltmedir. Çarpıcı farklar iddia eden karşılaştırma grafikleri görürseniz, Brotli'nin en yavaş ve en yüksek eforlu seviyesini Gzip'in varsayılanıyla kıyaslayıp kıyaslamadığına bakın; o ayarlarda Brotli istek başına çalışamayacak kadar yavaştır ve statik dosyaları önceden sıkıştırmak için kullanılır.
Uyumluluk yıllar önce dert olmaktan çıktı: bugünkü neredeyse her tarayıcı Accept-Encoding'inde br gönderir ve pazarlık sayesinde göndermeyen nadir eski istemci basitçe Gzip alır. Ziyaretçi için aleyhte senaryo yoktur.
Asla sıkıştırılmaması gerekenler
Aynanın kuralı da bir o kadar önemlidir: zaten sıkıştırılmış baytları sıkıştırmak CPU israf eder ve dosyaları çoğu zaman biraz büyütür. Görseller (JPEG, PNG, WebP, AVIF), video ve ses, WOFF2 fontlar, ZIP arşivleri, gömülü görselli PDF'ler — formatları fazlalığı zaten sıkmıştır. Gzip ya da Brotli'nin bulacağı bir şey kalmamıştır.
Sıkıştırmanın içerik tipine göre yapılandırılmasının ve battaniye gibi bir "her şeyi sıkıştır" kuralının küçük ama gerçek bir hata olmasının sebebi budur. Pratik ayrım: metin tipleri açık (HTML, CSS, JS, JSON, XML, SVG), ikili medya kapalı. Metin sütununa ait tek görsel formatı SVG'dir — XML'dir ve harika sıkışır.
Nerede çalışmalı: uygulama sunucunuzda değil, edge'de
Sıkıştırma her cevapta CPU harcar ve akışın ne kadar aşağısında çalışırsa o kadar az çalışır. Edge sıkıştırdığında, cache'lenen sayfa bir kez sıkıştırılır ve cache'ten binlerce kez sunulan şey o sıkıştırılmış kopyadır — origin'iniz hiçbir şey harcamaz, edge de istemcinin kabul edebildiği her varyantı saklar.
cdn.com.tr'de bu, dağıtım kuralı başına bir ayardır: her kural, panelde aynı kuralın cache ve optimizasyon seçeneklerinin yanında işaretlediğiniz bir sıkıştırma listesi (gzip, zip, brotli) taşır. Brotli'yi açmak bir onay kutusudur, sunucu taşıması değil — ve kuralın üstünde durduğu için sayfalarınızı agresifçe sıkıştırırken zaten-sıkıştırılmış medya kuralınızı rahat bırakabilirsiniz; önceki bölümün savunduğu ayrım tam da budur.
Gerçekte ne gönderdiğinizi doğrulayın
Sıkıştırma hakkındaki varsayımlar, kontrolün otuz saniyeye değeceği kadar sık yanlıştır. Bir sayfayı farklı Accept-Encoding teklifleriyle iki kez isteyin ve dönen Content-Encoding'i okuyun. Oradayken aktarılan boyutları karşılaştırın — fark, inanılan değil ölçülen tasarrufunuzdur.
CDN üzerinden test ederken bir uyarı: edge, varyantı önceki bir istekten cache'lemiş olabilir; taze davranışı görmek için cache kıran bir sorgu dizesi kullanın — ve anında cevap veren sıkıştırılmış cache kopyasının tam da hedef olduğunu unutmayın.
İki istek, iki teklif — dönene bakın
# brotli teklif edilince sunucu ne gonderiyor?
curl -sI -H 'Accept-Encoding: br' https://example.com/ | grep -i content-encoding
# yalnizca gzip teklif edilince?
curl -sI -H 'Accept-Encoding: gzip' https://example.com/ | grep -i content-encoding
# gercek aktarilan baytlari karsilastir (sikistirilmis vs duz)
curl -so /dev/null -H 'Accept-Encoding: br' -w 'brotli: %{size_download} bayt\n' https://example.com/
curl -so /dev/null -H 'Accept-Encoding: identity' -w 'duz: %{size_download} bayt\n' https://example.com/Sık sorulan sorular
Brotli ve Gzip'i birlikte mi açmalıyım?
Evet — normal kurulum budur. Pazarlık, br teklif eden tarayıcılara Brotli'yi seçer, kalanlara Gzip'e düşer. İkisini açmak, tek başına herhangi birinden kesin olarak iyidir.
Sıkıştırma sunucumu yavaşlatır mı?
CPU harcar, ama istek başına kullanılan seviyelerde maliyet, kazanılan bant genişliğinin yanında küçüktür — ve cache'lenen içeriği edge sıkıştırdığında origin'iniz hiç ödemez: sıkıştırılmış kopya bir kez üretilir, cache'ten sunulur.
Görsel trafiğimde neden sıkıştırma görünmüyor?
Çünkü doğrusu bu: JPEG, PNG, WebP ve AVIF zaten sıkıştırılmış formatlardır; yeniden sıkıştırmak sıfır (bazen eksi) kazanç için CPU harcar. Sıkıştırma metin içindir. Daha küçük görsel istiyorsanız kol, Content-Encoding değil format ve boyutlandırmadır — WebP/AVIF dönüşümü.
Brotli için site kodumu değiştirmem gerekir mi?
Hayır. Sıkıştırma, tarayıcı ile sunucu/edge arasında istek başına pazarlıkla olur; HTML, CSS ve JavaScript'inize dokunulmaz. cdn.com.tr'de dağıtım kuralındaki bir işarettir, gerisini edge halleder.