מעקב אחר ביצועים באמצעות 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, כמו אופטימיזציה למנועי חיפוש (SEO) או נגישות.

הפונקציונליות העיקרית של 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 Server.

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

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

שימוש ב-Lighthouse CI באופן מקומי

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

  1. התקנת CLI של Lighthouse CI.

    npm install -g @lhci/cli

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

  2. ברמה הבסיסית (root) של המאגר, יוצרים קובץ תצורה של 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. יש לספק את הערך של המאפיין 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. בהמשך המאמר נסביר איך מגדירים פעולת 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. כדי לנסות את זה, מוסיפים את טענות הנכוֹנוּת שמפורטות בהמשך לקובץ 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
    • התקנה והגדרה של Node
    • התקנת חבילות 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 Action להרצת 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. בדיקת הסטטוס מוכנה לשימוש. כדי לבדוק זאת, אפשר ליצור בקשת משיכה חדשה או לדחוף מחויבות לבקשת משיכה קיימת.

הגדרת שרת CI של Lighthouse

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

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

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

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

למידע נוסף