ميزانيات الأداء والمراقبة

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

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

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

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

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

• ما هو حجم JavaScript المسموح لنا بتضمينه؟

• ما مدى سرعة ضرورة أن تصبح الصفحة تفاعلية؟

• ما هو أكبر محتوى طلاء مقبول لدينا (LCP)؟

• كيف نكتشف حالات التراجع تلقائيًا؟

• كيف نراقب الأداء في حركة مرور الإنتاج الحقيقية؟

الأداء ليس مجرد عملية ضبط. إنه نموذج حوكمة للعرض والتسليم.

في الرسم التخطيطي أعلاه، تتدفق الأسهم إلى أسفل من التسليم إلى وقت التشغيل (يؤثر حجم الحزمة على LCP والترطيب) وإلى أعلى من المراقبة إلى البنية (تؤثر مقاييس الإنتاج على تعديلات الميزانية).

ميزانيات الأداء والمراقبة في React 19

ميزانيات الأداء هي حدود صريحة تُفرض على الموارد المُرسلة وسلوك وقت التشغيل.

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

تُقيّد ميزانية وقت التشغيل زمن الاستجابة المرئي للمستخدم، مثل زمن عرض أول محتوى (FCP)، وزمن التفاعل (TTI)، وتأخير إدخال ، واستقرار التخطيط. ويتم تتبع هذه العوامل عادةً باستخدام مؤشرات أداء الويب الحيوية مثل LCP (أكبر محتوى معروض)، وCLS (التحول التراكمي للتخطيط)، وINP (التفاعل حتى العرض التالي).

في React 19، لم يعد العرض خطوة واحدة مُعطِّلة. يمكن مقاطعة العمل أو تأجيله أو بثه. هذا يعني أن الأداء يتأثر بكل من التسليم (حجم الحزمة) والجدولة (كيفية تحديد React لأولويات التحديثات وتثبيتها). تؤدي الحزمة الكبيرة إلى تأخير عملية التحميل. وتؤدي المهام المتزامنة الطويلة إلى إعاقة استجابة إدخال . كما أن إعادة العرض المفرطة تزيد منINP .

لذا نفكر في الأداء عبر ثلاث طبقات:

• طبقة التوصيل: ما هي البيانات التي نقوم بشحنها؟

• طبقة التنفيذ: ما هي المدة التي يحجب فيها JavaScript خيط الرئيسي؟

• طبقة العرض: كيف تعمل عملية جدولة React ومقاطعتها وتنفيذها؟

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

تُكمل المراقبة في بيئة الإنتاج هذه الحلقة. تُحاكي القياسات المخبرية ظروفًا مُحكمة، بينما تُسجّل مراقبة المستخدم الحقيقي (RUM) تنوّع الأجهزة الفعلي، وتغيّر الشبكة، وزمن الاستجابة الجغرافي. بدون بيانات القياس عن بُعد في بيئة ...