فاحص ضغط Gzip / Brotli

بمساعدة الخادم جديد تشخيص المواقع وHTTP

يطلب خادم متقن العنوان ثلاث مرات: بلا ضغط، ثم بـ gzip، ثم بـ Brotli، ويعرض Content-Encoding وContent-Length وتوقيت كل إجابة. ولا تُحسب نسبة التوفير إلا حين يجيب الترميز فعلاً مع Content-Length، وتُسمّى كل حالة يتعذّر قياسها، فلا تُنسب إلى استجابة مقسّمة على أجزاء أو معاد توجيهها نسبةُ توفير لم تظهر.

الخصوصية: يرسل خادم متقن طلبات الاختبار الصغيرة والثابتة الموصوفة في هذه الصفحة إلى المضيف الذي تحدده، ولا يُخزَّن أي شيء. استخدمه فقط مع الأنظمة المصرّح لك باختبارها.
جارٍ تحميل الأداة…

كيف يعمل ضغط HTTP بـ gzip وBrotli؟

يسرد المتصفح في Accept-Encoding الترميزات التي يستطيع فكّها (اليوم gzip وdeflate وbr وكثيراً zstd)؛ فيضغط الخادم المحتوى بأحدها ويسمّيه في Content-Encoding، ويفكّه المتصفح قبل استخدامه. وBrotli (RFC 7932) يجعل النص عادةً أصغر مما يجعله gzip (RFC 1952). والصيغ النصية مثل HTML وCSS وJavaScript وJSON تصغر كثيراً، بينما الصور والفيديو وخطوط WOFF2 مضغوطة أصلاً، وينبغي أن ترسل الاستجابة المضغوطة Vary: Accept-Encoding لتحتفظ الذاكرات المؤقتة بنسخة لكل ترميز.

كيفية استخدام فاحص ضغط Gzip / Brotli

  1. أدخل العنوان النهائي للصفحة أو السكربت أو ملف الأنماط أو استجابة API المراد اختبارها (لا تُتبع عمليات إعادة التوجيه).
  2. اضغط «افحص الضغط».
  3. اقرأ الملاحظات أولاً ثم الطلبات الثلاثة: يبيّن عمود Content-Encoding الترميزات التي استخدمها الخادم فعلاً.
  4. إن كان النص يُقدَّم بلا ضغط أو غابت Vary، ففعّل الضغط أو ترويسة Vary على الخادم أو في CDN وأعد الفحص.

مزايا فاحص ضغط Gzip / Brotli

  • يرسل من خادم متقن ثلاثة طلبات GET لا تختلف إلا في Accept-Encoding — identity (بلا ضغط) وgzip وbr (Brotli) — ويقارن الإجابات جنباً إلى جنب
  • يعرض لكل طلب رمز حالة HTTP، وContent-Encoding الذي اختاره الخادم، وContent-Length الذي أعلنه، والبايتات بعد فك الضغط، والزمن حتى أول بايت، والزمن الكلي
  • لا يحسب نسبة التوفير لـ gzip وBrotli إلا حين يجيب الترميز فعلاً مع Content-Length، ويذكر بالاسم سبب تعذّر القياس (نقل مقسّم، أو إعادة توجيه، أو طلب مرفوض)
  • يشرح النتيجة بحسب نوع المحتوى: استجابة نصية تُقدَّم بلا ضغط، أو صورة أو فيديو مضغوط أصلاً، أو خادم يعرض gzip وحده أو Brotli وحده
  • يتحقق من أن الاستجابة المضغوطة ترسل Vary: Accept-Encoding، لتحتفظ الذاكرات المشتركة بنسخة لكل ترميز
  • ينبّه إلى الخادم الذي يضغط حتى حين يُطلب منه عدم الضغط، وإلى نتيجة Brotli أكبر من gzip

المدخلات والمخرجات

المدخلات

  • العنوان المراد فحصه — العنوان النهائي للمورد بـ http:// أو https://؛ ويُضاف https:// إلى اسم المضيف المجرد. وإن كان العنوان يعيد التوجيه فأعد الفحص على وجهته.
  • لا شيء غيره: قيم Accept-Encoding الثلاث وترويسات الطلب ثابتة.

المخرجات

  • الملخص — هل يُستخدم gzip وBrotli، ونسبة توفير كل منهما حين يمكن قياسها، والحجم غير المضغوط.
  • الملاحظات — معنى الإجابات لنوع المحتوى هذا، وغياب Vary: Accept-Encoding، والاستجابات الصغيرة أو المضغوطة أصلاً.
  • الطلبات الثلاثة — رمز الحالة وContent-Encoding وContent-Length والبايتات بعد فك الضغط والتوقيت لكل من identity وgzip وbr؛ ويمكن تنزيلها بصيغة CSV.
  • الاستجابة — العنوان وContent-Type وترويسة Vary ومكان القياس؛ وتشرح الملاحظات كل حالة تعذّر قياسها.

