Brotli Compression برای وردپرس چرا از Gzip بهتر است؟

الگوریتم فشرده‌سازی بروتلی Brotli Compression برای وردپرس به دلیل استفاده از یک دیکشنری پیش‌ساخته با بیش از سیزده هزار عبارت پرکاربرد متنی و ساختار بهینه‌تر LZ77 و کدهای هافمن، حجم فایل‌های متنی را تا حدود بیست درصد نسبت به جی‌زیپ Gzip کاهش می‌دهد. این تفاوت در نرخ فشرده‌سازی مستقیماً به کاهش بایت‌های دانلودی، کوچک‌تر شدن بسته انتقال و بهبود محسوس زمان بارگذاری کامل سایت منجر می‌شود. کاهش حجم به معنی تخلیه سریع‌تر بافر شبکه و ارسال پکت‌های TCP کمتری در لایه انتقال بوده که سرعت بارگذاری را در شبکه‌های با تاخیر بالا متحول می‌سازد. بررسی لایه‌های مهندسی وب ثابت کرده که پیاده‌سازی صحیح آن بر روی وب‌سرور، استرس زیرساخت را در مواجهه با ترافیک‌های ورودی سنگین کاهش داده و هزینه پهنای باند را به طرز چشمگیری می‌کاهد. بنابراین بهره‌گیری از این فشرده‌ساز در معماری سرویس‌‌دهی پلتفرم وردپرس، یک ضرورت بی‌چون‌وچرا برای سایت‌های خواهان پرفورمنس حداکثری و کمترین تاخیر در انتقال بایت‌هاست.
Brotli Compression برای وردپرس یک الگوریتم فشرده‌سازی است که در مقایسه با Gzip، پاسخ‌های متنی را در حجم کمتری منتقل می‌کند و همین کاهش حجم، مستقیماً روی زمان پاسخ و تجربه کاربر اثر می‌گذارد.

Brotli (Brotli) توسط گوگل توسعه یافته و در سال ۲۰۱۵ به‌عنوان یک استاندارد باز منتشر شد، اما پشتیبانی مرورگرها از آن چند سال بعد فراگیر شد.

سه عامل اصلی، برتری این الگوریتم را در محیط تولید تعیین می‌کنند: نسبت فشرده‌سازی بالاتر، واژه‌نامه داخلی اختصاصی و پشتیبانی گسترده مرورگرهای مدرن.

بدون فعال‌سازی درست این لایه، حتی با وجود فشرده‌سازی Gzip، بخشی از پهنای باند به‌صورت پنهان هدر می‌رود.

هدف این نوشته، روشن‌کردن تفاوت‌های فنی این دو الگوریتم و ارائه الگوهای عملی برای فعال‌سازی Brotli در سرورهای وردپرسی است.

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

Brotli دقیقاً چه چیزی را فشرده می‌کند

Brotli یک الگوریتم فشرده‌سازی بدون اتلاف (Lossless) است که داده متنی را با کاهش تکرار و کدگذاری کارآمدتر، به حجم کمتری تبدیل می‌کند. این الگوریتم در سمت سرور اجرا می‌شود و خروجی فشرده‌شده به مرورگر کاربر منتقل می‌گردد.

در چارچوب وب، Brotli برای فشرده‌سازی انواع محتوای متنی استفاده می‌شود: فایل‌های HTML، CSS، JavaScript، JSON، XML، SVG و فونت‌های وب. این انواع، بخش بزرگی از حجم یک صفحه وردپرسی را تشکیل می‌دهند.

Brotli در محتوای دودویی پیش‌فشرده مانند تصاویر WebP، فایل‌های MP4 و بسته‌های ZIP سود محدودی دارد. این فایل‌ها از قبل فشرده شده‌اند و اعمال فشرده‌سازی دوباره، تنها هزینه پردازش اضافه می‌کند بدون کاهش محسوس حجم.

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

اثر فشرده‌سازی روی زمان بارگذاری، در چارچوب کلی بهینه‌سازی سرعت سایت به‌عنوان یک لایه انتقال بررسی می‌شود. این لایه مستقل از لایه کش عمل می‌کند و مکمل آن است.

فشرده‌سازی یک تصمیم انتقال است، نه یک تصمیم ذخیره‌سازی؛ فایل اصلی دست‌نخورده می‌ماند و تنها مسیر انتقال کوتاه‌تر می‌شود.

تفاوت‌های بنیادین Brotli و Gzip

Gzip سال‌ها استاندارد غالب فشرده‌سازی در وب بوده است و همچنان توسط همه مرورگرها و سرورها پشتیبانی می‌شود. Brotli نسل جدیدتر این فناوری است که با همان هدف اما با رویکرد متفاوتی طراحی شده است.

