الضغط (Gzip وBrotli وZstd)

الخلاصة — يقلّص الضغط ملفات النص — HTML وCSS وJavaScript — قبل إرسالها عبر الإنترنت، فينزّل المتصفح بايتات أقل وتُحمّل الصفحة أسرع إذا كان النقل هو عنق الزجاجة فعلًا. أشهر خيارين هما Gzip، المدعوم في كل مكان، وBrotli، الذي ينتج عادة ملفات أصغر وتفضله Google. تختلف نسبة الخفض باختلاف الملف، فلا تعامل نسبة واحدة بوصفها وعدًا. وإذا طلب منك PageSpeed Insights «تفعيل ضغط النص»، فهذا هو الحل.

ما الضغط؟

عندما يفتح شخص صفحتك، يجب أن ينزّل متصفحه كل الملفات التي تكوّنها. يجعل الضغط هذه الملفات أصغر أثناء انتقالها، ثم يفكها المتصفح عند الطرف الآخر. لا يتغير شيء في الصفحة للزائر؛ إنما تصل إليه أسرع.

يعمل الأمر كمصافحة سريعة مع كل طلب:

1. يقول المتصفح «هذه الترميزات التي أستطيع فكها»؛ فيرسل ترويسة Accept-Encoding تسرد الخوارزميات التي يفهمها، مثل gzip وbr.
2. يختار الخادم واحدة، ويضغط الملف بها، ثم يعيد ترويسة Content-Encoding التي تحدد ما استخدمه.
3. يفك المتصفح الملف ويعرض الصفحة.

هذا كل شيء. يحدث تلقائيًا لكل ملف، ولا تحتاج إلا إلى تفعيله مرة واحدة في إعدادات الخادم أو الاستضافة.

الخياران اللذان يلزمك معرفتهما

• Gzip — الخيار القديم الموثوق، وتدعمه جميع المتصفحات ومحركات البحث، لذا فهو البديل الآمن.
• Brotli — أحدث، طورته Google، ويجعل ملفات النص عادة أصغر قليلًا من Gzip. عندما يدعمه المتصفح توصي Google باستخدامه، مع Gzip بديلًا لما لا يدعمه.

سترى أيضًا Zstandard ‏(Zstd)، وهو خيار ثالث سريع الفك، لكنه ما زال في بداية اعتماده وغير واسع الاستخدام.

ما الذي لا يُعد ضغطًا؟

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

ما الذي تضغطه وما الذي تتجاوزه؟

اضغط النصوص: ملفات HTML وCSS وJavaScript وJSON وSVG وXML، بما فيها خرائط الموقع.

لا تحاول ضغط الملفات المضغوطة أصلًا، مثل JPG وPNG وGIF ومعظم الفيديو وخطوط WOFF2 ومعظم ملفات PDF. لن تصغر، وإعادة ضغطها تهدر العمل فحسب. وقد أوضحت Google هذه النقطة نفسها عام 2008.

هل يفيد تحسين محركات البحث؟

بصورة غير مباشرة. الضغط ليس عامل ترتيب مستقلًا، لكن الملفات الأصغر تعني تحميلًا أسرع، والسرعة تدخل في Core Web Vitals التي تسهم في تقييم Google لتجربة الصفحة. فعّل الضغط لأنه يسرّع موقعك، لا لأن Google تمنح نقاطًا للإعداد نفسه.

للتفاصيل الفعلية، من أرقام Gzip مقابل Brotli ودعم Googlebot إلى حدود PageSpeed ومستويات الضغط والتفعيل والتحقق، انتقل إلى تبويب Advanced.

الخلاصة — الضغط تفاوض على ترميز محتوى HTTP: يرسل العميل Accept-Encoding، ويمكن أن يتضمن أوزان q وidentity، ويرد الخادم بـContent-Encoding لكل طلب ومورد. ويحتاج الرد القابل للتخزين الذي يختلف حسب الترميز إلى Vary: Accept-Encoding. يتفوق Brotli عادة على Gzip للنص نفسه؛ وتُذكر نسبة 15–20% كثيرًا، لكن الفارق يتوقف على المحتوى وإصدار المرماز والمستوى. وتفضله Google عند دعمه، بينما يظل Gzip البديل العام. أما Zstd فمرماز مسجل لكنه غير مدعوم عالميًا، ولا تذكر وثائق الزاحف دعم Googlebot له. يدعم Googlebot ‏gzip وdeflate وBrotli ‏(br). لا يُعد الضغط عامل ترتيب ولا يضمن تحسن TTFB أو LCP أو البحث؛ لكنه يقلص النقل، وقد يساعد TTFB ← LCP عندما يكون النقل هو عنق الزجاجة، كما يساعد HTML على البقاء دون حد جلب Google البالغ 2 MB وفق منشور 2026. اختر الأنواع وفق MIME والقياس، لا وفق قائمة امتدادات عامة. وخطر BREACH مقصور على رد يجمع سرًا مع محتوى يعكسه مهاجم، وليس مبررًا لتعطيل الضغط في الموقع كله. استخدم مستويات أعلى للملفات الثابتة المضغوطة مسبقًا، ومنخفضة إلى متوسطة للمحتوى الديناميكي بعد قياس الحركة وCPU. ويسمح بروتوكول خرائط الموقع صراحة بخرائط gzip.

ما الضغط فعليًا؟

