Web performance - الجزء الثاني

بسم الله الرحمن الرحيم

الحمد لله ربّ العالمين، يُحب من دعاه خفياً، ويُجيب من ناداه نجيّاً، ويزيدُ من كان منه حيِيّاً، ويكرم من كان له وفيّاً، ويهدي من كان صادق الوعد رضيّاً، الحمد لله ربّ العالمين.

Web performance - 2

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

عندما نتحدث عن ال Web performance فإننا نتحدث عن وسيلة قياس موضوعية للأداء بالإضافة إلى تجربة المستخدم المتوقعة في الموقع الخاص بنا بناء على ال Business model، وهذا يعني ما ذكرناه سابقا، وهو أن نجعل الموقع الإلكتروني أسرع بشكل حقيقي أو تخيلي، بشكله الحقيقي بزيادة السرعة الفعلية، وتخيلي من خلال استخدام بعض الأساليب التي تجعل بعض العمليات البطيئة تظهر وكأنها أسرع للمستخدم…وهذا كله يشمل إجابة الأسئلة التالية:

هل الموقع تم تحميله بسرعة؟
هل الموقع يسمح بالتفاعل معه من قبل المستخدم بسرعة؟
هل يتم توفير أو استخدام بعض الوسائل لإعلام المستخدم بأن هناك عملية ما تحتاج إلى وقت؟ مثلا إظهار loading spinner؟
هل تتم عملية التنقل بين البيانات المعروضة في الصفحة بشكل سهل وسلس؟ وهل عملية ال scroll تتم بشكل سلس أيضا؟

بناء على ما ذكر أعلاه، يمكن القول أن هناك مجموعة مهمة من العناوين التي يجب أن ندركها أو أن ندرسها أو أن نتحدث عنها ضمن سياق الحديث عن ال Web performance، وهي الأبواب الرئيسية لقياس أو معالجة مشاكل الأداء، ويمكن سردها بما يلي:

Reducing overall load time: تقليل الوقت الإجمالي لتحميل الموقع الإلكتروني الخاص بك أول ما يمكنك التفكير به، وللقيام بهذا عليك التفكير بعدة نقاط مهمة، وهي:

ما هو الوقت الإجمالي اللازم لتحميل جميع ال files الضرورية على جهاز المستخدم؟
ما هي الأحجام الخاصة بهذه ال files؟
ما هو عدد هذه ال files؟

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

تقليل حجم الملفات إلى أصغر ما يمكن
تقليل عدد ال HTTP request قدر الإمكان
استخدام تقنيات تساهم في تحميل الملفات في أقرب وقت ممكن، مثل استخدام ال Preload.

Making the site usable as soon as possible: من البديهي أن الموقع كلما كان أسرع في قابليته للاستخدام، كلما زادت الثقة بينه وبين المستخدم، ولجعل هذا ممكنا يجب أن نهتم بكيفية تحميل ال assets الخاصة بالموقع الإلكتروني، وهذا يعني ترتيب ال assets المراد تحميلها بشكل منطقي، بحيث يتمكن المستخدم من إجراء أول action يحتاجه بسرعة، وهذه فكرة بسيطة، فالملفات التي لن يحتاجها المستخدم فورا، يمكننا تأجيل تحميلها حتى ننتهي من تحميل الملفات المطلوبة، وسيتم هذا بال background دون أن يشعر المستخدم بذلك!، كما يمكن فصل الملفات التي لا نحتاجها ونجلبها عند الضرورة فقط (lazy loading)، وهذا الوقت حتى يصبح كل شيء جاهزا للتفاعل يطلق عليه time to interactive.
Smoothness and interactivity: تعد هذه النقطة من النقاط البديهية والبسيطة، لكنها في نفس الوقت من أكثر ما قد يزعج المستخدم إن وجد فيها مشاكل، ويقصد بهذه النقطة هو مقدار السهولة والسلاسة والقدرة على التفاعل مع المكونات الخاصة بالموقع الإلكتروني، وهذا يشمل الكثير من الأشياء منها مثلا، هل ال scroll يعمل بشكل سلس؟ هل ال buttons يمكن الضغط عليها؟ هل ال popup تظهر للمستخدم بسرعة؟ هل هناك مشاكل بال animation؟، هذه المشاكل كلها إن وجدت يمكن حلها بالكثير والعديد من الطرق والتي تجعل من التطبيق سلس، منها استخدام ال css animation بدلا من js Animation، وتقليل عمليات ال repaints لل UI من خلال ال DOM قدر الإمكان.
Perceived performance: إن مقدار الإحساس بسرعة الموقع للمستخدمين وطبيعة إنفعالاتهم بناء على هذا الإحساس أهم من السرعة الحقيقية للموقع!، لأنك قد تبني موقع سريع من خلال القياس، لكن المستخدم يراه سيء بناء على تجربته!، لذلك تعد رؤية الأداء من قبل المستخدمين عملية مهمة إن لم تكن الأهم، لكن، هذا الأمر ليس من السهل قياسه، وذلك لأن هذه العملية تعتمد على قياس الأداء من خلال الزاوية التي ينظر منها المستخدمون للموقع، لذلك، يتم الحرص هنا على كيفية الحفاظ على المستخدم وإبقائه متفاعلا مع الموقع في وقت الانتظار، ومن الوسائل لذلك إظهار ال spinner أو مجموعة من ال hints المتعلقة بالخدمات…إلى آخره، ومع أنك في الواقع لم تقم هنا بزيادة سرعة الموقع من الناحية القياسية، إلا أنك قمت بالتفاعل مع المستخدم ليشعر بأن الموقع ما زال يعمل، ولا يوجد هناك أي عطل، ويعطيه شعورا متغيرا بحدوث أو استمرار العمليات…
Performance measurements: في هذه الجزئية سنقوم بقياس الأداء بشكل حقيقي من خلال مجموعة من الحسابات أو العمليات أو الوسائل التي ستساعدنا في تقييم التطبيق والخدمات التي يقدمها من ناحية الأداء، هل هي ناجحة أم فاشلة، هل استطعنا المحافظة على مستوى الجودة مع الوقت، وهل نضمن تحسنها أو ثباتها مع الوقت؟، أم أنها مع الوقت تزداد سوء!…

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