تفاوت اول، الگوریتم پایه است. Gzip بر پایه الگوریتم DEFLATE کار می‌کند که خود ترکیبی از LZ77 و Huffman Coding است. Brotli از یک الگوریتم پیشرفته‌تر استفاده می‌کند که امکان تشخیص الگوهای پیچیده‌تر را فراهم می‌سازد.

تفاوت دوم، نسبت فشرده‌سازی است. Brotli در بیشتر انواع محتوای متنی، حجم کمتری تولید می‌کند. این تفاوت در فایل‌های HTML و CSS معمولاً در محدوده ۱۵ تا ۲۵ درصد است. در فایل‌های JavaScript، این نسبت می‌تواند به بیش از ۲۰ درصد برسد.

تفاوت سوم، واژه‌نامه داخلی است. Brotli یک واژه‌نامه پیش‌ساخته از رشته‌های پرتکرار در وب را در خود دارد. این واژه‌نامه شامل تگ‌های HTML، ویژگی‌های CSS، نام‌های رایج JavaScript و اصطلاحات استاندارد وب است. همین ویژگی، فشرده‌سازی فایل‌های کوچک را نیز کارآمد می‌کند.

تفاوت چهارم، سرعت فشرده‌سازی است. Gzip در سطوح پایین بسیار سریع‌تر از Brotli عمل می‌کند. Brotli در سطوح بالای فشرده‌سازی، زمان پردازش بیشتری نیاز دارد. این تفاوت در محیط‌های با منابع محدود، تصمیم‌گیری را تحت تأثیر قرار می‌دهد.

تفاوت پنجم، پشتیبانی از فایل‌های کوچک است. Gzip در فایل‌های کوچک‌تر از چند صد بایت، سود محدودی دارد. Brotli با استفاده از واژه‌نامه داخلی، در همین فایل‌های کوچک نیز فشرده‌سازی مؤثری انجام می‌دهد.

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

واژه‌نامه داخلی و مزیت پنهان Brotli

واژه‌نامه داخلی Brotli یکی از متمایزکننده‌ترین ویژگی‌های این الگوریتم است. این واژه‌نامه شامل بیش از ۱۳ هزار رشته پرتکرار است که در فایل‌های وب به‌طور معمول ظاهر می‌شوند.

رشته‌های این واژه‌نامه از منابع مختلفی استخراج شده‌اند. بخش بزرگی از آن شامل تگ‌های HTML مانند <div>، <span> و <a href است. بخش دیگر شامل ویژگی‌های CSS مانند display، margin و padding. بخش سوم شامل اصطلاحات رایج JavaScript مانند function، return و document.

مزیت این واژه‌نامه در فایل‌های کوچک آشکار می‌شود. در فشرده‌سازی معمولی، الگوریتم برای رسیدن به نسبت مطلوب، به تکرار کافی در فایل نیاز دارد. در فایل‌های کوچک، این تکرار کم است و نسبت فشرده‌سازی پایین می‌ماند. اما Brotli می‌تواند از واژه‌نامه داخلی خود استفاده کند و حتی در فایل‌های کوچک نیز فشرده‌سازی مؤثری انجام دهد.

اثر این ویژگی در سایت‌های وردپرسی محسوس است. صفحات وردپرس از ده‌ها فایل CSS و JavaScript تشکیل می‌شوند که هر یک چند کیلوبایت حجم دارند. Brotli در این فایل‌ها اثر بیشتری از Gzip نشان می‌دهد.

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

سطوح فشرده‌سازی و انتخاب درست

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

سطوح پایین (صفر تا سه) برای فشرده‌سازی پویا طراحی شده‌اند. در این سطوح، زمان پردازش کوتاه است و نسبت فشرده‌سازی متوسط. این سطوح برای پاسخ‌های پویا که در هر درخواست ساخته می‌شوند، مناسب‌اند.

سطوح میانی (چهار تا شش) تعادل بهتری بین سرعت و نسبت فشرده‌سازی برقرار می‌کنند. سطح پنج معمولاً به‌عنوان نقطه تعادل عمومی توصیه می‌شود.

سطوح بالا (هفت تا ده) برای فشرده‌سازی استاتیک طراحی شده‌اند. در این سطوح، زمان پردازش طولانی‌تر است اما نسبت فشرده‌سازی بالاتر. این سطوح برای فایل‌های استاتیک که یک‌بار فشرده و چندین بار سرو می‌شوند، مناسب‌اند.

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

انتخاب سطح مناسب به سه معیار بستگی دارد. معیار اول، نوع محتوا است. اگر محتوا پویا است، سطوح پایین انتخاب می‌شوند. اگر محتوا استاتیک است، سطوح بالا کارآمدترند.

