أداء الواجهة الأمامية 2021: تحديد أهداف واقعية

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

جدول المحتويات

1. الاستعداد: التخطيط والقياسات
2. تحديد أهداف واقعية
3. تعريف البيئة
4. تحسينات الأصول
5. بناء التحسينات
6. تحسينات التسليم
7. الشبكات ، HTTP / 2 ، HTTP / 3
8. الاختبار والمراقبة
9. انتصارات سريعة
10. كل شيء في صفحة واحدة
11. قم بتنزيل قائمة التحقق (PDF ، Apple Pages ، MS Word)
12. اشترك في النشرة الإخبارية عبر البريد الإلكتروني حتى لا تفوت الأدلة التالية.

تحديد أهداف واقعية

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

   

   أيضًا ، يجب إكمال كل إطار للرسوم المتحركة في أقل من 16 مللي ثانية ، وبالتالي تحقيق 60 إطارًا في الثانية (ثانية واحدة ÷ 60 = 16.6 مللي ثانية) - ويفضل أن يكون ذلك أقل من 10 مللي ثانية. نظرًا لأن المتصفح يحتاج إلى وقت لرسم الإطار الجديد على الشاشة ، يجب أن تنتهي التعليمات البرمجية الخاصة بك من التنفيذ قبل الوصول إلى علامة 16.6 مللي ثانية. لقد بدأنا في إجراء محادثات حول 120 إطارًا في الثانية (على سبيل المثال ، تعمل شاشات iPad Pro عند 120 هرتز) وقد غطت Surma بعض حلول أداء العرض لـ 120 إطارًا في الثانية ، ولكن ربما هذا ليس هدفًا نتطلع إليه الآن .

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

2. FID <100 مللي ثانية ، LCP <2.5 ثانية ، TTI <5s على شبكة الجيل الثالث ، ميزانية حجم الملف الحرج <170 كيلو بايت (مضغوط).
   على الرغم من أنه قد يكون من الصعب جدًا تحقيقه ، إلا أن الهدف النهائي الجيد هو "حان وقت التفاعل" دون سن الخامسة ، وبالنسبة للزيارات المتكررة ، يجب أن يكون الهدف أقل من ثانيتين (لا يمكن تحقيقه إلا مع عامل الخدمة). استهدف الحصول على أكبر لوحة ذات محتوى أقل من 2.5 ثانية وتقليل وقت الحظر الإجمالي وتغيير التخطيط التراكمي . يكون تأخير الإدخال الأول المقبول أقل من 100 مللي ثانية - 70 مللي ثانية. كما ذكرنا أعلاه ، نحن نفكر في أن خط الأساس هو هاتف Android بقيمة 200 دولار (مثل Moto G4) على شبكة 3G بطيئة ، تتم محاكاتها بسرعة نقل تبلغ 400 مللي ثانية RTT و 400 كيلوبت في الثانية.

   لدينا قيدان رئيسيان يشكلان بشكل فعال هدفًا معقولاً للتسليم السريع للمحتوى على الويب. من ناحية أخرى ، لدينا قيود على توصيل الشبكة بسبب بداية بطيئة لـ TCP. أول 14 كيلوبايت من HTML - 10 حزم TCP ، كل 1460 بايت ، مما يجعل حوالي 14.25 كيلوبايت ، وإن لم يتم أخذها حرفيًا - هو الجزء الأكثر أهمية للحمولة الصافية ، والجزء الوحيد من الميزانية الذي يمكن تسليمه في الرحلة الأولى ذهابًا وإيابًا ( وهو كل ما تحصل عليه في ثانية واحدة عند 400 مللي ثانية RTT بسبب أوقات إيقاظ الهاتف المحمول).

   

   ( ملاحظة : نظرًا لأن TCP بشكل عام لا يستخدم اتصال الشبكة بكمية كبيرة ، فقد طورت Google TCP Bottleneck Bandwidth و RRT ( BBR ) ، وهي خوارزمية للتحكم في تدفق TCP يتم التحكم فيها عن طريق التأخير. بدلاً من فقدان الحزم مثل TCP ، فهو أسرع بشكل ملحوظ ، مع إنتاجية أعلى وزمن انتقال أقل - وتعمل الخوارزمية بشكل مختلف. ( شكرًا ، فيكتور ، باري! )

   من ناحية أخرى ، لدينا قيود على الأجهزة على الذاكرة ووحدة المعالجة المركزية بسبب تحليل JavaScript وأوقات التنفيذ (سنتحدث عنها بالتفصيل لاحقًا). لتحقيق الأهداف المذكورة في الفقرة الأولى ، علينا أن نأخذ في الاعتبار ميزانية حجم الملف الحرج لجافا سكريبت. تختلف الآراء حول ما يجب أن تكون عليه هذه الميزانية (وتعتمد بشكل كبير على طبيعة مشروعك) ، ولكن الميزانية التي تبلغ 170 كيلوبايت جافا سكريبت gzipped ستستغرق بالفعل ما يصل إلى 1 ثانية لتحليلها وتجميعها على هاتف متوسط ​​المدى. بافتراض أن 170 كيلو بايت تتوسع إلى 3 × هذا الحجم عند فك الضغط (0.7 ميجا بايت) ، فقد يكون هذا بالفعل بمثابة ناقوس الموت لتجربة مستخدم "لائقة" على Moto G4 / G5 Plus.

   

   في حالة موقع Wikipedia على الويب ، في عام 2020 ، أصبح تنفيذ الكود أسرع بنسبة 19٪ لمستخدمي ويكيبيديا. لذلك ، إذا ظلت مقاييس أداء الويب الخاصة بك على مدار العام ثابتًا ، فعادة ما تكون هذه علامة تحذير لأنك تتراجع بالفعل مع استمرار تحسن البيئة (التفاصيل في منشور مدونة بواسطة Gilles Dubuc).

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

   

   

   في الواقع ، يوصي Alex Russell من Google باستهداف 130-170 كيلوبايت gzip كحد أعلى معقول. في سيناريوهات العالم الواقعي ، فإن معظم المنتجات ليست قريبة من هذا الحد: يبلغ متوسط ​​حجم الحزمة اليوم حوالي 452 كيلوبايت ، وهو ما يزيد بنسبة 53.6٪ مقارنة بأوائل عام 2015. على جهاز محمول من الطبقة المتوسطة ، يستغرق ذلك 12-20 ثانية بالنسبة للوقت -تفاعلية .

   

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

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

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

جدول المحتويات

1. الاستعداد: التخطيط والقياسات
2. تحديد أهداف واقعية
3. تعريف البيئة
4. تحسينات الأصول
5. بناء التحسينات
6. تحسينات التسليم
7. الشبكات ، HTTP / 2 ، HTTP / 3
8. الاختبار والمراقبة
9. انتصارات سريعة
10. كل شيء في صفحة واحدة
11. قم بتنزيل قائمة التحقق (PDF ، Apple Pages ، MS Word)
12. اشترك في النشرة الإخبارية عبر البريد الإلكتروني حتى لا تفوت الأدلة التالية.