الضغط، أو بدقة ترميز محتوى HTTP، يقلص متن الرد النصي قبل عبوره الشبكة، فينزّل العميل بايتات أقل ويفكها محليًا. ويجري التفاوض لكل طلب. تقول وثائق Lighthouse: “When a browser requests a resource, it will use the Accept-Encoding HTTP request header to indicate what compression algorithms it supports.” (ترجمة) «عند طلب مورد، يبين المتصفح خوارزميات الضغط التي يدعمها بواسطة ترويسة طلب HTTP المسماة Accept-Encoding». وتبدو ترويسة معتادة هكذا: Accept-Encoding: gzip, deflate, br. يختار الخادم ترميزًا ويعلنه في ترويسة الرد Content-Encoding.

هناك حدّان يستحقان الدقة وفق RFC 9110: ترميز المحتوى تحويل لبيانات التمثيل، أي متن الرد، وهو غير ترميز النقل الذي يعمل على الرسالة أثناء الاتصال. موضوع هذه الصفحة هو ترميز المحتوى المحدد بـContent-Encoding. وقد يحمل Accept-Encoding أوزان q لترتيب التفضيلات، ويرفض ترميزًا بـq=0، وتشير identity إلى «لا ترميز» (§8.4 و§12.5.3). وإذا اختلف متن رد قابل للتخزين حسب الترميز، مثل نسختي gzip وBrotli، وجب إرسال Vary: Accept-Encoding كي لا يقدم المخزن نسخة لا يستطيع العميل فكها (§12.5.5). وتصف وثائق Apache ‏mod_deflate متطلب Vary نفسه.

ينطبق الضغط على HTML وCSS وJavaScript وJSON وSVG وXML، بما فيها خرائط الموقع. ويمكن لـGzip وBrotli تقليص النص كثيرًا؛ وتذكر Google سقفًا يصل إلى 90%. هذه سقف لا نسبة معتادة، فالوفر يتوقف على تكرار المحتوى وحجمه وتصغيره والمرماز وإصداره وقاموسه ومستوى الضغط، ولا يصح تعميم أرقام موقع على آخر.

هناك شيئان لا يمثلهما الضغط، وكلاهما مهم:

• ليس تصغيرًا. يزيل التصغير محارف المصدر، بينما يعيد الضغط ترميز البايتات الناتجة للنقل. اجمعهما: صغّر ثم اضغط.
• ليس تخزينًا مؤقتًا. الضغط يتعلق بالترميز وتقليل بايتات الشبكة، أما التخزين فيتعلق بالحفظ وإعادة الاستخدام عبر Cache-Control وETag وCDN. راجع التخزين المؤقت.

هذه الصفحة هي الشرح المتعمق للضغط ضمن محور مسار العرض الحرج، الذي يورد «ضغط النص» ضمن قائمة البايتات الحرجة.

‏Gzip مقابل Brotli مقابل Zstd

نسبة الضغط

يحقق Brotli عادة نتيجة أفضل للنص، لكن لا تعامل رقمًا بعينه بوصفه عامًا. توضح وثيقة Lighthouse أن التوفير المبلغ عنه محسوب بـGzip وأن Brotli قد يحقق مزيدًا منه. يعرض مختبر Brotli من web.dev مثالًا: تقلص main.bundle.js من 225 KB إلى نحو 61,6 KB بـGzip و53,1 KB بـBrotli، أي أصغر بنحو 14% في ذلك الملف. الأرقام الشائعة مثل 15–20% اتجاهية لا ضمان؛ يتوقف الفارق على إصدار المكتبة والمستوى وتكرار المحتوى وتصغيره. اختبر ملفاتك بدل نقل نسبة موقع آخر.

Gzip هو البديل العام. تقول Google: “Use GZIP as a fallback to Brotli. GZIP is supported in all major browsers, but is less efficient than Brotli.” (ترجمة) «اجعل GZIP بديل Brotli؛ فكل المتصفحات الرئيسية تدعمه، وإن كان أقل كفاءة».

Zstd مرماز ثالث مسجل، لكنه ليس خيارًا افتراضيًا آمنًا بعد. يسرد سجل IANA الرموز gzip وbr وzstd، لكن التسجيل لا يعني دعم كل عميل أو زاحف أو خادم أو CDN. يفرض RFC 9659، الذي يحدّث RFC 8878، دعم نوافذ حتى 8 MB ويمنع طلب نافذة أكبر للتشغيل البيني. كما أن zstd غير ترميز القاموس dcz. ما زال الاعتماد مبكرًا؛ يتيح Caddy مثلًا encode zstd gzip، بينما تسرد وثائق Google ‏gzip وdeflate وBrotli ولا تذكر Zstd لـGooglebot. فعّله حين تدعمه المنظومة ويطلبه العميل، لا بديلًا كاملًا بعد.

دعم المتصفحات والزواحف

صار دعم Brotli شبه شامل، لكنه لم يكن كذلك دائمًا. تقول وثائق Lighthouse: “As of December 2022 Brotli is supported in all major browsers except Safari on iOS.” (ترجمة) «بحلول ديسمبر 2022 كانت كل المتصفحات الرئيسية عدا Safari على iOS تدعم Brotli». وتفسر تلك الفجوة استمرار أهمية Gzip بديلًا.

تقول Google: “If the browser supports Brotli (br) you should use Brotli because it can reduce the file size of the resources more than the other compression algorithms.” (ترجمة) «متى دعم المتصفح Brotli ‏(br)، فاستخدمه لأنه يستطيع تصغير الموارد أكثر من بقية خوارزميات الضغط».