معیار دوم، ظرفیت سرور است. اگر منابع پردازشی سرور محدود باشد، سطوح پایین از فشار اضافه جلوگیری می‌کنند. اگر سرور ظرفیت کافی داشته باشد، سطوح میانی تعادل بهتری ارائه می‌دهند.

معیار سوم، نسبت کش است. اگر پاسخ‌ها به‌طور گسترده کش می‌شوند، سطوح بالاتر انتخاب می‌شوند چون پردازش تنها یک‌بار انجام می‌گردد. اگر پاسخ‌ها در هر درخواست ساخته می‌شوند، سطوح پایین‌تر منطقی‌ترند. اصول کلی این تعادل در بهینه‌سازی کدهای PHP به‌عنوان یک اصل کلی توصیه شده است.

پشتیبانی مرورگرها و مکانیزم مذاکره

Brotli از سال ۲۰۱۶ در مرورگرها پشتیبانی می‌شود. Chrome، Firefox، Edge، Safari و Opera از این الگوریتم پشتیبانی می‌کنند. در سال‌های اخیر، این پشتیبانی به همه مرورگرهای مدرن گسترش یافته است.

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

مکانیزم انتخاب میان دو الگوریتم، از طریق هدر Accept-Encoding انجام می‌شود. مرورگر این هدر را در هر درخواست ارسال می‌کند و لیست الگوریتم‌هایی که پشتیبانی می‌کند را اعلام می‌دارد.

Accept-Encoding: gzip, deflate, br, zstd

در این هدر، br مخفف Brotli و zstd مخفف Zstandard است. سرور بر اساس این لیست، مناسب‌ترین الگوریتم را انتخاب می‌کند و پاسخ را با هدر Content-Encoding مناسب ارسال می‌دارد.

Content-Encoding: br

اگر سرور Brotli را به‌درستی پشتیبانی کند، پاسخ با هدر br ارسال می‌شود. در غیر این صورت، سرور به گزینه‌های بعدی در لیست مرورگر روی می‌آورد.

مسئله مهم این است که پیکربندی سرور باید طوری تنظیم شود که Brotli در اولویت باشد و Gzip به‌عنوان پشتیبان باقی بماند. این ترکیب، بهترین نتیجه را در همه سناریوها فراهم می‌کند.

مسائل امنیتی مرتبط با این مکانیزم، از جمله خطر حملات BREACH، در افزایش امنیت برنامه‌های وب به‌تفصیل آمده است. رعایت این اصول در پیکربندی فشرده‌سازی ضروری است.

پیکربندی Brotli در Nginx

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

پس از نصب ماژول، پیکربندی Brotli در فایل تنظیمات Nginx یا در فایل تنظیمات سایت انجام می‌شود.

brotli on;
brotli_comp_level 5;
brotli_static on;
brotli_types text/plain text/css application/javascript application/json
    application/xml text/xml image/svg+xml application/x-font-ttf
    font/opentype application/vnd.ms-fontobject;

brotli_min_length 256;

هر پارامتر در این پیکربندی نقش مشخصی ایفا می‌کند. پارامتر brotli on فشرده‌سازی پویا را فعال می‌کند. پارامتر brotli_comp_level سطح فشرده‌سازی را تعیین می‌کند. پارامتر brotli_static امکان استفاده از فایل‌های پیش‌فشرده را فعال می‌سازد.

پارامتر brotli_types انواع محتوایی که باید فشرده شوند را مشخص می‌کند. پارامتر brotli_min_length حداقل طول محتوا برای فشرده‌سازی را تعیین می‌کند. این پارامتر از فشرده‌سازی فایل‌های بسیار کوچک جلوگیری می‌کند که سود آن‌ها محدود است.

در کنار پیکربندی Brotli، Gzip نیز باید فعال باقی بماند تا مرورگرهای قدیمی نیز پاسخ مناسب بگیرند.

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

ترکیب این دو پیکربندی، اطمینان می‌دهد که همه کاربران، چه با مرورگر مدرن و چه با مرورگر قدیمی، پاسخ مناسب می‌گیرند.

مسائل ظریف در پیکربندی Nginx، از جمله هماهنگی با لایه کش، در بهینه‌سازی Nginx برای وردپرس به‌تفصیل آمده است. رعایت این اصول، از تداخل میان لایه‌ها جلوگیری می‌کند.

نکته مهم دیگر، هماهنگی Brotli با FastCGI Cache است. اگر پاسخ در لایه کش ذخیره شود، نسخه فشرده‌شده ذخیره می‌شود. این رفتار در پیکربندی Nginx FastCGI Cache برای وردپرس به‌عنوان یک اصل مهم بررسی شده است.

پیکربندی Brotli در Apache