مثال على فاحص ضغط Gzip / Brotli

صفحة تُقدَّم بـ gzip وبـ Brotli مقسّم على أجزاء

الإدخال:

العنوان المراد فحصه: https://www.example.com/

النتيجة:

gzip Used · Brotli Used · gzip saving 76.4 % · Brotli saving — (not measurable) · Uncompressed size 84210 B
identity → 200, no Content-Encoding, Content-Length 84210
gzip → 200, gzip, Content-Length 19870
br → 200, br, Content-Length not sent (chunked)
The server compresses with both Brotli and gzip, choosing by the Accept-Encoding the client sends.
The server compresses but does not send Vary: Accept-Encoding; a shared cache may hand the compressed copy to a client that cannot decode it.
The Brotli response was sent without Content-Length (chunked), so its compressed size is not reported.

كيف تقرأ نتائج فاحص ضغط Gzip / Brotli

«مستخدم» يعني أن الطلب الذي طلب ذلك الترميز تلقّى إجابة 2xx بترويسة Content-Encoding المطابقة. و«غير مستخدم» يعني إجابة 2xx بدونها، و«—» يعني أن الطلب لم يُجَب بـ 2xx فلا يمكن قول شيء.

لا تظهر نسبة التوفير إلا حين تحمل الإجابة المضغوطة Content-Length. و«غير قابلة للقياس» ليست عيباً في الموقع: فكثير من الخوادم ترسل الاستجابات المضغوطة على أجزاء، وهذا طبيعي.

في HTML وCSS وJavaScript وJSON وXML وSVG يستحق غياب الضغط تماماً الإصلاح. أما في JPEG وPNG وWebP والفيديو وWOFF2 وZIP فعدم الضغط هو الخيار الصحيح.

تُقاس الأزمنة من خادم متقن وتشمل الاتصال الأول؛ فقارن الطلبات الثلاثة تقريبياً فقط، إذ قد يهيّئ أحدها ذاكرةً مؤقتة للطلب الذي يليه.

متى تستخدم فاحص ضغط Gzip / Brotli

  • بعد تغيير الخادم أو CDN أو إطار العمل، تأكد أن صفحات HTML والسكربتات وملفات الأنماط ما زالت تُقدَّم مضغوطة.
  • تحقق من أن Brotli مفعّل فعلاً في CDN لملفاتك النصية، لا gzip وحده.
  • تتبّع صفحة بطيئة أو تقييم أداء منخفض يشير إلى ضغط النصوص.
  • تأكد أن واجهة API تعيد JSON مضغوطاً حين يطلبه العميل، وأن Vary: Accept-Encoding مضبوطة للذاكرات المؤقتة.

استكشاف الأخطاء وإصلاحها

  • الطلبات الثلاثة تجيب بـ 301 أو 302: العنوان يعيد التوجيه والفاحص لا يتبع إعادة التوجيه. تُظهر الملاحظات الوجهة؛ فافحص ذلك العنوان.
  • gzip وBrotli كلاهما «غير مستخدم» في صفحة يعرضها متصفحك مضغوطة: بعض الخوادم لا تضغط إلا لعملاء User-Agent معيّنين أو بعد أن يهيّئ طلبٌ أول الذاكرة المؤقتة. أعد الفحص، وراجع قواعد الضغط على الخادم.
  • طلب identity عاد مضغوطاً هو أيضاً: الخادم يتجاهل Accept-Encoding: identity. والمتصفحات تقبل gzip دائماً فلا يضر ذلك غالباً، لكن العملاء الذين لا يستطيعون فك الضغط سيفشلون.
  • رفض برسالة مثل «This address cannot be reached from the Mutqan server»: العناوين الخاصة والمحجوزة لا تُطلب أبداً. لا تُفحص إلا العناوين العامة.

الأسئلة الشائعة حول فاحص ضغط Gzip / Brotli

كيف يختبر الفاحص الضغط؟

يرسل ثلاثة طلبات GET لا تختلف إلا في Accept-Encoding: identity (بلا ضغط) وgzip وbr (Brotli). والخادم الذي يدعم ترميزاً ما يجيب بترويسة Content-Encoding المطابقة له. ولا تُتبع عمليات إعادة التوجيه، فافحص العنوان النهائي.

لماذا لا تظهر نسبة التوفير أحياناً؟

