لقد استخدمت الويب لمدة يوم بميزانية 50 ميغابايت

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

في المرة الأخيرة ، قمت بالتنقل على الويب لمدة يوم باستخدام Internet Explorer 8. هذه المرة ، قمت بتصفح الويب لمدة يوم واحد بميزانية تبلغ 50 ميجا بايت.

لماذا 50 ميجا بايت؟

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

ولكن هناك أجزاء من العالم تكون فيها البيانات المتنقلة باهظة التكلفة ، وحيث توجد بنية تحتية للنطاق العريض قليلة أو معدومة.

غالبًا ما يشتري الأشخاص حزم بيانات لا تزيد عن عشرات الميجابايت في المرة الواحدة ، مما يجعل من الجيجابايت كمية كبيرة نسبيًا وبالتالي مكلفة من البيانات للشراء.
- دان هودل ، محلل اتصالات المستهلك في Cable.co.uk

فقط ما هي تكلفة نتحدث؟

تكلفة بيانات الجوال

وجدت دراسة أجرتها cable.co.uk عام 2018 أن زيمبابوي كانت أغلى بلد في العالم لبيانات الجوال ، حيث تبلغ تكلفة 1 جيجا بايت في المتوسط ​​75.20 دولارًا ، وتتراوح من 12.50 دولارًا إلى 138.46 دولارًا. يرجع النطاق الهائل في السعر إلى الكميات الصغيرة من البيانات التي تكون باهظة الثمن ، مما يؤدي إلى انخفاض التكلفة نسبيًا كلما كانت خطة البيانات التي تلتزم بها أكبر. يمكنك قراءة منهجية الدراسة لمزيد من المعلومات.

إن زيمبابوي ليست بأي حال من الأحوال حالة وحيدة. وتأتي غينيا الاستوائية وسانت هيلانة وجزر فوكلاند في المرتبة التالية ، حيث تبلغ تكلفة 1 جيجابايت من البيانات 65.83 دولارًا و 55.47 دولارًا و 47.39 دولارًا على التوالي. تتمتع هذه البلدان عمومًا بمزيج من البنية التحتية التقنية الضعيفة والاعتماد المنخفض ، مما يعني أن توفير البيانات مكلف وليس لديها اقتصاد الحجم لخفض التكاليف.

البيانات باهظة الثمن في أجزاء من أوروبا أيضًا. غيغا بايت من البيانات في اليونان سيعيدك 32.71 دولارًا ؛ في سويسرا ، 20.22 دولار. للمقارنة ، تبلغ تكلفة نفس الكمية من البيانات 6.66 دولارًا أمريكيًا في المملكة المتحدة ، أو 12.37 دولارًا أمريكيًا في الولايات المتحدة الأمريكية. على الطرف الآخر من المقياس ، تعد الهند أرخص مكان في العالم للبيانات ، بمتوسط ​​تكلفة يبلغ 0.26 دولار. تليها قيرغيزستان وكازاخستان وأوكرانيا بـ 0.27 دولار و 0.49 دولار و 0.51 دولار لكل جيجابايت على التوالي.

تختلف سرعة شبكات الهاتف المحمول أيضًا اختلافًا كبيرًا بين البلدان. ربما يكون من المدهش أن يختبر المستخدمون سرعات أعلى عبر شبكة الهاتف المحمول من شبكة WiFi في ما لا يقل عن 30 دولة حول العالم ، بما في ذلك أستراليا وفرنسا. تتمتع كوريا الجنوبية بأسرع سرعة تنزيل للهاتف المحمول ، بمتوسط ​​52.4 ميجابت في الثانية ، لكن العراق لديها أبطأ ، بمتوسط ​​1.6 ميجابت في الثانية للتنزيل و 0.7 ميجابت في الثانية للتحميل. تحتل الولايات المتحدة الأمريكية المرتبة 40 في العالم من حيث سرعات التنزيل عبر الأجهزة المحمولة ، بحوالي 34 ميجابت في الثانية ، وهي معرضة لخطر التخلف أكثر مع تحرك العالم نحو 5G.

بالنسبة لنوع الاتصال بشبكة الهاتف المحمول ، فإن 84.7٪ من اتصالات المستخدمين في المملكة المتحدة على 4G ، مقارنة بـ 93٪ في الولايات المتحدة ، و 97.5٪ في كوريا الجنوبية. هذا بالمقارنة مع أقل من 50٪ في أوزبكستان وأقل من 60٪ في الجزائر والإكوادور ونيبال والعراق.

