توفير العمل في الموقع السريع كجزء من خط التطوير

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



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

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

ترجم إلى Alconost

كان Steve Suders من أوائل المهتمين بتحليل كيفية طلب المتصفحات موارد الويب وانتظار الرد: ما هي الموارد التي تعمل ، وما هي الموارد التي يمكن تأجيلها ، وماذا يحدث مع رؤوس الاستجابة؟ استنادًا إلى نتائج بحثه ، وضع قائمة من 14 قاعدة لتحميل موقع ويب بسرعة . على سبيل المثال ، فيما يلي قواعد الأداء التي تنطبق في أداة YSlow (قد تكون على دراية بها بالفعل) .


14 قواعد ستيف سودرز ( المصدر )

اليوم هناك المزيد والمزيد من الأدوات الجديدة للتحكم في الإنتاجية: يحتاج بعضها إلى إطلاقه بشكل منفصل ، في حين أن البعض الآخر مدمج في خط التطوير والنشر. أحدها هو Google Lighthouse : فهي تعرض بيانات عن مؤشرات PWA (تطبيقات الويب التقدمية) ، SEO ، إلخ.


لقطة شاشة لمنارة 3.0 معروضة في مؤتمر Google I / O 2018 ( المصدر )

تساعد هذه الأدوات على تحديد ما يجب الانتباه إليه بشكل خاص عند الانتهاء من الموقع ، وفي الوقت نفسه ، نفذت العديد من المفاهيم ، من بينها ليس من السهل فهمها: PRPL ، RAIL ، Paint Timing API ، TTI ، HTTP / 2 ، مؤشر السرعة ، تلميحات الأولوية والمزيد ...

لماذا الأداء وراء الكواليس

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

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

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

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

عند حل المهام اليومية ، يجب عليك العمل في العديد من المجالات الفنية: تطوير وظائف جديدة ، والتفاعل مع الأقسام الأخرى (إضافة نصوص للتحليلات ، والإعلان ، وتجديد النشاط التسويقي ، واختبار A / B) ، وتنظيم التكامل والتوصيل المستمر (CI / CD) ، وضمان الأمان ، إنشاء واجهة جميلة وسهلة الاستخدام. لكنك لا تزال بحاجة إلى تغطية المؤخرة بالاختبارات!

غالبًا ما يكون من المستحيل تقريبًا الانتباه إلى شيء آخر: الوقت محدود ، ويميل حجم العمل المتميز إلى النمو. لذلك ، يجب عليك تحديد الأولويات.



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

• تنفيذ الوظائف . عادة ، يتم تعيين المهام الجديدة من قبل المالك أو مدير المنتج ، وفقًا لرؤيته وهدف الفريق. قد يأتي طلب وظيفة من أولئك الذين يعتمدون على عملنا (على سبيل المثال ، إضافة برنامج نصي تابع لجهة خارجية للتتبع أو اختبار A / B ).
  
• منظمة CI / CD . يمكن للمطورين إنشاء خطوط الأنابيب الخاصة بهم للتجميع والنشر ، ولكن على الأرجح سيستخدمون البنية التحتية التي أعدها الآخرون (على سبيل المثال ، قسم البنية التحتية).
  
• الأمن . إنه أمر رائع إذا كان للمشروع قسم (أو شخص واحد على الأقل) متخصص في الأمن ، مما يساعد على التحقق من هيكل النظام ، وتنفيذ الوظائف ، وإرسال تقارير أمنية إلينا وإبلاغنا بالتصحيحات.
  
• واجهة المستخدم عادةً ما يكون للمشروع مصمم و / أو متخصص في تفاعل المستخدم يكون مسؤولاً عن المظهر وسهولة الاستخدام وهندسة المعلومات.
  
• الاختبار . أين نحن بدون اختبارات ، صحيح؟
  

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

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

ست خطوات لتنفيذ أهمية أداء موارد الويب

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

لقد جمعت قائمة من ست نقاط من شأنها أن تساعد في هذا الأمر.

1. بيئة التطوير environment بيئة المستخدم

عمل سهل ، برصاص إميل بيرون

لتطوير موقع الويب ، أستخدم MacBook Pro. لدي هاتف iPhone X ولدي جهاز اختبار منفصل. بالإضافة إلى ذلك ، لدي اتصال إنترنت سريع للغاية ، وأنا أجلس بالقرب من مراكز البيانات في ستوكهولم ولندن. بعد العمل ، أذهب إلى مترو الأنفاق ، حيث يوجد 4G (ولا توجد فجوات). بشكل عام ، ظهر في ستوكهولم لأول مرة 4G - في عام 2009 .

لن يكون لدى المستخدمين مثل هذه الظروف الأنيقة (مع استثناءات نادرة).

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

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

فكر في الأفضل: جذب المزيد من المستخدمين ، حتى لو كانوا أقل قابلية للمذيبات ، أو أقل ، ولكن أكثر قابلية للمذيبات؟

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

