איך מוסיפים את Lighthouse למערכת אינטגרציה רציפה, כמו GitHub Actions.
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
מוגדר בצורה נכונה.
מתקינים את ה-CLI של Lighthouse CI.
npm install -g @lhci/cli
כדי להגדיר את Lighthouse CI, צריך להוסיף קובץ
lighthouserc.js
ברמה הבסיסית (root) של המאגר של הפרויקט. הקובץ הזה הוא חובה והוא יכלול פרטי הגדרות שקשורים ל-Lighthouse CI. אפשר להגדיר את Lighthouse CI לשימוש בלי מאגר git, אבל ההוראות במאמר הזה מבוססות על ההנחה שמאגר הפרויקט מוגדר לשימוש ב-git.יוצרים קובץ תצורה בשם
lighthouserc.js
ברמה הבסיסית של המאגר.touch lighthouserc.js
צריך להוסיף את הקוד הבא ל-
lighthouserc.js
. הקוד הזה הוא הגדרה ריקה של Lighthouse CI. אתם תוסיפו אותם להגדרות האלה בשלבים מאוחרים יותר.module.exports = { ci: { collect: { /* Add configuration here */ }, upload: { /* Add configuration here */ }, }, };
בכל פעם ש-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', }
מוסיפים את המאפיין
url
לאובייקטci.collect
כדי לציין את כתובות ה-URL שמערכת Lighthouse CI צריכה להריץ את Lighthouse עליהן. הערך של המאפייןurl
צריך להיכלל כמערך של כתובות URL. המערך הזה יכול להכיל כתובת URL אחת או יותר. כברירת מחדל, Lighthouse CI יפעיל את Lighthouse שלוש פעמים לכל כתובת URL.collect: { // ... url: ['http://localhost:8080'] }
מוסיפים את המאפיין
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 הזו לא תפעל כי הדוח כבר נמחק).
מריצים את ה-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
מופעל.מעדכנים את
lighthouserc.js
כך שישתמש במאפייןnumberOfRuns
:module.exports = { // ... collect: { numberOfRuns: 5 }, // ... }, };
מריצים מחדש את הפקודה
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
: כשלים בהדפסה ל-stderrerror
: כשלים בהדפסה ל-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: {
// ...
},
},
};
הפלט שנוצר במסוף נראה כך:
למידע נוסף על טענות נכוֹנוּת (assertions) של Lighthouse CI, אפשר לעיין במסמכי התיעוד.
הגדרת GitHub Action להרצת Lighthouse CI
אפשר להשתמש ב-GitHub Action כדי להריץ את Lighthouse CI. כך ייווצר דוח Lighthouse חדש בכל פעם ששינוי קוד יזוזם לכל הסתעפות של מאגר ב-GitHub. אפשר להשתמש באפשרות הזו בשילוב עם בדיקת סטטוס כדי להציג את התוצאות האלה בכל בקשת משיכה.
יוצרים ספרייה בשם
.github/workflows
בתיקיית השורש של המאגר. תהליכי העבודה של הפרויקט יישמרו בספרייה הזו. תהליך עבודה הוא תהליך שפועל בזמן שנקבע מראש (למשל, כשדוחפים את הקוד) והוא מורכב מפעולה אחת או יותר.mkdir .github mkdir .github/workflows
יוצרים קובץ בשם
lighthouse-ci.yaml
ב-.github/workflows
. הקובץ הזה יכיל את ההגדרות של תהליך עבודה חדש.touch lighthouse-ci.yaml
מוסיפים את הטקסט הבא ל-
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 ומעלים את התוצאות לאחסון ציבורי זמני.
שומרים את השינויים האלה ודוחפים אותם ל-GitHub. אם פעלתם לפי השלבים שלמעלה, דחיפת הקוד ל-GitHub תפעיל את תהליך העבודה שהוספתם.
כדי לוודא ש-Lighthouse CI הופעל וכדי לצפות בדוח שנוצר, עוברים לכרטיסייה Actions בפרויקט. תהליך העבודה Build project and Run Lighthouse CI אמור להופיע מתחת להתחייבות האחרונה שלכם.
אפשר לעבור לדוח Lighthouse שמתאים להתחייבות ספציפית בכרטיסייה Actions. לוחצים על השמירה, לוחצים על שלב תהליך העבודה Lighthouse CI ואז מרחיבים את התוצאות של השלב הרצת Lighthouse CI.
הגדרתם עכשיו פעולת GitHub להרצת Lighthouse CI. האפשרות הזו שימושית במיוחד בשילוב עם בדיקת סטטוס ב-GitHub.
הגדרת בדיקת סטטוס ב-GitHub
בדיקת סטטוס, אם היא מוגדרת, היא הודעה שמופיעה בכל בקשת תיקון, ובדרך כלל כוללת מידע כמו תוצאות הבדיקה או הצלחת ה-build.
בשלבים הבאים מוסבר איך להגדיר בדיקת סטטוס ל-Lighthouse CI.
עוברים אל דף האפליקציה של Lighthouse CI ב-GitHub ולוחצים על Configure.
(אופציונלי) אם אתם חברים במספר ארגונים ב-GitHub, בוחרים את הארגון שבבעלותו המאגר שבו אתם רוצים להשתמש ב-Lighthouse CI.
בוחרים באפשרות All repositories אם רוצים להפעיל את Lighthouse CI בכל המאגרים, או באפשרות Only select repositories אם רוצים להשתמש בו רק במאגרים ספציפיים, ולאחר מכן בוחרים את המאגרים. לאחר מכן לוחצים על Install & Authorize.
מעתיקים את האסימון שמוצג. משתמשים בה בשלב הבא.
כדי להוסיף את האסימון, נכנסים לדף Settings של המאגר ב-GitHub, לוחצים על Secrets ואז על Add a new Secret.
מגדירים את השדה Name לערך
LHCI_GITHUB_APP_TOKEN
, מגדירים את השדה Value לאסימון שהעתקתם בשלב האחרון, ואז לוחצים על הלחצן Add Secret (הוספת סוד).נכנסים לקובץ
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: $
- בדיקת הסטטוס מוכנה לשימוש. כדי לבדוק זאת, אפשר ליצור בקשת משיכה חדשה או לדחוף מחויבות לבקשת משיכה קיימת.
הגדרה של Lighthouse CI Server
השרת של Lighthouse CI מספק לוח בקרה לעיון בדוחות ההיסטוריים של Lighthouse. הוא יכול לשמש גם כמאגר נתונים פרטי לטווח ארוך לדוחות של Lighthouse.
- בוחרים את השמירות שרוצים להשוות.
- הסכום של דירוג Lighthouse השתנה בין שתי השמירות.
- בקטע הזה מוצגים רק מדדים שהשתנו בין שתי ההתחייבויות.
- רגרסיות מודגשות בורוד.
- השיפורים מודגשים בכחול.
שרת Lighthouse CI מתאים במיוחד למשתמשים שמתמצאים בפריסה ובניהול של תשתית משלהם.
מידע נוסף על הגדרת שרת Lighthouse CI, כולל מתכונים לשימוש ב-Heroku וב-Docker לפריסה, זמין בהוראות האלה.