تكلفة بيانات النطاق العريض

وفي الوقت نفسه ، تُظهر دراسة عن تكلفة النطاق العريض في عام 2018 أن اتصال النطاق العريض في النيجر يكلف 263 دولارًا لكل ميغابت شهريًا. يصعب فهم هذا المقياس قليلاً ، لذا إليك مثال: إذا كان متوسط ​​تكلفة حزم النطاق العريض في بلد ما هو 22 دولارًا ، ومتوسط ​​سرعة التنزيل التي تقدمها الحزم هو 10 ميجابت في الثانية ، فإن التكلفة "لكل ميغابت شهريًا" ستكون يكون 2.20 دولار.

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

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

على تكلفة الحزمة وحدها ، موريتانيا لديها أغلى نطاق عريض في العالم ، بمتوسط ​​768.16 دولار (نطاق من 307.26 دولار إلى 1368.72 دولار). تشمل هذه التكلفة الهائلة بناء خطوط مادية للممتلكات ، حيث يوجد القليل منها بالفعل في موريتانيا. بمعدل 0.7 ميغابت في الثانية ، تمتلك موريتانيا أيضًا واحدة من أبطأ شبكات النطاق العريض في العالم.

تمتلك تايوان أسرع نطاق عريض في العالم ، بمتوسط ​​سرعة 85 ميجابت في الثانية. اليمن هو الأبطأ عند 0.38 ميغابت في الثانية. ولكن حتى البلدان التي تمتلك بنية تحتية جيدة النطاق عريض النطاق لديها ما يسمى "مواقع غير محددة". تحتل المملكة المتحدة المرتبة 34 من بين 207 دولة من حيث سرعة النطاق العريض ، ولكن في يوليو 2019 ، كانت لا تزال هناك مدرسة في المملكة المتحدة بدون النطاق العريض.

يبلغ متوسط ​​تكلفة حزمة النطاق العريض في المملكة المتحدة 39.58 دولارًا أمريكيًا وفي الولايات المتحدة الأمريكية 67.69 دولارًا أمريكيًا. أرخص متوسط ​​في العالم هو أوكرانيا ، حيث يبلغ 5 دولارات فقط ، على الرغم من أن أرخص صفقة النطاق العريض لجميعهم وُجدت في قيرغيزستان (1.27 دولار - مقابل متوسط ​​البلد البالغ 108.22 دولارًا).

كانت زيمبابوي الدولة الأكثر تكلفة لبيانات الهاتف المحمول ، والإحصائيات ليست أفضل بكثير بالنسبة للنطاق العريض ، حيث بلغ متوسط ​​التكلفة 128.71 دولارًا وتكلفة "لكل ميغابت شهريًا" 6.89 دولارًا.

التكلفة المطلقة مقابل التكلفة بالقيمة الحقيقية

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

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

للمقارنة ، 3.67 دولار هي حوالي نصف الحد الأدنى للأجور البالغ 7.25 دولار في الولايات المتحدة. بصفتي مواطناً في زيمبابوي ، كان عليّ العمل لمدة يوم ونصف تقريبًا لكسب المال لشراء هذه البيانات البالغ حجمها 50 ميغا بايت ، مقارنة بنصف ساعة فقط في الولايات المتحدة الأمريكية. ليس من السهل مقارنة تكلفة المعيشة بين البلدان ، ولكن بالنسبة للأجور وحدها ، فإن تكلفة البيانات البالغة 3.67 دولارًا والتي تبلغ 50 ميجابايت في زيمبابوي ستبدو وكأنها 52 دولارًا أمريكيًا مقابل الحد الأدنى للأجور.

إعداد التجربة

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

لقد قمت بتثبيت ModHeader وقمت بتعيين رأس "حفظ البيانات" للسماح لمواقع الويب بمعرفة أنني أريد تقليل استخدام البيانات الخاصة بي. هذا أيضًا هو العنوان الذي حدده Chrome لـ "الوضع البسيط" في Android ، والذي سأتناوله بمزيد من التفاصيل لاحقًا.

لقد قمت بتنزيل TripMode ؛ تطبيق لنظام Mac يمنحك التحكم في التطبيقات الموجودة على جهاز Mac الخاص بك والتي يمكنها الوصول إلى الإنترنت. يتم حظر الوصول إلى الإنترنت لأي تطبيق آخر تلقائيًا.

