23 سبتمبر 2025·8 دقيقة
ZSTD مقابل Brotli مقابل GZIP: اختيار ضغط واجهات الـ API
قارن ZSTD و Brotli و GZIP لواجهات الـ API: السرعة، نسبة الضغط، تكلفة المعالجة، والافتراضات العملية لحمولات JSON والثنائية في الإنتاج.
قارن ZSTD و Brotli و GZIP لواجهات الـ API: السرعة، نسبة الضغط، تكلفة المعالجة، والافتراضات العملية لحمولات JSON والثنائية في الإنتاج.
ضغط استجابات الـ API يعني أن الخادم يُشفّر جسم الاستجابة (غالبًا JSON) إلى تدفق بايتات أصغر قبل إرساله عبر الشبكة. يقوم العميل (المتصفح، تطبيق الهاتف، الـ SDK، أو خدمة أخرى) بفك الضغط لاحقًا. عبر HTTP، يتم التفاوض عبر رؤوس مثل Accept-Encoding (ما يدعمه العميل) و Content-Encoding (ما اختاره الخادم).
يوفر الضغط بشكل رئيسي ثلاث فوائد:
المقايضة واضحة: الضغط يوفر النطاق الترددي لكنه يكلف وحدة معالجة مركزية (ضغط/فك) وأحيانًا ذاكرة (مخازن مؤقتة). ما إذا كان يستحق يعتمد على عنق الزجاجة لديك.
الضغط يتألق عادةً عندما تكون الاستجابات:
إذا كنت تعيد قوائم JSON كبيرة (كتالوجات، نتائج بحث، تحليلات)، فالضغط غالبًا ما يكون واحدًا من أسهل تحسينات الأداء.
الضغط غالبًا ما يكون استخدامًا سيئًا للـ CPU عندما تكون الاستجابات:
عند الاختيار بين ZSTD و Brotli و GZIP لضغط واجهات الـ API، يأتي القرار العملي عادةً إلى:
كل ما تبقى في هذه المقالة يتعلق بموازنة هذه الثلاثة وفقًا لأنماط حركة المرور وواجهة الـ API الخاصة بك.
كل الثلاثة تقلل حجم الحمولة، لكنها تُحسّن لقيود مختلفة—السرعة، نسبة الضغط، والتوافق.
سرعة ZSTD: مفيدة عندما تكون واجهة الـ API حساسة لزمن الذيل أو خوادمك مقيدة بالـ CPU. يمكنها الضغط بسرعة كافية بحيث تكون التكلفة غالبًا متجاهلة مقارنة بزمن الشبكة—خاصة للاستجابات JSON المتوسطة إلى الكبيرة.
نسبة ضغط Brotli: الأفضل عندما يكون النطاق الترددي هو القيد الأساسي (عملاء الجوال، تكاليف إخراج مرتفعة، تسليم عبر CDN) والاستجابات نصّية بشكل أساسي. يمكن أن تستحق الحمولات الصغيرة ذلك حتى لو استغرق الضغط وقتًا أطول.
توافق GZIP: الأفضل عندما تحتاج إلى أقصى دعم للعميل مع أقل مخاطر تفاوض (SDKs القديمة، عملاء مدمجون، بروكسيات قديمة). خيار آمن حتى لو لم يكن الأفضل أداءً.
"المستويات" هي إعدادات تضبط المقايضة بين زمن المعالجة وصغر المخرجات:
فك الضغط عادةً أرخص بكثير من الضغط لكل الثلاثة، لكن المستويات العالية قد تزيد تكلفة فك العميل—مهم للأجهزة المحمولة.
يُسوَّق الضغط غالبًا على أنه "استجابات أصغر = واجهات أسرع." هذا صحيح كثيرًا على الشبكات البطيئة—لكن ليس تلقائيًا. إذا أضاف الضغط وقت CPU كافيًا، قد تحصل على طلبات أبطأ رغم قلة البايتات.
من المفيد فصل تكاليفين:
نسبة ضغط عالية قد تقلل زمن النقل، لكن إن أضاف الضغط، على سبيل المثال، 15–30 مللي ثانية لكل استجابة، قد تخسر أكثر مما تكسب—خاصة على الاتصالات السريعة.
تحت الحمل، يمكن للضغط أن يضر زمن الذيل p95/p99 أكثر من p50. عندما يرتفع استخدام CPU، تُحتجز الطلبات في قائمة انتظار. إن الطوابير تضخم تكاليف الطلبات الصغيرة إلى تأخيرات كبيرة—قد يبدو المتوسط جيدًا، لكن أبطأ المستخدمين يعانون.
لا تخمن. نفّذ اختبار A/B أو نشر تدريجي وقارن:
اختبر بأنماط حركة المرور والحمولات الحقيقية. "أفضل" مستوى ضغط هو الذي يقلّل الوقت الكلّي، ليس فقط البايتات.
الضغط ليس "مجانًا"—ينقل العمل من الشبكة إلى CPU والذاكرة على الطرفين. في الـ APIs، يظهر ذلك كزمن معالجة أعلى، بصمة ذاكرة أكبر، وأحيانًا تباطؤ في جانب العميل.
معظم CPU ينفق في ضغط الاستجابات. الضغط يبحث عن الأنماط، يبني حالات/معاجم، ويكتب المخرجات المشفرة.
فك الضغط عادة أرخص، لكنه يظل مهمًا:
إذا كانت واجهتك مقيدة بالـ CPU بالفعل، تفعيل مستوى ضغط عالٍ يمكن أن يزيد زمن الذيل حتى مع تقلص الحمولة.
الضغط يمكن أن يزيد استخدام الذاكرة بعدة طرق:
في بيئات الحاويات، ذروة الذاكرة الأعلى يمكن أن تؤدي إلى قتل العمليات بسبب OOM أو حدود أقوى تقلل الكثافة.
الضغط يضيف دورات CPU لكل استجابة، مما يقلل من معدل المعالجة لكل مثيل. هذا يمكن أن يحفّز التحجيم التلقائي بسرعة أكبر، مسببًا زيادة التكاليف. نمط شائع: تنخفض البيانات المنقولة، لكن يرتفع استهلاك CPU—فالخيار الصحيح يعتمد على المورد النادر لديك.
على الأجهزة المحمولة أو منخفضة الطاقة، يتنافس فك الضغط مع العرض، تنفيذ JavaScript، والبطارية. ترميز يوفر بضعة كيلوبايت ولكن يستغرق وقتًا أطول لفكّه قد يبدو أبطأ، خصوصًا عندما يكون "الوقت إلى البيانات القابلة للاستخدام" مهمًا.
Zstandard (ZSTD) هو تنسيق ضغط حديث مصمم لتقديم نسبة ضغط قوية بدون إبطاء واجهتك كثيرًا. للعديد من واجهات JSON، هو افتراضي قوي: استجابات أصغر بشكل ملحوظ من GZIP بزمن مماثل أو أقل، وفك سريع جدًا على العملاء.
ZSTD قيّم عندما تهتم بالزمن من طرف إلى طرف، ليس فقط أصغر عدد بايتات. يميل إلى الضغط بسرعة وفك بسرعة فائقة—مفيد للواجهات حيث كل مللي ثانية في CPU تتنافس مع معالجة الطلب.
يؤدي أيضًا أداءً جيدًا عبر نطاق أحجام الحمولة: JSON الصغير إلى المتوسط غالبًا يرى مكاسب، والاستجابات الكبيرة تستفيد أكثر.
لمعظم الواجهات، ابدأ بالمستويات المنخفضة (غالبًا المستوى 1–3). هذه توفر غالبًا أفضل مقايضة زمن/حجم.
استخدم مستويات أعلى فقط عندما:
نهج عملي: افتراضي منخفض عام، ثم رفع المستوى انتقائيًا لنقاط نهاية "الاستجابة الكبيرة".
ZSTD يدعم البث، مما يقلل ذروة الذاكرة ويمكن أن يبدأ الإرسال مبكرًا للاستجابات الكبيرة.
وضع المعجم يمكن أن يكون مفيدًا عندما تُعيد الـ API كائنات متشابهة كثيرًا (مفاتيح متكررة، مخططات مستقرة). يكون فعالًا عند:
دعم الخادم سهل في كثير من الأُطُر، لكن توافق العميل قد يحدد القرار. بعض عملاء HTTP والـ proxies والبوابات لا يعلنون أو لا يقبلون Content-Encoding: zstd افتراضيًا.
إذا كنت تقدم لمستهلكين طرف ثالث، احتفظ بخيار احتياطي (عادةً GZIP) ومكّن ZSTD فقط عندما يتضمن Accept-Encoding صراحةً أنه يدعمه.
Brotli مصمم لضغط النص بشكل متميز. على JSON وHTML وأنواع الحمولة النصية الأخرى، غالبًا يتفوق على GZIP في نسبة الضغط—خاصة عند إعدادات الضغط العالية.
الاستجابات النصية بكثرة هي نقطة قوة Brotli. إذا كانت API ترسل مستندات JSON كبيرة (كتالوجات، نتائج بحث، حِزم تكوين)، يمكن أن يقلل Brotli البايتات بشكل ملحوظ، مما يساعد على الشبكات البطيئة ويمكن أن يقلل تكلفة الإخراج.
Brotli قوي أيضًا عندما يمكنك ضغط مرة واحدة وخدمة مرات عديدة (الاستجابات القابلة للتخزين المؤقت، الموارد المرقمة بالإصدار). في هذه الحالات، قد يستحق مستوى Brotli العالي لأن تكلفة الـ CPU تتوزع على طلبات متعددة.
للـ استجابات الديناميكية (تُولد لكل طلب)، غالبًا تتطلب أفضل نسب Brotli مستويات عالية قد تكون باهظة CPU وتضيف كمونًا. عندما تحسب وقت الضغط، قد يكون الفارق الحقيقي مع ZSTD (أو حتى GZIP مضبوطًا جيدًا) أصغر مما تتوقع.
كما أنه أقل جذبًا للحمولات التي لا تضغط جيدًا (بيانات مضغوطة مسبقًا، تنسيقات ثنائية كثيرة). في هذه الحالات تحرق CPU بلا جدوى.
المتصفحات عمومًا تدعم Brotli جيدًا عبر HTTPS، لذا فهو شائع لحركة الويب. بالنسبة لعملاء API غير المتصفح (SDKs الجوالة، أجهزة إنترنت الأشياء، ستاكات HTTP القديمة)، قد يكون الدعم غير متسق—فتفاوض عبر Accept-Encoding واحتفظ بخيار احتياطي (عادةً GZIP).
لا يزال GZIP الإجابة الافتراضية لأنّه أكثر الخيارات المدعومة عالميًا. تقريبا كل عميل HTTP، متصفح، بروكسي، وبوابة يفهم Content-Encoding: gzip، وهذه التنبؤية مهمة عندما لا تملك تحكمًا كاملاً على الطريق بين خادمك ومستخدميك.
الميزة ليست أن GZIP "الأفضل"—إنها أنه نادرًا ما يكون خيارًا خاطئًا. لدى العديد من المؤسسات خبرة تشغيلية سنوات معه، إعدادات افتراضية في الخوادم، ومفاجآت أقل مع الوسائط التي قد تتعامل بشكل سيئ مع الترميزات الأحدث.
لحمولات الـ API (غالبًا JSON)، مستويات الضغط المتوسطة إلى المنخفضة هي نقطة التوازن. مستويات مثل 1–6 تعطي معظم تقليل الحجم مع بقاء CPU معقولًا.
المستويات العالية جدًا (8–9) تعطي ربحًا بسيطًا لكن تكلفة CPU عادةً لا تستحقها للزمن الحقيقي الديناميكي.
على الأجهزة الحديثة، GZIP عمومًا أبطأ من ZSTD لنفس نسبة الضغط، وغالبًا لا يضاهي أفضل نسب Brotli على النص. في عبء واجهة حقيقي، هذا يعني عادةً:
إذا كان عليك دعم عملاء قدامى، أجهزة مدمجة، بروكسيات شركات صارمة، أو بوابات قديمة، فـ GZIP هو الخيار الأكثر أمانًا. بعض الوسائط الوسيطة ستزيل الترميزات غير المعروفة، تفشل في تمريرها، أو تكسر التفاوض—مشكلات أقل شيوعًا مع GZIP.
إذا كان بيئتك مختلطة أو غير مؤكدة، بدءًا بـ GZIP (ثم إضافة ZSTD/Brotli حيث تسيطر على المسار) غالبًا ما يكون الاستراتيجية الأكثر موثوقية.
النجاحات في الضغط ليست فقط عن الخوارزمية. المحرك الأكبر هو نوع البيانات التي ترسلها. بعض الحمولات تتقلص بشكل كبير مع ZSTD أو Brotli أو GZIP؛ والبعض الآخر بالكاد يتغير ويستهلك CPU دون جدوى.
الاستجابات النصية تضغط جيدًا لأنها تحتوي على مفاتيح متكررة، فراغات، وأنماط متوقعة.
كلما زادت التكرارية والبنية، زادت نسبة الضغط.
التنسيقات الثنائية مثل Protocol Buffers و MessagePack أكثر تماسُكًا من JSON، لكنها ليست عشوائية. غالبًا تحتوي على علامات متكررة، مخططات سجلات متشابهة، وتسلسلات متوقعة.
هذا يعني أنها غالبًا قابلة للضغط، خاصةً للاستجابات الكبيرة أو النقاط النهائية التي تعيد قوائم طويلة. الجواب الوحيد الموثوق هو القياس مع حركة المرور الحقيقية: نفس النهاية، نفس البيانات، الضغط مُفعل/معطل، وقارن الحجم والزمن.
العديد من التنسيقات مضغوطة داخليًا. تطبيق ضغط HTTP عليها يعطي موفورات ضئيلة وقد يزيد زمن الاستجابة.
لهذه الأنواع، من الشائع تعطيل الضغط حسب نوع المحتوى.
نهج بسيط هو ضغط الاستجابات فقط عندما تتجاوز حجمًا أدنى:
Content-Encoding.هذا يحافظ على CPU موجهًا نحو الحمولات التي تُحسِن عرض النطاق وتُسرّع الأداء من طرف إلى طرف.
الضغط يعمل بسلاسة عندما يتفق العميل والخادم على الترميز. هذا الاتفاق يحدث عبر Accept-Encoding (يرسله العميل) و Content-Encoding (يرسله الخادم).
يعلن العميل ما يمكنه فكّه:
GET /v1/orders HTTP/1.1
Host: api.example
Accept-Encoding: zstd, br, gzip
يختار الخادم واحدًا ويصرّح بما استخدم:
HTTP/1.1 200 OK
Content-Type: application/json
Content-Encoding: zstd
إذا أرسل العميل Accept-Encoding: gzip وردّت بـ Content-Encoding: br، فقد يفشل العميل في تحليل الجسم. إن أرسل العميل لا شيء في Accept-Encoding، فالاختيار الآمن هو عدم الضغط.
ترتيب عملي للواجهات غالبًا ما يكون:
zstd أولًا (توازن جيد سرعة/نسبة)br (أصغر أحيانًا، أبطأ أحيانًا)gzip (أوسع توافقًا)بمعنى آخر: zstd > br > gzip.
لا تعامل هذا كقانون مطلق: إذا كانت حركة المرور لديك معظمها متصفحات، فقد يكون br أعلى أحقية؛ إذا كان لديك عملاء جوال قدامى، فقد يكون gzip الخيار الأكثر أمانًا.
إذا يمكن تقديم الاستجابة بعدة ترميزات، أضف:
Vary: Accept-Encoding
بدونه، قد يخزن CDN أو بروكسي نسخة gzip ويخدمها بطريق الخطأ لعميل لم يطلب أو لا يستطيع فكها.
بعض العملاء يعلنون الدعم لكن لديهم مفككات معيبة. للبقاء مرنًا:
zstd، عد مؤقتًا إلى gzip.التفاوض أقل عن ضغط كل بايت وأكثر عن عدم كسر العميل.
ضغط الـ API لا يعمل في فراغ. بروتوكول النقل، تكاليف TLS، وأي CDN أو بوابة وسيطة يمكن أن يغيروا النتيجة الواقعية—أو حتى يكسروا الأشياء إذا أُعدّوا خطأ.
مع HTTP/2، تشترك عدة طلبات في اتصال TCP واحد. هذا يقلل من تكلفة الاتصال، لكن فقدان الحزم يمكن أن يوقف كل التدفقات بسبب حظر رأس-التدفق في TCP. الضغط يمكن أن يساعد بتقليص أجسام الاستجابة، مما يقلل البيانات "العالقة" خلف حدث فقدان.
HTTP/3 يعمل فوق QUIC (UDP) ويتجنب حظر رأس-التدفق بين التدفقات على مستوى TCP. حجم الحمولة ما زال مهمًا، لكن عقوبة الفقد غالبًا أقل لكل اتصال. عمليًا، يظل الضغط مفيدًا—تتوقع أن تظهر الفوائد أكثر كوفورات عرض نطاق أسرع و"الوقت إلى آخر بايت" أسرع بدلًا من انخفاضات كمون دراماتيكية.
TLS بالفعل يستهلك CPU (مصافحة، تشفير/فك تشفير). إضافة الضغط (خصوصًا على مستويات عالية) قد تدفعك إلى حدود CPU أثناء الذروات. لذلك إعدادات "ضغط سريع بنسبة لا بأس بها" غالبًا تتفوق على "أقصى نسبة" في الإنتاج.
بعض CDNs/البوابات تضغط تلقائيًا أنواع MIME معينة، بينما يمرر آخرون ما يرسله المنشأ. قد يقوم بعضهم بتطبيع أو حتى إزالة Content-Encoding إذا أسيء تهيئته.
تحقق من السلوك لكل مسار، وتأكد من الحفاظ على Vary: Accept-Encoding حتى لا يخدم الكاش متغيرًا مضغوطًا لعميل لم يطلبه.
إذا تخزن على الحافة، ففكّر في تخزين متغيرات منفصلة لكل ترميز (gzip/br/zstd) بدلًا من إعادة الضغط على كل ضربة. إذا تخزن عند المنشأ، قد تريد أن تفاوض الحافة وتخزن عدة ترميزات.
المفتاح هو الاتساق: Content-Encoding صحيح، Vary صحيح، ووضوح من أين يحدث الضغط.
لواجهات الموجهة للمستعرض، فضّل Brotli عندما يعلنه العميل (Accept-Encoding: br). المتصفحات تفك Brotli بكفاءة وغالبًا يقدم تقليل حجم أفضل للمحتوى النصي.
لواجهات خدمة إلى خدمة داخلية، اجعل ZSTD الافتراضي عندما تكون الجانبان تحت سيطرتك. عادة أسرع لنفس أو أفضل نسب الضغط من GZIP والتفاوض واضح.
لواجهات عامة يستخدمها SDKs متنوعة، احتفظ بـ GZIP كأساس عالمي وأضف ZSTD كخيار اختياري للعملاء الذين يعلنون دعمه. هذا يتجنب كسر ستاكات HTTP القديمة.
ابدأ بمستويات سهلة القياس ومن غير المحتمل أن تفاجئك:
إذا احتجت نسبة أقوى، تحقق بعينات حمل إنتاجية وتتبع p95/p99 قبل رفع المستويات.
ضغط الاستجابات الصغيرة قد يكلف CPU أكثر مما يوفر على الشبكة. نقطة بداية عملية:
اضبط عبر مقارنة: (1) البايتات الموفّرة، (2) زمن الخادم المضاف، (3) التغيير في الزمن من طرف إلى طرف.
نشر الضغط خلف علامة ميزة، ثم أضف إعداد لكل مسار (تمكين لـ /v1/search، تعطيل للمسارات الصغيرة). امنح العميل خيار تعطيل عبر Accept-Encoding: identity للتحرّي. دائمًا ضف Vary: Accept-Encoding للحفاظ على صحة التخزين الوسيط.
إذا كنت تُنشئ واجهات بسرعة (مثلاً بناء واجهات React مع Go + PostgreSQL ثم ضبط بناءً على حركة حقيقية)، يصبح الضغط واحدًا من مفاتيح "تكوين صغير، تأثير كبير". في منصات مثل Koder.ai، عادةً يصل الفرق مبكرًا لأنهم يقدرون نشر التطبيقات بسرعة ثم ضبط سلوك الإنتاج (بما في ذلك ضغط الاستجابات ورؤوس الكاش) عندما تستقر أشكال الحمولة.
الخلاصة العملية: اعتبر الضغط ميزة أداء، انشرها خلف علم، وقِس p95/p99 قبل إعلان النصر.
تغييرات الضغط سهلة النشر ومفاجئًا سهلة الخطأ. عاملها كميزة إنتاجية: أنشر تدريجيًا، قِس الأثر، واجعل التراجع سهلًا.
ابدأ بـ كاناري: فعّل Content-Encoding الجديد (مثلاً zstd) لشريحة صغيرة أو عميل داخلي واحد.
ثم استخدم التدرج (1% → 5% → 25% → 50% → 100%)، وتوقف إذا تحرّكّت المقاييس الأساسية في الاتجاه الخاطئ.
احتفظ بمسار تراجع سهل:
gzip).راقب الضغط كأمر أداء وموثوقية:
4xx/5xx، أخطاء فك العميل، وانتهاء المهلات.عند حدوث خلل، المشتبه بهم المعتادين:
Content-Encoding معلن لكن الجسم غير مضغوط (أو العكس)Accept-Encoding، أو إرجاع ترميز لم يعلنه العميلContent-Length غير صحيح، أو تدخل بروكسي/CDNحدد الترميزات المدعومة في مستنداتك، مع أمثلة قابلة للنسخ:
Accept-Encoding: zstd, br, gzipContent-Encoding: zstd (أو احتياطي)إذا تصدر SDKs، أضف أمثلة فك بسيطة واذكر نسخ الحد الأدنى التي تدعم Brotli أو Zstandard.
استخدم ضغط الاستجابة عندما تكون الاستجابات نصّية بكثافة (JSON/GraphQL/XML/HTML)، متوسطة إلى كبيرة، ومستخدموك على شبكات بطيئة أو مكلفة أو إذا كنت تدفع تكاليف خروج بيانات ملموسة. تجنّبها (أو استخدم عتبة أعلى) للاستجابات الصغيرة جدًا، والوسائط المضمّنة بالفعل (JPEG/MP4/ZIP/PDF)، والخدمات المقيّدة بالمعالجة حيث سيؤدي عبء العمل الإضافي لكل طلب إلى زيادة زمن الذيل (p95/p99).
لأنها تستبدل النطاق الترددي بوحدة المعالجة المركزية (وأحيانًا الذاكرة). وقت الضغط يمكن أن يؤخر بدء إرسال البايتات من الخادم (TTFB)، وتحت الحمل يمكن أن يطيل قوائم الانتظار—ما يضر أحيانًا زمن الذيل حتى لو تحسّن المتوسط. الإعداد “الأفضل” هو الذي يقلل الزمن من طرف إلى طرف، وليس فقط حجم الحمولة.
أولوية عملية عامة للعديد من واجهات الـ API هي:
zstd أولًا (سريع ونسبة ضغط جيدة)br (عادةً أصغر للنصوص، وقد يستهلك CPU أكثر)gzip (أوسع توافقًا)اعتمد دائمًا على ما يعلنه العميل في ، واحتفظ بخيار احتياطي آمن (عادةً أو ).
ابدأ بمستويات منخفضة وقِس النتائج.
استخدم عتبة حجم استجابة دنيا حتى لا تهدر CPU على الحمولة الصغيرة.
اضبط لكل مسار بمقارنة البايتات المحفوظة مقابل زمن الخادم الإضافي وتأثير ذلك على p50/p95/p99.
ركّز على أنواع المحتوى المنظمة والمتكررة:
يجب أن يتبع الضغط مفاوضة HTTP:
Accept-Encoding (مثلاً zstd, br, gzip)Content-Encoding المدعومإذا لم يرسل العميل ، فالخيار الأكثر أمانًا عادةً هو . لا ترجع لم يعلنها العميل، لأن ذلك قد يكسر فك الجسد لدى العميل.
أضف:
Vary: Accept-Encodingهذا يمنع شبكات التوزيع/الوكالات من تخزين نسخة gzip (مثلاً) وإرسالها بطريق الخطأ إلى عميل لم يطلب أو لا يستطيع فك gzip (أو zstd/br). عند دعم عدة ترميزات، هذا الرأس ضروري لسلوك التخزين الوسيط الصحيح.
أوضاع الفشل الشائعة:
نزّلها كميزة أداء:
Accept-Encodinggzipidentityالمستويات الأعلى تعطي أرباحًا صغيرة على الحجم لكنها قد ترفع استخدام CPU وتزيد p95/p99.
النهج الشائع: تفعيل الضغط فقط لأنواع Content-Type النصية وتعطيله للأنواع المعروفة المضغوطة مسبقًا.
Accept-EncodingContent-EncodingContent-EncodingAccept-Encoding)عند التصحيح، سجّل الرؤوس الخام وتحقق من فك الضغط بأداة/عميل موثوق.
gzipإذا ارتفع زمن الذيل تحت الحمل، خفّض المستوى، ارفع العتبة، أو انتقل إلى ترميز أسرع (غالبًا ZSTD).