متى تظل بحاجة إلى Gzip؟

اضبط Gzip دائمًا إلى جانب Brotli. يجري التفاوض لكل طلب، فيقدم الخادم Brotli للعملاء الذين يعلنون br وGzip للباقين تلقائيًا؛ أي إنك تعرض كليهما وتدع التفاوض يقرر.

هل يدعم Google وBing ‏Brotli وGzip؟

تؤكد مقالات كثيرة الجواب بلا دليل. وفيما يأتي مسار مؤرخ من ثلاث إفادات صادرة عن Google نفسها.

منشور Google الأول عن الترويسات والضغط عام 2008

تشرح Google الضغط بصوتها منذ 2008. ففي منشورها عن Googlebot والترويسات والضغط كتب Maile Ohye وJeremy Lilley أن محركات البحث والمتصفحات الرئيسية تدعم gzip، وأنك قد ترى x-gzip، وهو gzip نفسه، وdeflate الذي تدعمه Google أيضًا، وidentity أي بلا ضغط. ويوضح المنشور أن Flash وJPG وPNG وGIF وPDF مضغوطة أصلًا، فلا تكسب كثيرًا من إعادة ضغطها، ويفضل gzip قليلًا على deflate للمتانة. يحمل المنشور تنبيهًا بأنه قديم، لكنه حي ومرتبط مباشرة بالموضوع.

تأكيد Gary Illyes لدعم Brotli عام 2020

أُكد دعم Googlebot لـBrotli بصورة غير رسمية قبل توثيقه. ففي أغسطس 2020 قال Gary Illyes، بعد اجتماع مع فريق Googlebot، إنه سُئل عن الدعم وإنه موجود. نقل Barry Schwartz الخبر يومها في Search Engine Roundtable. سبق ذلك الوثائق الحالية بنحو أربع سنوات.

وثائق الزاحف الرسمية الحالية

تقول نظرة عامة على زواحف Google: “Google’s crawlers and fetchers support the following content encodings (compressions): gzip, deflate, and Brotli (br).” (ترجمة) «تتعامل زواحف Google وأدوات الجلب مع ترميزات gzip وdeflate وBrotli ‏(br)». وتشرح أن كل هوية تعلن دعمها في Accept-Encoding لكل طلب، مثل Accept-Encoding: gzip, deflate, br. ويقول دليلي لدى Ahrefs: “Googlebot supports gzip, deflate, and Brotli (br).” (ترجمة) «يتعامل Googlebot مع gzip وdeflate وBrotli ‏(br)».

إذن التسلسل هو: منشور 2008 ← تأكيد Illyes عام 2020 ← وثائق الزاحف الحالية. الأمر راسخ وليس تخمينًا.

فجوة وثائق Bing

لا توجد وثيقة عامة من Bing تحدد ترميزات Bingbot عند زحف HTML، ولا مقابل لصفحة Google. ما يوثقه Bing أضيق: تدعم واجهة Content Submission ‏Gzip، ويمكن إرسال خرائط .xml.gz. وبما أن ضغط HTTP آلية معيارية تتفاوض عليها العملاء عبر Accept-Encoding، فمن المعقول استنتاج دعم Gzip على الأقل، لكنه استنتاج لا تصريح موثق. إنها فجوة شفافية لا حكم على سلوك Bingbot.

لماذا يهم الضغط للأداء وCore Web Vitals؟

السلسلة السببية بدقة

الضغط ليس عامل ترتيب مباشرًا. قد يقصر النقل الأصغر زمن التنزيل، فيساعد Time to First Byte ثم Largest Contentful Paint ضمن Core Web Vitals، وهي إشارة لتجربة الصفحة. لكن Google تضمن بايتات أقل لا تحسن TTFB أو LCP أو البحث؛ فإذا كان الاختناق في قاعدة بيانات أو نص يحظر العرض أو إعداد الاتصال فلن يغير ضغط رد صغير النتيجة. قِس الاختناق والنتيجة الميدانية. راجع Time to First Byte وLargest Contentful Paint وCore Web Vitals.

يقدم Martin Splitt إطارًا مفيدًا: المهم ما يعبر الشبكة بعد الضغط لا الحجم غير المضغوط على القرص؛ فقد تبدو الصفحة 10 MB لكنها تنقل خمسة أو ستة. نُقلت النقطة عبر Search Engine Journal لا نص أولي، لذا صيغت بالمعنى.

الضغط وكفاءة الزحف: الزاوية التي لا تحظى بما يكفي من الاهتمام

يساعد الضغط أيضًا على البقاء تحت حد الجلب لدى Google. وفق تحديث «Inside Googlebot» لعام 2026 بقلم Gary Illyes، يجلب Googlebot نحو 2 MB لكل عنوان HTML بدل الرقم الأقدم 15 MB، وما يتجاوز الحد يُقتطع ولا يُرفض؛ فلا يمر للفهرسة إلا الجزء المنزّل. ضغط HTML أداة لإبقاء المحتوى الحرج داخل الميزانية. راجع الزحف.

تدقيق Lighthouse لتفعيل ضغط النص: الحدود الدقيقة

