Brotli أم Gzip: أي ضغط يجب أن يستخدمه موقعك؟

كيف يعمل ضغط HTTP فعليًا

الضغط على الويب تفاوض صامت يحدث عند كل طلب. يعلن المتصفح عمّا يستطيع فك ضغطه في ترويسة Accept-Encoding — والمتصفحات الحديثة ترسل gzip وbr. يختار الخادم واحدًا، ويضغط جسم الاستجابة، ويضع عليه علامة Content-Encoding ليعرف المتصفح كيف يفكّه. لا يتغير كود تطبيقك ولا HTML الخاص بك؛ التحويل يحدث بالكامل أثناء النقل.

المكسب كبير لأن النصوص تنضغط جيدًا للغاية. صفحة HTML بحجم 100 KB تنتقل عادةً بحجم 20 KB مع Gzip؛ وحزمة JavaScript كثيرًا ما تتقلص بثلاثة أرباع حجمها. للزوار على اتصالات بطيئة أو عبر الهاتف، هذا الفرق هو الجزء المرئي من زمن تحميل موقعك — ولهذا يُعدّ الضغط ذلك التحسين النادر الذي يكاد يكون مجانيًا وصائبًا دائمًا تقريبًا للنصوص.

ما الذي يحسّنه Brotli فعليًا

تأتي ميزة Brotli من خيارَين في التصميم: صيغة أذكى، وقاموس مدمج للسلاسل النصية التي تتكرر باستمرار على الويب — وسوم HTML وأسماء خصائص CSS ورموز JavaScript الشائعة. نصوص الويب هي بالضبط ما ضُبط من أجله، وعليها ينتج Brotli عادةً ملفات أصغر من Gzip بنسبة 15-20% عند مستويات الضغط التي تستخدمها الخوادم في الوقت الفعلي.

لكن لنُبقِ الإطار صادقًا: هذه النسبة 15-20% تأتي فوق تخفيض Gzip القائم أصلًا البالغ 70-80%. إذا كانت صفحة تنتقل بحجم 20 KB مضغوطة بـ Gzip، يجعلها Brotli نحو 16-17 KB. مكسب يستحق الاقتناء — فهو يتراكم عبر كل مورد وكل زائر — لكنه تحسين وليس ثورة. وإذا قرأت رسومًا قياسية تدّعي فروقًا هائلة، فتحقق مما إذا كانت تقارن أبطأ مستويات 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 عند كل استجابة، وكلما جرى أبعد في اتجاه التدفق، قلّ عدد مرات تنفيذه. عندما تضغط الحافة، تُضغط الصفحة المخزّنة مؤقتًا مرة واحدة، والنسخة المضغوطة هي التي تُقدَّم من الكاش آلاف المرات — لا ينفق الأصل شيئًا، وتخزّن الحافة كل نسخة يستطيع العميل قبولها.

على cdn.com.tr هذا إعداد يخص كل قاعدة توصيل: تحمل كل قاعدة قائمة ضغط (gzip وzip وbrotli) تفعّلها من اللوحة، إلى جانب خيارات التخزين المؤقت والتحسين للقاعدة نفسها. تفعيل Brotli هو خانة اختيار لا ترحيل خادم — ولأنه يقع على مستوى القاعدة، يمكنك ضغط صفحاتك بقوة مع ترك قاعدة وسائطك المضغوطة أصلًا كما هي، وهذا بالضبط التقسيم الذي دافع عنه القسم السابق.

تحقق مما ترسله فعليًا

الافتراضات حول الضغط تخطئ كثيرًا بما يجعل الفحص يستحق ثلاثين ثانية. اطلب الصفحة مرتين بعرضَي Accept-Encoding مختلفين واقرأ Content-Encoding العائدة. وما دمت هناك، قارن الأحجام المنقولة — الفرق هو توفيرك، مقيسًا لا مفترضًا.

تنبيه واحد عند الاختبار عبر CDN: قد تكون الحافة خزّنت النسخة من طلب سابق، فاستخدم معامل استعلام كاسرًا للكاش لترى السلوك الطازج، وتذكّر أن نسخة مضغوطة مخزّنة تجيب فورًا هي الهدف بعينه.

طلبان وعرضان — اقرأ ما يعود

# 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/