מעקב אחר ביצועים באמצעות Lighthouse CI

איך מוסיפים את Lighthouse למערכת אינטגרציה רציפה, כמו GitHub Actions.

Katie Hempenius
Katie Hempenius
X

Lighthouse CI הוא חבילת כלים לשימוש ב-Lighthouse במהלך אינטגרציה רציפה. אפשר לשלב את Lighthouse CI בתהליכי העבודה של המפתחים בדרכים רבות. המדריך הזה עוסק בנושאים הבאים:

  • באמצעות ה-CLI של Lighthouse CI.
  • הגדרת ספק ה-CI להרצת Lighthouse CI.
  • הגדרת GitHub Action ובדיקת סטטוס ל-Lighthouse CI. כך תוצאות Lighthouse יוצגו באופן אוטומטי בבקשות המשיכה ב-GitHub.
  • יצירת מרכז בקרה לביצועים ואחסון נתונים לדוחות Lighthouse.

סקירה כללית

Lighthouse CI הוא חבילת כלים בחינם שמאפשרת להשתמש ב-Lighthouse למעקב אחר ביצועים. דוח Lighthouse יחיד מספק תמונת מצב של ביצועי דף אינטרנט בזמן שהוא פועל. ב-Lighthouse CI מוצגים השינויים שחלו בתוצאות האלה לאורך זמן. אפשר להשתמש בכך כדי לזהות את ההשפעה של שינויים ספציפיים בקוד או לוודא שסף הביצועים מתקיים במהלך תהליכי השילוב המתמשך. מעקב הביצועים הוא התרחיש הנפוץ ביותר לשימוש ב-Lighthouse CI, אבל אפשר להשתמש בו גם כדי לעקוב אחרי היבטים אחרים בדוח Lighthouse – למשל, אופטימיזציה למנועי חיפוש או נגישות.

הפונקציונליות העיקרית של Lighthouse CI מסופקת על-ידי ממשק שורת הפקודה CI של Lighthouse. (הערה: זהו כלי נפרד מ-Lighthouse CLI). CLI של Lighthouse CI מספק קבוצה של פקודות לשימוש ב-Lighthouse CI. לדוגמה, הפקודה autorun עורכת כמה הפעלות של Lighthouse, מזהה את הדוח החציוני של Lighthouse ומעלה את הדוח לאחסון. אפשר להתאים אישית את ההתנהגות הזו באופן נרחב על ידי העברת דגלים נוספים או התאמה אישית של קובץ התצורה של Lighthouse CI,‏ lighthouserc.js.

למרות שהפונקציונליות העיקרית של Lighthouse CI מוטמעת בעיקר ב-Lighthouse CI CLI, משתמשים ב-Lighthouse CI בדרך כלל באחת מהגישות הבאות:

  • הפעלת Lighthouse CI כחלק מאינטגרציה רציפה
  • שימוש בפעולת GitHub CI GitHub שמריצים ומגיבים על כל בקשת משיכה
  • מעקב אחרי הביצועים לאורך זמן באמצעות מרכז הבקרה שסופק על ידי שרת Lighthouse.

כל הגישות האלה מבוססות על CLI של Lighthouse CI.

חלופות ל-Lighthouse CI כוללות שירותי מעקב ביצועים של צד שלישי או כתיבת סקריפט משלכם לאיסוף נתוני ביצועים במהלך תהליך ה-CI. כדאי להשתמש בשירות של צד שלישי אם אתם מעדיפים שמישהו אחר ינהל את השרת למעקב אחר ביצועים ואת מכשירי הבדיקה, או אם אתם רוצים יכולות התראות (כמו אימייל או שילוב עם Slack) בלי שתצטרכו לפתח את התכונות האלה בעצמכם.

שימוש מקומי ב-Lighthouse CI

בקטע הזה מוסבר איך להריץ ולהתקין את Lighthouse CI CLI באופן מקומי, ואיך להגדיר את lighthouserc.js. הפעלת ה-CLI של Lighthouse CI באופן מקומי היא הדרך הקלה ביותר לוודא שה-lighthouserc.js מוגדר בצורה נכונה.

  1. מתקינים את ה-CLI של Lighthouse CI.

    npm install -g @lhci/cli

    כדי להגדיר את Lighthouse CI, צריך להוסיף קובץ lighthouserc.js ברמה הבסיסית (root) של המאגר של הפרויקט. הקובץ הזה הוא חובה והוא יכלול פרטי הגדרות שקשורים ל-Lighthouse CI. אפשר להגדיר את Lighthouse CI לשימוש בלי מאגר git, אבל ההוראות במאמר הזה מבוססות על ההנחה שמאגר הפרויקט מוגדר לשימוש ב-git.

  2. יוצרים קובץ תצורה בשם lighthouserc.js ברמה הבסיסית של המאגר.

    touch lighthouserc.js

  3. צריך להוסיף את הקוד הבא ל-lighthouserc.js. הקוד הזה הוא הגדרה ריקה של Lighthouse CI. אתם תוסיפו אותם להגדרות האלה בשלבים מאוחרים יותר.

    module.exports = {
  ci: {
    collect: {
      /* Add configuration here */
    },
    upload: {
      /* Add configuration here */
    },
  },
};

  4. בכל פעם ש-Lighthouse CI פועל, הוא מפעיל שרת כדי להציג את האתר. השרת הזה מאפשר ל-Lighthouse לטעון את האתר גם כשאין שרתים אחרים שפועלים. בסיום ההרצה של Lighthouse CI, השרת יכבה באופן אוטומטי. כדי להבטיח שההצגה תפעל כמו שצריך, צריך להגדיר את המאפיינים staticDistDir או startServerCommand.

    אם האתר סטטי, מוסיפים את המאפיין staticDistDir לאובייקט ci.collect כדי לציין את המיקום של הקבצים הסטטיים. במהלך בדיקת האתר, Lighthouse CI ישתמש בשרת משלו כדי להציג את הקבצים האלה. אם האתר שלכם לא סטטי, צריך להוסיף את המאפיין startServerCommand לאובייקט ci.collect כדי לציין את הפקודה שמפעילה את השרת. Lighthouse CI יתחיל תהליך חדש לשרת במהלך הבדיקה, ותשבית אותו לאחר מכן.

    // Static site example
collect: {
  staticDistDir: './public',
}

    // Dynamic site example
collect: {
  startServerCommand: 'npm run start',
}

  5. מוסיפים את המאפיין url לאובייקט ci.collect כדי לציין את כתובות ה-URL שמערכת Lighthouse CI צריכה להריץ את Lighthouse עליהן. הערך של המאפיין url צריך להיכלל כמערך של כתובות URL. המערך הזה יכול להכיל כתובת URL אחת או יותר. כברירת מחדל, Lighthouse CI יפעיל את Lighthouse שלוש פעמים לכל כתובת URL.

    collect: {
  // ...
  url: ['http://localhost:8080']
}

  6. מוסיפים את המאפיין target לאובייקט ci.upload ומגדירים את הערך כ-'temporary-public-storage'. הדוחות של Lighthouse שנאספים על ידי Lighthouse CI יעלו לאחסון ציבורי זמני. הדוח יישאר שם למשך שבעה ימים ולאחר מכן יימחק באופן אוטומטי. במדריך ההגדרה הזה נעשה שימוש באפשרות ההעלאה 'אחסון ציבורי זמני' כי היא קלה להגדרה. מידע על דרכים אחרות לאחסון דוחות Lighthouse זמין במסמכי העזרה.

    upload: {
  target: 'temporary-public-storage',
}

    מיקום האחסון של הדוח יהיה דומה לזה:

    https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/1580152437799-46441.report.html

    (כתובת ה-URL הזו לא תפעל כי הדוח כבר נמחק).

  7. מריצים את ה-CLI של Lighthouse CI מהטרמינל באמצעות הפקודה autorun. הפקודה הזו תפעיל את Lighthouse שלוש פעמים ותעלה את דוח Lighthouse החציוני.

    lhci autorun

    אם הגדרתם את Lighthouse CI בצורה נכונה, הפעלת הפקודה הזו אמורה להניב פלט דומה לזה:

    ✅  .lighthouseci/ directory writable
