لا يكفي التصميم المتجاوب ، فنحن بحاجة إلى أداء سريع الاستجابة

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

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

"لم القلق؟" ربما تسال. "يمتلك معظم زوارنا هواتف ذكية عالية الأداء تعمل بأحدث إصدارات نظام التشغيل. يمكنهم التعامل مع مواقعنا. تخبرنا التحليلات بذلك. "

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

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

نموذج التصميم الأول من الطوب

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

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

ما مدى صعوبة تنفيذ تخطيط فرعي للجوّال أولاً يوفر هذه المعلومات فقط للأجهزة التي تقل عن عتبة معينة من القدرات والأداء؟

تحسين رشيقة

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

عندما تصبح هذه الوظيفة متاحة بسهولة أكثر فأكثر ، تصبح الحاجة إلى التفكير فيها (ناهيك عن ما هو أبعد منها) بعيدة أكثر فأكثر.

من وجهة نظر هذه المقالة يمكن تقسيمها على النحو التالي:

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

تدهور رشيق: إذا لم تكن الميزة متاحة بسهولة ، فإنها تفشل بطريقة لا تزال تتيح قابلية استخدام مقبولة.

تحسين غير رشيق: إذا لم تكن الميزة متاحة بسهولة ، فسيتم محاكاتها بواسطة polyfill أو shim.

هناك ، حلت المشكلة.

حسنًا ، ما لم تفكر في أداء تلك الأجهزة المنخفضة النهاية.

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

وهكذا تقوم بتنفيذ modernizr و polyfill فقط في حالة. ينتهي الجهاز الأقل كفاءة بتحميل أكبر قدر من البيانات وإجراء أكبر قدر من المعالجة. وبالتالي ضمان "أفضل" تجربة للمستخدم النهائي.

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

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

يمكن ، ولكن هل يجب أن؟

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

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

بدأت هذه المشكلة مؤخرًا في التأثير على تطبيقات Android بشكل كبير (من وجهة نظر المستخدم). أثر أحد أكثر التدهور الملحوظ بهذا المعنى على ترقية تطبيق Google Talk / Hangouts التي حولت خدمتهم من تطبيق الدردشة خفيف الوزن المتاح إلى تطبيق غير قابل للاستخدام تقريبًا بسبب مشكلات الأداء على الأجهزة القديمة. (فقط للتأكيد على هذه النقطة مرة أخرى: تعني كلمة "أقدم" هنا أنه لا يزال بإمكانك شرائها جاهزة ، وهي جديدة تمامًا في أي متجر تقريبًا). أثرت المشكلة نفسها على تطبيق YouTube وتطبيق Twitter (من واقع خبرتي) والعديد من التطبيقات الأخرى على ما يبدو.

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

اسمح للمستخدمين بالانسحاب من حافة النزيف

هل وجدت نفسك يومًا تحاول استخدام Gmail من جهاز قديم ، أو عبر اتصال ضعيف؟ من المؤكد أن رابط "تحميل HTML الأساسي" هذا مفيد.

لماذا لا تتمتع واجهة متجرك عبر الإنترنت المتطورة والمتجاوبة والمتحركة والتي تعمل باللمس بهذه الوظيفة؟

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

هل تحتاج حقًا إلى المكتبة بأكملها؟

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

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

ألن يكون الأمر رائعًا إذا كان بإمكانك تلقائيًا تحليل ما وكمية المكتبة التي تم استخدامها وفقدان الوزن بناءً على النتائج؟

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

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

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

لكن ماذا يمكنني أن أفعل حيال ذلك؟

بادئ ذي بدء ، شارك في المشكلة . فكر في الأمر وناقشه مع زملائك وحاول تحديد المشكلة في سيناريوهات العالم الحقيقي.

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

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

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

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

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

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