لتدقيق PageSpeed Insights/Lighthouse قواعد دقيقة. يجمع الردود النصية التي لا تحمل content-encoding بقيمة br أوgzip أوdeflate، ثم يضغط كلًا منها بـGzip لتقدير الوفر. ولا يضع علامة إذا كان حجم الرد الأصلي أقل من 1,4 KiB أو كان الوفر المحتمل أقل من 10%. لذلك لا تطلق الملفات الأصغر من نحو 1,4 KiB التحذير ولو لم تُضغط. ومنذ Lighthouse 13 دُمج التدقيق في رؤية أوسع لزمن طلب المستند، لكن الإرشاد الأساسي لم يتغير.

لماذا قد يفشل موقع مضبوط بصورة صحيحة في التدقيق؟

توضح وثائق PageSpeed أن الخوادم الوكيلة وبرامج مكافحة الفيروسات قد تعطل الضغط عند تنزيل الملفات. لذلك قد يبلغ الفاحص نتيجة سلبية كاذبة رغم صحة الخادم، لأن وسيطًا أزال Content-Encoding أثناء النقل. اختبر عبر مسار شبكة نظيف قبل لوم الأداة أوالخادم.

الضغط الثابت مقابل الديناميكي: مفاضلات التنفيذ

مستويات الضغط

لكلا الخوارزميتين مستويات قابلة للضبط توازن زمن CPU مع نسبة الضغط:

• Gzip: المستويات 1–9.
• Brotli: المستويات 0، بلا ضغط، حتى 11، الحد الأقصى، وفق مختبر web.dev.

تضغط المستويات الأعلى بقوة أكبر، لكنها تستهلك زمن CPU أكثر.

كلفة CPU ولماذا يهم الفرق بين الثابت والديناميكي

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

• الملفات الثابتة المضغوطة مسبقًا أووقت البناء — يمكن للمحتوى المستقر أن يتحمل مستويات أعلى، لأن كلفة CPU تُدفع مرة عند البناء لا مع كل طلب. وتوثق gzip_static في nginx وmod_deflate في Apache اختيار ملف مضغوط مسبقًا. يصبح المقابل زمن بناء أطول لا تأخيرًا لكل زائر.
• الردود الديناميكية المتولدة لكل طلب — يضيف أعلى ضغط تأخيرًا لكل رد، لذا يكون المستوى المنخفض إلى المتوسط بداية شائعة؛ وتبدأ بعض الأدوات جودة Brotli عند نحو 4. لكنه رقم تختبره مقابل سعة CPU والحركة. وقد ذكرت Google منذ 2008 كلفة gzip/deflate على خادم مثقل يقدم محتوى ديناميكيًا.

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

كيفية تفعيل الضغط

هيئ الخادم أو CDN أو الحافة لضغط الردود النصية، واعرض Brotli مع Gzip بديلًا. بحسب المنصة:

• Apache — وحدة mod_deflate وmod_brotli لـBrotli.
• Nginx — وحدة ngx_http_gzip_module المضمنة، أي gzip on; مع gzip_types، ووحدة Brotli لـbr.
• IIS — ضغط HTTP المضمن للثابت والديناميكي.
• CDN / الحافة — توفر Cloudflare وFastly وأشباههما Brotli وGzip عادة، ويتيح Caddy ‏encode zstd gzip.
• أطر التطبيقات — وسيط compression في Node/Express، وتضغط Next.js/Vercel ومعظم الاستضافات الحديثة افتراضيًا.

ثم تحقق منه كما توضح قائمة الفحص. أسرع اختبار: curl -I -H "Accept-Encoding: br, gzip" https://example.com/، ثم ابحث عن ترويسة content-encoding في الرد.

ما الذي لا ينبغي ضغطه؟

لا تعِد ضغط JPG وPNG وGIF ومعظم الفيديو وخطوط WOFF2 ومعظم PDF. فهي مضغوطة داخليًا، وتشغيل Gzip أو Brotli عليها يهدر CPU لقاء تغير ضئيل، وربما سلبي. تعامل مع القائمة كأمثلة؛ تقول إرشادات GTmetrix إن الصيغ المضغوطة أو عالية الإنتروبيا قد لا تستفيد وقد تكبر. حدد الأنواع النصية وفق MIME، وقِس ناتج الرد بدل الثقة بقائمة امتدادات عامة.

ولا يوجد حد أدنى عالمي لحجم الرد لا يستحق الضغط تحته. قد تلغي كلفة التأطير والبيانات الوصفية الوفر في الأجسام الصغيرة أو الكثيفة، لكن نقطة التعادل تتوقف على المرماز والتنفيذ والترويسات والمحتوى. حدّا Lighthouse، أي 1,4 KiB و10%، قاعدة لذلك التدقيق تحديدًا لا حدًا عامًا، وقد تنشر CDN حدًا مختلفًا.

الضغط وBREACH: خطر محدود لا مبرر لتعطيل الضغط في الموقع كله

خطر BREACH ليس صفة للضغط في المجرد؛ تصف الدراسة هجومًا محددًا: رد HTTP مضغوط يمزج سرًا، مثل رمز CSRF، بمحتوى يستطيع المهاجم التأثير فيه وينعكس في الرد نفسه، ويستطيع المهاجم ملاحظة طول الرد عبر طلبات متكررة لاستنتاج السر. تلفت وثائق Apache ‏mod_deflate إلى التركيبة نفسها. إن لم يجمع الرد سرًا مع مدخل يعكسه المهاجم فلا ينطبق الهجوم الكلاسيكي. العلاج هو مراجعة الرد المعرّض ومنع عكس المدخل بجوار الأسرار أو إضافة رموز لكل طلب أو تقييد المعدل، لا تعطيل الضغط في الموقع كله.