✅  Configuration file found
✅  Chrome installation found
⚠️   GitHub token not set
Healthcheck passed!

Started a web server on port 65324...
Running Lighthouse 3 time(s) on http://localhost:65324/index.html
Run #1...done.
Run #2...done.
Run #3...done.
Done running Lighthouse!

Uploading median LHR of http://localhost:65324/index.html...success!
Open the report at https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/1591720514021-82403.report.html
No GitHub token set, skipping GitHub status check.

Done running autorun.

    אפשר להתעלם מההודעה GitHub token not set בפלט המסוף. אסימון GitHub נדרש רק אם רוצים להשתמש ב-Lighthouse CI עם GitHub Action. בהמשך המאמר נסביר איך מגדירים פעולת GitHub.

    לחיצה על הקישור בפלט שמתחיל ב-https://storage.googleapis.com... תעביר אתכם לדוח Lighthouse שתואם להרצה החציונית של Lighthouse.

    אפשר לשנות את הגדרות ברירת המחדל שבהן autorun משתמש באמצעות שורת הפקודה או באמצעות lighthouserc.js. לדוגמה, ההגדרה של lighthouserc.js שבהמשך מציינת שצריך לאסוף חמישה ריצות של Lighthouse בכל פעם ש-autorun מופעל.

  8. מעדכנים את lighthouserc.js כך שישתמש במאפיין numberOfRuns:

    module.exports = {
    // ...
    collect: {
      numberOfRuns: 5
    },
  // ...
  },
};

  9. מריצים מחדש את הפקודה autorun:

    lhci autorun

    בפלט של הטרמינל אמור להופיע שהפעלתם את Lighthouse חמש פעמים במקום שלוש פעמים כברירת מחדל:

    ✅  .lighthouseci/ directory writable
✅  Configuration file found
✅  Chrome installation found
⚠️   GitHub token not set
Healthcheck passed!

Automatically determined ./dist as `staticDistDir`.
Set it explicitly in lighthouserc.json if incorrect.

Started a web server on port 64444...
Running Lighthouse 5 time(s) on http://localhost:64444/index.html
Run #1...done.
Run #2...done.
Run #3...done.
Run #4...done.
Run #5...done.
Done running Lighthouse!

Uploading median LHR of http://localhost:64444/index.html...success!
Open the report at https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/1591716944028-6048.report.html
No GitHub token set, skipping GitHub status check.

Done running autorun.

    מידע על אפשרויות הגדרה נוספות זמין במאמרי העזרה בנושא הגדרות אישיות של Lighthouse CI.

הגדרה של תהליך CI להרצת Lighthouse CI

אפשר להשתמש ב-Lighthouse CI עם כלי ה-CI המועדף. בקטע Configure Your CI Provider במסמכי התיעוד של Lighthouse CI יש דוגמאות קוד שמראות איך לשלב את Lighthouse CI בקובצי התצורה של כלי CI נפוצים. באופן ספציפי, דוגמאות הקוד האלה מראות איך להריץ את Lighthouse CI כדי לאסוף מדידות ביצועים במהלך תהליך ה-CI.

שימוש ב-Lighthouse CI לאיסוף מדידות ביצועים הוא מקום טוב להתחיל בו את מעקב הביצועים. עם זאת, יכול להיות שמשתמשים מתקדמים ירצו לבצע צעד נוסף ולהשתמש ב-Lighthouse CI כדי להיכשל לגרסאות build שלא עומדות בקריטריונים מוגדרים מראש, כמו העברת ביקורות מסוימות של Lighthouse או עמידה בכל תקציבי הביצועים. ההתנהגות הזו מוגדרת באמצעות המאפיין assert של הקובץ lighthouserc.js.

