🧡 👃🏿 🔀 كفاءة بروتلي في العالم الحقيقي 🧑🏿‍🤝‍🧑🏻 🌼 👩🏻‍🏫

من أهم القواعد الأساسية لتطوير مواقع الويب السريعة تحسين مواردها. إذا كنا نتحدث عن الموارد النصية - حول التعليمات البرمجية المكتوبة بلغة HTML و CSS و JavaScript ، فهذا يعني أننا نتحدث عن ضغط البيانات. المعيار الفعلي لضغط موارد النص على الويب هو طريقة Gzip. وبالتحديد ، يتم ضغط حوالي 80٪ من الموارد المضغوطة التي يتم الحصول عليها أثناء تنزيلات الموقع باستخدام Gzip. لضغط الـ 20٪ المتبقية من الموارد ، يتم استخدام خوارزمية أحدث بكثير - Brotli.

بالطبع ، فإن 100٪ من الموارد المضغوطة التي تأتي إلى المتصفحات عندما يتلقون إجابات لطلبات المواقع لا تتضمن جميع الموارد على الإطلاق. لا يزال هناك العديد من الموارد التي يمكن ضغطها أو يمكن ضغطها. لكن هذه الموارد تظل غير مضغوطة. يمكن العثور على مقاييس أكثر تفصيلاً بشأن الضغط في قسم الضغط في مورد Web Almanac.

طريقة ضغط gzip فعالة بشكل لا يصدق. يأخذ كل عمل شكسبير في نص عادي 5.3 ميغابايت. وبعد ضغط Gzip (مستوى الضغط 6) يشغلون 1.9 ميغابايت فقط. وهذا يعني أن حجم الملف الذي يتم تخزين هذه البيانات فيه قد انخفض بمقدار 2.8 مرة. في نفس الوقت ، لا يتم فقدان البيانات أثناء الضغط. عظيم!

والأفضل من ذلك ، تتأثر درجة ضغط Gzip بوجود خطوط مكررة في الملفات. لمزيد من التكرار في النص ، كلما زاد الضغط. هذا جيد جدًا للويب ، نظرًا لأن الشفرة المكتوبة بلغة HTML و CSS و JS لها بنية موحدة وتحتوي على العديد من التكرارات.

ولكن ، على الرغم من أن Gzip هي طريقة ضغط فعالة للغاية ، إلا أنها قديمة جدًا. ظهر في عام 1992 (والذي بالطبع يساعد في تفسير انتشاره على نطاق واسع). بعد 21 عامًا ، في عام 2013 ، أصدرت Google Brotli ، خوارزمية جديدة تعد بمستويات ضغط أعلى من تلك التي تستطيع طريقة Gzip تحقيقها. يتم ضغط نفس أعمال شكسبير بحجم 5.2 ميجابايت باستخدام Brotli إلى حجم 1.7 ميجابايت (مع مستوى ضغط يبلغ 6). وهذا يعني بالفعل تقليل حجم الملف 3.1 أضعاف. هذا أفضل من استخدام Gzip.

باستخدام أداة لتقييم مستوى ضغط البيانات باستخدام Gzip و Brotli ، من المحتمل أن تكتشف أنه عند ضغط بعض البيانات ، يكون Brotli أكثر كفاءة من Gzip. على سبيل المثال ، تكون بيانات ReactDOM أصغر بنسبة 27٪ عند ضغطها باستخدام Brotli مع أقصى مستوى ضغط (11) عن استخدام Gzip بحد أقصى لضغط (9).

هنا مقارنة ضغط Brotli مع ضغط Gzip عند معالجة ReactDOM.

مستوى الضغط	الحجم (بالبايت)	كفاءة الضغط (مقارنة بالبيانات غير المضغوطة)	تحسن على Gzip
1	43456	2.73	3٪
2	39898	2.97	أحد عشر٪
3	39416	3.08	خمسة عشر٪
4	38488	3.08	خمسة عشر٪
5	36323	3.27	تسعة عشر٪
6	36048	3.29	عشرين٪
7	35804	3.31	عشرين٪
8	35709	3.32	21٪
9	35659	3.33	21٪
10	33590	3.53	25٪
أحد عشر	33036	3.59	27٪

كما ترى ، في جميع مستويات الضغط يتجاوز Brotli Gzip. عند الحد الأقصى لمستوى الضغط المتاح مع Brotli ، فهو أكثر كفاءة بنسبة 27٪ من Gzip.

وبناءً على الملاحظة الشخصية ، ألاحظ أن انتقال أحد عملائي من Gzip إلى Brotli أدى إلى انخفاض متوسط في حجم الملفات بنسبة 31٪.