إلى أي مدى أتوقع أن تأخذني ميزانيتي البالغة 50 ميغابايت؟ نظرًا لأن متوسط ​​وزن صفحة الويب يبلغ 1.7 ميجابايت تقريبًا ، فإن هذا يشير إلى أن ميزانيتي تبلغ حوالي 29 صفحة ، على الرغم من أنها ربما تكون أكثر بقليل من ذلك إذا كنت قادرًا على البقاء على نفس المواقع والاستفادة من التخزين المؤقت للمتصفح.

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

التجربة

بدون أي مزيد من اللغط ، قمت بتحميل google.com ، باستخدام 402 كيلوبايت من ميزانيتي وإنفاق 0.03 دولار (حوالي 1٪ من ميزانيتي في زيمبابوي).

بشكل عام ، ليس حجم صفحة سيئًا ، لكنني تساءلت من أين تأتي طلبات الشبكة الـ 24 هذه وما إذا كان يمكن جعل الصفحة أخف وزناً أم لا.

صفحة Google الرئيسية - DOM

بالنظر إلى ترميز الصفحة ، لا توجد أوراق أنماط خارجية - كل CSS مضمنة.

نصيحة الأداء رقم 1: CSS الحرجة المضمنة

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

النصيحة العامة هي أن تكون أنماطك الهامة (أي شيء في الجزء المرئي من الصفحة) مضمنة ، وأن تكون بقية التصميم خارجيًا ويتم تحميلها بشكل غير متزامن. يمكن تحقيق التحميل غير المتزامن لـ CSS في سطر واحد من HTML ذكي بشكل ملحوظ:

 <link rel="stylesheet" href="/path/to/my.css" media="print" onload="this.media='all'">

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

يمكنك أن ترى أن هناك الكثير من JavaScript مضمنة هنا. من الجدير بالذكر أنه تم تقويضه بدلاً من تصغيره فقط.

نصيحة الأداء رقم 2: تصغير أصولك وتقبحها

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

ومع ذلك ، يبدو أن البرامج النصية المضمنة تبلغ 120 كيلوبايت تقريبًا من مورد الصفحة البالغ 210 كيلوبايت (حوالي نصف حجم 60 كيلوبايت gzip). بالإضافة إلى ذلك ، هناك خمسة ملفات جافا سكريبت خارجية تصل إلى 291 كيلوبايت من 402 كيلوبايت التي تم تنزيلها:

هذا يعني أن JavaScript يمثل حوالي 80 بالمائة من إجمالي وزن الصفحة.

هذا ليس عديم الفائدة جافا سكريبت. يجب أن يكون لدى Google البعض من أجل عرض الاقتراحات أثناء الكتابة. لكني أشك في أن الكثير منه يتعلق برمز التتبع وإعداد الإعلان.

للمقارنة ، عطلت JavaScript وأعدت تحميل الصفحة:

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

نصيحة الأداء رقم 3: الأقل هو الأكثر

يعد تضمين الأصول وتقليلها وتقليلها أمرًا جيدًا وجيدًا ، ولكن أفضل أداء يأتي من عدم إرسال الأصول في المقام الأول.

• قبل إضافة أي ميزات جديدة ، هل لديك ميزانية أداء قائمة؟
• قبل إضافة JavaScript إلى موقعك ، هل يمكن إنجاز ميزتك باستخدام HTML عادي؟ (على سبيل المثال ، التحقق من صحة نموذج HTML5).
• قبل سحب مكتبة JavaScript أو CSS كبيرة إلى تطبيقك ، استخدم شيئًا مثل bundlephobia.com لقياس حجمها. هل الراحة تستحق الوزن؟ هل يمكنك تحقيق نفس الشيء باستخدام كود الفانيليا بحجم بيانات أصغر بكثير؟

تحليل معلومات المورد

هناك الكثير لتفريغه هنا ، لذلك دعونا نتصدع. لدي 50 ميغابايت فقط للعب بها ، لذا سأقوم باستهلاك كل جزء من تحميل هذه الصفحة. استقر في برنامج تعليمي قصير لـ Chrome Devtools.

402 كيلوبايت تم نقلها ، لكن 1.1 ميغابايت من الموارد: ماذا يعني ذلك في الواقع؟