Apache نیز به‌طور پیش‌فرض از Brotli پشتیبانی نمی‌کند. برای فعال‌سازی آن، نیاز به ماژول mod_brotli است که در توزیع‌های مدرن به‌صورت بسته در دسترس قرار دارد.

پس از فعال‌سازی ماژول، پیکربندی Brotli در فایل .htaccess یا در فایل تنظیمات اصلی Apache انجام می‌شود.

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

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

در این پیکربندی، دو بلوک تعریف شده است. بلوک اول Brotli را برای انواع محتوای متنی فعال می‌کند. بلوک دوم Gzip را برای همان انواع فعال نگه می‌دارد تا پشتیبان مرورگرهای قدیمی باشد.

پارامتر BrotliCompressionQuality سطح فشرده‌سازی را تعیین می‌کند و مشابه brotli_comp_level در Nginx عمل می‌کند. پارامتر BrotliCompressionMinSize حداقل طول محتوا برای فشرده‌سازی را مشخص می‌کند. پارامتر BrotliCompressionWindow پنجره لغزان الگوریتم را تنظیم می‌کند که بر نسبت فشرده‌سازی و مصرف حافظه اثر می‌گذارد.

مسئله مهم در Apache، محل تعریف پیکربندی است. اگر این قواعد در فایل .htaccess تعریف شوند، Apache در هر درخواست مجبور به خواندن و تفسیر آن‌ها می‌شود. این رفتار، بار اضافه‌ای روی سرور تحمیل می‌کند. اصول تفصیلی این تصمیم در بهینه‌سازی Apache برای وردپرس آمده است.

راه‌حل توصیه‌شده، انتقال قواعد به فایل تنظیمات اصلی و تنظیم AllowOverride None است. این کار، بار تفسیر .htaccess در هر درخواست را حذف می‌کند.

Brotli در لایه شبکه توزیع محتوا

بیشتر سرویس‌های شبکه توزیع محتوا (Content Delivery Network یا CDN) از Brotli پشتیبانی می‌کنند. این پشتیبانی می‌تواند در سمت گره‌های لبه یا در سمت سرور مبدأ اعمال شود.

دو رویکرد اصلی برای پیاده‌سازی Brotli در لایه CDN وجود دارد. رویکرد اول، فشرده‌سازی در سمت سرور مبدأ است. در این رویکرد، پاسخ از سرور مبدأ به‌صورت فشرده‌شده به CDN منتقل می‌شود و CDN همان نسخه را به کاربر می‌فرستد.

رویکرد دوم، فشرده‌سازی در سمت گره‌های لبه است. در این رویکرد، پاسخ از سرور مبدأ به‌صورت خام به CDN منتقل می‌شود و CDN بر اساس هدر Accept-Encoding کاربر، نسخه مناسب را فشرده و ارسال می‌کند.

# Example: Cloudflare Brotli setting (conceptual)
# Enable Brotli at edge level
# Let origin serve uncompressed content when CDN handles compression

انتخاب میان این دو رویکرد به معماری کلی بستگی دارد. رویکرد اول، پهنای باند بین سرور مبدأ و CDN را کاهش می‌دهد اما پردازش را روی سرور مبدأ متمرکز می‌کند. رویکرد دوم، پهنای باند را افزایش می‌دهد اما پردازش را بین گره‌های لبه توزیع می‌کند.

مسئله مهم در هماهنگی این لایه با سرور مبدأ، جلوگیری از فشرده‌سازی مضاعف است. اگر سرور مبدأ پاسخ را با Brotli فشرده کند و CDN نیز همان پاسخ را دوباره فشرده کند، هزینه پردازش اضافه می‌شود و نسبت فشرده‌سازی بهبود نمی‌یابد.

راه‌حل استاندارد، تعیین یک نقطه مسئولیت مشخص است. یا سرور مبدأ مسئول فشرده‌سازی است و CDN پاسخ را بدون تغییر منتقل می‌کند، یا CDN مسئول فشرده‌سازی است و سرور مبدأ پاسخ را خام تحویل می‌دهد. اصول تفصیلی این هماهنگی در نقش CDN در بهبود سرعت سایت آمده است.

هر لایه‌ای که فشرده‌سازی انجام می‌دهد، باید مطمئن شود لایه بالاتر همان کار را تکرار نمی‌کند.

فشرده‌سازی پویا و استاتیک

فشرده‌سازی در سرور به دو صورت انجام می‌شود: پویا و استاتیک. هر رویکرد، مزایا و هزینه‌های مختص خود را دارد.

فشرده‌سازی پویا در زمان درخواست انجام می‌شود. سرور پاسخ را می‌سازد، آن را فشرده می‌کند و به کاربر می‌فرستد. هزینه پردازش در هر درخواست تکرار می‌شود، اما محتوا همیشه به‌روز است.

