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

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

Katie Hempenius
Katie Hempenius

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

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

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

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

חלופות ל-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. יוצרים קובץ תצורה בשם 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. כדי לנסות את זה, מוסיפים את טענות הנכוֹנוּת שמפורטות בהמשך לקובץ 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

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

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

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

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

למידע נוסף