Brotli vs Gzip للمحترف: 22% توفير في فاتورة Egress بـ 4 سطور NGINX

load_module modules/ngx_http_brotli_filter_module.so;
load_module modules/ngx_http_brotli_static_module.so;

تالت حاجة (الأربع سطور الأساسية) جوّه الـ http { } block:

رابع حاجة: اختبر الـ config واعمل reload:

تحقّق إنه شغّال فعلاً

من ناحية الـ client ابعت طلب بـ Accept-Encoding يحتوي br:

المفروض ترجع response header:

لو رجعت Content-Encoding: gzip معناها NGINX رجع لـ fallback. السبب الأكثر شيوعًا: الطلب على HTTP بدل HTTPS. Chrome و Firefox ما بيبعتوش br في Accept-Encoding إلا على TLS — ده سلوك مقصود في spec الـ HTTP/1.1 لتفادي man-in-the-middle interference على connections غير مشفّرة.

Trade-offs لازم تعرفها قبل ما تشغّلها على الإنتاج

• وقت الضغط على المستويات العالية: Brotli level 11 بياخد 380ms لضغط 412KB على Intel Xeon E5-2680. Gzip level 6 بياخد 14ms على نفس الـ CPU. التوصية: للـ on-the-fly compression خلّيك على level 4 أو 6. Level 11 يستخدم بس مع static precompression وقت الـ build.
• Static vs Dynamic: أفضل ممارسة هي الـ pre-compress للملفات الثابتة (CSS، JS، fonts) وقت الـ build بـ brotli -11 وتخزين الـ .br جنب الملف الأصلي. بعدين فعّل brotli_static on; وNGINX هيقدّم الملف الجاهز بدون ضغط في الـ runtime — يعني مكسب الحجم بدون تكلفة CPU.
• دعم المتصفح: Brotli مدعوم في 96.4% من المتصفحات (Can I Use، مايو 2026). الـ 3.6% الباقية بتفتح من شبكات قديمة جدًا أو IE11 على Windows 7، وNGINX بيرجع لها تلقائيًا بـ Gzip لو ماطلبتش br.
• الذاكرة وقت الضغط: Brotli بياخد ذاكرة ضعف Gzip في الضغط (حوالي 16MB per request على level 6 vs 8MB في Gzip). على سيرفر بـ 1GB RAM وtraffic عالي، استخدم brotli_comp_level 4 بدل 6 — الفارق في الحجم هيبقى 1-2% بس، والذاكرة هتنزل للنص.

متى لا تستخدم Brotli

Brotli بيكون مضيعة وقت — أو ضرر فعلي — في الحالات دي:

• محتوى ثنائي مضغوط بالفعل: صور JPEG و PNG و WebP و AVIF، فيديوهات MP4، ملفات ZIP و .tar.gz. الـ overhead هنا بيزيد الحجم 0.2 لـ 0.8%. علشان كده brotli_types فيها text/* و application/json بس.
• API responses أقل من 1KB: الـ compression overhead (header + setup) أكبر من المكسب على payload صغير. خلّي brotli_min_length على 1024 على الأقل، أحسن 2048 لو بتقدّم JSON قصير كتير.
• Internal microservices على نفس الـ VPC: الـ latency للضغط وفك الضغط على CPU بيبقى أكبر من زمن نقل البايتات الزيادة على شبكة 10Gbps أو 25Gbps. هنا الـ raw JSON أحسن.
• تطبيقات على CPU محدود جدًا: Raspberry Pi 4 في IoT gateways، containers بـ 0.25 vCPU في Kubernetes pods. هنا Gzip level 4 بيكون أحكم.

الخطوة التالية

افتح nginx.conf، ضيف الأربع سطور، اعمل reload، واختبر بـ curl. لو نسبة الضغط مازادتش 15% على الأقل على bundle.js عندك، السبب الأكثر احتمالًا: في CDN في المنتصف بيفك الضغط ويعيد ضغط بـ Gzip. شوف إعدادات Origin Shield في CloudFront أو "Brotli Compression" في Cloudflare Speed Dashboard — لازم تكون مفعّلة على مستوى الـ edge كمان.

مصادر

• RFC 7932 — Brotli Compressed Data Format (IETF، يوليو 2016)
• Google Open Source Blog — "Introducing Brotli: a new compression algorithm for the internet" (سبتمبر 2015)
• NGINX ngx_brotli module — Google GitHub repository، توثيق التكوين الرسمي
• Can I Use — Brotli accept-encoding/content-encoding (مايو 2026)
• Cloudflare Blog — "Results of experimenting with Brotli for dynamic web content"
• Akamai Tech Docs — "Configure Brotli compression at the edge"