Lighthouse CI برای وردپرس چطور کیفیت را تضمین می‌کند؟

Lighthouse CI برای وردپرس یعنی اجرای خودکار تست‌های کیفیت عملکرد در جریان استقرار، به‌گونه‌ای که افت کیفیت پیش از رسیدن به محیط تولید شناسایی و متوقف شود.

Lighthouse CI (Continuous Integration) یک ابزار متن‌باز است که Lighthouse را در خط لوله استقرار ادغام می‌کند.

سه جزء اصلی این ابزار وجود دارد: سرور Lighthouse، جریان استقرار و قواعد کیفیت.

بدون این ابزار، ارزیابی کیفیت به یک کار دستی و پراکنده تبدیل می‌شود که در بازه‌های شلوغ فراموش می‌گردد.

هدف این نوشته، ارائه چارچوب عملی برای پیاده‌سازی این ابزار در پروژه‌های وردپرسی است.

در پروژه‌ای که تیم چند نفره داشت، افت کیفیت معمولاً در بازه‌های شلوغ اتفاق می‌افتاد: کسی یک کتابخانه جدید اضافه می‌کرد، کسی دیگر یک افزونه سنگین نصب می‌کرد و پس از چند هفته، امتیاز کیفیت سایت به‌طور محسوس افت می‌کرد. افزودن Lighthouse CI به جریان استقرار، این افت تدریجی را متوقف کرد. حالا هر تغییر، پیش از ادغام، ارزیابی می‌شد.

Lighthouse CI دقیقاً چه چیزی را می‌سنجد

Lighthouse CI یک ابزار است که Lighthouse را در خط لوله استقرار ادغام می‌کند. Lighthouse (Lighthouse software) ابزار متن‌باز گوگل برای تحلیل کیفیت صفحات وب است که معیارهای عملکرد، دسترس‌پذیری، بهترین شیوه‌ها و سئو را می‌سنجد.

Lighthouse CI این تحلیل را خودکار می‌کند. به‌جای اجرای دستی Lighthouse روی صفحات مختلف، ابزار در هر استقرار، صفحات مشخصی را تحلیل می‌کند و نتایج را با آستانه‌های تعریف‌شده مقایسه می‌نماید.

سه دسته معیار اصلی Lighthouse CI می‌سنجد. دسته اول، معیارهای عملکرد شامل LCP، INP، CLS و زمان‌های بارگذاری. دسته دوم، معیارهای دسترس‌پذیری شامل ساختار معنایی و خوانایی. دسته سوم، معیارهای سئو و بهترین شیوه‌ها.

نکته مهم این است که این ابزار در سطح کد کار می‌کند، نه در محیط تولید. یعنی افت کیفیت در زمان تغییر کد شناسایی می‌شود، نه در زمان مواجهه کاربر با آن.

Lighthouse CI یک ابزار کیفیت است، نه یک ابزار گزارش؛ هدف آن جلوگیری از افت است، نه فقط ثبت وضعیت.

چرا پروژه‌های وردپرسی به آن نیاز دارند

پروژه‌های وردپرسی به دلایل مشخصی به این ابزار نیاز دارند. شناخت این دلایل، تصمیم پیاده‌سازی را توجیه می‌کند.

دلیل اول، ماهیت پویا و مبتنی بر افزونه وردپرس است. هر افزونه‌ای که نصب می‌شود، می‌تواند کیفیت سایت را تحت تأثیر قرار دهد. با افزایش تعداد افزونه‌ها، احتمال افت کیفیت افزایش می‌یابد.

دلیل دوم، تعداد بالای تغییرات است. در پروژه‌های فعال، تغییرات کد، محتوا و تنظیمات به‌طور مداوم انجام می‌شوند. بدون پایش خودکار، ارزیابی هر تغییر به‌صورت دستی عملاً غیرممکن است.

دلیل سوم، توزیع مسئولیت بین اعضای تیم است. در تیم‌های چند نفره، هر عضو ممکن است تغییراتی اعمال کند که اثر تجمعی آن در طول زمان منفی باشد. Lighthouse CI این اثر را پیش از تبدیل به مشکل شناسایی می‌کند.

دلیل چهارم، فشار زمانی در محیط تولید است. شناسایی مشکل در محیط توسعه، هزینه کمتری از شناسایی و رفع آن در محیط تولید دارد. Lighthouse CI این شناسایی را به‌طور خودکار انجام می‌دهد.

مسائل مرتبط با جریان استقرار و کیفیت در چارچوب پیاده‌سازی CI/CD برای پروژه‌های وردپرسی به‌تفصیل آمده است.

معماری ابزار و اجزای اصلی

Lighthouse CI از چند جزء اصلی تشکیل شده که هر یک نقش مشخصی ایفا می‌کند.

جزء اول، سرور Lighthouse CI است که نتایج آزمون‌ها را ذخیره می‌کند و امکان مقایسه بین اجراهای مختلف را فراهم می‌سازد. این سرور می‌تواند محلی یا میزبانی‌شده باشد.

جزء دوم، ابزار خط فرمان است که آزمون را اجرا می‌کند و نتایج را به سرور ارسال می‌نماید. این ابزار در خط لوله استقرار فراخوانی می‌شود.

جزء سوم، فایل تنظیمات است که مشخص می‌کند کدام صفحات آزمون شوند و چه قواعدی اعمال گردد.

# Install Lighthouse CI
npm install -g @lhci/cli

# Run audit
lhci autorun

این دو دستور، پایه استفاده از ابزار را نشان می‌دهند.

مسائل مرتبط با ادغام ابزار در خط لوله در آموزش GitHub Actions به‌تفصیل آمده است.

پیکربندی و فایل تنظیمات

پیکربندی Lighthouse CI از طریق یک فایل مشخص انجام می‌شود. این فایل مشخص می‌کند کدام صفحات آزمون شوند و چه قواعدی اعمال گردد.

{
  "ci": {
    "collect": {
      "url": [
        "http://localhost:8000/",
        "http://localhost:8000/blog/",
        "http://localhost:8000/shop/"
      ],
      "numberOfRuns": 3,
      "settings": {
        "preset": "desktop"
      }
    },
    "assert": {
      "assertions": {
        "categories:performance": ["error", { "minScore": 0.85 }],
        "categories:accessibility": ["error", { "minScore": 0.90 }],
        "categories:seo": ["warn", { "minScore": 0.90 }]
      }
    },
    "upload": {
      "target": "temporary-public-storage"
    }
  }
}

در این پیکربندی، سه بخش اصلی تعریف شده است. بخش collect مشخص می‌کند کدام صفحات آزمون شوند و چند بار. بخش assert قواعد کیفیت را تعیین می‌کند. بخش upload مقصد ذخیره نتایج را مشخص می‌کند.

پارامتر numberOfRuns تعداد اجرای هر آزمون را تعیین می‌کند. مقدار بیشتر، نتایج پایدارتری تولید می‌کند اما زمان اجرا را افزایش می‌دهد.

پارامتر preset شرایط آزمون را تعیین می‌کند. مقدار desktop شرایط دسکتاپ و مقدار mobile شرایط موبایل را شبیه‌سازی می‌کند.

Assertions و تعریف قواعد کیفیت

Assertions قلب Lighthouse CI هستند. این بخش تعیین می‌کند کدام معیارها با چه آستانه‌ای پذیرفته شوند.

سه سطح شدت برای هر assertion وجود دارد. سطح error باعث شکست آزمون و توقف جریان استقرار می‌شود. سطح warn هشدار تولید می‌کند اما جریان را متوقف نمی‌کند. سطح off معیار را نادیده می‌گیرد.

"assertions": {
  "largest-contentful-paint": ["error", { "maxNumericValue": 2500 }],
  "cumulative-layout-shift": ["error", { "maxNumericValue": 0.1 }],
  "total-blocking-time": ["warn", { "maxNumericValue": 300 }],
  "unused-javascript": ["warn", { "maxLength": 0 }]
}

این پیکربندی، سه معیار مشخص را با آستانه‌های عددی تعریف می‌کند.

مسئله مهم در تعریف assertions، انتخاب آستانه‌های واقع‌بینانه است. آستانه‌های بسیار سختگیرانه، هشدارهای مکرر تولید می‌کنند که به بی‌اعتباری ابزار منجر می‌شود. آستانه‌های بسیار آسان، هدف بهبود را از بین می‌برند.

رویکرد متعادل، شروع با آستانه‌های میانه و تدریجاً سختگیرانه‌تر کردن آن‌ها است. این رویکرد، امکان تطبیق تیم با ابزار را فراهم می‌کند.

Performance Budgets و تعیین سقف

Performance Budgets یک مفهوم مکمل Assertions است. این مفهوم، سقف مشخصی برای معیارهای مختلف تعیین می‌کند و از عبور از آن سقف جلوگیری می‌نماید.

سه نوع Budget اصلی وجود دارد. نوع اول، Budget بر اساس زمان است که سقف زمانی برای معیارهایی مانند LCP تعیین می‌کند. نوع دوم، Budget بر اساس حجم است که سقف حجم برای منابعی مانند JavaScript و CSS مشخص می‌کند. نوع سوم، Budget بر اساس تعداد است که سقف تعداد منابع یا درخواست‌ها را تعیین می‌نماید.

"budgets": [
  {
    "path": "/*",
    "timings": [
      { "metric": "interactive", "budget": 3000 },
      { "metric": "first-contentful-paint", "budget": 1500 }
    ],
    "resourceSizes": [
      { "resourceType": "script", "budget": 200 },
      { "resourceType": "stylesheet", "budget": 100 }
    ],
    "resourceCounts": [
      { "resourceType": "third-party", "budget": 10 }
    ]
  }
]

این پیکربندی، سقف مشخصی برای زمان، حجم و تعداد منابع تعیین می‌کند. عبور از این سقف، به شکست آزمون منجر می‌شود.

مسئله مهم در تعریف Budgets، هماهنگی با نیازهای واقعی پروژه است. در پروژه‌های وردپرسی، برخی افزونه‌ها حجم قابل توجهی اضافه می‌کنند. Budgets باید بر اساس واقعیت پروژه تعریف شوند، نه بر اساس آرمان.

مسائل مرتبط با فشرده‌سازی منابع در این چارچوب در فشرده‌سازی Brotli در وردپرس آمده است.

ادغام با جریان استقرار

ادغام Lighthouse CI با جریان استقرار، بخش اصلی پیاده‌سازی است. این ابزار باید در یک مرحله مشخص از جریان، پیش از رسیدن کد به محیط تولید، اجرا شود.

سه نقطه ادغام اصلی وجود دارد. نقطه اول، پیش از ادغام Pull Request است که از ورود کد مشکل‌دار به شاخه اصلی جلوگیری می‌کند. نقطه دوم، پس از ادغام و پیش از استقرار است. نقطه سوم، پس از استقرار در محیط آزمایشی است.

ترتیب استاندارد، اجرای آزمون پس از ساخت نسخه آزمایشی و پیش از استقرار تولید است. این ترتیب، امکان آزمون در شرایط نزدیک به تولید را فراهم می‌کند.

# Typical CI pipeline steps
1. Install dependencies
2. Build project
3. Deploy to staging environment
4. Run Lighthouse CI against staging
5. If tests pass, deploy to production

این ترتیب، از رسیدن کد مشکل‌دار به محیط تولید جلوگیری می‌کند.

پیاده‌سازی با GitHub Actions

GitHub Actions یکی از رایج‌ترین پلتفرم‌های CI/CD است که امکان ادغام Lighthouse CI را فراهم می‌کند.

name: Lighthouse CI
on: [push, pull_request]

jobs:
  lighthouse:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: "18"
      - name: Install dependencies
        run: npm install
      - name: Build project
        run: npm run build
      - name: Run Lighthouse CI
        run: |
          npm install -g @lhci/cli
          lhci autorun
        env:
          LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}

این پیکربندی، Lighthouse CI را در هر push و pull request اجرا می‌کند.

مسائل مرتبط با راه‌اندازی پروژه وردپرسی در محیط CI/CD در توسعه وردپرس با محیط لوکال آمده است.

پیاده‌سازی با GitLab CI

GitLab CI نیز امکان ادغام Lighthouse CI را فراهم می‌کند. پیکربندی در این پلتفرم متفاوت است اما منطق یکسان است.

stages:
  - build
  - test

lighthouse:
  stage: test
  image: node:18
  script:
    - npm install -g @lhci/cli
    - npm install
    - npm run build
    - lhci autorun
  only:
    - merge_requests
    - main

این پیکربندی، آزمون را در مرحله test اجرا می‌کند.

مسائل مرتبط با مدیریت شاخه‌ها و ادغام در برنچ در Git آمده است.

عوامل اختصاصی وردپرس

پیاده‌سازی Lighthouse CI در پروژه‌های وردپرسی چند چالش اختصاصی دارد که باید لحاظ شوند.

چالش اول، راه‌اندازی محیط آزمایشی است. محیط آزمایشی باید مشابه محیط تولید باشد، شامل همان افزونه‌ها، همان داده‌ها و همان پیکربندی سرور.

چالش دوم، داده‌های پویا هستند. صفحات وردپرس پویا هستند و نتایج آزمون می‌تواند بین اجراها متفاوت باشد. راه‌حل، اجرای چندباره آزمون و میانگین‌گیری است.

چالش سوم، وابستگی به پایگاه داده است. سایت وردپرسی برای اجرا به پایگاه داده نیاز دارد. محیط آزمون باید پایگاه داده نمونه با داده‌های واقعی داشته باشد.

چالش چهارم، افزونه‌های شخص ثالث هستند. برخی افزونه‌ها ممکن است در محیط CI/CD به‌درستی کار نکنند یا به سرویس‌های خارجی وابسته باشند.

مسائل مرتبط با ساختاربندی پروژه وردپرسی در ساختاربندی پروژه توسعه وردپرس آمده است.

تحلیل نتایج و گزارش‌ها

Lighthouse CI چند نوع گزارش تولید می‌کند. شناخت این گزارش‌ها، پیش‌نیاز استفاده مؤثر از ابزار است.

گزارش اول، گزارش خطاهای Assertion است. این گزارش نشان می‌دهد کدام قواعد کیفیت نقض شده‌اند.

گزارش دوم، گزارش مقایسه است. این گزارش نتایج آزمون فعلی را با آزمون قبلی مقایسه می‌کند.

گزارش سوم، گزارش تفصیلی است. این گزارش همه معیارها را با امتیاز و جزئیات نشان می‌دهد.

# Analyze results locally
lhci open

# View detailed report
lhci upload --target=filesystem --outputDir=./lhci-report

این دستورات، امکان مشاهده گزارش‌ها را فراهم می‌کنند.

مدیریت هشدارهای نادرست

یکی از چالش‌های اصلی در استفاده از Lighthouse CI، هشدارهای نادرست است. این هشدارها می‌توانند به بی‌اعتباری ابزار منجر شوند.

سه منبع اصلی هشدار نادرست وجود دارد. منبع اول، نوسان طبیعی نتایج است. منبع دوم، تفاوت شرایط آزمون است. منبع سوم، تفاوت محیط آزمایشی و تولید.

راه‌حل منبع اول، اجرای چندباره آزمون و میانگین‌گیری است. پارامتر numberOfRuns این کار را انجام می‌دهد.

راه‌حل منبع دوم، تثبیت شرایط آزمون است. استفاده از یک preset مشخص و پرهیز از تغییرات مکرر.

راه‌حل منبع سوم، هماهنگی محیط آزمایشی با محیط تولید است. اصول تفصیلی در مشخصات سرور وردپرس آمده است.

جدول تصمیم‌گیری پیاده‌سازی

سناریو	نقطه ادغام	سطح سختگیری
پروژه شخصی	پس از push	warn
پروژه تیمی کوچک	pull request	error برای عملکرد
پروژه سازمانی	pull request + pre-deploy	error برای همه معیارها
فروشگاه اینترنتی	pull request + post-deploy	سختگیرانه با بودجه مشخص

اشتباهات رایج

نخستین اشتباه، تعریف آستانه‌های بسیار سختگیرانه از ابتدا است. این رویکرد، هشدارهای مکرر تولید می‌کند و تیم را به بی‌اعتباری ابزار سوق می‌دهد.

دومین اشتباه، نبود هماهنگی محیط آزمایشی با تولید است. اگر محیط آزمایشی با تولید متفاوت باشد، نتایج معنادار نخواهند بود.

سومین اشتباه، نادیده گرفتن نوسان طبیعی نتایج است. اجرای یک‌باره آزمون، تصویر ناپایداری ارائه می‌دهد.

چهارمین اشتباه، تمرکز صرف بر یک معیار است. کیفیت کلی سایت، ترکیبی از چند معیار است.

پنجمین اشتباه، نبود پیگیری نتایج است. گزارش‌هایی که بررسی نشوند، ارزش عملی ندارند.

ششمین اشتباه، فراموش کردن تفاوت دستگاه‌ها است. آزمون تنها در یک شرایط، تصویر ناقصی ارائه می‌دهد.

هفتمین اشتباه، نبود ادغام با جریان استقرار است. اجرای دستی Lighthouse CI، همان مشکل قبلی را با شکل دیگری بازتولید می‌کند.

پرسش‌های پرتکرار درباره Lighthouse CI در وردپرس

Lighthouse CI چیست و چه تفاوتی با Lighthouse دارد؟

Lighthouse ابزار تحلیل کیفیت صفحات است که به‌صورت دستی اجرا می‌شود. Lighthouse CI این تحلیل را خودکار می‌کند و در جریان استقرار ادغام می‌نماید.

چرا پروژه‌های وردپرسی به Lighthouse CI نیاز دارند؟

به دلیل ماهیت پویا، تعداد بالای افزونه‌ها، تغییرات مکرر و توزیع مسئولیت بین اعضای تیم. این ابزار افت کیفیت را پیش از رسیدن به تولید شناسایی می‌کند.

چگونه Lighthouse CI را در GitHub Actions پیاده کنم؟

با تعریف یک workflow که Lighthouse CI را در مرحله test اجرا می‌کند. بخش اصلی، تنظیم فایل .lighthouserc.json و افزودن مرحله اجرای آن است.

آیا Lighthouse CI روی محیط تولید اجرا می‌شود؟

معمولاً نه. این ابزار در محیط آزمایشی یا CI/CD اجرا می‌شود تا از رسیدن کد مشکل‌دار به تولید جلوگیری کند. اجرای آن روی تولید می‌تواند نتایج نادرست بدهد.

چند وقت یک‌بار باید Lighthouse CI اجرا شود؟

در هر push و pull request. این اجرای مکرر، از افت تدریجی جلوگیری می‌کند.

آیا Lighthouse CI جایگزین اندازه‌گیری میدانی است؟

خیر. Lighthouse CI داده آزمایشگاهی تولید می‌کند. داده میدانی از CrUX می‌آید. این دو مکمل یکدیگرند.

چگونه هشدارهای نادرست را کاهش دهم؟

با اجرای چندباره آزمون، تثبیت شرایط آزمون و هماهنگی محیط آزمایشی با تولید.

آیا Lighthouse CI نیازمند سرور اختصاصی است؟

خیر. سرور Lighthouse CI می‌تواند محلی یا میزبانی‌شده باشد. برای بیشتر پروژه‌ها، ذخیره‌سازی موقت کافی است.

آیا Lighthouse CI برای همه پروژه‌های وردپرسی مناسب است؟

برای پروژه‌های تیمی و پروژه‌هایی که به کیفیت اهمیت می‌دهند، بله. برای پروژه‌های شخصی کوچک، ممکن است سربار اضافه باشد.

یک نکته برای ادامه مسیر

Lighthouse CI یک ابزار کیفیت است که در طول زمان ارزش خود را نشان می‌دهد. تفاوت میان یک پروژه با کیفیت پایدار و یک پروژه با کیفیت نوسانی، اغلب در همین توجه مستمر نهفته است.

اگر روی پروژه خودتان این مسیر را طی کرده‌اید، خوشحال می‌شوم بدانم کدام بخش بیشترین زمان را گرفت: تنظیم محیط آزمایشی، تعریف آستانه‌های مناسب یا ادغام با جریان استقرار. تجربه‌تان را در دیدگاه‌ها بنویسید.