خرافة خريطة الموقع: الضغط مسموح به صراحة

يسمح بروتوكول خرائط الموقع صراحة بخرائط مضغوطة بـgzip. الاعتقاد بعكس ذلك خطأ. يسمح بروتوكول sitemaps.org بملفات .xml.gz لتقليل النطاق، ويقبلها المحركان، كما تدعمها أدوات Bing. التحفظ أن تظل الخريطة غير المضغوطة ضمن 50 000 عنوان URL و50 MB. ضغطها أثناء النقل صحيح ومفيد للخرائط الكبيرة.

موضع الضغط ضمن أداء الويب

الضغط أداة ضمن المجموعة. يقلل البايتات التي ينزّلها مسار العرض الحرج، وقد يخفض TTFB ثم LCP، وهو تدقيق في PageSpeed Insights وLighthouse. ويتكامل مع التخزين المؤقت ومع الموارد الحاجبة للعرض. راجع أدوات أداء الويب.

ملخص الذكاء الاصطناعي

خلاصة مركزة للنسخة المتقدمة:

• الضغط هو ترميز محتوى HTTP، وهو غير ترميز النقل وفق RFC 9110، §8.4. يرسل العميل Accept-Encoding، الذي قد يحمل أوزان q وidentity، ويرد الخادم بـContent-Encoding، وتحتاج نسخ التخزين المختلفة إلى Vary: Accept-Encoding.
• ثلاثة مراميز: Gzip بديل عام؛ Brotli أصغر عادة وتفضله Google، لكن نسبة 15–20% تتغير؛ وZstd مسجل في RFC 9659 لكنه غير عام، ولا تذكر وثائق Google دعم Googlebot له.
• يدعم Googlebot ‏gzip وdeflate وBrotli ‏(br) وفق الوثائق الحالية وتأكيد 2020 ومنشور 2008. لا يملك Bing وثيقة مماثلة؛ دعم Gzip استنتاج من HTTP.
• ليس عامل ترتيب ولا ضمان سرعة. قد يساعد النقل الأصغر TTFB وLCP إذا كان النقل هو الاختناق، كما يساعد HTML على البقاء تحت حد جلب Googlebot البالغ نحو 2 MB في 2026؛ وما يتجاوزه يُقتطع.
• يتجاوز Lighthouse الملفات دون 1,4 KiB أوذات وفر دون 10%؛ هذه قاعدة التدقيق. وقد تزيل الوكلاء وبرامج الحماية Content-Encoding فتنتج نتيجة سلبية كاذبة.
• المستويات: Gzip ‏1–9 وBrotli ‏0–11. استخدم أعلى للثابت المضغوط مسبقًا، وأدنى إلى متوسط للديناميكي، واختبر حركتك.
• قرر وفق MIME والقياس؛ الصور والفيديو وWOFF2 ومعظم PDF مضغوطة أصلًا.
• خطر BREACH محدود برد يمزج سرًا بمحتوى يعكسه مهاجم مع طول مرصود تكرارًا؛ أصلح السياق ولا تعطل الضغط كله.
• اختبر Vary: Accept-Encoding ومنع الضغط المزدوج، وعامل ETag وContent-Length والنطاق وفق الترميز المختار.
• يسمح بروتوكول خرائط الموقع صراحة بخرائط gzip ‏(.xml.gz) مع بقاء حدود الحجم غير المضغوط.

الوثائق الرسمية

وثائق المصادر الأولية عن الضغط وترميز المحتوى.

Google

• تفعيل ضغط النص في Lighthouse — حدود التدقيق وتفاوض Accept-Encoding وتفضيل Brotli مع Gzip بديلًا.
• تصغير حمولات الشبكة وضغطها باستخدام Brotli — مستويات 0–11 ومفاضلات الثابت والديناميكي ومثال قبل وبعد.
• تفعيل الضغط في PageSpeed Insights — سقف 90% ووحدات الخوادم وتحذير النتيجة السلبية الكاذبة.
• نظرة عامة على زواحف Google — دعم gzip وdeflate وBrotli ‏(br) والإعلان عبر Accept-Encoding.
• منشور Googlebot عن الترويسات والضغط لعام 2008 — شرح gzip وdeflate والصيغ التي لا تستفيد.

المعايير والبروتوكولات

• RFC 9110: دلالات HTTP — ترميز المحتوى، وأوزان q وidentity، ومتطلب Vary.
• RFC 9659: ‏Zstandard بوصفه ترميز محتوى HTTP — تحديث RFC 8878 ونافذة 8 MB والتمييز عن dcz.
• سجل IANA لترميزات المحتوى — الرموز الرسمية zstd وgzip وbr، مع عدم مساواة التسجيل بالدعم العام.
• وثائق Apache ‏mod_deflate — Vary: Accept-Encoding ومنع الضغط المزدوج وDeflateAlterETag وBREACH.
• ضغط المحتوى في Cloudflare — التحويل والحد الأدنى للحجم واختيار المرماز.
• وحدة gzip الثابتة في nginx — توثيق ngx_http_gzip_static_module لتقديم الملفات المضغوطة مسبقًا.
• بروتوكول خرائط الموقع — السماح بملفات gzip وحدود الحجم غير المضغوط.

الأمان