فشرده‌سازی استاتیک پیش از درخواست انجام می‌شود. نسخه فشرده‌شده فایل روی دیسک ذخیره می‌شود و در زمان درخواست، مستقیماً از همان نسخه سرو می‌گردد. هزینه پردازش تنها یک‌بار پرداخت می‌شود، اما نیازمند یک مرحله پیش‌پردازش است.

# Generate precompressed .br files for static assets
for file in $(find /var/www/html/wp-content -type f ( -name "*.css" -o -name "*.js" )); do
    brotli -q 9 -k "$file"
done

این اسکریپت، نسخه فشرده‌شده همه فایل‌های CSS و JavaScript را در کنار فایل اصلی می‌سازد. پارامتر -q 9 سطح فشرده‌سازی بالا را تعیین می‌کند و پارامتر -k اطمینان می‌دهد که فایل اصلی حفظ شود.

پس از تولید این فایل‌ها، پیکربندی Nginx یا Apache باید طوری تنظیم شود که در زمان درخواست، نسخه فشرده‌شده سرو شود. در Nginx، پارامتر brotli_static on این رفتار را فعال می‌کند.

در Apache، پیکربندی مشابهی وجود دارد که در فایل .htaccess یا تنظیمات اصلی اعمال می‌شود.

RewriteCond %{HTTP:Accept-Encoding} br
RewriteCond %{REQUEST_FILENAME}.br -f
RewriteRule ^(.*)$ $1.br [L]

ترکیب فشرده‌سازی پویا برای پاسخ‌های HTML و فشرده‌سازی استاتیک برای فایل‌های CSS و JavaScript، بهترین نتیجه را در بیشتر سناریوها فراهم می‌کند.

مسئله مهم در فشرده‌سازی استاتیک، به‌روزرسانی فایل‌های فشرده در زمان تغییر فایل اصلی است. اگر این مرحله به‌درستی انجام نشود، کاربران نسخه قدیمی محتوا را می‌بینند. راه‌حل استاندارد، گنجاندن تولید فایل‌های فشرده در جریان استقرار است که اصول آن در پیاده‌سازی CI/CD برای پروژه‌های وردپرسی آمده است.

فایل‌های پیش‌فشرده و بارگذاری بهینه

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

مزیت اصلی این رویکرد، دستیابی به نسبت فشرده‌سازی بالاتر بدون تحمیل هزینه پردازشی به سرور در زمان درخواست است. سطح فشرده‌سازی ۹ یا ۱۰ که در فشرده‌سازی پویا گران است، در فشرده‌سازی استاتیک کاملاً مقرون‌به‌صرفه می‌شود.

# Manual precompression for a single file
brotli -q 11 -o style.css.br style.css

# Batch precompression for all CSS and JS in a theme
find /var/www/html/wp-content/themes/ -type f -name "*.css" -exec brotli -q 11 -k {} ;
find /var/www/html/wp-content/themes/ -type f -name "*.js"  -exec brotli -q 11 -k {} ;

این اسکریپت، همه فایل‌های CSS و JavaScript قالب را با بالاترین سطح فشرده‌سازی پیش‌فشرده می‌کند. نتایج این فشرده‌سازی، در کنار فایل‌های اصلی ذخیره می‌شوند.

مسئله مهم در این رویکرد، مدیریت حجم فایل‌ها است. اگر تعداد فایل‌های فشرده زیاد باشد، حجم دیسک مصرفی افزایش می‌یابد. این هزینه در مقابل مزیت سرعت، معمولاً قابل قبول است.

نکته تکمیلی، نسخه‌گذاری فایل‌های فشرده است. اگر فایل اصلی تغییر کند و نسخه فشرده به‌روز نشود، کاربران نسخه قدیمی می‌بینند. راه‌حل، استفاده از نسخه‌گذاری در نام فایل یا پاک‌سازی خودکار کش در زمان تغییر است که اصول آن در بی‌اعتبارسازی کش در وردپرس آمده است.

چه فایل‌هایی سود می‌برند و چه فایل‌هایی نه

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

فایل‌های متنی بیشترین سود را از فشرده‌سازی می‌برند. HTML، CSS، JavaScript، JSON، XML، SVG و فونت‌های وب در این دسته قرار می‌گیرند. در این فایل‌ها، تکرار رشته‌ها و الگوهای متنی امکان فشرده‌سازی مؤثر را فراهم می‌کند.

فایل‌های تصویری از قبل فشرده شده، سود محدودی از فشرده‌سازی مجدد می‌برند. فرمت‌هایی مانند WebP، AVIF، JPEG و PNG در این دسته قرار می‌گیرند. اعمال Brotli روی این فایل‌ها، حجم را کاهش محسوسی نمی‌دهد اما زمان پردازش را افزایش می‌دهد.

