deflate چیست؟
deflate یک الگوریتم فشردهسازی بدون اتلاف داده است که ترکیبی از LZ77 و کدگذاری هافمن را به کار میگیرد و در RFC 1951 استاندارد شده است. در وب، همین الگوریتم هستهی فشردهسازی gzip را میسازد و باعث میشود فایلهای متنی مانند HTML، CSS و جاوااسکریپت با حجمی بهمراتب کمتر از سرور به مرورگر منتقل شوند.
«بدون اتلاف» یعنی داده پس از باز شدن، بایتبهبایت با نسخهی اصلی یکسان است؛ برخلاف کم کردن کیفیت یک تصویر، اینجا چیزی دور ریخته نمیشود.
deflate دقیقاً چه کار میکند؟
این الگوریتم دو تکنیک را پشت سر هم اجرا میکند:
- LZ77 — رشتههای تکراری را با یک ارجاع کوتاه جایگزین میکند: «فلان تعداد بایت عقبتر برو و فلان تعداد بایت را از آنجا کپی کن.» در یک صفحهی HTML که دهها بار
<div class=در آن تکرار شده، بیشترین صرفهجویی در همین مرحله اتفاق میافتد. - کدگذاری هافمن — به نمادهای پرتکرار کد بیتی کوتاهتر و به نمادهای کمیاب کد بلندتر اختصاص میدهد، تا میانگین تعداد بیتهای هر نماد پایین بیاید.
چون محتوای متنی وب پر از تکرار است، خروجی این ترکیب معمولاً بسیار کوچکتر از ورودی میشود. میزان دقیق کاهش حجم اما به محتوا بستگی دارد و عدد ثابتی ندارد؛ یک فایل CSS با کلاسهای تکراری خیلی بهتر از متنی که از پیش بهینه شده جمع میشود. اگر سایت شما روی هاست اشتراکی قرار دارد، به فایل پیکربندی اصلی وبسرور دسترسی ندارید و معمولاً تنها راه دخالت در این تنظیمات، فایل .htaccess در ریشهی سایت است.
تفاوت deflate، zlib، gzip و Brotli
این چهار نام مدام با هم اشتباه گرفته میشوند، در حالی که لایههای متفاوتی هستند:
| نام | استاندارد | ماهیت |
|---|---|---|
| deflate | RFC 1951 |
خود الگوریتم و جریان خام داده، بدون هدر و بدون کد کنترل خطا |
| zlib | RFC 1950 |
جریان deflate بههمراه یک هدر کوتاه و کد صحتسنجی Adler-32 |
| gzip | RFC 1952 |
جریان deflate بههمراه هدر gzip، نام فایل اختیاری و کد صحتسنجی CRC-32 |
| Brotli | RFC 7932 |
الگوریتمی جداگانه و جدیدتر، با فرهنگ لغت ایستای داخلی و مدلسازی بهتر متن |
یک نکتهی تاریخی مهم: طبق استاندارد HTTP، مقدار Content-Encoding: deflate باید به فرمت zlib اشاره کند، اما بعضی سرورها در گذشته جریان خام deflate را با همین نام میفرستادند و همین ابهام باعث خطا در برخی کلاینتها میشد. به همین دلیل در عمل تقریباً همه از gzip یا br استفاده میکنند و deflate بهعنوان مقدار Content-Encoding عملاً کنار گذاشته شده است.
Brotli؛ گزینهی امروزیتر
Brotli در هدرها با نام br شناخته میشود و روی محتوای متنی معمولاً خروجی کوچکتری از gzip تولید میکند، چون یک فرهنگ لغت آماده از رشتههای پرتکرار وب را در خود دارد. سطح فشردهسازی آن از 0 تا 11 تنظیم میشود و سطوح بالا محسوس کند و پرمصرفاند.
قاعدهی عملی ساده است: برای فایلهای ایستا از سطح بالا استفاده کنید و خروجی را یکبار روی دیسک ذخیره کنید تا سرور در هر درخواست دوباره فشرده نکند؛ برای پاسخهای پویا سطح متوسط بگذارید. بیشتر مرورگرها br را فقط روی اتصال HTTPS اعلام میکنند، پس سرور باید همچنان gzip را بهعنوان جایگزین نگه دارد.
mod_deflate در آپاچی چطور کار میکند
در آپاچی، فشردهسازی با ماژول mod_deflate انجام میشود که یک فیلتر خروجی است: پاسخ پیش از ارسال از این فیلتر عبور میکند. نکتهی گیجکننده اینکه با وجود نامش، این ماژول خروجی را با Content-Encoding: gzip برچسب میزند.
روی وبسرورهای دیگر مسیر متفاوت است: در Nginx تنظیمات با دستور gzip on و بستگان آن انجام میشود، و در وبسرور LiteSpeed — که موتور بازنویسی سازگار با آپاچی دارد — فشردهسازی از کنسول مدیریتی خود وبسرور کنترل میشود، نه با mod_deflate.
در آپاچی، ابتدا فعال بودن ماژول را بررسی کنید:
apachectl -M | grep deflate
سپس در پیکربندی، فقط انواع محتوای متنی را به فیلتر بسپارید:
AddOutputFilterByType DEFLATE text/html text/plain text/css text/xml application/javascript application/json application/xml image/svg+xml
سطح فشردهسازی با DeflateCompressionLevel بین 1 تا 9 تنظیم میشود؛ اگر ننویسیدش، مقدار پیشفرض کتابخانهی zlib اعمال میشود. بالا بردن این عدد تا انتها معمولاً سود ناچیزی در حجم دارد ولی مصرف پردازنده را بالا میبرد.
ماژول هدر Vary: Accept-Encoding را خودکار اضافه میکند. این هدر حیاتی است: بدون آن، یک پروکسی یا CDN ممکن است نسخهی فشرده را به کلاینتی بدهد که فشردهسازی را پشتیبانی نمیکند.
هشدار: پیش از ریاستارت آپاچی حتماً از فایل پیکربندی نسخهی پشتیبان بگیرید و صحت آن را بررسی کنید. یک خطای نگارشی، وبسرور را بالا نمیآورد و کل سایتهای روی سرور را از دسترس خارج میکند:
apachectl configtest
و در صورت تأیید، بهجای restart از بارگذاری مجدد نرم استفاده کنید تا اتصالهای باز قطع نشوند: systemctl reload httpd
چه چیزی را فشرده کنیم و چه چیزی را نه
رایجترین اشتباه همینجاست. فشردهسازی را فقط روی محتوایی اعمال کنید که واقعاً فشردهشدنی است:
فشردهسازی فقط روی محتوای متنی معنا دارد؛ تصویر و ویدیوی از قبل فشردهشده با عبور دوباره از این مسیر کوچکتر نمیشوند و فقط پردازنده را مشغول میکنند.
- بله: HTML، CSS، جاوااسکریپت، JSON، XML، SVG، فایلهای متنی و فونتهای قدیمی
ttfوotf. - خیر: JPEG، PNG، GIF، WebP، AVIF، MP3، MP4، آرشیوهای
zipوgzوrar، و فونتهایwoffوwoff2. اینها همگی در ساختار خودشان از پیش فشرده شدهاند.
فشردهسازی دوبارهی یک فایل از پیش فشرده، عملاً بایتی صرفهجویی نمیکند، پردازنده را بیدلیل مشغول میکند و گاهی حتی چند بایت به حجم اضافه میکند. فایلهای بسیار کوچک هم ارزشش را ندارند، چون سربار هدرها از سود آن بیشتر میشود؛ در Nginx این آستانه با gzip_min_length کنترل میشود. اگر ترجیح میدهید تنظیم و نگهداری اینگونه پیکربندیها را خودتان بر عهده نگیرید، سرور مجازی با مدیریت کامل گزینهای است که پیکربندی و رفع اشکال سرور را به تیم پشتیبانی میسپارد.
چطور مطمئن شویم فشردهسازی واقعاً کار میکند؟
سادهترین راه یک درخواست با curl است. مرورگر پشتیبانی خود را با هدر Accept-Encoding اعلام میکند و سرور با Content-Encoding پاسخ میدهد:
curl -s -I -H "Accept-Encoding: gzip, br" https://example.com/
اگر در پاسخ خطی مثل content-encoding: br یا content-encoding: gzip دیدید، همهچیز درست است. برای سنجش حجم واقعی، همان درخواست را یکبار با هدر و یکبار بدون آن بفرستید و اندازهی دانلود را مقایسه کنید:
curl -s -o /dev/null -w "%{size_download}\n" https://example.com/
اثر واقعی روی سرعت صفحه
فشردهسازی تعداد بایتهای منتقلشده را کم میکند، پس بیشترین تأثیر آن روی کاربرانی است که پهنای باند محدود یا اتصال موبایل دارند؛ آنجا معیارهایی مثل FCP و LCP — که در سئوی فنی هم سنجیده میشوند — محسوس بهتر میشوند. اما چند واقعیت را نباید نادیده گرفت:
- فشردهسازی پویا خودش زمان پردازنده میخواهد، بنابراین ممکن است زمان تا اولین بایت را کمی افزایش دهد. راهحل، فشردهسازی از پیش انجامشده برای فایلهای ایستا است.
- اگر گلوگاه سایت شما کوئری کند دیتابیس یا پاسخدهی کند سرور باشد، فشردهسازی آن را حل نمیکند. این ابزار برای کاهش حجم است، نه برای جبران کندی سمت سرور.
- برای فایلهای متنی، فشردهسازی مکمل کش مرورگر است نه جایگزین آن؛ هر دو را با هم فعال کنید.
برای دیدن تصویر کلیتر از وضعیت سایت — زمان تا اولین بایت، زمان بارگذاری کامل و خطاهای شبکه — میتوانید از ابزار رایگان بررسی سلامت سایت استفاده کنید و ببینید کندی واقعاً از کجا میآید.
یک نکتهی امنیتی که نباید فراموش شود
فشردهسازی پاسخهایی که همزمان دادهی محرمانه (مثل توکن CSRF) و ورودی کنترلشده توسط کاربر دارند، پایهی حملاتی مانند BREACH بوده است، چون حجم پاسخ فشرده اطلاعاتی دربارهی محتوای آن لو میدهد. برای صفحات عمومی و فایلهای ایستا این نگرانی عملاً وجود ندارد، اما در اپلیکیشنهای حساس بهتر است فشردهسازی پاسخهای احرازهویتشده را با دقت و همراه محافظتهای دیگر پیاده کنید.