• بحث BREACH الأصلي — شروط الهجوم: رد مضغوط يمزج سرًا بمحتوى متأثر بالمهاجم، مع قياس متكرر للطول.

Bing / Microsoft

• لا تحدد وثيقة مخصصة دعم Bingbot لترميز زحف HTML. تؤكد مساعدة الإرسال دعم خرائط gzip وGzip في Content Submission API؛ راجع مساعدة Bing Webmaster Tools. تعامل مع دعم الزاحف بوصفه استنتاجًا من HTTP.

اقتباسات من المصدر

إفادات مسجلة من Google. ينقل كل رابط يحوي #:~:text= إلى العبارة المقتبسة في صفحة المصدر.

Google — تدقيق Lighthouse لتفعيل ضغط النص

• “When a browser requests a resource, it will use the Accept-Encoding HTTP request header to indicate what compression algorithms it supports.” (ترجمة) «عندما يطلب المتصفح موردًا، يستخدم ترويسة Accept-Encoding لبيان خوارزميات الضغط التي يدعمها». انتقل إلى الاقتباس
• “If the browser supports Brotli (br) you should use Brotli because it can reduce the file size of the resources more than the other compression algorithms.” (ترجمة) «إذا دعم المتصفح Brotli فينبغي استخدامه لأنه قد يقلل حجم الموارد أكثر». انتقل إلى الاقتباس
• “The potential savings that Lighthouse lists are the potential savings when the response is encoded with GZIP. If Brotli is used, even more savings are possible.” (ترجمة) «التوفير الذي يسرده Lighthouse محسوب عند استخدام GZIP، وقد يحقق Brotli توفيرًا أكبر». انتقل إلى الاقتباس
• “If the original size of a response is less than 1,4KiB, or if the potential compression savings is less than 10% of the original size, then Lighthouse does not flag that response in the results.” (ترجمة) «إذا كان حجم الرد دون 1,4 KiB أو كان الوفر دون 10%، فلا يضع Lighthouse علامة عليه». انتقل إلى الاقتباس
• “As of December 2022 Brotli is supported in all major browsers except Safari on iOS.” (ترجمة) «في ديسمبر 2022 كان Brotli مدعومًا في كل المتصفحات الرئيسية عدا Safari على iOS». … “Use GZIP as a fallback to Brotli. GZIP is supported in all major browsers, but is less efficient than Brotli.” (ترجمة) «استخدم GZIP بديلًا لـBrotli؛ تدعمه كل المتصفحات الرئيسية لكنه أقل كفاءة». انتقل إلى الاقتباس

Google — ‏PageSpeed Insights لتفعيل الضغط

• “Enabling gzip compression can reduce the size of the transferred response by up to 90%.” (ترجمة) «قد يقلل تفعيل gzip حجم الرد المنقول بنسبة تصل إلى 90%». انتقل إلى الاقتباس
• “Proxy servers and anti-virus software can disable compression when files are downloaded to a client machine.” (ترجمة) «قد تعطل الخوادم الوكيلة وبرامج الحماية الضغط عند التنزيل». انتقل إلى الاقتباس

Google — نظرة عامة على الزاحف وهوية المستخدم

• “Google’s crawlers and fetchers support the following content encodings (compressions): gzip, deflate, and Brotli (br).” (ترجمة) «تدعم زواحف Google وأدوات الجلب gzip وdeflate وBrotli ‏(br)». انتقل إلى الاقتباس
• “The content encodings supported by each Google user agent is advertised in the Accept-Encoding header of each request they make. For example, Accept-Encoding: gzip, deflate, br.” (ترجمة) «تعلن كل هوية مستخدم الترميزات المدعومة في Accept-Encoding لكل طلب». انتقل إلى الاقتباس

Gary Illyes، ‏Google — تأكيد Brotli ‏(2020)

• أكد Illyes، بعد اجتماع مع فريق Googlebot، دعم Googlebot لضغط Brotli. نُشر على X في أغسطس 2020 ونقله Barry Schwartz. هذه صياغة بالمعنى. اقرأ التغطية

أي إعداد ضغط ينبغي أن أستخدم؟

ابدأ بما تقدمه ومكان تقديمه، لا بسؤال «Gzip أم Brotli؟»؛ ففي الواقع تقدم كليهما غالبًا.

س1. هل يستطيع خادمك أو CDN تقديم Brotli مع Gzip بديلًا؟

• نعم ← فعّل Brotli + Gzip. يختار التفاوض Brotli لمن يعلن br وGzip للباقين. تابع إلى س2.
• لا ← فعّل Gzip وحده حاليًا. يدعمه الجميع ويحقق معظم المكسب، ثم أضف Brotli عندما تستطيع.

س2. هل الملف ثابت أم متولد لكل طلب؟

• ثابت، مثل CSS/JS وHTML المبني وخرائط الموقع ← اضغطه مسبقًا بمستوى أعلى، حتى Gzip 9 أو Brotli 11، بعد الاختبار. تُدفع كلفة CPU مرة.
• ديناميكي، مثل HTML من تطبيق أو CMS ← استخدم مستوى منخفضًا إلى متوسط؛ وجودة Brotli نحو 4 نقطة بدء شائعة. يتوقف الاختيار على الحركة وسعة CPU.

س3. هل الملف ثنائي مضغوط أصلًا؟ مثل JPG وPNG وGIF والفيديو وWOFF2 ومعظم PDF.