ونتيجة لذلك ، على مدى السنوات القليلة الماضية ، قمت ، إلى جانب خبراء الأداء الآخرين ، بتشجيع العملاء على التحول من Gzip إلى Brotli.

سأقول بضع كلمات حول دعم المتصفح لـ Gzip و Brotli. Gzip واسع الانتشار لدرجة أن CanIUse لا يعرض حتى جدولًا يحتوي على معلومات الدعم. تقول ذلك: "رأس HTTP هذا مدعوم في جميع المتصفحات تقريبًا (بدءًا من IE6 + و Firefox 2+ و Chrome 1+ وما إلى ذلك)." و Brotli ، أثناء كتابة هذه المواد ، يتمتع بمستوى طيب للغاية من الدعم.بنسبة 93.17٪. وهذا كثير جداً! وبالتالي ، إذا كان موقعك يحتوي على بعض الحجم الكبير على الأقل ، فقد لا ترغب بشكل خاص في عودة الموارد غير المضغوطة إلى أكثر من 6٪ من المستخدمين. لكن باستخدام Brotli ، لن تخسر أي شيء. يستخدم العملاء نموذجًا تدريجيًا لدعم الخوارزميات الجديدة ، لذا فإن المستخدمين الذين لا يمكنهم قبول موارد Brotli سيستخدمون ببساطة الخيار الاحتياطي في شكل Gzip. سنتحدث أكثر عن هذا أدناه.

بشكل عام ، خاصة إذا كنت تستخدم CDN ، فإن تشغيل Brotli هو مسألة ثوان. على الأقل هذا هو الحال مع Cloudflare ، الخدمة التي أستخدمها لموقع CSS Wizardry. ومع ذلك ، فإن العديد من عملائي ، إذا تحدثنا عن العامين الماضيين ، ليسوا ناجحين للغاية. البعض منهم يدعم بنيته التحتية الخاصة به ، وتظهر الممارسة أن تثبيت Brotli ونشره ليس بهذه البساطة. يستخدم البعض خدمات CDN التي لا تختلف في القدرات التي يمكن الوصول إليها بسهولة لدعم الخوارزمية الجديدة.

في تلك الحالات عندما لم نتمكن من التحول إلى Brotli ، كان لدينا دائمًا سؤال دون إجابة: "ماذا لو ...". ونتيجة لذلك ، قررت أخيرًا تسليح نفسي بالأرقام وإعطاء إجابة على سؤال ما الذي يمنح الموقع الانتقال إلى Brotli.

القليل ليس بالضرورة أسرع.

عادةً ما يعني "أقل" "أسرع". كقاعدة ، إذا قمت بتقليل حجم الملف ، فسيتم نقله بشكل أسرع من الخادم إلى العميل. ولكن إذا قمت بإنشاء ملف ، على سبيل المثال ، أصغر بنسبة 20٪ ، فهذا لا يعني أنه سيصل أسرع بنسبة 20٪. النقطة هنا هي أن حجم الملف هو مجرد جانب واحد من أداء الويب. ومهما كان حجم الملف ، فإن المورد الذي يتم تسليمه إلى المتصفح مرتبط بالعديد من العوامل الأخرى ومع العديد من قيود النظام - تأخيرات الشبكة وفقدان الحزم وما شابه. بمعنى آخر ، يساعد الحفظ على حجم الملف على نقل البيانات نفسها كما كان من قبل ، وإرسال عدد أقل من الحزم ، ولكن نقل البيانات بين الخادم والعميل محدود بسبب تأخيرات الشبكة ، ونتيجة لذلك ، لن تتغير سرعة وصول الحزم إلى العميل.

TCP والحزم وتأخير ذهابا وإيابا

إذا كان من السهل جدًا التفكير في نقل الملفات من الخادم إلى العميل ، فسنضطر إلى إلقاء نظرة على بروتوكول TCP. عندما نتلقى ملفًا من الخادم ، لا يأتي إلينا دفعة واحدة. يقوم بروتوكول TCP ، الذي يعمل HTTP عليه ، بتقسيم الملفات إلى مقاطع تسمى الحزم. يتم إرسال هذه الحزم إلى العميل بالترتيب وبالتسلسل. يؤكد العميل استلام كل حزمة في السلسلة قبل البدء في نقل السلسلة التالية. يحدث هذا حتى يجمع العميل جميع الحزم الضرورية ، حتى لا توجد حزم غير مرسلة على الخادم ، وحتى يتمكن العميل من جمع الحزم في شيء يمكن التعرف عليه كملف. لكي تكتمل جلسة نقل تسلسل الحزم بنجاح ، يجب أن يرسلها الخادم إلى العميل ، ويجب أن يقر العميل باستلامها. زمن،يُطلق على كمية البيانات المطلوبة لاستلام البيانات وتلقي تأكيد الاستلام وقت الرحلة المستديرة (RTT).

