هندسة الأداء في Next.js

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

كيف يسير العمل

القياس أولًا، من الميدان. نبدأ ببيانات تقرير Chrome UX وبيانات المراقبة لديكم، مقسّمة حسب فئة الجهاز وقالب المسار. فالقول إنّ قيمة LCP عند الشريحة 75 تبلغ 3.4 ثانية في صفحات المنتجات على الهاتف عبارة قابلة للتنفيذ، أما «درجتنا في Lighthouse هي 62» فليست كذلك.

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

الإصلاح على المستوى المعماري. نقل مكوّن عبر حدّ الخادم، وإزالة جلب بيانات من جهة العميل كان ينبغي أن يكون عرضًا على الخادم، واستبدال مكتبة تواريخ بحجم 300 كيلوبايت، وتقسيم مسار يُرسل حزمة لوحة الإدارة كاملةً إلى زوّار مجهولين. هذه هي التغييرات التي تصمد.

الدفاع عن النتيجة. ينتهي كل عمل بميزانية أداء مفروضة في خطّ التكامل المستمر. أي pull request يدفع حزمة المسار فوق سقفها يُسقط الفحص. الميزانية هي المُخرَج الحقيقي، والدرجة أثر جانبي.

ما الذي تحصلون عليه

وثيقة نتائج مرتّبة بالأولوية، كل مشكلة فيها متتبَّعة إلى سببها ومُقدَّرة بالجهد؛ والإصلاحات المنفَّذة على هيئة pull requests قابلة للمراجعة؛ وإعداد ميزانية التكامل المستمر؛ ومقارنة قبل/بعد على بيانات الميدان بعد أن يمضي على التغيير في الإنتاج ما يكفي لتحريك نافذة الثمانية والعشرين يومًا.