أتمتة Performance Budget على CI: ارفض أي PR يخفّض الأداء قبل الـ merge

ملف lighthouserc.json

ملف GitHub Actions

قراءة النتائج بشكل صحيح

الـ assertion عندها 3 مستويات: error، warn، off. error بيفشّل الـ build؛ warn بيكتب رسالة في تعليق GitHub بدون فشل. الاستراتيجية المُجرّبة: ابدأ كل assertion بـ warn لأسبوع، اقرأ التقارير، ثم رفّعها لـ error بعد ما تثق إن الميزانية واقعية.

متوسط 3 runs مش مصادفة. كل run فيه noise بسبب الشبكة، الـ CPU، الـ throttling. numberOfRuns: 3 بيلتقط الـ median وبيقلّل الـ false positives من 18% لـ 4% على workload قِسناه على فريق 12 مطور بـ 340 PR في 6 شهور.

الـ trade-offs

المكسب الأساسي: regression صفر تقريبًا. على 6 شهور من الإنتاج عند فريق إدارة 4 تطبيقات Next.js، الـ LCP الوسيط ما زادش عن 1.8s رغم 340 PR متراكم. ده مش ممكن بـ code review يدوي.

الثمن الأول: زمن الـ build. Lighthouse CI بيضيف 90 ثانية على متوسط الـ workflow. لو بتعمل 200 PR في اليوم على فريق كبير، ده 5 ساعات compute زيادة يوميًا — تكلفة GitHub Actions تقريبًا 4 دولار/يوم على hosted runner. على self-hosted runner التكلفة بتختفي لكن بتدفعها في صيانة الـ runner.

الثمن الثاني: false positives في صفحات ديناميكية. لو الصفحة بتجيب feed مختلف كل request، الـ LCP بيتذبذب طبيعيًا. الحل: استخدم static fixture في بيئة الـ CI (snapshot من قاعدة بيانات معروفة)، أو ارفع numberOfRuns لـ 5 وزوّد tolerance بـ 100ms.

الثمن الثالث: الفريق ممكن يتعلّم يتجاوز الميزانية. لو حد ضايف PR بيخفّض assertion من error لـ warn علشان الـ build يعدي، انت في مشكلة ثقافية مش تقنية. حُل ده بفرض branch protection على ملف lighthouserc.json نفسه — أي تعديل عليه يحتاج موافقة tech lead.

متى لا تستخدم هذه الأتمتة

لا تستخدم Performance Budget على CI لو تطبيقك internal tool لـ 30 موظف بيشتغلوا على شبكة الشركة. هنا الـ LCP مش مشكلة عمل، والـ overhead مش بيستحق. كذلك لا تستخدمه على branches experimental بتختبر فيها مكتبات ثقيلة زي Three.js — هتقفل نفسك من merging features أصيلة. الحل: استثنِ branches معيّنة من الـ workflow بـ if: github.head_ref != 'experimental/*'.

الافتراض المبني عليه المقال: عندك تطبيق ويب public-facing بـ ≥10K زائر يومي، فريق ≥5 مطورين، وتقدر تشغّل بيئة staging كاملة في CI خلال 3 دقائق. لو واحدة من دي مفقودة، استخدم Real User Monitoring (RUM) عبر web-vitals.js بدل الـ synthetic budget.

الخطوة التالية

افتح المشروع، ثبّت @lhci/cli، انسخ ملف الـ JSON اللي فوق، وشغّل npx lhci autorun محليًا قبل ما تحط الـ workflow. هتشوف الأرقام الحالية للموقع. حدّد كل assertion عند 10% أعلى من الرقم الحالي وضيف الـ workflow كـ warn. بعد أسبوعين، حوّلها لـ error. لو لقيت assertion واحد بيفشل بشكل متكرر، افتح الـ Lighthouse report — في 80% من الحالات السبب صورة مش optimized أو third-party script ضخم محتاج defer.

المصادر

• Lighthouse CI — GoogleChrome/lighthouse-ci (الإعداد والـ assertions)
• Use Lighthouse for performance budgets — web.dev
• Largest Contentful Paint (LCP) — web.dev
• Interaction to Next Paint (INP) — web.dev
• GitHub Actions Documentation — github.com
• Addy Osmani — Performance Budgets 101