لا يمكن لكل اتصال TCP جديد معرفة ماهية النطاق الترددي المتاح ، ومدى موثوقية الاتصال (أي مستوى فقدان الحزمة). إذا حاول الخادم إرسال ميغا بايت من البيانات عبر اتصال يدعم معدل نقل بيانات واحد ميغا بت في الثانية ، فإن هذا النقل سوف يطغى على الاتصال ويؤدي إلى زيادة تحميل قناة الاتصال. والعكس صحيح - إذا حاول الخادم نقل كمية صغيرة من البيانات من خلال اتصال سريع جدًا ، فسيتم استخدام الاتصال بشكل غير فعال ، سيكون خاملاً.

من أجل حل هذا اللغز ، يستخدم TCP آلية تسمى البداية البطيئة. هذا جزء من استراتيجية إدارة نافذة التحميل الزائد. كل اتصال TCP جديد محدود بالقدرة على إرسال 10 حزم بيانات فقط في التسلسل الأول للحزم (10 حزم - حجم نافذة الازدحام الأولية). عشرة مقاطع TCP هي حوالي 14 كيلوبايت من البيانات. إذا تلقى العميل هذه الحزم بنجاح ، فستحتوي السلسلة الثانية بالفعل على 20 حزمة ، ثم سيكون هناك 40 و 80 و 160 وما إلى ذلك. سيستمر النمو الأسي للحزم بالتسلسل حتى يحدث أحد الأحداث التالية:

سيواجه النظام فقدان الحزم. عند هذه النقطة ، سيقلل الخادم من عدد الحزم في التسلسل التالي ، ويقسم عدد الحزم السابقة على 2 ، ويحاول نقل البيانات مرة أخرى.
لقد وصلنا إلى حد النطاق الترددي المتاح ويمكن استخدامه بكامل طاقته.

تتيح لك هذه الاستراتيجية البسيطة والأنيقة التوازن على حافة الحذر والتفاؤل. ينطبق على كل اتصال TCP جديد أنشأه تطبيق الويب.

بكلمات بسيطة ، الحجم الأولي لنافذة الازدحام لاتصال TCP الجديد هو حوالي 14 كيلوبايت فقط. أو حوالي 11.8٪ من بيانات ReactDOM غير المضغوطة. يتم ضغط 36.94٪ من البيانات باستخدام Gzip ، أو 42.38٪ من البيانات المضغوطة باستخدام Brotli (عند أقصى مستوى ضغط).

ثم سنتباطأ. إن الانتقال من 11.8٪ إلى 36.94٪ يعد تحسنًا ملحوظًا بالفعل! لكن الانتقال من 36.94٪ إلى 42.38٪ - وهذا أبعد ما يكون عن الإعجاب. ماذا يحدث؟

رقم جلسة البيانات	كمية البيانات المنقولة في جلسة واحدة كيلوبايت	المبلغ التراكمي للبيانات المنقولة ، كيلوبايت	التسلسل الذي يتم فيه نقل بيانات ReactDOM
1	14	14
2	28	42	Gzip (37.904 كيلو بايت) ، Brotli (33.036 كيلو بايت)
3	56	98
4	112	210	خيار غير مضغوط (118.656 كيلو بايت)
5	224	434

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

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

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

تجدر الإشارة إلى أن النموذج أعلاه مبسط تمامًا. هناك عوامل أخرى كثيرة للنظر فيها. على سبيل المثال - هل هو اتصال TCP جديد أم مفتوح بالفعل؟ هل يتم استخدام الاتصال لشيء آخر؟ هل تتوقف آليات تحديد أولويات حركة مرور الخادم وبدء نقل البيانات؟ هل تيارات H / 2 لها وصول حصري إلى عرض النطاق الترددي؟ هذا القسم هو دراسة أكثر جدية. يجب اعتباره نقطة انطلاق جيدة لبحثك الخاص. ولكن ضع في اعتبارك التحليل الشامل للبيانات باستخدام شيء مثل Wireshark ، واقرأ هذه المادة ، التي توفر وصفًا أعمق لـ "السحر" الأول 14 كيلوبايت.

