Sıkıştırma (Gzip, Brotli, Zstd)

TL;DR — Sıkıştırma, metin dosyalarınızı — HTML, CSS, JavaScript — internet üzerinden gönderilmeden önce küçültür; böylece tarayıcı daha az bayt indirir ve sayfa daha hızlı yüklenir (tabii darboğaz gerçekten buysa). En sık duyacağınız iki seçenek Gzip (her yerde çalışır) ve Brotli’dir (genellikle daha küçüktür ve Google’ın tercihidir) — dosyanın ne kadar küçüleceği dosyaya göre değişir, bu nedenle tek bir yüzdeyi garanti olarak görmeyin. PageSpeed Insights size “Enable text compression” dediyse çözüm budur.

Sıkıştırma nedir?

Birisi sayfanızı yüklediğinde, tarayıcısının sayfayı oluşturan tüm dosyaları indirmesi gerekir. Sıkıştırma, bu dosyaları aktarılırken küçültmenin ve ardından tarayıcının diğer uçta açmasını sağlamanın bir yoludur. Ziyaretçi açısından sayfada hiçbir şey değişmez — yalnızca sayfaya daha hızlı ulaşır.

Her istekte gerçekleşen kısa bir el sıkışma gibi çalışır:

1. Tarayıcı, “neleri açabildiğini” söyler — anladığı algoritmaları (gzip ve br gibi) sıralayan Accept-Encoding adlı bir başlık gönderir.
2. Sunucu bunlardan birini seçer, dosyayı onunla sıkıştırır ve hangisini kullandığını belirten Content-Encoding başlığını geri gönderir.
3. Tarayıcı dosyayı açar ve sayfayı gösterir.

Hepsi bu. İşlem her dosya için otomatik gerçekleşir; sunucu veya barındırma ayarlarınızda bir kez etkinleştirmeniz yeterlidir.

Bilmeniz gereken iki seçenek

• Gzip — eski ve güvenilir seçenek. Her tarayıcı ve arama motoru tarafından desteklenir. Güvenli varsayılandır.
• Brotli — daha yenidir, Google tarafından geliştirilmiştir ve metin dosyalarını genellikle Gzip’den biraz daha fazla küçültür. Bir tarayıcı Brotli’yi destekliyorsa Google onu kullanmanızı, desteklemeyenler içinse Gzip’i yedek olarak tutmanızı söyler.

Ayrıca, açılması hızlı olan üçüncü bir seçenek Zstandard (Zstd) ile de daha sık karşılaşacaksınız; ancak kullanımı henüz erken aşamadadır ve yaygın değildir.

Sıkıştırma ne değildir?

• Küçültme değildir. Küçültme, kodunuzdaki boşlukları ve yorumları kaldırır; sıkıştırma ise baytları aktarım için yeniden paketler. Bunlar farklı işlerdir ve ikisini de yaparsınız — önce küçültür, sonra sıkıştırırsınız.
• Önbelleğe alma değildir. Önbelleğe alma, dosyanın yeniden gönderilmesine gerek kalmaması için bir kopyasını saklar. Sıkıştırma ise dosya gönderildiğinde onu küçültür. (Bu konu için önbelleğe alma sayfasına bakın.)

Neleri sıkıştırmalı, neleri atlamalısınız?

Metinlerinizi sıkıştırın: HTML, CSS, JavaScript, JSON, SVG ve XML dosyaları (site haritaları dâhil).

Zaten sıkıştırılmış dosyaları — JPG, PNG, GIF, çoğu video, WOFF2 web yazı tipi ve çoğu PDF — yeniden sıkıştırmaya çalışmayın. Küçülmezler; onları yeniden sıkıştırmak yalnızca kaynak israfına yol açar. Google bu noktayı 2008’de özellikle belirtmişti.

SEO’ya yardımcı olur mu?

Dolaylı olarak. Sıkıştırma tek başına bir sıralama faktörü değildir. Ancak daha küçük dosyalar daha hızlı yükleme anlamına gelir ve hız, Google’ın sayfa deneyimini değerlendirme biçiminin bir parçası olan Core Web Vitals’ı etkiler. Dolayısıyla sıkıştırmayı, Google bu ayarın kendisine puan verdiği için değil, sitenizi hızlandırdığı için etkinleştirirsiniz.

Gerçek sürümü — Gzip ve Brotli rakamlarını, Googlebot’un tam olarak neleri desteklediğini ve bunu nasıl bildiğimizi, PageSpeed denetim eşiklerini, sıkıştırma düzeylerini ve sunucunuzda sıkıştırmayı nasıl etkinleştirip doğrulayacağınızı — istiyor musunuz? Gelişmiş sekmesine geçin.

TL;DR — Sıkıştırma, HTTP içerik kodlaması uzlaşmasıdır: istemci Accept-Encoding (q ağırlıkları ve identity içerebilir) gönderir, sunucu her istek ve kaynak için Content-Encoding ile yanıt verir — kodlamaya göre değişen önbelleğe alınabilir bir yanıtın Vary: Accept-Encoding içermesi gerekir. Brotli aynı metinde genellikle Gzip’den daha iyi sonuç verir (kesin fark içeriğe, codec sürümüne ve düzeye bağlı olsa da sıklıkla %15–20 civarında belirtilir) ve desteklendiğinde Google’ın açıkladığı tercihtir; Gzip evrensel yedektir; Zstd, kayıtlı ancak evrensel olarak desteklenmeyen üçüncü bir codec’tir (Google’ın tarayıcı belgeleri Googlebot için Zstd desteği belirtmez). Googlebot gzip, deflate ve Brotli’yi (br) destekler — bu bugün açıkça belgelenmiştir, Gary Illyes tarafından 2020’de gayriresmî olarak doğrulanmıştır ve kökeni Google’ın 2008 tarihli “First date with the Googlebot” yazısına dayanır. Sıkıştırma bir sıralama faktörü değildir ve tek başına TTFB/LCP ya da Arama değişikliği garanti etmez; aktarım boyutunu küçültür ve gerçek darboğazınız buysa TTFB → LCP sürecine yardımcı olabilir. Ayrıca sayfaların Google’ın getirme sınırının (2026 tarihli “Inside Googlebot” yazısına göre HTML için 2 MB) altında kalmasına yardımcı olur — bu yalnızca hız değil, tarama verimliliği kazancıdır. Neleri sıkıştırıp sıkıştırmayacağınıza genel bir uzantı listesiyle değil, MIME türü ve ölçülen çıktıyla karar verin; BREACH türü risk, gizli bir değeri saldırganın yansıttığı içerikle birleştiren yanıtlarla sınırlıdır ve sıkıştırmayı site genelinde kapatmak için gerekçe değildir. Statik/önceden sıkıştırılmış varlıklarda daha yüksek, dinamik içerikte düşük/orta aralıkta sıkıştırma kullanın — evrensel olarak en iyi tek bir düzey olmadığından kendi trafiğiniz ve CPU’nuzla karşılaştırmalı ölçüm yapın. Sitemaps protokolü de gzip ile sıkıştırılmış site haritalarına açıkça izin verir.

Sıkıştırma gerçekte nedir?

Sıkıştırma — doğru ifadeyle HTTP içerik kodlaması — metin tabanlı yanıt gövdesini ağdan geçmeden önce küçültür; böylece istemci daha az bayt indirir ve bunları yerel olarak açar. Her istek için uzlaşma yapılır. Google’ın Lighthouse belgelerinde şöyle açıklanır: “When a browser requests a resource, it will use the Accept-Encoding HTTP request header to indicate what compression algorithms it supports.” Tipik bir başlık Accept-Encoding: gzip, deflate, br biçimindedir. Sunucu bunlardan birini seçer ve seçimini Content-Encoding yanıt başlığında bildirir.