• نعم ← لا تضغطه. لن يصغر وستُهدر CPU وربما يكبر قليلًا. اقصر القواعد على MIME النصي.
• لا، مثل HTML وCSS وJS وJSON وSVG وXML ← اضغطه.

س4. ما زال PageSpeed يطلب تفعيل ضغط النص بعد التفعيل.

• هل الملف دون 1,4 KiB أويوفر أقل من 10%؟ ← لا يضع Lighthouse علامة على هذه الملفات أصلًا.
• هل يعرض curl -I -H "Accept-Encoding: br, gzip" ترويسة content-encoding؟ ← الخادم سليم غالبًا، ووسيط في مسار الاختبار أزالها. أعد الاختبار على شبكة نظيفة.
• لا توجد content-encoding ← الرد غير مضغوط فعلًا؛ راجع نطاق MIME وإعداد الوحدة.

إعداد الضغط والتحقق منه: قائمة فحص

مراجعة للتأكد من ضغط النص، وتفضيل Brotli، وعدم ضغط أي شيء مرتين:

• Brotli مفعّل مع Gzip بديلًا — يعلن الخادم br ويقدم Gzip لغير الداعمين.
• الضغط مقصور على MIME النصي — HTML وCSS وJS وJSON وSVG وXML، مع استبعاد الصور والفيديو وWOFF2 ومعظم PDF.
• الملفات الثابتة مضغوطة مسبقًا بمستوى أعلى، حتى Gzip 9 أو Brotli 11، بعد الاختبار.
• الردود الديناميكية تستخدم مستوى منخفضًا إلى متوسط لموازنة CPU والتأخير.
• Vary: Accept-Encoding موجودة في الردود القابلة للتخزين التي تختلف حسب الترميز.
• لا يوجد ضغط مزدوج عبر الوكيل أو CDN أو الأصل، وتطابق Content-Length المتن الفعلي.
• تم التحقق من سطر الأوامر: يعيد curl -I -H "Accept-Encoding: br, gzip" https://example.com/ ترويسة content-encoding: br أوgzip.
• تم التحقق في DevTools — حجم transferred أقل من resource للردود النصية.
• PageSpeed Insights / Lighthouse — لا يظهر طلب تفعيل ضغط النص للردود فوق نحو 1,4 KiB.
• استُبعدت النتيجة السلبية الكاذبة — إن عرض curl ‏content-encoding فاشتبِه في وسيط يزيلها.
• خرائط الموقع — تُقدم الخرائط الكبيرة .xml.gz، مع بقاء غير المضغوط ضمن 50 000 عنوان و50 MB.
• التصغير منفذ أيضًا — نفّذ التصغير والضغط معًا.

ورقة غش للضغط

المراميز الثلاثة

مستويات الضغط

ما الذي تضغطه وما الذي تتجاوزه؟

حقائق سريعة

• يدعم Googlebot ‏gzip وdeflate وBrotli ‏(br) عبر Accept-Encoding، ولم يتأكد Zstd.
• تذكر Google سقف توفير Gzip حتى نحو 90%؛ إنه سقف لا رقمًا نموذجيًا.
• لا يبلغ Lighthouse عن ملف أصغر من 1,4 KiB أوعن فرصة خفض دون 10%؛ فذلك سلوك هذا التدقيق وحده.
• يساعد الضغط HTML على البقاء دون حد جلب Googlebot البالغ نحو 2 MB في 2026؛ وما يتجاوزه يُقتطع.
• تحتاج نسخ التخزين المختلفة إلى Vary: Accept-Encoding.
• يقتصر BREACH على رد يجمع سرًا بمحتوى يعكسه مهاجم.
• يسمح بروتوكول خرائط الموقع بـgzip ‏(.xml.gz).
• تحقق عبر curl -I -H "Accept-Encoding: br, gzip" <url> وابحث عن content-encoding وvary.

خرافات الضغط وأخطاؤه

أبرز الأفكار المتكررة التي ينبغي التخلص منها:

• «تفعيل الضغط سيرفع ترتيبي». ليس عامل ترتيب؛ فعّله للسرعة.
• «Google لا يدعم Brotli». معلومة قديمة؛ تؤكد وثائق الزاحف الدعم.
• «ضغط الصور والخطوط والفيديو يسرع الموقع». هي مضغوطة أصلًا، وإعادة ضغطها تهدر CPU.
• «تقرير PageSpeed معطوب». قد تزيل الوكلاء أوبرامج الحماية Content-Encoding؛ اختبر بـcurl.
• «الضغط والتصغير شيء واحد». مرحلتان مختلفتان؛ نفّذ الاثنين.
• «أعلى مستوى هو الأفضل دائمًا». المستويات القصوى تكلف CPU لكل طلب؛ خصصها للثابت.
• «لا يجوز gzip لخريطة الموقع». خطأ؛ يسمح البروتوكول بملفات .xml.gz ضمن حدود غير المضغوط.

تحقق من الضغط المتفاوض عليه من سطر الأوامر

شغّل الأوامر على macOS أو Linux. يعلن --compressed الترميزات المدعومة ويفك المتن للعرض، بينما تظل الترويسات مبينة لما انتقل عبر الشبكة.

curl -sS --compressed -D - -o /dev/null https://example.com/app.js
curl -sS -H 'Accept-Encoding: br' -D - -o /dev/null https://example.com/app.js
curl -sS -H 'Accept-Encoding: gzip' -D - -o /dev/null https://example.com/app.js
curl -sS -H 'Accept-Encoding: identity' -D - -o /dev/null https://example.com/app.js