مصطلحات ومفردات مهمة:

latency: يقصد بذلك الوقت المستغرق لإرسال حزمة من البيانات من نقطة إلى نقطة أخرى (من ال source إلى destination) مع الوقت المستغرق لاستقبال النتيجة من قبل ال source مجددا، باختصار، هو الوقت المستغرق من لحظة إرسال request من قبل المستخدم ولغاية عودة ال response إليه، وكلما قلت قيمة ال latency كلما كان الأداء أفضل!، وكلما زادت قيمة ال latency كلما كان الأداء أسوأ…
preload: هي قيمة يتم استخدامها أو وضعها داخل ال rel attribute في ال link tag، هذه القيمة ببساطة تقوم على إعطاء أولوية لجلب ال resources المهمة والضرورية للصفحة في أسرع وقت، وتقدم هذه القيمة مزايا كثيرة وعديدة خصوصا عند جلب الصور أو ملفات الخطوط أو ملفات الجافا سكربت أو الفيديو ذو الحجم الكبير…إلى آخره، من المزايا التي تقدمها أنك ستضمن تحميل ال resource المطلوبة بالأولوية المتوقعة وبشكل أفضل مما لو كانت بدونها، وسيتم تخزين ما تم تحميله من resource في ال cache الخاص بالمتصفح ليقوم باستخدامها في صفحة أخرى عند الحاجة…، وهذا كله يؤثر إيجابا على ال performance ويحسنه بشكل ملحوظ…
lazy loading: بكل بساطة هي استراتيجية تفصل ال resource الغير مهمة في ال render أو التي لا توقف أو تؤثر على ال render الخاص بالصفحة عن ال resource المهمة، ومن ثم جلب هذه ال resource عند الحاجة فقط!، مثلا، قد تمنع جلب ملف جافا سكربت وصورة في الصفحة التي تقوم بعرضها للمستخدم إلا إذا قام بالضغط على زر عرض ال modal…، هناك الكثير من الطرق للقيام بهذه الاستراتيجية، لكنها بشكل عام تقوم على عمل splitting لل js, css وال Html لتكون على أصغر حجم ممكن، بحيث يمكن تضمين الملفات المطلوبة فقط عند الحاجة دون غيرها، بالإضافة لبعض الوسائل والخصائص الموجودة والمعرفة مسبقا مثل استخدام ال module type لملفات الجافا سكربت…
time to interactive: هذا المصطلح يشير إلى مقياس لحساب الوقت الزمني المستغرق لتصبح الصفحة قابلة للتفاعل بشكل كامل، وبشكل تقني أدق، هي آخر long task تم الإنتهاء منها يليها 5 ثواني بدون أي نشاط على مستوى ال network أو ال thread، وال long task هي أي مدة زمنية تزيد أو تساوي 50ms تكون فيها ال thread مشغولة بدون أي قطع…

يتبع في الجزء الثالث إن شاء الله…

أو مشاهدة مباشرة: