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

TTFB سایت بالا رفته و فایل‌ها هنوز سنگین‌اند

سایت را در PageSpeed Insights چک کرده‌اید و می‌گوید «فشرده‌سازی متن فعال نیست». یا TTFB را اندازه گرفته‌اید و عدد ۱.۲ ثانیه را می‌بینید، در حالی که محتوای صفحه تقریباً هیچ تصویری ندارد. اولین چیزی که به ذهن می‌رسد فعال‌کردن Gzip است. اما نسخه جدیدتر Brotli هم هست. کدام را باید فعال کنید؟

پاسخ کوتاه: Brotli، اگر سرور شما اجازه بدهد. اما این پاسخ شرط دارد و هزینه دارد. در این مقاله می‌گویم هر دو را کجا و چطور فعال کنید، چه عددی از هرکدام انتظار داشته باشید، و کجا این کار نتیجه معکوس می‌دهد.

تفاوت واقعی Gzip و Brotli در عدد، نه در شعار

Brotli الگوریتمی است که گوگل در سال ۲۰۱۵ منتشر کرد. Gzip قدمت بیشتری دارد و هنوز استاندارد پیش‌فرض وب است. تفاوت اصلی در نسبت فشرده‌سازی و مصرف CPU است.

روی یک فایل HTML واقعی (مثل صفحه اصلی یک سایت خبری با ۸۵ کیلوبایت حجم خام)، اعداد معمولاً این‌طور است:

• Gzip با سطح ۶ (پیش‌فرض): حدود ۲۲ تا ۲۸ کیلوبایت — یعنی ۶۷ تا ۷۴ درصد کاهش حجم
• Brotli با سطح ۵: حدود ۱۸ تا ۲۱ کیلوبایت — یعنی ۷۵ تا ۷۹ درصد کاهش حجم
• Brotli با سطح ۱۱ (حداکثر): حدود ۱۶ تا ۱۸ کیلوبایت، اما زمان فشرده‌سازی می‌تواند ۱۰ تا ۲۰ برابر Gzip طول بکشد

تفاوت ۵ تا ۸ درصدی بین Gzip و Brotli شاید کم به نظر برسد. برای یک فایل CSS که ۴۰ کیلوبایت است، یعنی ۲ تا ۳ کیلوبایت صرفه‌جویی. اما برای یک فایل JSON با ۲ مگابایت داده، تفاوت به ۱۵۰ تا ۲۰۰ کیلوبایت می‌رسد. روی ترافیک ماهانه ۵۰ گیگابایت، این یعنی چند گیگابایت پهنای باند کمتر.

نکته مهم: Brotli روی فایل‌های کوچک (زیر ۱ کیلوبایت) عملاً برتری ندارد. گاهی حتی بزرگ‌تر از Gzip خروجی می‌دهد. پس اگر سایت شما صفحات سبکی دارد، این بهینه‌سازی در رتبه اول کارها نیست.

هزینه CPU را دست کم نگیرید

Brotli با سطح ۱۱ می‌تواند ۵ تا ۲۰ میلی‌ثانیه زمان CPU برای هر فایل مصرف کند. روی یک سرور اشتراکی که ۲۰۰ سایت روی آن است، این عدد جمع می‌شود. این‌جا اشتباه می‌کنند: سطح ۱۱ را روی همه فایل‌ها فعال می‌کنند و بعد تعجب می‌کنند که چرا CPU سرور ۹۰ درصد است.

راه حل: فشرده‌سازی را یک‌بار انجام بدهید و نتیجه را کش کنید. اگر از Nginx با ماژول ngx_brotli استفاده می‌کنید، سطح ۵ را بگذارید و کش فشرده را فعال کنید. اگر فایل‌های استاتیک را از قبل با دستور brotli -q 11 فشرده‌اید، سطح ۱۱ اشکالی ندارد چون فقط یک‌بار انجام می‌شود.

فعال‌سازی روی Nginx؛ جایی که بیشترین کنترل را دارید

Nginx به صورت پیش‌فرض Gzip دارد اما Brotli را باید به‌صورت ماژول جدا نصب کنید. در دبیان و اوبونتو، بسته nginx-extras شامل ngx_brotli است. در توزیع‌های دیگر باید از مخزن منبع کامپایل کنید.

برای Gzip در بلاک http یا server:

gzip on;
gzip_comp_level 6;
gzip_min_length 1024;
gzip_types text/plain text/css application/json application/javascript application/xml image/svg+xml;
gzip_vary on;

برای Brotli، بعد از نصب ماژول:

brotli on;
brotli_comp_level 5;
brotli_min_length 1024;
brotli_types text/plain text/css application/json application/javascript application/xml image/svg+xml;

توجه کنید که brotli_static on; را هم می‌توانید اضافه کنید تا Nginx فایل‌های از پیش فشرده‌شده با پسوند .br را مستقیم سرو کند. این کار هزینه CPU را به صفر می‌رساند.

یک نکته ظریف: اگر هر دو ماژول فعال باشند، Nginx بر اساس هدر Accept-Encoding مرورگر تصمیم می‌گیرد. مرورگرهای مدرن (کروم ۵۰ به بالا، فایرفاکس ۴۴ به بالا، سافاری ۱۱ به بالا) Brotli را پشتیبانی می‌کنند. بقیه به Gzip می‌افتند. پس فعال‌کردن هر دو اشکالی ندارد، به شرطی که ترتیب را درست بچینید.

فعال‌سازی روی Apache و cPanel

Apache با ماژول mod_deflate کار می‌کند. در cPanel این ماژول معمولاً فعال است و فقط باید قوانین را در فایل .htaccess بنویسید:

<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/css application/json application/javascript application/xml image/svg+xml
DeflateCompressionLevel 6
</IfModule>

مشکل اینجاست: Apache به صورت پیش‌فرض Brotli ندارد. ماژول mod_brotli باید جداگانه کامپایل شود و در هاست اشتراکی معمولاً فعال نیست. اگر هاست لینوکس اشتراکی دارید، اول چک کنید که آیا mod_brotli در لیست ماژول‌های بارگذاری‌شده هست:

httpd -M | grep brotli

اگر خروجی خالی بود، فقط Gzip دارید. این بد نیست. Gzip با سطح ۶ روی ۹۵ درصد سایت‌ها کافی است و تفاوتش با Brotli برای کاربر نهایی محسوس نیست مگر اینکه فایل‌های حجیم JSON یا جاوااسکریپت داشته باشید.

در cPanel، اگر ماژول Brotli فعال باشد، می‌توانید در فایل .htaccess بنویسید:

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

اما اگر هاست اشتراکی دارید و این ماژول فعال نیست، درخواست نصب آن از تیم پشتیبانی معمولاً بی‌نتیجه می‌ماند. در این حالت، بهترین کار این است که فایل‌های استاتیک را از قبل فشرده کنید و با هدر Content-Encoding: br سرو کنید. ابزارهایی مثل brotli در لینوکس این کار را انجام می‌دهند:

brotli -q 11 -f style.css -o style.css.br

سپس در .htaccess قوانین بازنویسی را اضافه کنید تا اگر فایل .br وجود داشت و مرورگر پشتیبانی می‌کرد، همان سرو شود.

کدام را انتخاب کنیم؟ یک تصمیم عملی

اگر کنترل کامل روی سرور دارید (سرور اختصاصی یا VPS)، Brotli با سطح ۵ را فعال کنید و Gzip را به عنوان fallback نگه دارید. این ترکیب بهترین نسبت فشرده‌سازی به هزینه CPU را می‌دهد.

اگر روی هاست اشتراکی هستید و فقط Gzip در دسترس است، همان را با سطح ۶ فعال کنید و سراغ بهینه‌سازی‌های دیگر بروید. فشرده‌سازی فقط یکی از فاکتورهای سرعت است. تصاویر WebP، کش مرورگر و حذف جاوااسکریپت‌های بلااستفاده معمولاً تأثیر بیشتری دارند.

شرط انتخاب Gzip به جای Brotli: اگر سرور شما CPU ضعیفی دارد (مثلاً ۱ هسته اشتراکی) و ترافیک بالایی دریافت می‌کند، Gzip انتخاب امن‌تری است. فشرده‌سازی در لحظه با Brotli روی سخت‌افزار ضعیف می‌تواند TTFB را ۱۰۰ تا ۲۰۰ میلی‌ثانیه افزایش دهد. این دقیقاً همان چیزی است که می‌خواستید حل کنید.

یک نکته دیگر: اگر سایت شما پشت CDN است، معمولاً CDN کار فشرده‌سازی را انجام می‌دهد و تنظیمات سرور اصلی بی‌اثر می‌شود. در Cloudflare، گزینه Brotli را در بخش Speed فعال کنید و بگذارید CDN مدیریت کند. در این حالت تنظیمات Nginx یا Apache فقط برای درخواست‌هایی اعمال می‌شود که مستقیم به سرور می‌آیند.

این‌جا اشتباه می‌کنند: فشرده‌سازی دوباره فایل‌های از قبل فشرده

رایج‌ترین خطایی که دیده‌ام: کسی فایل‌های PNG یا JPEG را هم در لیست gzip_types یا brotli_types قرار می‌دهد. این کار نه تنها حجم را کم نمی‌کند، بلکه CPU را هدر می‌دهد و در بعضی موارد فایل را بزرگ‌تر هم می‌کند. تصاویر PNG و JPEG خودشان فشرده هستند و فشرده‌سازی مجدد با Gzip یا Brotli معمولاً ۰ تا ۲ درصد حجم کم می‌کند، در حالی که ۵ تا ۱۵ میلی‌ثانیه CPU مصرف می‌کند.