فایل‌های ویدئویی و صوتی نیز از قبل فشرده شده‌اند. فرمت‌هایی مانند MP4، WebM، MP3 و AAC در این دسته قرار می‌گیرند. فشرده‌سازی این فایل‌ها نه سودی دارد و نه توصیه می‌شود.

قاعده کلی این است که فشرده‌سازی روی محتوایی اعمال شود که ماهیت متنی دارد و از قبل فشرده نشده است. اعمال آن روی محتوای دودویی پیش‌فشرده، هزینه‌ای است بدون بازدهی.

نکته تکمیلی، انتخاب فرمت تصویر مناسب است. اگر تصاویر با فرمت‌های مدرن مانند WebP یا AVIF ذخیره شوند، حجم کلی صفحه کاهش می‌یابد و نیاز به فشرده‌سازی انتقال نیز کمتر می‌شود. اصول تفصیلی این موضوع در بهترین فرمت تصویر برای وب آمده است.

اندازه‌گیری و اعتبارسنجی

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

ابزار نخست، خط فرمان curl است. با استفاده از این ابزار می‌توان هدرهای پاسخ را مشاهده و نوع فشرده‌سازی اعمال‌شده را تشخیص داد.

curl -I -H "Accept-Encoding: br" https://example.com/
curl -I -H "Accept-Encoding: gzip" https://example.com/

در خروجی این دستورات، هدر Content-Encoding نشان می‌دهد کدام الگوریتم اعمال شده است. اگر درخواست اول با هدر Accept-Encoding: br ارسال شود، سرور باید پاسخ با Content-Encoding: br بدهد.

ابزار دوم، ابزارهای اندازه‌گیری اندازه پاسخ است. با محاسبه حجم پاسخ پیش و پس از فعال‌سازی Brotli، می‌توان اثر واقعی را اندازه گرفت.

# Measure size without compression
curl -s -H "Accept-Encoding: identity" https://example.com/style.css | wc -c

# Measure size with Brotli
curl -s -H "Accept-Encoding: br" https://example.com/style.css | wc -c

مقایسه این دو عدد، نسبت فشرده‌سازی واقعی را نشان می‌دهد. اگر این نسبت از ۳۰ درصد کمتر باشد، احتمالاً فایل مورد نظر از نوع دودویی یا از قبل فشرده است.

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

در سطح تجربه کاربر، معیارهای Core Web Vitals باید اندازه‌گیری شوند. بهبود این معیارها، هدف نهایی بهینه‌سازی فشرده‌سازی است. اصول تفصیلی این معیارها در Core Web Vitals چیست و کاهش زمان TTFB آمده است.

اندازه‌گیری تنها راه تشخیص تفاوت میان یک پیکربندی بهینه و یک پیکربندی خوش‌شانس است.

Brotli در فروشگاه ووکامرس

فروشگاه‌های ووکامرس یکی از سناریوهایی هستند که Brotli در آن‌ها اثر محسوسی دارد. صفحات ووکامرس حجم بالایی از HTML، CSS و JavaScript تولید می‌کنند و فشرده‌سازی این فایل‌ها به کاهش زمان بارگذاری منجر می‌شود.

سه نوع صفحه در ووکامرس بیشترین سود را از فشرده‌سازی می‌برند. صفحه اصلی فروشگاه که حجم بالایی از HTML و CSS تولید می‌کند. صفحه محصول که شامل توضیحات، گالری تصاویر و بخش‌های پویا است. صفحه تسویه حساب که شامل فرم‌های پیچیده و اسکریپت‌های اعتبارسنجی است.

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

location ~ ^/(cart|checkout|my-account)/ {
    # Disable caching for personal pages
    fastcgi_cache_bypass 1;
    fastcgi_no_cache 1;
    
    # But keep Brotli compression active
    brotli on;
    brotli_comp_level 4;
}

این پیکربندی، کش را برای صفحات شخصی غیرفعال می‌کند اما فشرده‌سازی را حفظ می‌نماید. نتیجه، کاهش حجم انتقال بدون ذخیره‌سازی داده شخصی است.

مسئله دیگر، فایل‌های JavaScript و CSS اختصاصی ووکامرس است. این فایل‌ها در نسخه‌های اخیر به‌طور قابل توجهی بهینه شده‌اند، اما فشرده‌سازی آن‌ها همچنان سودمند است.

در لایه کش لبه، اگر فروشگاه از CDN استفاده می‌کند، Brotli در گره‌های لبه می‌تواند محتوای استاتیک را فشرده کرده و به همه کاربران سرو کند. این رویکرد، بار سرور مبدأ را کاهش می‌دهد. اصول تفصیلی این موضوع در بهینه‌سازی سرعت ووکامرس آمده است.