يعمل خادم متقن على Cloudflare Workers، وبيئة التشغيل فيها تفك ضغط المحتوى قبل أن يراه الفحص، فلا يُعرف الحجم المضغوط إلا من ترويسة Content-Length. والاستجابة المرسلة على أجزاء دون Content-Length لا حجم مضغوطاً معلناً لها، فيقول الفاحص ذلك بدلاً من تقدير رقم.

هل Brotli أفضل من gzip؟

للنصوص مثل HTML وCSS وJavaScript ينتج Brotli (RFC 7932) عادةً ملفات أصغر من gzip (RFC 1952) بسرعة مقاربة، وكل المتصفحات الحالية تدعمه عبر HTTPS. وتعرض الخوادم عادةً الترميزين وتختار Brotli حين يذكر العميل br في Accept-Encoding.

هل يجب ضغط الصور والفيديو أيضاً؟

لا. صيغ JPEG وPNG وWebP وAVIF والفيديو وخطوط WOFF2 وملفات ZIP مضغوطة أصلاً، وgzip أو Brotli يضيفان عملاً ولا يوفران شيئاً يُذكر. الضغط مهم للصيغ النصية: HTML وCSS وJavaScript وJSON وXML وSVG.

لماذا تهم ترويسة Vary: Accept-Encoding؟

الذاكرة التي تخزّن إجابة مضغوطة يجب ألا تقدّمها لعميل لا يستطيع فكّ ضغطها. وVary: Accept-Encoding تطلب من الذاكرات المشتركة الاحتفاظ بنسخة لكل ترميز؛ وينبّه الفاحص حين لا ترسلها استجابة مضغوطة.

ملاحظات تقنية

يعرّف القسم 8.4 من RFC 9110 ترميز المحتوى في HTTP: يسرد العميل الترميزات التي يقبلها في Accept-Encoding، ويسمّي الخادم الترميز الذي طبّقه في Content-Encoding. وgzip هي صيغة RFC 1952، وbr هي صيغة Brotli في RFC 7932، و"identity" تعني عدم الترميز إطلاقاً.

يرسل POST /api/v1/internet/http/compression ثلاثة طلبات GET بمجموعة ترويسات متقن الثابتة مع Accept-Encoding بقيم identity وgzip وbr، دون اتباع إعادة التوجيه. وبيئة Cloudflare Workers تفك ضغط المحتوى قبل أن يقرأه الفحص، فالحجم المضغوط هو Content-Length الذي أعلنه الخادم؛ وحين يُرسل المحتوى مقسّماً لا توجد هذه الترويسة ولا تُحسب نسبة توفير. ويُقرأ المحتوى حتى 1 ميغابايت.

نسبة التوفير هي 1 − الحجم المضغوط ÷ الحجم غير المضغوط، ويؤخذ الحجم غير المضغوط من Content-Length في إجابة identity، أو من المحتوى بعد فك ضغطه إن ضغط الخادم طلب identity رغم ذلك أو أرسله مقسّماً.

الحدود ومنهجية القياس

لا تأتي الأحجام المضغوطة إلا من Content-Length الذي أعلنه الخادم؛ فخادم متقن لا يرى البايتات المضغوطة نفسها، فلا توفير مقيساً للاستجابات المقسّمة.

يُطلب كل ترميز مرة واحدة من خادم متقن على شبكة Cloudflare. وقد تضغط شبكة CDN بشكل مختلف في نقاط طرفية أخرى أو لعملاء آخرين أو بعد امتلاء ذاكرتها.

لا يُختبر إلا gzip وBrotli؛ فلا يُطلب Zstandard (zstd) ولا deflate، ولا يُقرأ من كل محتوى أكثر من 1 ميغابايت.

الأمان والخصوصية

يتسلّم خادم متقن العنوان، ويرسل ثلاثة طلبات GET ثابتة دون أي من ملفات تعريف الارتباط أو بيانات الاعتماد الخاصة بك، ولا يقرأ المحتوى إلا ليعدّ بايتاته، ولا يخزّن شيئاً.

المراجع

  • RFC 9110: HTTP SemanticsIETF · 2022معاني أساليب HTTP وحقول الترويسات ورموز الحالة والتفاوض على المحتوى، بغضّ النظر عن إصدار البروتوكول.
  • RFC 1952: GZIP file format specification version 4.3IETF · 1996صيغة gzip: ترويسة، ثم بيانات مضغوطة بخوارزمية DEFLATE، ثم ذيل فيه CRC-32 والطول — وهي الصيغة التي يقوم عليها ترميز المحتوى gzip في HTTP.
  • RFC 7932: Brotli Compressed Data FormatIETF · 2016صيغة Brotli المسجّلة في HTTP بوصفها ترميز المحتوى br: خوارزمية LZ77 مع ترميز Huffman ونمذجة السياق وقاموس مدمج لنصوص الويب الشائعة.