Brotli در برابر Gzip: سایت شما باید از کدام فشرده‌سازی استفاده کند؟

فشرده‌سازی HTTP واقعاً چگونه کار می‌کند

فشرده‌سازی در وب یک توافق بی‌صدا است که در هر درخواست اتفاق می‌افتد. مرورگر در هدر Accept-Encoding اعلام می‌کند چه چیزهایی را می‌تواند باز کند — مرورگرهای مدرن gzip و br را می‌فرستند. سرور یکی را انتخاب می‌کند، بدنه‌ی پاسخ را فشرده می‌کند و با Content-Encoding برچسب می‌زند تا مرورگر بداند چگونه آن را باز کند. نه کد اپلیکیشن شما تغییر می‌کند و نه HTML شما؛ این تبدیل کاملاً در مسیر انتقال انجام می‌شود.

نتیجه چشمگیر است، چون متن فوق‌العاده خوب فشرده می‌شود. یک صفحه‌ی HTML صد کیلوبایتی معمولاً با Gzip در قالب 20 کیلوبایت منتقل می‌شود؛ یک باندل JavaScript اغلب سه‌چهارم کوچک‌تر می‌شود. برای بازدیدکنندگانی که اتصال کند یا موبایلی دارند، همین تفاوت بخش قابل‌مشاهده‌ی زمان بارگذاری شماست — به همین دلیل فشرده‌سازی از آن بهینه‌سازی‌های نادر است که تقریباً رایگان است و برای متن تقریباً همیشه درست.

Brotli واقعاً چه چیزی را بهتر می‌کند

برتری Brotli از دو انتخاب طراحی می‌آید: قالبی هوشمندتر، و یک دیکشنری داخلی از رشته‌هایی که دائماً در وب تکرار می‌شوند — تگ‌های HTML، نام property‌های CSS، توکن‌های رایج JavaScript. متنِ وب دقیقاً همان چیزی است که برایش تنظیم شده، و روی آن Brotli معمولاً در سطوح فشرده‌سازی‌ای که سرورها به‌صورت بلادرنگ استفاده می‌کنند، فایل‌هایی 15-20% کوچک‌تر از Gzip تولید می‌کند.

اما چارچوب منصفانه را حفظ کنید: این 15-20% روی کاهش 70-80 درصدیِ از قبل موجودِ Gzip سوار می‌شود. اگر صفحه‌ای با Gzip در 20 کیلوبایت منتقل می‌شود، Brotli آن را تقریباً به 16-17 کیلوبایت می‌رساند. ارزشش را دارد — روی هر asset و هر بازدیدکننده جمع می‌شود — اما یک بهبود است، نه یک انقلاب. اگر نمودارهای بنچمارکی دیدید که تفاوت‌های چشمگیر ادعا می‌کنند، بررسی کنید که آیا کندترین و پرهزینه‌ترین سطح Brotli را با سطح پیش‌فرض Gzip مقایسه کرده‌اند؛ در آن تنظیمات Brotli کندتر از آن است که برای هر درخواست اجرا شود و در عوض برای پیش‌فشرده‌سازی فایل‌های استاتیک به کار می‌رود.

سازگاری سال‌هاست که دیگر دغدغه نیست: عملاً همه‌ی مرورگرهای فعلی br را در Accept-Encoding خود می‌فرستند، و سازوکار توافق باعث می‌شود آن کلاینت قدیمی نادری که نمی‌فرستد، به‌سادگی Gzip بگیرد. برای بازدیدکننده هیچ سناریوی ضرری وجود ندارد.

چه چیزهایی هرگز نباید فشرده شوند

قاعده‌ی معکوس هم به همان اندازه مهم است: فشرده‌کردن بایت‌هایی که از قبل فشرده‌اند، CPU هدر می‌دهد و اغلب فایل‌ها را اندکی بزرگ‌تر می‌کند. تصاویر (JPEG، PNG، WebP، AVIF)، ویدیو و صدا، فونت‌های WOFF2، آرشیوهای ZIP، فایل‌های PDF با تصاویر جاسازی‌شده — قالب این فایل‌ها از قبل افزونگی را بیرون کشیده است. چیزی برای Gzip یا Brotli باقی نمانده که پیدا کند.

به همین دلیل فشرده‌سازی بر اساس نوع محتوا پیکربندی می‌شود، و به همین دلیل قانون کلیِ «همه‌چیز را فشرده کن» یک اشتباه کوچک اما واقعی است. تقسیم‌بندی عملی: انواع متنی روشن (HTML، CSS، JS، JSON، XML، SVG)، رسانه‌های باینری خاموش. SVG تنها فرمت تصویری است که به ستون متن تعلق دارد — چون XML است و به‌زیبایی فشرده می‌شود.

کجا باید اجرا شود: لبه، نه سرور اپلیکیشن شما

فشرده‌سازی در هر پاسخ CPU مصرف می‌کند، و هرچه در پایین‌دستِ مسیر اجرا شود، دفعات کمتری اجرا می‌شود. وقتی لبه فشرده می‌کند، یک صفحه‌ی کش‌شده یک‌بار فشرده می‌شود و همان نسخه‌ی فشرده است که هزاران بار از کش سرو می‌شود — origin شما هیچ هزینه‌ای نمی‌پردازد، و لبه هر واریانتی را که کلاینت می‌پذیرد نگه می‌دارد.

در cdn.com.tr این یک تنظیم به‌ازای هر قانون تحویل است: هر قانون یک فهرست فشرده‌سازی (gzip، zip، brotli) دارد که در پنل روشن یا خاموش می‌کنید، در کنار گزینه‌های کش و بهینه‌سازی همان قانون. روشن‌کردن Brotli یک چک‌باکس است، نه یک مهاجرت سرور — و چون روی خودِ قانون قرار دارد، می‌توانید صفحات‌تان را با شدت فشرده کنید و در عین حال به قانونِ رسانه‌های از قبل فشرده‌تان دست نزنید؛ دقیقاً همان تقسیم‌بندی‌ای که بخش قبل از آن دفاع کرد.

بررسی کنید واقعاً چه می‌فرستید

فرض‌ها درباره‌ی فشرده‌سازی به‌قدری اشتباه از آب درمی‌آیند که این بررسی به سی ثانیه‌اش می‌ارزد. یک صفحه را دو بار با پیشنهادهای متفاوت Accept-Encoding درخواست کنید و Content-Encoding برگشتی را بخوانید. همان‌جا حجم‌های منتقل‌شده را هم مقایسه کنید — تفاوت، صرفه‌جویی شماست؛ اندازه‌گیری‌شده، نه صرفاً باورشده.

یک نکته هنگام تست از پشت CDN: ممکن است لبه واریانت را از یک درخواست قبلی کش کرده باشد، پس برای دیدن رفتار تازه از یک query string کش‌شکن استفاده کنید — و به یاد داشته باشید که یک نسخه‌ی کش‌شده‌ی فشرده که فوراً پاسخ می‌دهد، دقیقاً همان هدف است.

دو درخواست، دو پیشنهاد — پاسخ برگشتی را بخوانید

# what does the server send when offered brotli?
curl -sI -H 'Accept-Encoding: br' https://example.com/ | grep -i content-encoding

# and when offered only gzip?
curl -sI -H 'Accept-Encoding: gzip' https://example.com/ | grep -i content-encoding

# compare actual transferred bytes (compressed vs uncompressed)
curl -so /dev/null -H 'Accept-Encoding: br' -w 'brotli:  %{size_download} bytes\n' https://example.com/
curl -so /dev/null -H 'Accept-Encoding: identity' -w 'plain:   %{size_download} bytes\n' https://example.com/