جدول مقایسه Brotli و Gzip

این جدول، تصویر کلی تفاوت‌ها را نشان می‌دهد. تصمیم نهایی بر اساس نیازهای خاص هر پروژه گرفته می‌شود، اما در بیشتر سناریوهای مدرن، Brotli انتخاب ترجیحی است.

اشتباهات رایج

نخستین اشتباه، فعال‌سازی Brotli بدون باقی‌گذاشتن Gzip به‌عنوان پشتیبان است. اگر مرورگرهای قدیمی Brotli را پشتیبانی نکنند و Gzip فعال نباشد، پاسخ بدون فشرده‌سازی منتقل می‌شود و حجم انتقال به‌شدت افزایش می‌یابد.

دومین اشتباه، اعمال فشرده‌سازی روی فایل‌های دودویی پیش‌فشرده است. اعمال Brotli روی فایل‌های WebP، MP4 یا ZIP، نه حجم را کاهش می‌دهد و نه سودی دارد.

سومین اشتباه، انتخاب سطح فشرده‌سازی نامناسب است. سطح بالا برای پاسخ‌های پویا، بار پردازشی غیرضروری تحمیل می‌کند. سطح پایین برای فایل‌های استاتیک، فرصت کاهش حجم را از دست می‌دهد.

چهارمین اشتباه، نادیده گرفتن نبود به‌روزرسانی فایل‌های پیش‌فشرده است. اگر فایل اصلی تغییر کند و نسخه فشرده قدیمی بماند، کاربران نسخه قدیمی محتوا را می‌بینند.

پنجمین اشتباه، فراموش کردن پیکربندی Vary است. اگر سرور بر اساس هدر Accept-Encoding پاسخ متفاوتی بدهد اما هدر Vary: Accept-Encoding را ارسال نکند، لایه‌های میانی می‌توانند نسخه نادرستی را به کاربر بعدی سرو کنند.

gzip_vary on;
brotli_vary on;

این دو پارامتر، اطمینان می‌دهند که هدر Vary مناسب در پاسخ‌ها ارسال می‌شود. اصول تفصیلی این موضوع در تنظیم هدرهای کش در وردپرس آمده است.

ششمین اشتباه، نبود هماهنگی میان سرور مبدأ و لایه CDN است. اگر هر دو لایه فشرده‌سازی انجام دهند، هزینه پردازش اضافه می‌شود بدون بهبود نسبت فشرده‌سازی.

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

هشتمین اشتباه، بی‌توجهی به اثر فشرده‌سازی روی مصرف CPU است. سطوح بالای فشرده‌سازی، مصرف پردازشی را افزایش می‌دهند. در سرورهای با ظرفیت محدود، این افزایش می‌تواند به کندی سراسری منجر شود. اصول تفصیلی این تعادل در کاهش مصرف CPU و RAM در وردپرس آمده است.

نهمین اشتباه، فراموش کردن آزمون با مرورگرهای مختلف است. تنظیمات باید در همه مرورگرهای هدف آزمایش شوند تا از پشتیبانی کامل اطمینان حاصل گردد.

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

یازدهمین اشتباه، نادیده گرفتن اثر فشرده‌سازی روی کش است. اگر پاسخ فشرده‌شده در کش ذخیره شود، نسخه فشرده‌شده ذخیره می‌گردد. این رفتار در بیشتر حالات مطلوب است اما باید آگاهانه مدیریت شود. اصول تفصیلی در گرم‌کردن کش در وردپرس آمده است.

دوازدهمین اشتباه، عدم اعتبارسنجی پس از تغییر است. هر تغییر در پیکربندی فشرده‌سازی باید با اندازه‌گیری همراه باشد. بدون این اعتبارسنجی، تفاوت میان یک تغییر مؤثر و یک تغییر بی‌اثر قابل تشخیص نیست.

پرسش‌های پرتکرار درباره فشرده‌سازی Brotli در وردپرس

Brotli چیست و چه تفاوتی با Gzip دارد؟

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

آیا Brotli جایگزین Gzip است؟

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

چگونه Brotli را در وردپرس فعال کنم؟

Brotli در سطح سرور فعال می‌شود، نه در سطح وردپرس. در Nginx با نصب ماژول ngx_brotli و تنظیم پارامترهای brotli on. در Apache با فعال‌سازی ماژول mod_brotli و تنظیم قواعد مربوطه در فایل تنظیمات.

آیا فعال‌سازی Brotli روی سرعت سایت اثر دارد؟

