00:00:00أصدرت GitHub للتو إضافة قوية جدًا لـ Storybook ستغير تمامًا
00:00:05الطريقة التي نختبر بها أداء المكونات.
00:00:07تتضمن لوحة أداء مفصلة للغاية مليئة برؤى قيمة مثل قياس
00:00:12توقيت الإطارات، واستجابة الإدخال، واستقرار التخطيط، وتحليل React، وضغط الذاكرة
00:00:18وأكثر من ذلك بكثير.
00:00:19في هذا الفيديو، سنلقي نظرة فاحصة على ما تقدمه هذه الإضافة.
00:00:23سيكون الأمر ممتعًا للغاية، لذا دعونا نبدأ.
00:00:31سؤال سريع قبل أن نبدأ.
00:00:32هل تعرف ما هو اختبار الأداء المبكر (Shift-left performance testing)؟
00:00:35إنه نموذج تطوير يفرض اختبار أداء مكونات تطبيقك
00:00:40في مرحلة مبكرة من عملية التطوير بدلاً من تركه كفكرة لاحقة.
00:00:45وهذه الأداة مصممة خصيصًا لمساعدة المطورين على اتخاذ تلك القرارات المبكرة،
00:00:50مما يمنحك نظرة مباشرة على كيفية تصرف مكوناتك قبل وصولها للإنتاج.
00:00:55توفر لوحة أداء Storybook نظرة عالية الدقة لكيفية تفاعل
00:01:00مكوناتك مع محرك عرض المتصفح.
00:01:02فهي تتبع، على سبيل المثال، توقيت الإطار لتحديد الارتعاش، تلك الفجوات الصغيرة
00:01:07بين الإطارات التي تجعل الرسوم المتحركة تبدو متقطعة.
00:01:10كما تراقب الخيط الرئيسي بحثًا عن كثرة تعديلات الـ DOM والإجهاد.
00:01:15تحدث كثرة التعديلات عندما يقوم الكود بإنشاء أو حذف أو تحديث عناصر
00:01:20بشكل غير ضروري، بينما يحدث الإجهاد عندما يضطر المتصفح لإعادة حساب
00:01:25التخطيط عدة مرات في إطار واحد بسبب القراءة والكتابة المتتالية للأنماط.
00:01:30وتتكيف هذه الإضافة مع أي إطار عمل تستخدمه.
00:01:33إذا كنت تستخدم React، فيمكنها إبراز مقاييس مثل تسلسلات العرض (render cascades)،
00:01:38وهي تغييرات الحالة الصغيرة التي تسبب موجة ضخمة من إعادة العرض عبر تطبيقك.
00:01:44كما تتبع مقياس P95، الذي يوضح أسوأ سيناريو لأبطأ المستخدمين
00:01:50بدلاً من مجرد عرض المتوسط.
00:01:52وإذا كنت لا تستخدم React، فإن الوضع العام يعمل بشكل مثالي مع Vue أو Svelte
00:01:58أو مكونات الويب.
00:01:59وللحصول على أفضل النتائج، يوصى بتشغيل هذه الإضافة على Chrome أو Edge.
00:02:04لديهم أيضًا دليل تشغيل حي حيث يمكننا رؤية هذه المقاييس قيد التنفيذ.
00:02:08على سبيل المثال، في نموذج الصندوق المتحرك، يمكننا تتبع عدد تعديلات
00:02:13الأنماط المباشرة التي تحدث أثناء الرسوم المتحركة.
00:02:16في هذه الحالة، يبدو كل شيء سليمًا.
00:02:18معدل الإطارات وتوقيتها يظلان مستقرين تمامًا، مما يعني أن المتصفح
00:02:23يتعامل مع تلك التحديثات دون أي مجهود يذكر.
00:02:25ومع ذلك، يظهر مثال القائمة الثقيلة قصة مختلفة.
00:02:29عند تصفية هذه القائمة الكبيرة، نرى بعض العلامات التحذيرية.
00:02:32أولاً، يقفز تغيير التخطيط التراكمي (CLS) إلى قيمة عالية جدًا، مما يشير
00:02:38إلى أن العناصر تتحرك بشكل كبير أثناء التحميل، مما يسبب تجربة مزعجة للمستخدم.
00:02:43نرى أيضًا ارتفاعًا في تعديلات الـ DOM، مما يعني أن المتصفح يبذل مجهودًا مضاعفًا
00:02:49لتفكيك وإعادة بناء عدد هائل من العقد في وقت واحد.
00:02:52يؤدي هذا أيضًا إلى سقوط بعض الإطارات، مما يقتل السرعة الملحوظة
00:02:57وسلاسة الواجهة.
00:02:58في مثال توقيت العناصر، يتم قياس وقت العرض الدقيق لأي عنصر DOM
00:03:04يحتوي على سمة “element timing”.
00:03:06هذا مفيد للغاية لأنه يساعدك على تحديد اللحظة الدقيقة التي يصبح فيها
00:03:11المحتوى الرئيسي أو زر الحث على اتخاذ إجراء مرئيًا، مما يعطيك صورة أدق
00:03:17عن الأداء الملحوظ بدلاً من مجرد مقاييس تحميل الصفحة العامة.
00:03:21وعندما ننظر إلى مثال العرض المكلف، إذا ضغطنا على زر إعادة العرض،
00:03:26فإنه يتسبب في ارتفاع مدة P95.
00:03:29يحدث هذا لأن الخيط الرئيسي يكون مشغولاً بتنفيذ أكواد JavaScript ثقيلة،
00:03:34مما يجعل واجهة المستخدم تبدو بطيئة جدًا.
00:03:36نرى أيضًا تحذيرات من ارتعاش الإطارات هنا، مما يشير إلى عرض غير متناسق
00:03:41حيث يتأرجح الوقت بين الإطارات بشكل كبير.
00:03:44وهناك أيضًا وقت حظر إجمالي (TBT) مرتفع.
00:03:47ويعتبر TBT علامة تحذير رئيسية لأنه يشير إلى أن الخيط الرئيسي محظور
00:03:52لفترة كافية تمنع المستخدم من التفاعل مع الصفحة، مثل
00:03:57النقر على زر أو التمرير.
00:03:58ونرى انهيارًا مماثلاً في مثال هدر التخزين المؤقت (memoization).
00:04:03هنا يظهر العرض التوضيحي أن إعادة عرض كل عنصر دون داعٍ يؤدي
00:04:08إلى تأخير هائل.
00:04:09في المقابل، يظهر مثال التخزين المؤقت الصحيح مقدار العمل الذي يتم توفيره
00:04:15إذا قمنا بتخزين مكوناتنا مؤقبًا.
00:04:16من خلال تخطي عمليات العرض الزائدة، نحافظ على الخيط الرئيسي فارغًا
00:04:21ويبقى معدل الإطارات ثابتًا عند 60 إطارًا في الثانية بسلاسة فائقة.
00:04:25في مثال تسلسل العرض، نرى بالضبط ما يحدث عند استخدام set state
00:04:30داخل use layout effect.
00:04:31كل زيادة تؤدي إلى تسلسل لأن use layout effect يعمل بشكل متزامن بعد
00:04:37كل تعديلات الـ DOM، ولكن قبل أن تتاح للمتصفح فرصة للرسم.
00:04:42لذا، من خلال تفعيل تحديث الحالة هنا، فأنت تجبر React على إعادة معالجة شجرة المكونات
00:04:47والمتصفح على إعادة حساب التخطيط مرة ثانية قبل أن يرى المستخدم
00:04:52النتيجة الأولى حتى.
00:04:53وهذا أمر سيئ لأنه يضاعف العمل فعليًا في كل إطار، مما يؤدي إلى
00:04:58تأخير في العرض يجعل حتى التفاعلات البسيطة تبدو ثقيلة.
00:05:02وهناك أيضًا مثال إجهاد الأنماط الذي يظهر ملاحظة هامة.
00:05:07ماذا يحدث عندما نعدل الأنماط المباشرة لـ 600 عقدة مختلفة في وقت واحد؟
00:05:13نرى على الفور تحذيرات التوقف هذه في قسم الإجهاد، مما يشير إلى
00:05:18أن المتصفح مجبر على الدخول في حلقة إعادة تدفق (reflow loop).
00:05:21إنه يحاول حساب مواقع 600 عنصر في آن واحد بينما لا تزال لغة
00:05:26JavaScript تجري التغييرات.
00:05:27يؤدي هذا إلى مؤشرات غير صحية لمقاييس الإطارات لدينا لأن الخيط
00:05:33الرئيسي مشبع تمامًا.
00:05:34لذا آمل أن توضح لك كل هذه الأمثلة كيف يمكنك استخدام إضافة Storybook هذه
00:05:38لتحديد نقاط الاختناق في بيئة أكثر دقة بكثير.
00:05:41بالتأكيد، يمكنك استخدام أداة مثل Lighthouse، لكن Lighthouse يشبه الفرشاة العريضة.
00:05:46فهو لا يمنحك تلك الدقة الجراحية لترى بالضبط كيف يؤثر كل مكون
00:05:51بشكل فردي على أداء تطبيقك.
00:05:53أشجعك حقًا على تنزيل هذه الإضافة، وإضافتها إلى مجموعة Storybook لديك،
00:05:58والاستمتاع بتجربتها.
00:05:59هناك الكثير من الرؤى القيمة التي يمكن اكتسابها بمجرد رؤية الصورة الكاملة
00:06:03لكيفية عمل مكوناتك فعليًا في الكواليس.
00:06:06هذا كل شيء يا رفاق، هذه هي إضافة لوحة أداء GitHub Storybook
00:06:10باختصار.
00:06:11ما رأيكم فيها؟
00:06:13وكيف تقيسون الأداء في تطبيقاتكم؟
00:06:16أخبرونا في التعليقات أدناه.
00:06:18ويا رفاق، إذا كنتم تحبون هذا النوع من التحليلات التقنية، فيرجى إخباري
00:06:22بالضغط على زر الإعجاب أسفل الفيديو ولا تنسوا أيضًا الاشتراك في قناتنا.
00:06:28كان معكم أندريس من Better Stack، وسأراكم في الفيديوهات القادمة.