الأداء ليس مجرد ميزة مرغوبة في تطوير الويب الحديث؛ بل هو مكون حاسم لتجربة المستخدم وترتيب محركات البحث ومعدلات تحويل الأعمال. مع تقديم Google لـ Core Web Vitals، تحول قياس الأداء من ممارسة رد فعل إلى مطلب استباقي. ومع ذلك، لم يعد الاعتماد على التدقيقات اليدوية كافياً للفرق التي تمارس التكامل المستمر والنشر المستمر (CI/CD). في هذا المنشور، نستكشف كيفية أتمتة مراقبة وتنبيهات Core Web Vitals مباشرة داخل خطوط أنابيب CI/CD الخاصة بك للكشف عن التدهور في الأداء قبل وصوله إلى بيئة الإنتاج.
لماذا دمج الأداء في CI/CD؟
غالباً ما يحدث اختبار الأداء التقليدي بعد النشر أو في بيئات معزولة لا تعكس الظروف الواقعية. من خلال دمج فحوصات Core Web Vitals في خط أنابيب CI/CD الخاص بك، فإنك تضع "ميزانية أداء" لكل طلب سحب (Pull Request). يضمن هذا النهج ما يلي:
- الكشف المبكر عن التدهور: يتم تحديد التغييرات في الكود التي تؤدي إلى تدهور LCP (أargest Contentful Paint) أو FID (First Input Delay) أو CLS (Cumulative Layout Shift) على الفور.
- الأداء مسؤولية مشتركة: يتلقى المطورون ملاحظات فورية حول تأثير أكوادهم على الأداء.
- زيادة ثقة النشر: توفر الفحوصات المؤتمتة شبكة أمان ضد الانخفاضات العرضية في الأداء.
اختيار الأدوات المناسبة
بينما يُعد Lighthouse المعيار الذهبي لتوليد تقارير الأداء، فإن تشغيله في بيئة متصفح بدون واجهة (headless) داخل خط أنابيب CI/CD قد يكون مكلفاً من حيث الموارد. بالنسبة للفحوصات الخفيفة والسريعة التنفيذ، تُعد أدوات مثل puppeteer أو playwright أو الخدمات المتخصصة مثل WebPageTest API خيارات ممتازة. وبدلاً من ذلك، يوفر lighthouse-ci أداة سطر أوامر (CLI) قوية مصممة خصيصاً لهذا الغرض.
في هذا الدليل، سنركز على دمج lighthouse-ci عبر GitHub Actions، حيث يوفر توازناً سلساً بين المقاييس التفصيلية وسهولة التكامل.
إعداد خط الأنابيب
للبدء، تحتاج إلى تثبيت Lighthouse CI CLI كاعتماد للتطوير في مشروعك. يتيح لك ذلك تشغيل التدقيقات محلياً وفي بيئة CI الخاصة بك.
npm install --save-dev @lhci/cliبعد ذلك، أنشئ ملف تكوين، .lighthouserc.json، لتحديد ميزانيات الأداء. يخبر هذا الملف أداة CI بالمقاييس التي يجب تتبعها والحدود المقبولة لها.
{
"ci": {
"collect": {
"numberOfRuns": 3,
"settings": {
"preset": "desktop"
}
},
"assert": {
"assertions": {
"categories:performance": ["error", { "minScore": 0.9 }],
"largest-contentful-paint": ["error", { "maxNumericValue": 2500 }],
"first-input-delay": ["error", { "maxNumericValue": 100 }],
"cumulative-layout-shift": ["error", { "maxNumericValue": 0.1 }]
}
},
"upload": {
"target": "filesystem"
}
}
}في هذا التكوين، نؤكد أن فئة الأداء الإجمالية يجب أن تحصل على درجة لا تقل عن 0.9. كما نحدد حدوداً رقمية صارمة لـ LCP (2.5 ثانية) و FID (100 مللي ثانية) و CLS (0.1). إذا تم تجاوز أي من هذه الحدود، سيفشل بناء CI.
التكامل مع GitHub Actions
الآن، دعنا نربط هذا بخط أنابيب CI/CD الخاص بك. أنشئ ملف سير عمل في .github/workflows/performance.yml. سيقوم هذا النص البرمجي بالتشغيل عند كل طلب سحب، وجمع المقاييس، وإصدار النتائج.
name: Performance CI
on: [pull_request]
jobs:
lighthouse-ci:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Install dependencies
run: npm ci
- name: Run local server
run: npm start &
working-directory: ./
continue-on-error: true
- name: Audit URLs
run: npx @lhci/cli@0.9.x collect --url=http://localhost:3000
لضمان توفير خط الأنابيب لملاحظات قابلة للتنفيذ، يجب عليك أيضاً تكوين إضافة Lighthouse CI لنشر التعليقات على طلب السحب. يوفر هذا رؤية فورية للمطورين حول المقاييس المحددة التي فشلت وبنسبة مقدار الفشل.
التنبيهات والمراقبة المتقدمة
بينما يعد فشل البناء فعالاً في منع دمج الأكواد السيئة، فإنه لا يساعد في تتبع الاتجاهات بمرور الوقت أو التنبيه إلى الشذوذ في بيئة الإنتاج. للمراقبة الشاملة، فكر في التكامل مع خدمات مثل Google Lighthouse CI API لرفع التقارير إلى لوحة تحكم. يمكنك بعد ذلك إعداد تنبيهات في Slack أو البريد الإلكتروني إذا أدى النشر إلى انخفاض كبير في درجات Core Web Vitals مقارنةً بخط الأساس.
الخاتمة
يحول تنفيذ مراقبة Core Web Vitals في خط أنابيب CI/CD الأداء من مفهوم مجرد إلى مقياس جودة قابل للقياس والإنفاذ. من خلال أتمتة هذه الفحوصات، تمنح فريقك القدرة على الإصدار بسرعة دون التضحية بتجربة المستخدم. ابدأ بشكل صغير بإضافة مقياس واحد، وقم بتوسيع ميزانيات الأداء تدريجياً مع نضج تطبيقك. النتيجة هي تطبيق ويب أكثر متانة وأداءً وسهولة في الاستخدام.