بله، اما اثر آن تجمعی است. کاهش حجم انتقال، به کاهش زمان بارگذاری منجر می‌شود. این کاهش در شبکه‌های کندتر و کاربران دور از سرور، محسوس‌تر است.

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

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

آیا Brotli روی همه مرورگرها پشتیبانی می‌شود؟

در مرورگرهای مدرن بله. Chrome، Firefox، Edge، Safari و Opera از آن پشتیبانی می‌کنند. مرورگرهای بسیار قدیمی ممکن است پشتیبانی نداشته باشند و برای آن‌ها Gzip فعال می‌ماند.

آیا فشرده‌سازی روی تصاویر اثر دارد؟

روی تصاویر پیش‌فشرده مانند WebP، AVIF و JPEG سود محدودی دارد. اعمال فشرده‌سازی روی این فایل‌ها، هزینه پردازش اضافه می‌کند بدون کاهش محسوس حجم. تصاویر SVG از این قاعده مستثنا هستند چون ماهیت متنی دارند.

آیا Brotli جایگزین بهینه‌سازی تصویر است؟

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

آیا Brotli روی سئو اثر دارد؟

اثر مستقیم ندارد، اما اثر غیرمستقیم آن جدی است. کاهش حجم انتقال، مستقیماً روی معیار TTFB اثر می‌گذارد و این معیار به‌عنوان سیگنال کیفیت تجربه صفحه در نظر گرفته می‌شود.

آیا Brotli روی مصرف CPU سرور اثر دارد؟

بله، به‌ویژه در سطوح بالای فشرده‌سازی. سطح پنج مصرف متعادلی دارد. سطح نه یا بالاتر، مصرف پردازشی محسوسی به همراه دارد که در سرورهای با ظرفیت محدود باید لحاظ شود.

آیا می‌توان Brotli را فقط برای برخی فایل‌ها فعال کرد؟

بله. با تنظیم پارامتر brotli_types در Nginx یا AddOutputFilterByType در Apache، می‌توان فشرده‌سازی را به انواع محتوای مشخص محدود کرد. این رویکرد از فشرده‌سازی بیهوده فایل‌های پیش‌فشرده جلوگیری می‌کند.

آیا Brotli روی CDN پشتیبانی می‌شود؟

بیشتر سرویس‌های CDN مدرن از Brotli پشتیبانی می‌کنند. اما نحوه پشتیبانی متفاوت است. برخی در سرور مبدأ فشرده‌سازی را انجام می‌دهند و برخی در گره‌های لبه. انتخاب رویکرد به معماری کلی بستگی دارد.

آیا فعال‌سازی Brotli نیازمند تغییر در وردپرس است؟

خیر. فشرده‌سازی در سطح سرور انجام می‌شود و وردپرس نیازی به تغییر ندارد. تنها در صورتی که از افزونه کش استفاده می‌شود، باید اطمینان حاصل شود که افزونه با فشرده‌سازی سرور تداخل ندارد.

آیا Brotli روی فایل‌های HTML پویا هم کار می‌کند؟

بله. فشرده‌سازی پویا برای HTML کار می‌کند، اگرچه سطح فشرده‌سازی باید متعادل باشد چون در هر درخواست تکرار می‌شود. برای HTML پویا، سطح چهار تا شش مناسب است.

آیا Brotli نیازمند تغییر تنظیمات مرورگر است؟

خیر. مرورگرهای مدرن به‌طور خودکار Brotli را در هدر Accept-Encoding اعلام می‌کنند. این مذاکره شفاف است و کاربر نیازی به تنظیم خاصی ندارد.

چگونه بفهمم Brotli فعال است؟

با ارسال درخواست با curl و هدر Accept-Encoding: br. اگر پاسخ شامل هدر Content-Encoding: br باشد، Brotli فعال است. در غیر این صورت، تنظیمات سرور باید بازبینی شود.

آیا Brotli در همه سرورها پشتیبانی می‌شود؟

Nginx و Apache از Brotli پشتیبانی می‌کنند، اما نیازمند نصب ماژول مناسب هستند. در هاست‌های اشتراکی، ممکن است این ماژول نصب نباشد. در این حالت، باید از سرویس‌های CDN استفاده کرد که Brotli را در گره‌های لبه فراهم می‌کنند.

آیا Brotli روی فایل‌های فشرده‌شده قبلی اثر دارد؟

خیر. اگر فایل از قبل فشرده شده باشد (مانند WebP یا MP4)، اعمال Brotli روی آن سود محسوسی ندارد. تنظیم پارامترهای brotli_types برای جلوگیری از این وضعیت، یک اقدام پایه است.

آیا Brotli برای سایت‌های کوچک توصیه می‌شود؟

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

یک نکته برای ادامه مسیر

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

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