نشانه این اشتباه: لاگ سرور را نگاه کنید. اگر می‌بینید درخواست‌های .png با هدر Content-Encoding: gzip پاسخ می‌گیرند، یعنی این اشتباه را کرده‌اید. فایل‌های متنی را فشرده کنید: HTML، CSS، JavaScript، JSON، XML، SVG، فونت‌های woff2 (اگرچه خودشان فشرده‌اند). نه تصاویر، نه ویدیو، نه PDF.

اشتباه دوم: فشرده‌سازی را روی پاسخ‌های کوچک فعال می‌کنید. gzip_min_length 0 یا حذف این خط یعنی حتی پاسخ‌های ۲۰۰ بایتی هم فشرده می‌شوند. هزینه CPU برای این پاسخ‌ها بیشتر از صرفه‌جویی پهنای باند است. حداقل ۱۰۲۴ بایت را بگذارید.

اندازه‌گیری؛ قبل و بعد از تغییر

قبل از هر تغییری، وضعیت فعلی را اندازه بگیرید. دو ابزار ساده:

1. خط فرمان: curl -H "Accept-Encoding: br" -o /dev/null -s -w "size_download: %{size_download}\ntime_total: %{time_total}\n" https://example.com/
2. مرورگر: در DevTools، تب Network، ستون Size را ببینید. عدد اول حجم انتقال‌یافته و عدد دوم حجم خام است. اگر برابر بودند، فشرده‌سازی کار نمی‌کند.

همچنین می‌توانید از ابزارهای رایگان وب‌مستر برای بررسی هدرهای پاسخ استفاده کنید. هدر Content-Encoding: br یا Content-Encoding: gzip باید در پاسخ باشد. اگر هیچ‌کدام نبود، تنظیمات شما اعمال نشده است.

بعد از تغییر، دوباره اندازه بگیرید. اگر TTFB بیشتر از ۵۰ میلی‌ثانیه افزایش پیدا کرد و حجم فقط ۵ درصد کم شد، سطح فشرده‌سازی را پایین بیاورید یا کش فشرده را فعال کنید.

رابطه فشرده‌سازی با سایر بهینه‌سازی‌ها

فشرده‌سازی متن فقط یکی از لایه‌های بهینه‌سازی است. اگر سایت شما کند است، اول بفهمید مشکل کجاست. فشرده‌سازی روی TTFB تأثیری ندارد. TTFB بالا معمولاً از دیر پاسخ‌دادن سرور، کوئری‌های سنگین دیتابیس یا DNS است. اگر TTFB شما بالای ۵۰۰ میلی‌ثانیه است، فشرده‌سازی وضعیت را بهتر نمی‌کند.

برای عیب‌یابی سیستماتیک، راهنمای کامل عیب‌یابی سایت کند را بخوانید. ترتیب کارها را مشخص می‌کند: اول DNS، بعد TTFB، بعد حجم پاسخ، بعد رندر مرورگر.

اگر سایت روی هاست اشتراکی است و محدودیت منابع دارید، شاید وقت آن رسیده که به سرور اختصاصی مهاجرت کنید. فشرده‌سازی Brotli با سطح بالا روی سروری که فقط سایت شما روی آن است، بدون نگرانی از مصرف CPU دیگران، قابل انجام است.

پرسش‌های پرتکرار

آیا Brotli با Gzip تفاوت محسوسی در سرعت سایت ایجاد می‌کند؟

برای کاربر نهایی، تفاوت معمولاً بین ۵ تا ۱۵ درصد زمان بارگذاری است، بسته به حجم فایل‌های متنی سایت. روی اتصال‌های پرسرعت این تفاوت محسوس نیست. روی اتصال 3G یا اینترنت با تأخیر بالا، تفاوت بیشتر دیده می‌شود. اگر سایت شما فایل‌های JSON یا جاوااسکریپت حجیم دارد، Brotli ارزشش را دارد.

چطور بفهمم فشرده‌سازی سایت من فعال است؟

با دستور curl -I -H "Accept-Encoding: gzip, br" https://example.com/ هدرهای پاسخ را ببینید. اگر Content-Encoding: br یا Content-Encoding: gzip در خروجی بود، فشرده‌سازی فعال است. ابزارهای آنلاین مثل GTmetrix هم این را نشان می‌دهند.

آیا فعال‌کردن همزمان Gzip و Brotli مشکلی ایجاد می‌کند؟

خیر. سرور بر اساس هدر Accept-Encoding مرورگر، بهترین گزینه را انتخاب می‌کند. مرورگرهای مدرن Brotli را ترجیح می‌دهند و مرورگرهای قدیمی به Gzip می‌افتند. فقط مطمئن شوید که هر دو ماژول به درستی نصب شده‌اند و تنظیمات با هم تداخل ندارند.

فشرده‌سازی روی کدام فایل‌ها را نباید فعال کنم؟

روی تصاویر (JPEG، PNG، GIF)، ویدیو، فایل‌های صوتی و PDF. این فایل‌ها از قبل فشرده هستند و فشرده‌سازی مجدد فقط CPU مصرف می‌کند. فشرده‌سازی را محدود به فایل‌های متنی کنید: HTML، CSS، JavaScript، JSON، XML و SVG.