Doğrudan HTTP belirtiminden (RFC 9110) gelen ve kesin biçimde ayrılması gereken iki sınır vardır: içerik kodlaması, temsil verilerinin dönüştürülmesidir — yani yanıt gövdesinin — ve bağlantı üzerinden ilerleyen ileti üzerinde çalışan aktarım kodlamasından farklıdır. Bu sayfada ele alınan sıkıştırma, Content-Encoding ile tanımlanan içerik kodlamasıdır. Uzlaşmanın kendisi de yalnızca düz bir liste değildir: Accept-Encoding, istemcinin kabul etmeye hazır olduğu kodlamalar arasındaki tercihlerini sıralayan ağırlıklar (q değerleri) taşıyabilir ve ret durumunu da (q=0) ifade edebilir; identity, “kodlama uygulanmadı” anlamındaki belirteçtir. (RFC 9110, §8.4 ve §12.5.3.) Önbelleğe alınabilir bir yanıtın gövdesi uzlaşılan kodlamaya göre gerçekten değişiyorsa — örneğin aynı URL’nin gzip ve Brotli sürümleri — önbelleğin çözemeyecek bir istemciye yanlış sürümü sunmaması için yanıtın Vary: Accept-Encoding içermesi gerekir (RFC 9110, §12.5.5; Apache’nin mod_deflate belgeleri, sıkıştırılmış önbellek sürümleri için tam olarak bu Vary gereksinimini açıklar).

Bu, metinlere uygulanır: HTML, CSS, JavaScript, JSON, SVG ve XML (site haritaları dâhil). Hem Gzip hem Brotli metin varlıklarını önemli ölçüde küçültebilir — Google’ın kendi PageSpeed kılavuzu bir üst sınır belirtir: “Enabling gzip compression can reduce the size of the transferred response by up to 90%.” Bunu tipik bir rakam değil, üst sınır olarak değerlendirin; belirli bir yanıttaki gerçek tasarruf içeriğin tekrar düzeyine, boyutuna, önceden küçültülüp küçültülmediğine, kullanılan codec’e, sürüme, sözlüğe ve sıkıştırma düzeyine bağlıdır. Bu nedenle bir sitenin rakamları başka bir siteye genellenemez.

Olmadığı iki şey vardır ve ikisi de önemlidir:

• Küçültme değildir. Küçültme, kaynaktaki karakterleri (boşluklar, yorumlar) kaldırır; sıkıştırma ise ortaya çıkan baytları aktarım için yeniden kodlar. Birlikte uygulanırlar — önce küçültün, sonra sıkıştırın — ve birini atlamak olası tasarrufun bir kısmından vazgeçmek demektir.
• Önbelleğe alma değildir. Sıkıştırma kodlamayla (hat üzerinden geçen baytları küçültmekle), önbelleğe alma ise saklama ve yeniden kullanımla (Cache-Control, ETag, CDN’ler) ilgilidir. Bunlar, “baytların tarayıcıya verimli biçimde ulaşmasını” sağlayan tamamlayıcı araçlardır. Saklama tarafı için önbelleğe alma sayfasına bakın.

Bu sayfa, kritik oluşturma yolu merkezi altındaki ayrıntılı sıkıştırma incelemesidir. Merkezdeki daha geniş kapsamlı kritik baytlar kontrol listesinde “metni sıkıştır” bir madde olarak yer alır. Bu sayfa, o maddeyi tüm ayrıntılarıyla ele alır.

Gzip, Brotli ve Zstd karşılaştırması

Sıkıştırma oranı

Brotli genellikle metinlerde daha iyi sonuç verir; ancak belirli bir rakamı evrensel kabul etmeyin. Google’ın Lighthouse belgesi, denetimde bildirilen tasarrufun Gzip ile hesaplandığını açıkça belirtir ve “if Brotli is used, even more savings are possible.” der. Google’ın kendi web.dev Brotli codelab çalışmasında somut bir örnek vardır: sıkıştırılmamış hâli 225 KB olan main.bundle.js, Gzip ile yaklaşık 61,6 KB’a, Brotli ile yaklaşık 53,1 KB’a düşmüştür — bu dosyada Brotli yaklaşık %14 daha küçük sonuç vermiştir. Bu tür rakamlar (ve başka yerlerde göreceğiniz yaklaşık %15–20 değeri) yön gösterir, garanti vermez. Belirli bir varlıktaki gerçek fark codec/kütüphane sürümüne, seçilen sıkıştırma düzeyine, içeriğin tekrar düzeyine ve önceden küçültülüp küçültülmediğine bağlıdır. Hiçbir codec veya kalite düzeyi, sıkıştırdığınız içerikten bağımsız olarak “her zaman en iyi” değildir; başkasının yüzdesini aktarmak yerine kendi varlıklarınızda karşılaştırmalı ölçüm yapın.

Gzip evrensel yedektir. Her yerde desteklenir; Google’ın onu güvenlik ağı olarak önermesinin nedeni tam olarak budur: “Use GZIP as a fallback to Brotli. GZIP is supported in all major browsers, but is less efficient than Brotli.”

Zstd, kayıtlı üçüncü bir codec’tir; henüz güvenli bir varsayılan değildir. IANA’nın HTTP içerik kodlaması sicilinde gzip, br ve zstd yer alır; ancak bu listeye kayıtlı olmak evrensel istemci, tarayıcı, kaynak sunucu veya CDN desteğiyle aynı şey değildir. Bu nedenle yalnızca belirli bir isteğin gerçekten talep ettiği kodlamaları bildirin ve çalışan bir yedek yolunu koruyun. Özellikle HTTP birlikte çalışabilirliği için, önceki RFC 8878 zstd kaydını güncelleyen RFC 9659, kod çözücülerin 8 MB’a kadar pencereleri desteklemesini zorunlu kılar ve kodlayıcıların bundan daha büyük bir pencere gerektirmesini yasaklar — bunun için bir sunucu veya CDN yapılandırıyorsanız bilmeniz yararlıdır. Bu HTTP içerik kodlaması zstd, sözlük tabanlı sıkıştırma kodlaması dcz’den de farklıdır; sağlayıcı belgelerini okurken ikisini karıştırmayın. Gerçek dünyadaki benimsenme hâlâ erken aşamadadır (örneğin Caddy, encode zstd gzip sunar) ve Google’ın güncel tarayıcı belgeleri, tarayıcıları ve getiricileri için gzip, deflate ve Brotli’yi sıralar; Googlebot için Zstandard desteğini belirtmez. Bu nedenle Zstd’nin bu gruba dâhil olduğunu varsaymayın. Zstd’yi izlenecek bir seçenek olarak görün; yığınınız desteklediğinde ve istek bunu talep ettiğinde etkinleştirin, ancak henüz Gzip/Brotli’nin yerine koymayın. Evidence for this claim gzip, br and zstd are registered HTTP content codings, but registration is not universal client, crawler, origin or CDN support; deploy only a coding advertised for the individual request and preserve a valid identity or fallback path. For HTTP interoperability, RFC 9659 requires zstd decoders to support windows through 8 MB and encoders not to require larger windows; this `zstd` coding is distinct from dictionary coding `dcz`. Scope: registry Confidence: high · Verified: 2026-07-16 HTTP Content Coding Registry

Tarayıcı ve web tarayıcısı desteği

Brotli desteği artık tarayıcılarda fiilen evrenseldir; ancak her zaman böyle değildi. Bu tarihsel boşluğu bilmek önemlidir, çünkü Gzip yedeğinin hâlâ gerekli olmasının nedeni budur. Google’ın Lighthouse belgesinde şöyle belirtilir: “As of December 2022 Brotli is supported in all major browsers except Safari on iOS.” iOS’taki Safari boşluğu, Gzip’i zincirde tutmanızın klasik örneğidir.

Google, istemci kullanabildiği her durumda Brotli’yi önerir: “If the browser supports Brotli (br) you should use Brotli because it can reduce the file size of the resources more than the other compression algorithms.”

Hangi durumlarda yine Gzip’e dönülmeli?

Gzip’i her zaman Brotli ile birlikte yapılandırın. İçerik kodlaması her istek için uzlaşmayla belirlenir; dolayısıyla doğru yapılandırılmış bir sunucu br bildiren istemcilere Brotli, diğer herkese otomatik olarak Gzip sunar. Birini veya diğerini seçmezsiniz; ikisini de sunar ve el sıkışmanın karar vermesini sağlarsınız.

Google (ve Bing) Brotli ile Gzip’i destekliyor mu?

Çoğu sıkıştırma makalesinin kanıt göstermeden kesin bir ifadeyle yanıtladığı soru budur. Burada Google’ın kendi açıklamalarından oluşan, tarihli ve üç aşamalı kanıt zincirini bulabilirsiniz.

2008 tarihli “First date with the Googlebot” yazısı

Google, sıkıştırmayı 2008’den beri kendi ifadeleriyle açıklıyor. First date with the Googlebot: Headers and compression yazısında (Maile Ohye ve Jeremy Lilley), tüm büyük arama motorlarıyla web tarayıcılarının bant genişliğinden tasarruf etmek için gzip sıkıştırmasını desteklediğini yazdı. Ayrıca x-gzip (gzip ile aynı), deflate (Google bunu da destekler) ve identity (hiçbiri) görebileceğinizi belirtti. Aynı yazıda Google, Flash, JPG, PNG, GIF ve PDF gibi birçok dosya biçiminin zaten sıkıştırılmış olduğunu ve bunları yeniden sıkıştırmanın çok az kazanç sağlayacağını açıklar. Sağlamlık gerekçesiyle gzip’i deflate’e hafifçe tercih ettiğini bile belirtir (gzip bir sağlama toplamı ve tam başlık taşır, dolayısıyla tahmine daha az yer bırakır). “Güncelliğini yitirmiş” etiketi taşıyan eski bir yazıdır; ancak içeriği hâlâ yayındadır, konuyla doğrudan ilgilidir ve güncel makalelerin neredeyse hiçbiri ona atıfta bulunmaz.

Gary Illyes’in 2020 tarihli Brotli doğrulaması

Googlebot’un Brotli desteği, resmen belgelenmeden önce gayriresmî olarak doğrulanmıştı. Ağustos 2020’de Google’dan Gary Illyes, Googlebot ekibiyle görüştükten sonra birkaç hafta önce kendisine Googlebot’un Brotli sıkıştırmasını destekleyip desteklemediğinin sorulduğunu ve desteklediğini söyledi. Barry Schwartz aynı gün bunu Search Engine Roundtable üzerinden bildirdi. Bu, güncel tarayıcı genel bakış belgelerinden yaklaşık dört yıl öncesine dayanır — bir temsilcinin tarayıcı davranışını belgelere girmesinden çok önce doğrulayabileceğini hatırlatan güzel bir örnektir.

Güncel resmî web tarayıcısı belgeleri

Bugün bu açıkça belirtilmektedir. Google’ın Crawler (User Agent) Overview belgesinde şöyle denir: “Google’s crawlers and fetchers support the following content encodings (compressions): gzip, deflate, and Brotli (br).” Ayrıca her istek için uzlaşmayı tarayıcıyla aynı biçimde açıklar: “The content encodings supported by each Google user agent is advertised in the Accept-Encoding header of each request they make. For example, Accept-Encoding: gzip, deflate, br.” Ayrı bir içerik kodlaması bölümü bulunan Ahrefs Googlebot rehberimde de aynı şeyi söylüyorum: “Googlebot supports gzip, deflate, and Brotli (br).”

Dolayısıyla silsile şöyledir: 2008 blog yazısı → 2020 Illyes doğrulaması → güncel web tarayıcısı belgeleri. Bu spekülasyon değil, sağlam biçimde yerleşmiş bir bilgidir.

Bing belgelerindeki boşluk

Buradaki dürüst dipnot Bing’dir. Bingbot’un sıradan HTML’yi tararken hangi içerik kodlamaları için uzlaşma yaptığını belirten, Google’ın web tarayıcısı genel bakış sayfasına eşdeğer, ayrıntılı ve herkese açık bir Bing belgesi yoktur. Bing’in belgelediği kapsam daha dardır: Content Submission API’si Gzip’i destekler ve Bing’e gzip ile sıkıştırılmış site haritası dosyaları (.xml.gz) gönderebilirsiniz. HTTP sıkıştırması, neredeyse tüm modern istemcilerin Accept-Encoding üzerinden uzlaştığı standart bir mekanizma olduğundan Bingbot’un en azından Gzip’i kullandığını varsaymak makuldür; ancak bunu belgelenmiş bir Bing açıklaması değil, HTTP’nin çalışma biçiminden çıkarılan bir sonuç olarak değerlendirin. Bu, Bingbot’un gerçek davranışına yönelik bir eleştiri değil, iki motor arasındaki gerçek bir belge şeffaflığı boşluğudur.

Sıkıştırma performans ve Core Web Vitals için neden önemlidir?

Nedensellik zinciri (kesin biçimde ifade edelim)

Sıkıştırma doğrudan bir sıralama faktörü değildir. Etkilediği mekanizma şudur: daha küçük aktarım boyutu indirme süresini kısaltabilir; bu da Time to First Byte ve sonraki Largest Contentful Paint değerlerine yardımcı olabilir. Bunlar, bir sayfa deneyimi sinyali olan Core Web Vitals’ı etkiler. Buradaki “olabilir” ifadesine dikkat edin: Google’ın kendi kılavuzu, garanti edilen sonucu daha az ağ baytıyla sınırlar; TTFB/LCP kazanımı, daha iyi Core Web Vitals veya Arama değişikliği garanti etmez. Yükleme başka bir yerde darboğaza giriyorsa (yavaş bir veritabanı sorgusu, oluşturmayı engelleyen bir komut dosyası, DNS/bağlantı kurulumu), zaten küçük bir yanıtı sıkıştırmak önemli bir fark yaratmaz. Sıkıştırmanın tek başına hız sorununu çözeceğini varsaymak yerine kendi darboğazınızı ve saha sonucunuzu ölçün. Puanlanan şey sıkıştırma ayarı değil, hız sonucudur. Bunu doğru anlamak önemlidir; çünkü birçok rakip içerik “SEO’ya yardımcı olur” ifadesini “sıralama faktörü” ile karıştırır. (Bkz. Time to First Byte, Largest Contentful Paint ve Core Web Vitals.) Evidence for this claim Reducing transferred bytes may improve a network-bound load, but compression alone does not guarantee lower TTFB/LCP, better Core Web Vitals or a Search change; measure the actual bottleneck and field outcome. Scope: lab audit Confidence: high · Verified: 2026-07-16 Enable text compression

Google’dan Martin Splitt’in, ham sayfa ağırlığının bu konuyu düşünmek için neden yanıltıcı olduğuna ilişkin güzel bir çerçevesi vardır: önemli olan diskteki sıkıştırılmamış boyut değil, sıkıştırmadan sonra kablo üzerinden gerçekten geçen veridir — sıkıştırılmamış hâli 10 MB görünen bir sayfa ağ üzerinden beş veya altı olabilir. Splitt’in bu görüşü birincil bir dökümden değil, Search Engine Journal’ın haberinden aktarıldığı için burada alıntılanmamış, başka sözcüklerle aktarılmıştır.

Sıkıştırma ve tarama verimliliği — yeterince önemsenmeyen yön

Sıkıştırma yalnızca insanlar için sayfa hızıyla ilgili değildir. Google’ın getirme sınırının altında kalmanıza da yardımcı olur. 2026 tarihli “Inside Googlebot” güncellemesine (Gary Illyes) göre Googlebot, HTML için URL başına yaklaşık 2 MB getirir (önceki 15 MB değerinden düşürülmüştür) ve sınırı aşan içerik reddedilmez, kesilir — yalnızca indirilen bölüm dizine ekleme için iletilir. HTML’nizi sıkıştırmak, kritik içeriği bu bütçe içinde tutan araçlardan biridir. Dolayısıyla bu yalnızca Core Web Vitals değil, tarama verimliliği meselesidir. (Sınır hakkında daha fazla bilgi için tarama sayfasına bakın.)

Lighthouse “Enable text compression” denetimi — kesin eşikler

PageSpeed Insights / Lighthouse “Enable text compression” denetiminin belirtilmeye değer kesin tetikleme kuralları vardır. Lighthouse, hâlihazırda br, gzip veya deflate değerli bir content-encoding taşımayan metin tabanlı yanıtları toplar, tasarrufu tahmin etmek için her birini Gzip ile sıkıştırır ve Google’ın belgesine göre şu kuralı uygular: “If the original size of a response is less than 1.4KiB, or if the potential compression savings is less than 10% of the original size, then Lighthouse does not flag that response in the results.” Dolayısıyla yaklaşık 1,4 KiB’ın altındaki küçük dosyalar sıkıştırılmamış olsalar bile uyarıyı tetiklemez. (Lighthouse 13 itibarıyla bu denetim daha geniş “Document request latency” içgörüsüne dâhil edilmiştir; ancak temel kılavuz değişmemiştir.)