ينطبق ما سبق فقط على اتصالات TCP الجديدة تمامًا. لن تمر الملفات المنقولة عبر اتصال موجود من خلال إجراء البدء البطيء. هذا يقودنا إلى استنتاجين مهمين:

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

	, ,	,
1	14	14
2	28	42
3	56	98
4	112	210
5	224	434
6	448	882
7	896	1778
8	1792	3570
9	3584	7154
10	7168	14322
…	…	…
20	7340032	14680050

في نهاية الجلسة العاشرة لنقل البيانات ، يبلغ حجم البيانات المنقولة في جلسة واحدة 7168 كيلوبايت ، في حين تم نقل 14322 كيلوبايت من البيانات بالفعل. هذا أكثر من كافٍ للعمل العادي على الإنترنت (أي ليس لعرض لعبة العروش). في الواقع ، يحدث عادةً أننا نقوم بتحميل صفحة الويب بالكامل وجميع مواردها دون الوصول إلى حد النطاق الترددي. بمعنى آخر ، لن يؤدي استخدام قناة اتصال من الألياف الضوئية بسرعة 1 جيجابت / ثانية (أي 0.125 جيجابايت / ثانية) إلى حقيقة أن التصفح العادي سيبدو أسرع بكثير من استخدام اتصال أبطأ ، لأن معظم هذه القناة لا سوف يستخدم.

وبحلول الجلسة العشرين لنقل البيانات ، ننقل نظريًا 7.34 غيغابايت من البيانات في تسلسل واحد من الحزم.

ماذا عن العالم الحقيقي؟

حتى الآن ، انخرطنا في الاعتبارات النظرية. وبدأت العمل على هذه المواد لأنني أود أن أعرف التأثير الذي يمكن أن يكون لـ Brotli على المواقع الحقيقية.

حتى الآن ، تشير الأرقام الواردة هنا إلى الاختلاف الكبير بين نقص الضغط واستخدام Gzip ، وحقيقة أن المكسب من استخدام Brotli ، مقارنة بـ Gzip ، متواضع تمامًا. هذا يخبرنا أن الانتقال من نقص الضغط إلى استخدام Gzip سيعطي تحسنًا ملحوظًا ، ولكن ربما يبدو الانتقال من Gzip إلى Brotli أقل إثارة للإعجاب.

لقد اخترت ، على سبيل المثال ، عدة مواقع ، مسترشدة بالاعتبارات التالية:

يجب أن يكون الموقع معروفًا نسبيًا (من الأفضل استخدام المواقع التي يمكن مقارنتها بشيء ما).
يجب أن يكون الموقع مناسبًا للاختبار. هذا - يجب أن يكون بحجم مناسب (لذا سيكون من المثير للاهتمام تحليل مواده للضغط) ، وفي الوقت نفسه يجب ألا يحتوي بشكل أساسي على مواد غير مضغوطة باستخدام Gzip / Brotli - على سبيل المثال ، YouTube.
لا يجب أن تنتمي جميع المواقع من المجموعة إلى شركات كبيرة (من الجدير تحليل بعض المواقع ، دعنا نقول ، "عادية").

نظرًا لهذه المتطلبات ، اخترت المواقع المدرجة أدناه وبدأت في الاختبار. إليك المواقع التي اخترتها:

لم أرغب في تعقيد الاختبارات ، لذلك استقرت على المؤشرات التالية:

كمية البيانات المنقولة.
وقت الدهان الأول (FCP).

تم تحليلها في المواقف التالية:

عدم وجود ضغط.
باستخدام gzip.
باستخدام brotli.

يبدو مقياس FCP قريبًا من العالم الحقيقي وعالميًا بما يكفي لتطبيقه على أي موقع ، نظرًا لأنه يسمح لك بتقييم ما يحتاجه الأشخاص من مواقع الويب - أي محتويات هذه المواقع. بالإضافة إلى ذلك ، اخترت هذا المقياس لأن بول كالفانو ، شخص ذكي ، قال هذا: "التجربة تخبرني أن استخدام Brotli يؤدي إلى تحسين FCP ، خاصة في الحالات التي تكون فيها موارد CSS / JS الهامة كبيرة" .

اختبارات

سأخبرك بسر قذر. لا تستند العديد من الدراسات حول أداء الويب (ليس جميعها ، ولكن الكثير منها) على البحث في تحسينات الأداء ، ولكن على استخلاص استنتاجات من العكس - من تدهور الأداء. على سبيل المثال ، من الأسهل بكثير أن تدعي هيئة الإذاعة البريطانية "أنها تفقد 10٪ من المستخدمين في كل ثانية إضافية يحتاجون إليها لتحميل موقعهم" بدلاً من معرفة ما يحدث بفضل تحسن مدته ثانية واحدة. من الأسهل بكثير إبطاء الموقع بدلاً من تسريعه ، وتشعر أن هذا هو السبب في أن العديد من الأشخاص يقومون بهذه المهمة بشكل جيد.

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