هذا يعني أنه تم تنزيل 402 كيلوبايت من المحتوى بالفعل ، ولكن في شكله المضغوط (باستخدام خوارزمية ضغط مثل gzip أو brotli). كان على المتصفح بعد ذلك القيام ببعض الأعمال لتفكيكها إلى شيء ذي معنى. الحجم الإجمالي للبيانات التي تم تفريغها هو 1.1 ميغا بايت.

هذا التفريغ ليس مجانيًا - فهناك بضعة أجزاء من الألف من الثانية من النفقات الزائدة في فك ضغط الموارد. لكن هذا عبء ضئيل مقارنة بإرسال 1.1 ميغا بايت عبر السلك.

نصيحة الأداء رقم 4: ضغط الأصول المستندة إلى النص

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

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

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

نصيحة الأداء رقم 5: إعطاء تلميحات الموارد إلى المتصفح

سيخمن المتصفح ما هي الأصول ذات الأولوية القصوى ، ولكن يمكنك تقديم تلميح مورد باستخدام العلامة <link rel="preload"> ، لتوجيه المتصفح لتنزيل الأصل في أقرب وقت ممكن. إنها لفكرة جيدة أن تقوم بالتحميل المسبق للخطوط والشعارات وأي شيء آخر يظهر في الجزء المرئي من الصفحة.

دعنا نتحدث عن التخزين المؤقت. سأقوم بضغط ALT والنقر بزر الماوس الأيمن لتغيير رؤوس أعمدتي لإلغاء تأمين بعض المعلومات المثيرة. سنقوم بفحص Cache-Control.

تشير Cache-Control إلى ما إذا كان يمكن تخزين مورد مؤقتًا أم لا ، ومدة تخزينه مؤقتًا ، والقواعد التي يجب أن يتبعها حول إعادة التحقق. يعد تعيين قيم ذاكرة التخزين المؤقت المناسبة أمرًا بالغ الأهمية للحفاظ على تكلفة البيانات للزيارات المتكررة منخفضة.

نصيحة الأداء رقم 6: تعيين رؤوس التحكم في ذاكرة التخزين المؤقت على جميع الأصول القابلة للتخزين المؤقت

لاحظ أن قيمة التحكم في ذاكرة التخزين المؤقت تبدأ بتوجيه public أو private ، متبوعًا بقيمة انتهاء الصلاحية (على سبيل المثال max-age=31536000 ). ماذا يعني التوجيه ، ولماذا قيمة max-age المحددة بشكل غريب؟

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

لشرح التوجيه العام / الخاص ، يجب أن نشرح ذاكرتي التخزين المؤقت الرئيسيتين الموجودتين خارج الخادم. أولاً ، هناك ذاكرة التخزين المؤقت التقليدية للمتصفح ، حيث يتم تخزين المورد على جهاز المستخدم ("العميل"). ثم هناك ذاكرة التخزين المؤقت CDN ، والتي تقع بين العميل والخادم ؛ يتم تخزين الموارد مؤقتًا على مستوى CDN لمنع CDN من طلب المورد من الخادم الأصلي مرارًا وتكرارًا.

يسمح توجيه Cache-Control public بتخزين المورد مؤقتًا في كل من العميل و CDN. تعني القيمة private أنه يمكن للعميل فقط تخزينها مؤقتًا ؛ CDN ليس من المفترض أن. تُستخدم هذه القيمة الأخيرة عادةً للصفحات أو الأصول الموجودة خلف المصادقة ، حيث من الجيد تخزينها مؤقتًا على العميل ولكننا لا نريد تسريب المعلومات الخاصة عن طريق تخزينها مؤقتًا في CDN وتسليمها إلى مستخدمين آخرين.

الشيء الوحيد الذي لفت انتباهي هو أن شعار Google يحتوي على عنصر تحكم في ذاكرة التخزين المؤقت لكلمة "خاص". تحتوي الصور الأخرى الموجودة على الصفحة على ذاكرة تخزين مؤقت عامة ، ولا أعرف سبب معاملة الشعار بشكل مختلف. إذا كان لديك أي أفكار ، أخبرني في التعليقات!

لقد قمت بتحديث الصفحة وتم تقديم معظم الموارد من ذاكرة التخزين المؤقت ، بصرف النظر عن الصفحة نفسها ، والتي كما رأيت بالفعل private, max-age=0 ، مما يعني أنه لا يمكن تخزينها مؤقتًا. هذا أمر طبيعي لصفحات الويب الديناميكية حيث من المهم أن يحصل المستخدم دائمًا على أحدث صفحة عند التحديث.