ينبغي أن يتضمن المورد القابل للتخزين Content-Encoding ملائمًا وترويسة Vary: Accept-Encoding. افحصها خلف مخزن مشترك أو CDN، لأن غيابها يسمح بتقديم نسخة لا يستطيع عميل فكها.

في Windows PowerShell اطلب كل ترميز وافحص الترويسات:

$headers = @{ "Accept-Encoding" = "br, gzip" }
$r = Invoke-WebRequest -Uri "https://example.com/app.js" -Headers $headers
$r.Headers | Select-Object Content-Encoding, Vary, Content-Length

اعثر على موارد النص من الأصل نفسه غير المضغوطة في DevTools

ألصق الشيفرة في Console بعد التحميل. تستخدم أحجام Resource Timing لقائمة أولية؛ تحقق من كل رد في Network لأن العناصر المخزنة والمصادر الأخرى قد تحذف الأحجام.

performance.getEntriesByType('resource')
  .filter((r) => r.transferSize > 0 && r.encodedBodySize === r.decodedBodySize)
  .map((r) => ({ url: r.name, bytes: r.transferSize }));

استخرج ترويسات الضغط في زاحف

استخدم XPath في سير يدرك ترويسات الرد فقط عندما يخزن الزاحف الترويسات منفصلة. في HTML العادي يكون الضغط ترويسة HTTP ولا يمكن استخراجه من DOM؛ لا يستطيع XPath وحده إثبات ترميز النقل.

أدوات اختبار ضغط HTTP

• Network في Chrome DevTools — افحص Content-Encoding والحجم المنقول ونوع المورد وتغيير CDN للرد.
• curl --compressed — اختبر التفاوض وقارن Brotli وGzip وidentity.
• PageSpeed Insights / Lighthouse — اعثر على موارد النص غير المضغوطة ذات الوفر الكافي.
• WebPageTest — قارن أحجام النقل وشلالات الطلبات ضمن شروط ثابتة.
• إعدادات وسجلات CDN أوالخادم — أكد المرماز والمستوى للثابت والديناميكي.

أثبت أن الضغط مضبوط بصورة صحيحة

اختبار تفاوض الترميز

الاختبار: اطلب موردًا بـAccept-Encoding: br ثم gzip ثم identity. المتوقع: Content-Encoding مطابق، وidentity قابلة للفك، والنسخ تحمل Vary. تفسير الفشل: خطأ في التفاوض أو التخزين أو إعداد الأصل وCDN. المراقبة: فور الانتشار. التراجع: أجسام تالفة أو نسخة بترميز خاطئ.

اختبار نطاق الموارد

الاختبار: خذ عينات من النصوص والصور والفيديو والخطوط. المتوقع: تُضغط النصوص ولا يعاد ضغط الصيغ عديمة المكسب. تفسير الفشل: قائمة MIME ناقصة أوواسعة. المراقبة: فورًا. التراجع: زيادة النقل أو CPU أوتعطل الملفات.

اختبار تراجع الأداء

الاختبار: قارن WebPageTest/Lighthouse وCPU قبل الضغط الديناميكي وبعده. المتوقع: تنخفض بايتات النص بلا تراجع ثابت في TTFB أوالأخطاء. تفسير الفشل: المرماز أوالمستوى مكلف، أو الضغط في الطبقة الخطأ. المراقبة: المختبر والإنتاج. التراجع: تأخير مستمر أوتشبع CPU أوارتفاع الأخطاء.

اختبار نسخة المخزن المؤقت (Vary)

الاختبار: اطلب ردًا قابلًا للتخزين بـbr ثم gzip ثم identity عبر CDN نفسه. المتوقع: كل نسخة بالترميز المطلوب ومع Vary: Accept-Encoding وفق RFC 9110، §12.5.5. تفسير الفشل: يقدم المخزن نسخة لعميل لا يفكها. المراقبة: بعد تغيير CDN. التراجع: جسم غير مدعوم أوانهيار الإصابات.

اختبار التحويل المزدوج والبيانات الوصفية القديمة

الاختبار: تتبع الرد عبر الوكيل وCDN والأصل لتأكيد الضغط مرة واحدة. المتوقع: تسمي Content-Encoding ترميزًا واحدًا وتطابق Content-Length المتن بلا طول قديم. تفسير الفشل: فك وسيط الرد وأعاد ضغطه بلا تحديث؛ تحذر وثائق Apache ‏mod_deflate وCloudflare من ذلك. المراقبة: بعد تغيير طبقة التحويل. التراجع: تنزيل تالف أو طول غير مطابق أو متن مضغوط مرتين.

اختبار أدوات التحقق وطلبات النطاق

الاختبار: اطلب المورد بـidentity وgzip وbr، وقارن ETag وContent-Length وRange. المتوقع: لكل تمثيل أداة تحقق وطول ونطاق صحيحان. تفسير الفشل: افتراض تمثيل واحد يعطل الطلبات الشرطية أونطاقات البايت. المراقبة: فورًا وبعد التغيير. التراجع: إعادة If-None-Match أوالنطاق أجسامًا خاطئة.

اختبر نفسك: الضغط

خمسة أسئلة سريعة عن عمل ضغط نص HTTP وما تدعمه Google. اختر إجابة لكل سؤال ثم تحقق منها.

سجل التغييرات