ב-Lighthouse CI יש תמיכה בשלושה רמות של טענות נכוֹנוּת (assertions):

  • off: התעלמות מטענות נכוֹנוּת (assertions)
  • warn: כשלים בהדפסה ל-stderr
  • error: כשלים בהדפסה ל-stderr ויציאה מ-Lighthouse CI עם קוד יציאה שאינו אפס

בהמשך מוצגת דוגמה להגדרה של lighthouserc.js שכוללת טענות נכוֹנוּת (assertions). הוא מגדיר טענות נכוֹנוּת (assertions) לגבי הציונים של קטגוריות הביצועים והנגישות ב-Lighthouse. כדי לנסות את זה, צריך להוסיף את טענות הנכונות (assertions) שמוצגות למטה לקובץ lighthouserc.js, ואז להריץ מחדש את Lighthouse CI.

module.exports = {
  ci: {
    collect: {
      // ...
    },
    assert: {
      assertions: {
        'categories:performance': ['warn', {minScore: 1}],
        'categories:accessibility': ['error', {minScore: 1}]
      }
    },
    upload: {
      // ...
    },
  },
};

הפלט שנוצר במסוף נראה כך:

צילום מסך של הודעת האזהרה שנוצרה על ידי Lighthouse CI

למידע נוסף על טענות נכוֹנוּת (assertions) של Lighthouse CI, אפשר לעיין במסמכי התיעוד.

הגדרת GitHub Action להרצת Lighthouse CI

אפשר להשתמש ב-GitHub Action כדי להריץ את Lighthouse CI. כך ייווצר דוח Lighthouse חדש בכל פעם ששינוי קוד יזוזם לכל הסתעפות של מאגר ב-GitHub. אפשר להשתמש באפשרות הזו בשילוב עם בדיקת סטטוס כדי להציג את התוצאות האלה בכל בקשת משיכה.

צילום מסך של בדיקת סטטוס ב-GitHub

  1. יוצרים ספרייה בשם .github/workflows בתיקיית השורש של המאגר. תהליכי העבודה של הפרויקט יישמרו בספרייה הזו. תהליך עבודה הוא תהליך שפועל בזמן שנקבע מראש (למשל, כשדוחפים את הקוד) והוא מורכב מפעולה אחת או יותר.

    mkdir .github
mkdir .github/workflows

  2. יוצרים קובץ בשם lighthouse-ci.yaml ב-.github/workflows. הקובץ הזה יכיל את ההגדרות של תהליך עבודה חדש.

    touch lighthouse-ci.yaml

  3. מוסיפים את הטקסט הבא ל-lighthouse-ci.yaml.

    name: Build project and run Lighthouse CI
on: [push]
jobs:
  lhci:
    name: Lighthouse CI
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - name: Use Node.js 10.x
        uses: actions/setup-node@v1
        with:
          node-version: 10.x
      - name: npm install
        run: |
          npm install
      - name: run Lighthouse CI
        run: |
          npm install -g @lhci/cli@0.3.x
          lhci autorun --upload.target=temporary-public-storage || echo "LHCI failed!"

    ההגדרה הזו מגדירה תהליך עבודה שמורכב ממשימה אחת שתפעל בכל פעם שקוד חדש יידחף למאגר. למשימה הזו יש ארבעה שלבים:

    • איך בודקים את המאגר שבו יתבצע הרצת Lighthouse CI
    • התקנה והגדרה של צומת
    • התקנת חבילות ה-npm הנדרשות
    • מריצים את Lighthouse CI ומעלים את התוצאות לאחסון ציבורי זמני.

  4. שומרים את השינויים האלה ודוחפים אותם ל-GitHub. אם פעלתם לפי השלבים שלמעלה, דחיפת הקוד ל-GitHub תפעיל את תהליך העבודה שהוספתם.

  5. כדי לוודא ש-Lighthouse CI הופעל וכדי לצפות בדוח שנוצר, עוברים לכרטיסייה Actions בפרויקט. תהליך העבודה Build project and Run Lighthouse CI אמור להופיע מתחת להתחייבות האחרונה שלכם.

    צילום מסך של הכרטיסייה 'הגדרות' ב-GitHub

    אפשר לעבור לדוח Lighthouse שמתאים להתחייבות ספציפית בכרטיסייה Actions. לוחצים על השמירה, לוחצים על שלב תהליך העבודה Lighthouse CI ואז מרחיבים את התוצאות של השלב הרצת Lighthouse CI.

    צילום מסך של הכרטיסייה 'הגדרות' ב-GitHub

    הגדרתם עכשיו פעולת GitHub להרצת Lighthouse CI. האפשרות הזו שימושית במיוחד בשילוב עם בדיקת סטטוס ב-GitHub.