في هذه المرحلة ، قمت بالنقر دون قصد على عنوان URL "شرح" في devtools ، والذي أخذني إلى مرجع تحليل الشبكة ، وكلفني حوالي 5 ميغابايت من ميزانيتي. أووبس.

جوجل ديف دوكس

4.2 ميغا بايت من هذه الصفحة الجديدة 5 ميغا بايت كانت متوفرة للصور ؛ على وجه التحديد SVGs. كان الأثقل من ذلك هو 186 كيلوبايت ، وهو ليس كبيرًا بشكل خاص - كان هناك الكثير منهم فقط ، وتم تنزيلهم جميعًا مرة واحدة.

كان تحميل الصفحة الذي يبلغ حجمه 5 ميغابايت يمثل 10٪ من ميزانيتي لهذا اليوم. لقد استخدمت حتى الآن 5.5 ميغابايت ، بما في ذلك إعادة تحميل صفحة Google الرئيسية بدون JavaScript ، وأنفقت 0.40 دولارًا. لم أقصد حتى فتح هذه الصفحة.

ما هي تجربة المستخدم الأفضل هنا؟

نصيحة رقم 7 حول الأداء: حمِّل صورك بشكل كسول

عادةً ، إذا قمت بالنقر فوق ارتباط بالخطأ ، فسوف أضغط على زر الرجوع في متصفحي. لم أكن لأتلقى أي فائدة على الإطلاق من تنزيل هذه الصور - يا لها من مضيعة لـ 4.2 ميغابايت!

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

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

يوجد دليل css-tricks.com رائع لطرح التحميل البطيء للصور والذي يوفر توازنًا جيدًا بين أولئك الذين لديهم اتصالات جيدة والذين لديهم اتصالات ضعيفة وتلك التي تم تعطيل JavaScript فيها.

إذا كانت هذه الصفحة قد نفذت تحميلًا كسولًا وفقًا للدليل أعلاه ، فسيتم تمثيل كل من 38 SVGs بصورة عنصر نائب بحجم 1 كيلوبايت افتراضيًا ، ويتم تحميلها فقط في العرض عند التمرير.

نصيحة رقم 8 حول الأداء: استخدم التنسيق الصحيح لصورك

اعتقدت أن Google قد فاتها خدعة بعدم استخدام WebP ، وهو تنسيق صورة أصغر حجمًا بنسبة 26٪ مقارنةً بصيغ PNG (بدون خسارة في الجودة) وأصغر حجمًا بنسبة 25-34٪ مقارنةً بصيغ JPEG (و جودة مماثلة). اعتقدت أنني سأحاول تحويل SVG إلى WebP.

أدى التحويل إلى WebP إلى خفض أحد SVGs من 186 كيلوبايت إلى 65 كيلوبايت فقط ، ولكن في الواقع ، بالنظر إلى الصور جنبًا إلى جنب ، ظهر WebP محببًا:

ثم حاولت بعد ذلك تحويل أحد ملفات PNG إلى WebP ، والتي من المفترض أن تكون بلا خسارة ويجب أن تكون أصغر. ومع ذلك ، كان إخراج WebP * أثقل * (127 كيلوبايت ، من 109 كيلوبايت)!

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

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

الآن نعود إلى DOM. جئت عبر هذا:

لاحظ الكلمة الأساسية async في برنامج Google Analytics النصي؟

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

طلب المنع هو الذي يوقف عرض الصفحة. يتم حظر استدعاء <script> افتراضيًا ، مما يؤدي إلى إيقاف تحليل HTML حتى يتم تنزيل البرنامج النصي وتصنيفه وتنفيذه. هذا هو سبب وضعنا لاستدعاءات <script> في نهاية المستند.

نصيحة رقم 9 بشأن الأداء: تجنب كتابة مكالمات حظر البرامج النصية

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

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

على أي حال ، يكفي تشريح جوجل. حان الوقت لتجربة موقع آخر. لا يزال لدي ما يقرب من 45 ميغابايت من ميزانيتي المتبقية!

أمازون

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

في الواقع ، كان هناك بضع مئات من الصور في علامة تبويب الشبكة الخاصة بي والتي لم أتمكن من رؤيتها بالفعل على الصفحة. أشك في وجود خطأ في التكوين في مكان ما على أمازون ، لكن هذه الصور غير المرئية مجتمعة تمضغ ما لا يقل عن 1 ميغابايت من بياناتي.

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

لقد قلتها مرة ، وسأقولها مرة أخرى: يعد تحسين صورك وتحميلها البطيء أكبر فائدة فردية يمكنك تحقيقها لوزن صفحة موقعك .

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

لكي نكون منصفين لـ Amazon ، إذا قمت بتغيير حجم المتصفح إلى حجم الهاتف المحمول وقمت بتحديث الصفحة ، فسيتم تحسين الموقع للجوال ويبلغ إجمالي وزن الصفحة 2.1 ميجا بايت فقط.

لكن هذا يقودني إلى نقطتي التالية ...

نصيحة الأداء رقم 10: لا تضع افتراضات حول اتصالات البيانات

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

نعم ، يجب أن نتوقع تحميل صفحة أكبر إذا كان إطار العرض الخاص بنا "بحجم سطح المكتب" حيث ستكون الصور أكبر وأفضل للشاشة من الصور المحمولة الأكثر تحببًا. لكن لا ينبغي أن تكون الصفحة أكبر بأحجام كبيرة.

علاوة على ذلك ، كنت أرسل عنوان Save-Data مع طلبي. يشير هذا العنوان صراحةً إلى تفضيل لتقليل استخدام البيانات ، وآمل أن يبدأ المزيد من مواقع الويب في الانتباه إليه في المستقبل.

قد يكون تحميل "سطح المكتب" الأولي 6 ميجا بايت ، ولكن بعد الجلوس ومشاهدته لمدة دقيقة ، ارتفع إلى 8.6 ميجا بايت مع بدء تشغيل الموارد ذات الأولوية المنخفضة وتتبع الأحداث. يشتمل وزن هذه الصفحة على ما يقرب من 1.7 ميجا بايت من JavaScript مصغر. لا أريد حتى أن أبدأ في النظر إلى ذلك.

نصيحة الأداء رقم 11: استخدم عمال الويب لجافا سكريبت الخاص بك

أيهما سيكون أسوأ - 1.7 ميغابايت من JavaScript أم 1.7 ميغابايت من الصور؟ الإجابة هي JavaScript: الأصول ليست متكافئة عندما يتعلق الأمر بالأداء.

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

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

أنا الآن حوالي 15.5 ميغابايت في ميزانيتي ، وقد أنفقت 1.14 دولارًا أمريكيًا من ميزانية بيانات زيمبابوي. كان علي أن أعمل لمدة نصف يوم كمدرس لكسب المال للوصول إلى هذا الحد.

بينتيريست

لقد سمعت أشياء جيدة عن أداء Pinterest ، لذلك قررت أن أخضعه للاختبار.

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

ومع ذلك ، رأيت أنه في عمليات تحميل الصفحات اللاحقة ، ظهر عامل الخدمة في جزء كبير من المحتوى - مما وفر حوالي نصف وزن الصفحة:

موقع Pinterest هو تطبيق ويب تقدمي ؛ قامت بتثبيت عامل خدمة للتعامل يدويًا مع التخزين المؤقت لـ CSS و JS. يمكنني الآن إيقاف تشغيل WiFi والاستمرار في استخدام الموقع (وإن لم يكن ذلك مفيدًا جدًا):

نصيحة الأداء رقم 12: استخدم عمال الخدمة لتقديم الدعم دون اتصال بالإنترنت

ألن يكون رائعًا إذا اضطررت إلى تحميل موقع ويب مرة واحدة عبر الشبكة ، والآن أحصل على جميع المعلومات التي أحتاجها حتى لو كنت غير متصل بالإنترنت؟

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

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

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

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

حتى الآن ، استهلكت Pinterest وحدها 14 ميغابايت ، مما يعني أنني أنفقت حوالي 30 ميغابايت من ميزانيتي ، أو 2.20 دولار (أجر يوم تقريبًا) من ميزانيتي في زيمبابوي.

من الأفضل أن أكون حذرًا مع آخر 20 ميجا بايت ... ولكن أين المتعة في ذلك؟

جيمسبوت

اخترت هذا لأنه شعرت بالركود بشكل ملحوظ على هاتفي المحمول في الماضي وأردت البحث في أسباب ذلك. من المؤكد أن تحميل الصفحة الرئيسية يستهلك 8.5 ميغابايت من البيانات.