Doğru yapılandırılmış bir site denetimde neden yine başarısız olabilir?

Google’ın PageSpeed belgelerinden doğrudan gelen, gerçekten yararlı bir sorun giderme bilgisi şudur: “Proxy servers and anti-virus software can disable compression when files are downloaded to a client machine.” Bu, sunucunuz doğru yapılandırılmış olsa bile bir aracının aktarım sırasında Content-Encoding başlığını kaldırması nedeniyle sıkıştırma denetleyicisinin yanlış negatif — “sıkıştırma etkin değil” — bildirebileceği anlamına gelir. Raporun bozuk veya sunucunun yanlış yapılandırılmış olduğunu varsaymadan önce temiz bir ağ yolundan test edin.

Statik ve dinamik sıkıştırma — uygulama ödünleşimleri

Sıkıştırma düzeyleri

Her iki algoritmada da CPU süresiyle sıkıştırma oranı arasında ödünleşim sağlayan ayarlanabilir düzeyler vardır:

• Gzip: 1–9 düzeyleri.
• Brotli: Google’ın web.dev codelab çalışmasına göre 0 (sıkıştırma yok) ile 11 (en yüksek) arasındaki düzeyler.

Daha yüksek düzeyler daha güçlü sıkıştırır, ancak daha fazla CPU süresi harcar.

CPU maliyeti — statik ve dinamik ayrımı neden önemlidir?

Sıkıştırma bedelsiz değildir; CPU tüketir ve önceden oluşturulmuş varlıklarla anında üretilen içeriğin maliyet profilleri tamamen farklıdır. Her iki durum için de doğru ayar tek bir evrensel rakam değildir. Temel içeriğin ne sıklıkla değiştiğine, önbellek/CDN katmanınızın sıkıştırılmış sürümü nasıl işlediğine, trafik hacminize ve yalnızca bir blog yazısından alınmış pratik kurala değil, gerçekten ölçtüğünüz sonuçlara bağlıdır.

• Statik (önceden sıkıştırılmış / derleme zamanında) varlıklar — önceden bir kez sıkıştırılacak kadar kararlı içerikler (nginx’in gzip_static ve Apache’nin mod_deflate belgelerinin ikisi de her istekte yeniden sıkıştırmak yerine önceden sıkıştırılmış bir dosyanın seçilmesini açıklar), CPU maliyeti her istekte değil derleme sırasında bir kez ödendiği için daha yüksek sıkıştırma düzeylerini kaldırabilir. web.dev codelab çalışmasının ifade ettiği gibi, sıkıştırma önceden yapıldığında yüksek sıkıştırma düzeylerinin gecikmesi artık sorun değildir; ödünleşim, ziyaretçi başına değil bir kez katlandığınız daha uzun derleme sürelerine kayar.
• Dinamik (her istek için üretilen) yanıtlar — gerçek zamanda en yüksek düzeylerde sıkıştırma her yanıta gecikme ekler. Bu nedenle düşük/orta aralıkta bir düzey yaygın bir başlangıç noktasıdır (araçlar bazen oran ve hız arasında başlangıç dengesi olarak dinamik içerikte Brotli’yi yaklaşık kalite 4’e ayarlar). Ancak bunu sabit bir kural değil, kendi CPU kapasiteniz ve trafiğinizle karşılaştırmalı ölçüm yapacağınız bir başlangıç noktası olarak değerlendirin. Google bu ödünleşimi 2008 tarihli yazısında bile vurgulamıştır: gzip/deflate’i etkinleştirmenin CPU maliyeti vardır ve zaten yoğun CPU yükü altında dinamik içerik sunan bir sunucuda her şey için en yüksek sıkıştırmayı açmadan önce bunu değerlendirmek gerekir.

Pratik başlangıç noktası statik için daha yüksek, dinamik için düşük/orta aralıkta bir düzeydir. Ancak bunu bir makaleden (bu makale dâhil) alınmış düzey numarasıyla değil, kendi değişkenliğiniz, önbellek/CDN davranışınız, trafiğiniz ve ölçülmüş öncesi/sonrası sonuçlarıyla doğrulayın.

Sıkıştırma nasıl etkinleştirilir?

Mekanizma her yerde aynıdır: sunucuyu (veya CDN/uç katmanını) metin yanıtlarını sıkıştıracak ve Gzip yedeğiyle Brotli sunacak şekilde yapılandırın. Platformlara göre:

• Apache — mod_deflate modülü (Brotli için de mod_brotli). Google’ın PageSpeed kılavuzu doğrudan buraya yönlendirir.
• Nginx — yerleşik ngx_http_gzip_module (gzip on; ve gzip_types) ile br için Brotli modülü.
• IIS — yerleşik HTTP Compression (statik ve dinamik).
• CDN / uç — Cloudflare, Fastly ve benzerleri genellikle Brotli + Gzip’i bir açma-kapama seçeneği olarak sunar; Caddy encode zstd gzip sunar.
• Uygulama çerçeveleri — Node/Express compression ara yazılımı; Next.js/Vercel ve çoğu modern barındırma hizmeti varsayılan olarak sıkıştırır.

Ardından doğrulayın (tam komutlar için Kontrol Listeleri görünümüne bakın). En hızlı kontrol: curl -I -H "Accept-Encoding: br, gzip" https://example.com/ komutunu çalıştırın ve yanıtta bir content-encoding başlığı arayın.

Neler sıkıştırılmamalı?

Zaten sıkıştırılmış biçimleri yeniden sıkıştırmayın: JPG, PNG, GIF, çoğu video, WOFF2 yazı tipleri ve çoğu PDF. Bunlar dâhili olarak zaten sıkıştırılmıştır; üzerlerinde yeniden Gzip veya Brotli çalıştırmak, ihmal edilebilir — bazen olumsuz — bir boyut değişikliği için CPU harcar. Bu listeyi kapsamlı bir kurallar bütünü değil, örnekler olarak değerlendirin. GTmetrix’in kendi sorun giderme kılavuzu da aynı çerçeveyi kullanır: zaten sıkıştırılmış veya yüksek entropili biçimler “may not benefit and can grow.” Daha güvenli genel kural, sıkıştırmayı MIME türüne (metin tabanlı biçimlere) göre sınırlamak ve mümkünse genel bir dosya uzantısı listesine güvenmek yerine belirli bir yanıtın ölçülmüş çıktısını kontrol etmektir; çünkü biçim ve içerik değişir.

Sıkıştırmanın altında “işe yaramadığı” tek bir evrensel minimum yanıt boyutu da yoktur. Çerçeveleme ve meta veri yükü, küçük veya zaten yoğun gövdelerde tasarrufu ortadan kaldırabilir; ancak başabaş noktasının nerede olduğu codec’e, uygulamaya, yanıt başlıklarına ve içeriğin kendisine bağlıdır. Lighthouse’un kendi 1,4 KiB / %10 tasarruf eşikleri (yukarıda), genel bir boyut tabanı değil, o denetime özgü bastırma kuralıdır. Bir CDN, yanıtı sıkıştırmaya ne zaman değeceğine ilişkin kendi farklı minimumunu yayımlayabilir (ve çoğu zaman yayımlar). Evidence for this claim Framing and metadata overhead can erase savings for small or poorly compressible bodies; there is no universal minimum response size because codec, implementation, headers and content determine the break-even point. Scope: lab audit Confidence: high · Verified: 2026-07-16 Enable text compression

Sıkıştırma ve BREACH — sınırlı bir risk, site genelinde sıkıştırmayı kapatma gerekçesi değil