הגדרת בדיקת סטטוס ב-GitHub

בדיקת סטטוס, אם היא מוגדרת, היא הודעה שמופיעה בכל בקשת תיקון, ובדרך כלל כוללת מידע כמו תוצאות הבדיקה או הצלחת ה-build.

צילום מסך של הכרטיסייה 'הגדרות' ב-GitHub

בשלבים הבאים מוסבר איך להגדיר בדיקת סטטוס ל-Lighthouse CI.

  1. עוברים אל דף האפליקציה של Lighthouse CI ב-GitHub ולוחצים על Configure.

  2. (אופציונלי) אם אתם חברים במספר ארגונים ב-GitHub, בוחרים את הארגון שבבעלותו המאגר שבו אתם רוצים להשתמש ב-Lighthouse CI.

  3. בוחרים באפשרות All repositories אם רוצים להפעיל את Lighthouse CI בכל המאגרים, או באפשרות Only select repositories אם רוצים להשתמש בו רק במאגרים ספציפיים, ולאחר מכן בוחרים את המאגרים. לאחר מכן לוחצים על Install & Authorize.

  4. מעתיקים את האסימון שמוצג. משתמשים בה בשלב הבא.

  5. כדי להוסיף את האסימון, נכנסים לדף Settings של המאגר ב-GitHub, לוחצים על Secrets ואז על Add a new Secret.

    צילום מסך של הכרטיסייה 'הגדרות' ב-GitHub

  6. מגדירים את השדה Name לערך LHCI_GITHUB_APP_TOKEN, מגדירים את השדה Value לאסימון שהעתקתם בשלב האחרון, ואז לוחצים על הלחצן Add Secret (הוספת סוד).

  7. נכנסים לקובץ lighthouse-ci.yaml ומוסיפים את הסוד של הסביבה החדשה לפקודה "run Lighthouse CI".

-           name: run Lighthouse CI
            run: |
              npm install -g @lhci/cli@0.3.x
              lhci autorun --upload.target=temporary-public-storage || echo "LHCI failed!"
+            env:
+              LHCI_GITHUB_APP_TOKEN: $
  1. בדיקת הסטטוס מוכנה לשימוש. כדי לבדוק זאת, אפשר ליצור בקשת משיכה חדשה או לדחוף מחויבות לבקשת משיכה קיימת.

הגדרה של Lighthouse CI Server

השרת של Lighthouse CI מספק לוח בקרה לעיון בדוחות ההיסטוריים של Lighthouse. הוא יכול לשמש גם כמאגר נתונים פרטי לטווח ארוך לדוחות של Lighthouse.

צילום מסך של לוח הבקרה של שרת Lighthouse CI
צילום מסך של השוואה בין שני דוחות של Lighthouse בשרת Lighthouse CI
  1. בוחרים את השמירות שרוצים להשוות.
  2. הסכום של דירוג Lighthouse השתנה בין שתי השמירות.
  3. בקטע הזה מוצגים רק מדדים שהשתנו בין שתי ההתחייבויות.
  4. רגרסיות מודגשות בורוד.
  5. השיפורים מודגשים בכחול.

שרת Lighthouse CI מתאים במיוחד למשתמשים שמתמצאים בפריסה ובניהול של תשתית משלהם.

מידע נוסף על הגדרת שרת Lighthouse CI, כולל מתכונים לשימוש ב-Heroku וב-Docker לפריסה, זמין בהוראות האלה.

למידע נוסף