كان 6.5 ميغابايت من هذا يرجع إلى مقطع فيديو يتم تشغيله تلقائيًا في منتصف الطريق أسفل الصفحة ، والذي - لكي نكون منصفين - لم يتم تنزيله حتى بدأت في التمرير. مع ذلك…

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

نصيحة الأداء رقم 13: لا تقم بتحميل الفيديو مسبقًا

كقاعدة عامة ، ما لم يكن وضع الاتصال الأساسي لموقعك هو الفيديو ، فلا تقم بتحميله مسبقًا.

إذا كنت تستخدم YouTube أو Netflix ، فمن المنطقي أن تفترض أن شخصًا ما قادمًا إلى صفحتك سيرغب في تحميل الفيديو تلقائيًا وتشغيله تلقائيًا. هناك توقع بأن الفيديو سوف يمضغ من خلال بعض البيانات ، ولكن هذا تبادل عادل للمحتوى. ولكن إذا كنت موقعًا تكون وسيطته الأساسية هي النص والصورة - ويصادف أنك تقدم محتوى فيديو إضافيًا - فلا تحمّل الفيديو مسبقًا.

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

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

إذا اتفقنا على أنها فكرة جيدة أن نجعل من الفيديو تجربة اشتراك (انقر للتشغيل) ، فيمكننا أن نتقدم خطوة إلى الأمام ونجعله ينقر للتحميل أيضًا. وهذا يعني الاستهزاء بصورة العنصر النائب للفيديو بزر تشغيل فوقه ، وتنزيل الفيديو فقط عند النقر فوق زر التشغيل. People on fast connections should notice no difference in buffer speed, and people on slow connections will appreciate how fast the rest of your site loaded because it didn't have to preload a large video file.

Anyway, back to Gamespot, where I was indeed forced to preload a large video file I ended up not watching. I then clicked through to a game review page that weighed another 8.5 MB, this time with 5.4 MB of video, before I even started scrolling down the page.

What was really galling was when I looked at what the video actually was. It was an advert for a Samsung TV! This advert cost me $0.40 of my Zimbabwe wages. Not only was it pre-loaded, but it also didn't end up playing anywhere as far as I'm aware, so I never actually saw it.

The 'real' video — the gameplay footage (in other words, the content) — wasn't actually loaded until I clicked on it. And that ploughed through my remaining data in seconds.

هذا هو. That's my 50 MB gone. I'll need to work another 1.5 days as a Zimbabwean schoolteacher to repeat the experience.

Performance Tip #14: Optimize For First Page Load

What's striking is that I used 50 MB of data and in most cases, I only visited one or two pages on any given site. If you think about it, this is true of most user journeys today.

Think about the last time you Googled something. You no doubt clicked on the first search result. If you got your answer, you closed the tab, or else you hit the back button and moved onto the next search result.

With the exception of a few so-called 'destination sites' such as Facebook or YouTube, where users habitually go as a starting point for other activities, the majority of user journeys are ephemeral. We stumble across random sites to get the answers to our questions, never to return to those sites again.

Web development practices are heavily skewed towards optimising for repeat visitors. “Cache these assets — they'll come in handy later”. “Pre-load this onward journey, in case the user clicks to read more”. “Subscribe to our mailing list”.

Instead, I believe we should optimize heavily for one-off visitors. Call it a controversial opinion, but maybe caching isn't really all that important. How important can a cached resource that never gets surfaced again be ? And perhaps users aren't actually going to subscribe to your mailing list after reading just the one article, so downloading the JavaScript and CSS for the mail subscription modal is both a waste of data and an annoying user experience.

The Decline Of Proxy Browsers

I had hoped to try out Opera Mini as part of this experiment. Opera Mini is a mobile web browser which proxies web pages through Opera's compression servers. It accounts for 1.42% of global traffic as of June 2019, according to caniuse.com.

Opera Mini claims to save up to 90% of data by doing some pretty intensive transcoding. HTML is parsed, images are compressed, styling is applied, and a certain amount of JavaScript is executed on Opera's servers. The server doesn't respond with HTML as you might expect — it actually transcodes the data into Opera Binary Markup Language (OBML), which is progressively loaded by Opera Mini on the device. It renders what is essentially an interactive 'snapshot' of the web page — think of it as a PDF with hyperlinks inside it. Read Tiffany Brown's excellent article, “Opera Mini and JavaScript” for a technical deep-dive.