Tedbir amacıyla sıkıştırmayı kapatmanızı öneren güvenlik tavsiyeleri görebilirsiniz. Bunu genellemeyin. BREACH türü risk, soyut olarak “sıkıştırmanın” bir özelliği değildir. Özgün araştırma belirli bir saldırı biçimini açıklar: (1) sıkıştırılan, (2) gizli bir değeri (CSRF belirteci gibi) (3) aynı yanıta yansıtılan, saldırganın etkileyebildiği içerikle birleştiren ve (4) saldırganın tekrarlanan isteklerde sıkıştırılmış yanıt uzunluğunu gözlemleyerek gizli değerin her seferinde bir baytını çıkarabildiği bir HTTP yanıtı. Apache’nin mod_deflate belgeleri, BREACH’e özgü incelemeye değer olanın tam olarak bu birleşim olduğunu belirtir. Yanıtlarınız sıkıştırılmış gövdede gizli bir değerle saldırganın kontrol ettiği yansıtılmış girdiyi birleştirmiyorsa klasik saldırı geçerli değildir. Çözüm, tüm sitede metin sıkıştırmasını kapatmak değil, savunmasız belirli yanıtı/bağlamı inceleyip azaltım uygulamaktır (örneğin kullanıcı girdisini gizli değerlerin yanında yansıtmamak, her istek için belirteç eklemek veya hız sınırı uygulamak).

Site haritası miti — sıkıştırmaya açıkça izin verilir

Yüksek sesle yapılmaya değer bir düzeltme: Sitemaps protokolü gzip ile sıkıştırılmış site haritalarına açıkça izin verir. Bazıları site haritası dosyasını gzip ile sıkıştıramayacağınıza veya sıkıştırmamanız gerektiğine inanır; bu yanlıştır. sitemaps.org protokolü, bant genişliğini azaltmak için gzip ile sıkıştırılmış site haritası dosyalarına (.xml.gz) izin verir; her iki motor da bunları kabul eder ve Bing’in kendi gönderim araçları da gzip’i destekler. Tek koşul olağandır: sıkıştırılmamış site haritası protokolün boyut sınırlarına (50 000 URL / sıkıştırılmamış 50 MB) uymaya devam etmelidir. Dosyayı aktarım sırasında gzip ile sıkıştırmak uygundur ve büyük site haritalarında teşvik edilir.

Sıkıştırmanın web performansındaki yeri

Sıkıştırma, bu kümedeki araçlardan biridir. Kritik oluşturma yolunun indirmesi gereken kritik baytları küçültür; TTFB ve sonraki LCP değerlerini düşürür; adlandırılmış bir PageSpeed Insights / Lighthouse denetimidir. Ayrıca önbelleğe alma (kodlama ve saklama) ve oluşturmayı engelleyen kaynaklarla (daha küçük engelleyici dosyalar daha erken görüntülenir) birlikte çalışır. Daha geniş araç seti için web performansı araçlarına bakın.

Yapay zekâ özeti

Gelişmiş sürümün özetlenmiş hâli:

• Sıkıştırma = HTTP içerik kodlamasıdır ve HTTP aktarım kodlamasından farklıdır (RFC 9110, §8.4). Metin yanıtlarını (HTML, CSS, JS, JSON, SVG, XML site haritaları) ağdan geçmeden önce küçültür. Her istek için uzlaşma yapılır: istemci Accept-Encoding (q ağırlıkları ve identity içerebilir) gönderir, sunucu Content-Encoding ile yanıt verir; kodlamaya göre değişen önbelleğe alınabilir bir yanıtın Vary: Accept-Encoding (§12.5.5) içermesi gerekir.
• Üç codec: Gzip (evrensel yedek), Brotli (metinde genellikle daha küçük; çoğu zaman yaklaşık %15–20 belirtilir ancak bu sabit bir rakam değildir, içeriğe/codec sürümüne/düzeye göre değişir ve desteklendiğinde Google’ın açıkladığı tercihtir), Zstd (IANA’da kayıtlıdır ve RFC 9659 ile kapsamı belirlenmiştir; ancak evrensel olarak desteklenmez ve Google’ın tarayıcı belgeleri Googlebot için Zstd desteği belirtmez). Brotli ve Gzip yedeğini birlikte sunun.
• Googlebot gzip, deflate ve Brotli’yi (br) destekler — bu güncel web tarayıcısı belgelerinde açıkça belirtilmiş, Gary Illyes tarafından 2020’de gayriresmî olarak doğrulanmış ve Google’ın 2008 tarihli “First date with the Googlebot” yazısına dayandırılmıştır. Bing’in eşdeğer bir web tarayıcısı sıkıştırma belgesi yoktur — Gzip desteğini HTTP standartlarından çıkarım olarak kabul edin ve bu boşluğu belirtin.
• Bir sıralama faktörü ve garanti edilmiş hız kazanımı değildir. Daha küçük aktarım boyutu, yalnızca gerçek darboğaz buysa TTFB → LCP → Core Web Vitals sürecine yardımcı olabilir. Google’ın kendi kılavuzu doğrudan sonucu daha az ağ baytıyla sınırlar; Core Web Vitals veya Arama değişikliği vaat etmez. Sıkıştırma ayrıca HTML’nin Googlebot’un yaklaşık 2 MB getirme sınırının (2026 tarihli “Inside Googlebot”) altında kalmasına yardımcı olur; bu bir tarama verimliliği kazancıdır. Sınırı aşan getirmeler reddedilmez, kesilir.
• Lighthouse “Enable text compression”, br/gzip/deflate kodlaması olmayan metin yanıtlarını işaretler; ancak yaklaşık 1,4 KiB altındaki veya olası tasarrufu %10 altında olan dosyaları atlar. Bu, evrensel bir boyut tabanı değil, denetime özgü bastırma kuralıdır (CDN’ler kendi minimumlarını yayımlar). Proxy/antivirüs Content-Encoding başlığını kaldırarak yanlış negatife yol açabilir.
• Düzeyler ve ödünleşimler: Gzip 1–9, Brotli 0–11. Statik/önceden sıkıştırılmış varlıklarda daha yüksek (maliyet derlemede bir kez ödenir), dinamik içerikte düşük/orta aralıkta (CPU/gecikme) düzey kullanın. Kendi trafiğinizle karşılaştırmalı ölçüm yapın; hiçbir düzey evrensel olarak en iyi değildir.
• Uzantıya göre genel dışlama yapmayın — MIME türüne ve ölçülen çıktıya göre karar verin; zaten sıkıştırılmış biçimler (görüntüler, video, WOFF2, çoğu PDF) nadiren yarar sağlar.
• BREACH riski sınırlıdır ve site genelinde sıkıştırmayı kapatma gerekçesi değildir: gizli bir değeri saldırganın yansıttığı içerikle birleştiren sıkıştırılmış bir yanıt ve gözlemlenebilir tekrarlı uzunluk gerektirir; belirli yanıtı/bağlamı inceleyip düzeltin.
• Kodlanmış temsilin kendisini doğrulayın: önbellek sürümleri için Vary: Accept-Encoding kullanın, proxy/CDN/kaynak sunucu geçişlerinde çift sıkıştırmayı izleyin ve ETag/Content-Length/aralık davranışını identity/gzip/br arasında aynı değil, seçilen kodlamaya özgü kabul edin.
• Site haritası miti çürütüldü: Sitemaps protokolü gzip ile sıkıştırılmış site haritalarına (.xml.gz) açıkça izin verir; sıkıştırılmamış boyut sınırları geçerliliğini korur.

Resmî belgeler

Sıkıştırma ve içerik kodlamasıyla ilgili birincil kaynak belgeleri.

Google

• Enable text compression (Lighthouse) — denetimin tetikleme eşikleri, Accept-Encoding uzlaşması ve “Brotli’yi tercih et, Gzip’e dön” kılavuzu.
• Minify and compress network payloads with brotli (web.dev codelab) — Brotli kalite düzeyleri (0–11), statik ve dinamik sıkıştırma ödünleşimleri ve bir öncesi/sonrası örneği.
• Enable Compression (PageSpeed Insights) — “up to 90%” değeri, sunucu modülleri (mod_deflate, gzip modülü, IIS) ve proxy/antivirüs kaynaklı yanlış negatif uyarısı.
• Google Crawler (User Agent) Overview — kesin “gzip, deflate, and Brotli (br)” açıklaması ve web tarayıcılarının bunu Accept-Encoding üzerinden nasıl bildirdiği.
• First date with the Googlebot: Headers and compression (2008) — Google’ın gzip ve deflate karşılaştırmasına ve sıkıştırmadan yarar sağlamayan dosya türlerine ilişkin özgün açıklaması.