على الرغم من أنني لا أستطيع ، على سبيل المثال ، الاتصال بخادم Linkedin وقطع اتصال Brotli ، يمكنني ببساطة الوصول إلى هذا الموقع من متصفح لا يدعم Brotli. على الرغم من أنني غير قادر على تعطيل دعم Brotli في Chrome ، إلا أنني قادر على إخفاء حقيقة أن المتصفح الخاص بي يدعم Brotli. تخبر المتصفحات الخوادم عن خوارزميات الضغط التي تدعمها باستخدام رأس الطلبcontent-encoding. باستخدام Webpagetest ، يمكنني تخصيص الرؤوس بنفسي. لذا ، كل شيء بسيط للغاية!

تسمح لنا الميزات المتقدمة لـ WebPageTest بتعيين رؤوس الطلبات المخصصة.

وإليك كيفية إعداد حقل رؤوس مخصصة:

اغلاق كامل للضغط: accept-encoding: randomstring.
تعطيل Brotli، ولكن الدعم ببرنامج Gzip: accept-encoding: gzip.
لاستخدام Brotli إذا كان الموقع يدعم طريقة الضغط هذه (بشرط أن يكون مدعومًا بواسطة المستعرض): يظل الحقل فارغًا.

يمكنك معرفة ما إذا كان هذا يعمل على النحو المنشود من خلال التحقق من وجود (أو غياب) الرأس content-encodingفي استجابة الخادم.

النتائج

كما هو متوقع ، كان الانتقال من عدم الضغط إلى Gzip يعني تحسنًا كبيرًا ، لكن الانتقال من Gzip إلى Brotli لا يبدو مثيرًا للإعجاب. يمكن العثور على البيانات الأولية من تجاربي هنا . فيما يلي النتائج التي تهمني أكثر:

Gzip : 73%.
FCP Gzip : 23.305%.
Brotli Gzip: 5.767%.
FCP Brotli Gzip: 3.462%.

هذه كلها قيم وسيطة. بالحديث عن "أحجام المواد" أعني فقط HTML و CSS و JavaScript.

بفضل استخدام Gzip ، تم تقليل أحجام الملفات بنسبة 73٪ مقارنة بإصداراتها غير المضغوطة. ويسمح استخدام Brotli بتقليل أحجام الملفات فقط بنسبة 5.7٪ إضافية. إذا تحدثنا عن FCP ، فبفضل Gzip تحسن هذا المؤشر بنسبة 23٪ مقارنة بنقص الضغط ، وأضاف Brotli فقط 3.5٪ إضافية لهذا.

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

بيانات الموارد الخاصة والبيانات من مصادر خارجية

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

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

بالحديث عن الضغط ، غالبًا ما نناقش النتائج التي تم الحصول عليها باستخدام أفضل سيناريو لتطبيق الضغط. وبالتحديد - عند استخدام Gzip ، نأخذ في الاعتبار المستوى التاسع من الضغط ، وعند استخدام Brotli - المستوى 11. ومع ذلك ، فمن غير المحتمل أن يتم تكوين الخادم قيد التحقيق بالطريقة المثلى. على سبيل المثال ، يستخدم Apache ضغط gzip من المستوى 6 ، بينما يستخدم NGINX الأول فقط.

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

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

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

ملخص

يحصل المرء على الانطباع بأنه ، من المنطقي ، يمكن للمرء أن يدرك عدم أهمية مزايا Brotli على Gzip.

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

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

ومع ذلك ، إذا كنت تريد الاستفادة من Brotli ، فقد تحتاج إلى أسابيع من التطوير والاختبار والنشر ، ولا داعي للذعر - فقط تأكد من استخدام ضغط Gzip لكل شيء يمكن ضغطه (وهذا يتضمن ، بالإضافة إلى الموارد النصية ، الملفات .ico و .ttf - إذا تم استخدامهما بالطبع في مشروعك).

أفترض أن نسخة قصيرة من هذه المقالة قد تبدو على النحو التالي: إذا كان لا يجب تمكين Brotli أو لا يمكنك ، فأنت لا تخسر الكثير.

القراء الأعزاء! هل تخطط لاستخدام بروتلي؟

كفاءة بروتلي في العالم الحقيقي