ولكن دعونا لا نتسرع. ولكن ماذا لو كان الأداء المنخفض على بعض الأنظمة الأساسية نتيجة لحقيقة أن منتجنا غير مريح أو غير فعال؟ من الصعب إثبات هذه الفرضية ، لأن المطورين سيقولون أن كل شيء على ما يرام معهم - على أجهزة الكمبيوتر الخاصة بهم وفي متصفح معين (لنفترض أنه سيكون Google Chrome). نحن نولي عن غير قصد اهتمامًا أكبر للمتصفح الذي نستخدمه ، ونتيجة لذلك ، غالبًا ما نتنازل لصالح بيئة عمل أكثر حداثة. أوه ، أسمع صرخة ألم من الجانب الآخر من الشاشة: "هل ما زلت تستخدم هذا المتصفح؟ دعهم يتم تحديثهم! "

لقد صادفت مؤخرًا اقتباسًا أعجبني حقًا:

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

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

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

2. من الأفضل تعلم أساسيات التكنولوجيا بدلاً من مكتبات محددة

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

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

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

هناك ثابتان لا يتغيران ، أينما أطبق مهاراتي كمطور:

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

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

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

3. إيجاد وقت للتجربة والاختبار.

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

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

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

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


العديد من دراسات الحالة التي أدت فيها زيادة الإنتاجية إلى تحسين مؤشرات الأداء الرئيسية.

في بعض الأحيان ، لجعل الشركة تولي اهتمامًا أكبر لسرعة مشروع الويب ، لا يكفي البحث العملي لشخص ما كدليل.

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

في رأيي ، يجب أن تمر كل وظيفة بثلاث مراحل:



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

عند البحث عما يمكن تسريعه ، اختر ما يمكن للمستخدمين تجربته. حتى يتمكن المستخدمون من ملاحظة الفرق في فترة زمنية مقبولة ، يجب أن تزيد سرعة الموقع بنسبة 20٪ على الأقل ، والأفضل - بنسبة 30٪ .

4. تدريب الزملاء

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


نستفيد من غياب جون - نتخلص من التعقيد غير الضروري.

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

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


خيارات لما يمكنك إظهاره قبل تحميل صورة.

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

إنه أكثر فاعلية لتجنب تسليم الصور وتحسين تلك التي لا يزال يتعين تسليمها - هذا ما يجب عليك السعي إليه.

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

بعد كل شيء ، إذا كنت تروج لفكرة معينة ، فلن تستمر طويلاً.

5. مشاركة قصص النجاح (والفشل)

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

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

- , .

-, Etsy. :

« « », , : , , , ».
— , « »

.

, , , .


Etsy

, , . Vox Media — , The Verge . 2015 . Vox Media , .

« . — . ».
— Vox Media, « » ( )

SpeedCurve , The Verge Vox Media ( )

Vox Media ( , ) , .


Vox Media .

: ( ), . , , .

6.

— ́ , -.

, : WebPagetest , Pagespeed Insights , Audits Chrome . .


WebPagetest — .

, , , .

, , . — .

— . . , ( , , . .).

RUM-, . , , , - , .

, , — Google Analytics , — : , Calibre , SpeedCurve SiteSpeed .

, .

— . (, SiteSpeed) , . , .

- Caliber . « », - . :

• . , ( , ) .
  
• . , , , , . , , , , .
  
• . , , : « - », « Caliber», «», «» « ». , , — : .
  

? , .

1. , .
   
2. . — .
   
3. — , , .
   
4. , , , .
   
5. كانت الأداة قادرة على تصور مؤشرات الأداء وإظهار تغيرها ، والذي كان مفيدًا عندما قررنا مشاركة تجربتنا مع مطوري الويب الآخرين للشركة. مثل هذه الأدوات تجعل من الضروري وضع قيود على مؤشرات الأداء ، بما يتجاوز الذي سيؤدي إلى رفض طلبات التغييرات في التعليمات البرمجية (أو ستأتي الإخطارات فقط).
   
6. تم تضمين الأداة المقترحة في سير العمل ويمكن أن تعمل بدون جهد من جانبنا - لم يكن من الضروري أخذ الموارد من المهام الأخرى.
   

الخلاصة

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

عن المترجم

تمت ترجمة المقال بواسطة Alconost.

تقوم Alconost بتوطين الألعاب والتطبيقات والمواقع بـ 68 لغة. مترجمون لغتهم الأم ، اختبار لغوي ، منصة سحابية بواجهة برمجة تطبيقات ، تعريب مستمر ، مدراء مشاريع 24/7 ، أي تنسيق لموارد السلسلة.

ننشئ أيضًا مقاطع فيديو إعلانية وتدريبية - للمواقع التي تبيع ، والصور ، والإعلانات ، والتدريب ، والتشويش ، والشرح ، والمقطورات لـ Google Play و App Store.

مزيد من التفاصيل