Standartlar / protokol

• RFC 9110 — HTTP Semantics — içerik kodlamasını aktarım kodlamasından farklı olarak temsil verilerinin dönüştürülmesi (§8.4) şeklinde tanımlar; q ağırlıkları ve identity ile Accept-Encoding uzlaşmasını (§12.5.3) ve kodlamaya göre değişen önbellek sürümleri için Vary gereksinimini (§12.5.5) açıklar.
• RFC 9659 — Zstandard (zstd) as an HTTP Content Coding — RFC 8878’i günceller, zstd için 8 MB birlikte çalışabilir pencere gereksinimini belirler ve onu sözlük kodlaması dcz’den ayırır.
• IANA HTTP Content Coding Registry — kayıtlı kodlama belirteçlerinin (gzip, br, zstd ve diğerleri) yetkili listesi; kayıt, evrensel istemci/web tarayıcısı/CDN desteğiyle aynı değildir.
• Apache mod_deflate documentation — sıkıştırılmış önbellek sürümleri için Vary: Accept-Encoding, önceden sıkıştırılmış içeriğin çift sıkıştırılmasını önleme, DeflateAlterETag ve BREACH inceleme notu.
• Cloudflare — content compression — kaynak/uç dönüştürme davranışı, sıkıştırma için minimum yanıt boyutu ve plana/kurala göre codec seçimi.
• nginx ngx_http_gzip_static_module — her istekte yeniden sıkıştırmak yerine önceden sıkıştırılmış statik dosyaları sunma.
• Sitemaps protocol (sitemaps.org) — gzip ile sıkıştırılmış site haritası dosyalarına izin verildiğini ve sıkıştırılmamış boyut sınırlarını doğrular.

Güvenlik

• BREACH attack — original research — saldırının gerçek ön koşulları: gizli bir değeri saldırganın etkilediği yansıtılmış içerikle birleştiren ve tekrarlı uzunluk ölçümüyle gözlemlenen sıkıştırılmış bir yanıt.

Bing / Microsoft

• Bingbot’un HTML taraması için içerik kodlaması desteğini belirten özel bir Bing belgesi yoktur. Bing’in URL/site haritası gönderim yardımı, gzip ile sıkıştırılmış site haritası desteğini ve Content Submission API’sinde Gzip kullanımını doğrular — Bing Webmaster Tools help. Web tarayıcısı tarafındaki desteği belgelenmiş bir açıklama değil, HTTP standartlarından yapılan çıkarım olarak değerlendirin.

Kaynaktan alıntılar

Google’ın kayda geçmiş açıklamaları. #:~:text= parçası içeren her bağlantı, kaynak sayfadaki alıntılanan bölüme gider.

Google — Lighthouse “Enable text compression”

• “When a browser requests a resource, it will use the Accept-Encoding HTTP request header to indicate what compression algorithms it supports.” Alıntıya git
• “If the browser supports Brotli (br) you should use Brotli because it can reduce the file size of the resources more than the other compression algorithms.” Alıntıya git
• “The potential savings that Lighthouse lists are the potential savings when the response is encoded with GZIP. If Brotli is used, even more savings are possible.” Alıntıya git
• “If the original size of a response is less than 1.4KiB, or if the potential compression savings is less than 10% of the original size, then Lighthouse does not flag that response in the results.” Alıntıya git
• “As of December 2022 Brotli is supported in all major browsers except Safari on iOS.” … “Use GZIP as a fallback to Brotli. GZIP is supported in all major browsers, but is less efficient than Brotli.” Alıntıya git

Google — PageSpeed Insights “Enable Compression”

• “Enabling gzip compression can reduce the size of the transferred response by up to 90%.” Alıntıya git
• “Proxy servers and anti-virus software can disable compression when files are downloaded to a client machine.” Alıntıya git

Google — Crawler (User Agent) Overview

• “Google’s crawlers and fetchers support the following content encodings (compressions): gzip, deflate, and Brotli (br).” Alıntıya git
• “The content encodings supported by each Google user agent is advertised in the Accept-Encoding header of each request they make. For example, Accept-Encoding: gzip, deflate, br.” Alıntıya git

Gary Illyes, Google — Brotli doğrulaması (2020)

• Illyes, Googlebot ekibiyle görüştükten sonra Googlebot’un Brotli sıkıştırmasını desteklediğini doğruladı — Ağustos 2020’de X’te yayımlandı ve aynı gün Barry Schwartz tarafından haberleştirildi. (Burada rapordan başka sözcüklerle aktarılmış, bire bir alıntı olarak çoğaltılmamıştır.) Haberi okuyun

Hangi sıkıştırma kurulumunu kullanmalıyım?

“Gzip mi, Brotli mi?” sorusundan değil, neyi nerede sunduğunuzdan başlayın — pratikte neredeyse her zaman ikisini de sunarsınız.

S1. Sunucunuz/CDN’niz Gzip yedeğiyle Brotli sunabiliyor mu?

• Evet (modern Nginx/Apache modülü veya bir CDN seçeneği) → Brotli + Gzip’i etkinleştirin. Uzlaşma, br bildiren istemciler için Brotli’yi, diğer herkes için Gzip’i otomatik olarak seçer. Varsayılan yanıt budur. S2’ye geçin.
• Hayır (eski yığın, Brotli modülü yok) → şimdilik yalnızca Gzip’i etkinleştirin. Her yerde desteklenir ve kazancın çoğunu sağlar. Brotli ekleyebildiğinizde yeniden değerlendirin.

S2. Varlık statik mi (önceden oluşturulmuş), yoksa her istek için mi üretiliyor?

• Statik (CSS/JS paketleri, önceden oluşturulmuş HTML, site haritaları) → derleme sırasında varlıklarınızla karşılaştırmalı ölçüm yaparak daha yüksek düzeyde önceden sıkıştırın (Gzip 9 / Brotli 11’e kadar). CPU maliyeti bir kez ödenir; her istek daha küçük dosyayı alır.
• Dinamik (uygulama/CMS tarafından her istek için üretilen HTML) → düşük/orta aralıkta sıkıştırın (Brotli ~4, karşılaştırmalı ölçüm için yaygın bir başlangıç noktasıdır). En yüksek düzeyler her yanıta gerçek zamanlı gecikme ekler; doğru düzey sabit bir rakama değil, trafiğinize ve boş CPU kapasitenize bağlıdır.

S3. Dosya zaten sıkıştırılmış bir ikili dosya mı? (JPG, PNG, GIF, video, WOFF2, çoğu PDF)

• Evet → sıkıştırmayın. Küçülmez; CPU harcarsınız ve dosya biraz büyüyebilir. Sıkıştırma kurallarınızı metin MIME türleriyle sınırlayın.
• Hayır (HTML, CSS, JS, JSON, SVG, XML) → sıkıştırın.

S4. Etkinleştirmenize rağmen PageSpeed raporunuz hâlâ “Enable text compression” diyor.

• İşaretlenen dosya yaklaşık 1,4 KiB’ın altında mı veya %10’dan az mı tasarruf sağlar? → Lighthouse bunları zaten işaretlemez; işaretlenmemişse düzeltilecek bir şey yoktur.
• curl -I -H "Accept-Encoding: br, gzip" ile test ettiğinizde bir content-encoding başlığı görüyor musunuz? → sunucu iyidir; test yolundaki bir proxy veya antivirüs muhtemelen başlığı kaldırmıştır. Temiz bir ağdan yeniden test edin.
• Hiç content-encoding başlığı yok → sunucu bu yanıtı gerçekten sıkıştırmıyordur; MIME türü kapsamınızı ve modül yapılandırmanızı kontrol edin.

Sıkıştırma kurulumu ve doğrulama — kontrol listesi

Metnin sıkıştırıldığını, Brotli’nin tercih edildiğini ve hiçbir şeyin çift sıkıştırılmadığını doğrulamak için bir kontrol:

• Gzip yedeğiyle Brotli etkin — sunucu br sunar ve bunu desteklemeyen istemcilere Gzip gönderir.
• Sıkıştırma metin MIME türleriyle sınırlı — HTML, CSS, JS, JSON, SVG, XML. Zaten sıkıştırılmış biçimler (görüntüler, video, WOFF2, çoğu PDF) dışlanır.
• Statik varlıklar derleme sırasında daha yüksek düzeyde önceden sıkıştırılmıştır (Gzip 9 / Brotli 11’e kadar) — bir blog yazısından kopyalanmamış, karşılaştırmalı olarak ölçülmüştür.
• Dinamik yanıtlar CPU/gecikme dengesini sağlamak için düşük/orta düzeydedir ve kendi trafiğinizle doğrulanmıştır.
• Kodlamaya göre değişen önbelleğe alınabilir yanıtlarda Vary: Accept-Encoding vardır, böylece paylaşılan önbellek yanlış sürümü sunmaz.
• Proxy/CDN/kaynak sunucu geçişlerinde çift sıkıştırma yoktur ve Content-Length her geçişteki gerçek kodlanmış gövdeyle eşleşir.
• Komut satırından doğrulanmıştır: curl -I -H "Accept-Encoding: br, gzip" https://example.com/ komutu bir content-encoding: br (veya gzip) başlığı döndürür.
• DevTools’da doğrulanmıştır — Network sekmesi, metin yanıtlarında transferred boyutun resource boyutundan çok daha düşük olduğunu gösterir.
• PageSpeed Insights / Lighthouse — yaklaşık 1,4 KiB üzerindeki metin yanıtlarında “Enable text compression” işareti yoktur.
• Yanlış negatif elenmiştir — denetleyici sıkıştırmanın kapalı olduğunu söylüyor ancak curl bir content-encoding başlığı gösteriyorsa sunucudan önce aktarım sırasında başlığı kaldıran proxy/antivirüsten şüphelenin.
• Site haritaları — büyük site haritaları gzip ile (.xml.gz) sunulur ve sıkıştırılmamış dosya 50 000 URL / 50 MB sınırları içinde kalır.
• Küçültme de yapılmıştır — sıkıştırma küçültmeyle birlikte uygulanır; birinin yerine diğerini değil, ikisini de yaparsınız.

Sıkıştırma kısa başvuru kılavuzu

Üç codec

Sıkıştırma düzeyleri

Neleri sıkıştırmalı, neleri atlamalısınız?

Kısa bilgiler

• Googlebot gzip, deflate ve Brotli’yi (br) destekler — Accept-Encoding üzerinden uzlaşılır (Zstd için doğrulanmamıştır).
• Google, Gzip’in tasarruf üst sınırını yaklaşık %90’a kadar olarak belirtir — bu tipik bir rakam değil, üst sınırdır; gerçek tasarruf içeriğe ve codec’e göre değişir.
• Lighthouse, yaklaşık 1,4 KiB’tan küçük dosyaları veya olası tasarrufu %10’dan az olanları atlar — bu evrensel minimum boyut değil, denetimin kendi bastırma kuralıdır.
• Sıkıştırma, HTML’nin Googlebot’un yaklaşık 2 MB getirme sınırının (2026) altında kalmasına yardımcı olur — bu bir tarama verimliliği kazancıdır; sınırı aşan getirmeler reddedilmez, kesilir.
• Kodlamaya göre değişen önbelleğe alınabilir yanıtların Vary: Accept-Encoding içermesi gerekir; aksi hâlde paylaşılan önbellek, çözemeyecek bir istemciye yanlış sürümü sunabilir.
• BREACH riski, gizli bir değeri saldırganın yansıttığı içerikle birleştiren yanıtlarla sınırlıdır — site genelinde sıkıştırmayı kapatmak için gerekçe değildir.
• Sitemaps protokolü gzip’e izin verir (.xml.gz) — “site haritası gzip ile sıkıştırılamaz” inancı bir mittir.
• Doğrulama: curl -I -H "Accept-Encoding: br, gzip" <url> → content-encoding ve vary başlıklarını arayın.

Sıkıştırma mitleri ve hataları

Unutulması gereken, sürekli tekrarlananlar:

• “Sıkıştırmayı etkinleştirmek sıralamalarımı yükseltir.” Resmî kaynaklar veya temsilciler sıkıştırmanın bir sıralama sinyali olduğunu söylemez. Sayfa hızı / Core Web Vitals için bir girdidir (sayfa deneyimiyle ilişkilidir), kendi başına puanlanan bir faktör değildir. Hız için etkinleştirin ve etkisini dürüstçe açıklayın.
• “Brotli Google tarafından desteklenmiyor, bu yüzden Gzip kullanın.” Güncelliğini yitirmiştir. Google’ın tarama altyapısı en az 2020’den (Illyes) beri Brotli’yi destekler ve bu, güncel web tarayıcısı belgelerinde açıkça belirtilir. Haber eski ve gözden kaçırılması kolay olduğu için mit yaşamaya devam eder.
• “Görüntülerimi / yazı tiplerimi / videolarımı sıkıştırmak siteyi hızlandırır.” Ters etki yaratır. JPG, PNG, GIF, çoğu video ve WOFF2 yazı tipleri zaten sıkıştırılmıştır; yeniden sıkıştırmak ihmal edilebilir veya sıfır kazanç için CPU harcar ve bazen dosyayı büyütebilir. Sıkıştırmayı metinlerle sınırlayın.
• “PageSpeed raporum sıkıştırmanın kapalı olduğunu söylüyor ama açtım — rapor bozuk.” Şart değil. Google’ın kendi PSI belgesine göre proxy’ler veya antivirüs, Content-Encoding başlığını ölçülmeden önce kaldırarak yanlış negatife yol açabilir. Aracı veya sunucuyu suçlamadan önce curl ile temiz bir yoldan test edin.
• “Sıkıştırma ve küçültme aynı şeydir.” Farklı aşamalardır: küçültme kaynak karakterlerini kaldırır, sıkıştırma baytları aktarım için yeniden kodlar. Birlikte uygulanırlar — ikisini de yapın.
• “En yüksek sıkıştırma düzeyi her zaman en iyidir.” Dinamik içerik için abartılı bir ifadedir. En yüksek düzeyler (Gzip 9, Brotli 11) istek başına gerçek CPU maliyeti oluşturur; bunları statik/önceden sıkıştırılmış varlıklarda, anında üretilen yanıtlarda ise orta aralıklı bir düzey kullanın.
• “Site haritasını gzip ile sıkıştıramazsınız (veya sıkıştırmamalısınız).” Yanlış — Sitemaps protokolü gzip ile sıkıştırılmış site haritalarına (.xml.gz) açıkça izin verir; yalnızca sıkıştırılmamış dosyayı 50 000 URL / 50 MB sınırları içinde tutun.

Uzlaşılan sıkıştırmayı komut satırından doğrulayın

macOS/Linux’ta çalıştırın. --compressed, desteklenen kodlamaları bildirir ve gövdeyi görüntülemek için açar; başlıklar, hat üzerinden neyin aktarıldığını göstermeye devam eder.

curl -sS --compressed -D - -o /dev/null https://example.com/app.js
curl -sS -H 'Accept-Encoding: br' -D - -o /dev/null https://example.com/app.js
curl -sS -H 'Accept-Encoding: gzip' -D - -o /dev/null https://example.com/app.js
curl -sS -H 'Accept-Encoding: identity' -D - -o /dev/null https://example.com/app.js

Önbelleğe alınabilir bir kaynağın yanıtı uygun bir Content-Encoding ve Vary: Accept-Encoding başlığı içermelidir. Kaynak paylaşılan bir önbelleğin veya CDN’nin arkasındaysa bu başlığı özellikle kontrol edin; başlığın bulunmaması, önbelleğin bir istemcinin kodlanmış sürümünü çözemeyecek başka bir istemciye sunmasına yol açar.

Windows PowerShell’de her kodlamayı isteyin ve başlıkları inceleyin:

$headers = @{ "Accept-Encoding" = "br, gzip" }
$r = Invoke-WebRequest -Uri "https://example.com/app.js" -Headers $headers
$r.Headers | Select-Object Content-Encoding, Vary, Content-Length