It would have been a perfect way to eek my 50 MB budget as far as possible. Unfortunately, Opera Mini is no longer available on iOS in the UK. Attempting to visit it in the app store throws an error:

It's still available “in some markets” but reading between the lines, Opera will be phasing out Opera Mini for its new app — Opera Touch — which doesn't have any data-saving functionality apart from the ability to natively block ads.

Opera desktop used to have a 'Turbo mode', acting as a traditional proxy server (returning a HTML document instead of OBML), applying data-saving techniques but less intensively than Opera Mini. According to Opera, JavaScript continues to work and “you get all the videos, photos and text that you normally would, but you eat up less data and load pages faster”. However, Opera quietly removed Turbo mode in v60 earlier this year, and Opera Touch doesn't have a Turbo mode either. Turbo mode is currently only available on Opera for Android.

Android is where all the action is in terms of data-saving technology. Chrome offers a 'Lite mode' on its mobile browser for Android, which is not available for iPhones or iPads because of “platform constraints“. Outside of mobile, Google used to provide a 'Data Saver' extension for Chrome desktop, but this was canned in April.

Lite mode for Chrome Android can be forcibly enabled, or automatically kicks in when the network's effective connection type is 2G or worse, or when Chrome estimates the page will take more than 5 seconds to reach first contentful paint. Under these conditions, Chrome will request the lite version of the HTTPS URL as cached by Google's servers, and display this stripped-down version inside the user's browser, alongside a “Lite” marker in the address bar.

I'd love to try it out — apparently it disables scripts, replaces images with placeholders, prevents loading of non-critical resources and shows offline copies of pages if one is available on the device. This saves up to 60% of data. However, it isn't available in private (Incognito) mode, which hints at some of the privacy concerns surrounding proxy browsers.

يشارك الوضع البسيط عنوان URL الخاص بـ HTTPS مع Google ، لذلك فمن المنطقي أن هذا الوضع غير متاح في وضع التصفح المتخفي. ومع ذلك ، لا تتم مشاركة المعلومات الأخرى مثل ملفات تعريف الارتباط ومعلومات تسجيل الدخول ومحتوى الصفحة الشخصية مع Google - وفقًا لـ ghacks.net - و "لا تقطع الاتصالات الآمنة بين Chrome وموقع الويب أبدًا". يتساءل المرء لماذا لا يُسمح على ما يبدو بأي من خدمات توفير البيانات هذه على نظام iOS (وليس هناك أخبار حول ما إذا كان الوضع البسيط سيصبح متاحًا على نظام iOS).

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

لم أتمكن من العثور على أي أداة لحفظ البيانات متوافقة مع OSX أو iOS باستثناء Bandwidth Hero for Firefox (الذي يتطلب إعداد خدمة ضغط البيانات الخاصة بك - بما يتجاوز الإمكانات التقنية لمعظم المستخدمين!) و skyZIP Proxy (الذي تم تحديثه مؤخرًا في 2017 مليئة بالأخطاء المطبعية ، لم أستطع أن أثق بنفسي).

خاتمة

يسير تقليل أثر بيانات موقع الويب الخاص بك جنبًا إلى جنب مع تحسين أداء الواجهة الأمامية. إنه الشيء الوحيد الأكثر موثوقية الذي يمكنك القيام به لتسريع موقعك.

بالإضافة إلى تكلفة البيانات ، هناك الكثير من الأسباب الوجيهة للتركيز على الأداء ، كما هو موضح في منشور مدونة GOV.UK حول هذا الموضوع:

• سيتخلى 53٪ من المستخدمين عن موقع الجوال إذا استغرق تحميله أكثر من 3 ثوانٍ.
• يتعين على الأشخاص التركيز بنسبة 50٪ أكثر عند محاولة إكمال مهمة بسيطة على موقع ويب باستخدام اتصال بطيء.
• تعد صفحات الويب الأكثر أداءً أفضل بالنسبة لعمر بطارية جهاز المستخدم ، وتتطلب عادةً طاقة أقل على الخادم لتقديمها. الموقع ذو الأداء جيد للبيئة.

ليس لدينا القدرة على تغيير التكلفة العالمية لعدم المساواة في البيانات. لكن لدينا القدرة على تقليل تأثيره ، وتحسين التجربة للجميع في هذه العملية.