DevTools’da sıkıştırılmamış aynı kaynaklı metin varlıklarını bulun

Sayfa yüklendikten sonra Chrome DevTools Console’a yapıştırın. Kısa liste oluşturmak için kaynak zamanlaması boyutlarını kullanır; önbelleğe alınmış ve kaynaklar arası girdiler boyutları atlayabildiğinden her yanıtı Network panelinde doğrulayın.

performance.getEntriesByType('resource')
  .filter((r) => r.transferSize > 0 && r.encodedBodySize === r.decodedBodySize)
  .map((r) => ({ url: r.name, bytes: r.transferSize }));

Bir web tarayıcısında sıkıştırma başlıklarını çıkarın

Bu XPath’i, yalnızca web tarayıcınız başlıkları ayrı olarak saklamışsa HTML işaretini bulmak üzere yanıt başlıklarını bilen özel bir çıkarma iş akışında kullanın. Sıradan HTML için sıkıştırma bir HTTP başlığıdır ve DOM’un kendisinden çıkarılamaz. Bu ayrım, yaygın bir hatalı testi önler: XPath tek başına aktarım kodlamasını kanıtlayamaz.

HTTP sıkıştırmasını test etme araçları

• Chrome DevTools Network paneli — Content-Encoding, aktarılan boyut, kaynak türü ve CDN/önbelleğin yanıtı değiştirip değiştirmediğini inceleyin.
• curl --compressed — tarayıcı arayüzüne bağlı kalmadan gerçek içerik uzlaşmasını test edin ve Brotli, Gzip ve identity yanıtlarını karşılaştırın.
• PageSpeed Insights / Lighthouse — makalede açıklanan “Enable text compression” denetimini tetikleyecek kadar bayt tasarrufu sağlayabilecek metin kaynaklarını gösterin.
• WebPageTest — tutarlı bir konum, tarayıcı ve ağ profili altında aktarım boyutlarıyla istek şelalelerini karşılaştırın.
• CDN/sunucu yapılandırması ve günlükleri — statik ve dinamik kaynaklar için hangi codec’in ve sıkıştırma düzeyinin seçildiğini doğrulayın.

Sıkıştırmanın doğru yapılandırıldığını kanıtlayın

Kodlama uzlaşması testi

Çalıştırılacak test: bir metin kaynağını ayrı ayrı Accept-Encoding: br, gzip ve identity ile isteyin. Beklenen sonuç: desteklenen istekler eşleşen Content-Encoding değerini alır; identity çözülebilir kalır ve sürümler uygun Vary değerini içerir. Başarısızlığın yorumu: uzlaşma, önbellek çeşitlendirmesi veya kaynak/CDN yapılandırması yanlıştır. İzleme aralığı: yayılımın hemen ardından. Geri alma tetikleyicisi: bozuk gövdeler veya yanlış kodlamayla sunulan bir sürüm.

Kaynak kapsamı testi

Çalıştırılacak test: Network panelinde örnek HTML, CSS, JS, JSON/SVG/XML ile zaten sıkıştırılmış görüntüleri, videoları ve yazı tiplerini inceleyin. Beklenen sonuç: metin biçimleri sıkıştırılır, kazanç sağlamayan biçimler yeniden sıkıştırılmaz. Başarısızlığın yorumu: MIME türü izin listesi eksik veya aşırı geniştir. İzleme aralığı: hemen. Geri alma tetikleyicisi: artan aktarım boyutu, aşırı kaynak sunucu CPU kullanımı veya bozuk varlıklar.

Performans gerilemesi testi

Çalıştırılacak test: dinamik sıkıştırmayı etkinleştirmeden önce ve sonra tekrarlanabilir WebPageTest/Lighthouse çalıştırmalarını ve sunucu CPU kullanımını karşılaştırın. Beklenen sonuç: tutarlı bir TTFB veya hata gerilemesi olmadan metin aktarımı baytları azalır. Başarısızlığın yorumu: seçilen codec/düzey çok fazla CPU harcıyordur veya sıkıştırma yanlış katmanda gerçekleşiyordur. İzleme aralığı: laboratuvarda hemen, üretimde temsilî yük sırasında. Geri alma tetikleyicisi: sürekli gecikme, CPU doygunluğu veya artan hatalar.

Önbellek sürümü (Vary) testi

Çalıştırılacak test: farklı istemcilere farklı kodlamalarla sunulan önbelleğe alınabilir bir yanıtı aynı önbellek/CDN yolu üzerinden sırasıyla Accept-Encoding: br, gzip ve identity ile isteyin. Beklenen sonuç: her sürüm, talep edilen kodlamaya uygun biçimde döner ve önbellek anahtarının uzlaşılan kodlamayı içermesi için yanıt Vary: Accept-Encoding taşır (RFC 9110, §12.5.5). Başarısızlığın yorumu: paylaşılan bir önbellek, kodlanmış tek bir sürümü saklayıp onu çözemeyen istemcilere sunuyordur — klasik belirti, br bildirmeyen bir istemcinin okuyamadığı Brotli gövdesi almasıdır. İzleme aralığı: herhangi bir CDN/önbellek katmanı değişikliğinin hemen ardından. Geri alma tetikleyicisi: destek bildirmediği bir gövdeyi alan herhangi bir istemci veya aşırı genişletilmiş önbellek anahtarı nedeniyle önbellek isabet oranının çökmesi.

Çift dönüştürme ve eski meta veri testi

Çalıştırılacak test: sıkıştırmanın tam olarak bir kez uygulandığını doğrulamak için bir yanıtı her proxy/CDN/kaynak sunucu geçişinde izleyin (örneğin kaynaktaki başlıklarla uçtaki başlıkları karşılaştırın). Beklenen sonuç: son Content-Encoding tek bir kodlamayı adlandırır ve Content-Length, gönderilen gerçek kodlanmış gövdeyle eşleşir; bir geçişin gövdeyi dönüştürmesinden önceki identity uzunluk başlığı kalmaz. Başarısızlığın yorumu: bir aracı, uzunluk/bütünlük meta verilerini güncellemeden yanıtı açıp yeniden sıkıştırmıştır (veya zaten sıkıştırılmış bir gövdeyi sıkıştırmıştır) — Apache’nin mod_deflate ve Cloudflare’in sıkıştırma belgeleri bu yeniden sıkıştırma/meta veri sapması durumunu açıkça belirtir. İzleme aralığı: herhangi bir CDN, ters proxy veya uç dönüştürme kuralı eklendikten ya da değiştirildikten sonra. Geri alma tetikleyicisi: bozuk indirmeler, eşleşmeyen Content-Length veya gözle görülür biçimde çift sıkıştırılmış gövdeler.

Doğrulayıcı ve aralık isteği testi

Çalıştırılacak test: aynı kaynağı identity, gzip ve br ile isteyin; her biri için ETag, Content-Length ve Range isteği altındaki davranışı karşılaştırın. Beklenen sonuç: her kodlanmış temsil ayrı kabul edilir — kendi ETag değeri (veya açıkça belgelenmiş paylaşılan doğrulayıcı politikası), o kodlamaya özgü doğru Content-Length ve identity/gzip/br genelinde aynı olduğu varsayılmadan seçilen temsile uygulanan aralık semantiği. Başarısızlığın yorumu: doğrulayıcılar veya kısmi içerik işleme, tek bir kanonik temsil varsayımıyla oluşturulmuştur; bu da sıkıştırılmış sürümlerde koşullu istekleri veya bayt aralığı indirmelerini bozar. İzleme aralığı: hemen ve sıkıştırma yapılandırması veya CDN önbellek kurallarındaki her değişiklikten sonra yeniden. Geri alma tetikleyicisi: koşullu isteklerin (If-None-Match) veya aralık isteklerinin sıkıştırılmış bir sürüm için yanlış ya da bozuk gövdeler döndürmesi.

Kendinizi sınayın: Sıkıştırma

HTTP metin sıkıştırmasının nasıl çalıştığı ve Google’ın neleri desteklediği hakkında beş kısa soru. Her biri için bir yanıt seçin, ardından kontrol edin.

Değişiklik günlüğü