תהליכי העבודה ב-Lighthouse

נסו את Lighthouse API החדש כדי למדוד את הביצועים ואת השיטות המומלצות לאורך מסלול המשתמש.

Brendan Kenny
Brendan Kenny

‫Lighthouse הוא כלי מצוין לבדיקת הביצועים והשיטות המומלצות במהלך טעינת הדף הראשונית. עם זאת, בעבר היה קשה להשתמש ב-Lighthouse כדי לנתח היבטים אחרים של חיי הדף, כמו:

  • טעינת דף עם מטמון חם
  • דפים עם Service Worker מופעל
  • התחשבות באינטראקציות פוטנציאליות של משתמשים

זה אומר ש-Lighthouse עלול לפספס מידע חיוני. המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals) מבוססים על כל טעינות הדפים, ולא רק על אלה עם מטמון ריק. בנוסף, אפשר למדוד מדדים כמו Cumulative Layout Shift (CLS) במשך כל הזמן שהדף פתוח.

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

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

הגדרה

ממשקי ה-API של מסלול המשתמש עדיין בגרסת טרום-השקה (Preview), אבל הם זמינים ב-Lighthouse כבר היום. כדי לנסות את ההדגמות שבהמשך, צריך את Node בגרסה 14 ואילך. יוצרים ספרייה ריקה ומריצים בה את הפקודה:

# Default to ES modules.
echo '{"type": "module"}' > package.json

# Init npm project without the wizard.
npm init -y

# Dependencies for these examples.
npm install lighthouse puppeteer open

מצב הניווט החדש של Lighthouse הוא למעשה שם להתנהגות הרגילה של Lighthouse (עד עכשיו): ניתוח של טעינה מההתחלה (cold load) של דף. זה המצב שבו צריך להשתמש כדי לעקוב אחרי הביצועים של טעינת הדף, אבל מסלולי המשתמשים גם פותחים אפשרות לתובנות חדשות.

כדי להגדיר סקריפט ל-Lighthouse שמתעד טעינת דף:

  1. משתמשים ב-Puppeteer כדי לפתוח את הדפדפן.
  2. מתחילים מסלול משתמש ב-Lighthouse.
  3. עוברים לכתובת ה-URL הרצויה.
import fs from 'fs';
import open from 'open';
import puppeteer from 'puppeteer';
import {startFlow} from 'lighthouse/lighthouse-core/fraggle-rock/api.js';

async function captureReport() {
  const browser = await puppeteer.launch({headless: false});
  const page = await browser.newPage();

  const flow = await startFlow(page, {name: 'Single Navigation'});
  await flow.navigate('https://web.dev/performance-scoring/');

  await browser.close();

  const report = await flow.generateReport();
  fs.writeFileSync('flow.report.html', report);
  open('flow.report.html', {wait: false});
}

captureReport();

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

דוח תהליכים של Lighthouse שמוצג בו ניווט יחיד

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

תיעוד של טעינה חמה

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

async function captureReport() {
  const browser = await puppeteer.launch({headless: false});
  const page = await browser.newPage();

  const testUrl = 'https://web.dev/performance-scoring/';
  const flow = await startFlow(page, {name: 'Cold and warm navigations'});
  await flow.navigate(testUrl, {
    stepName: 'Cold navigation'
  });
  await flow.navigate(testUrl, {
    stepName: 'Warm navigation',
    configContext: {
      settingsOverrides: {disableStorageReset: true},
    },
  });

  await browser.close();

  const report = await flow.generateReport();
  fs.writeFileSync('flow.report.html', report);
  open('flow.report.html', {wait: false});
}

captureReport();

דוח הזרימה שיתקבל ייראה בערך כך:

דוח תהליך של Lighthouse שבו מוצגים שני ניווטים, אחד קר ואחד חם, עם ציון ביצועים גבוה יותר

השילוב של טעינות קרות וחמות מספק תמונה מלאה יותר של החוויה של המשתמשים בפועל. אם יש לכם אתר שבו המשתמשים טוענים הרבה דפים באותו ביקור, יכול להיות שהמדד הזה ייתן לכם תמונה מציאותית יותר של חוויית המשתמשים בשטח.

תמונת מצב

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

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

תפריט ההגדרות המתקדמות של Squoosh
תפריט ההגדרות המתקדמות של Squoosh

אפשר להוסיף סקריפט לתהליך הזה באמצעות Puppeteer, ואפשר גם ליצור תמונת מצב של Lighthouse בכל שלב:

async function captureReport() {
  const browser = await puppeteer.launch({headless: false});
  const page = await browser.newPage();

  const flow = await startFlow(page, {name: 'Squoosh snapshots'});

  await page.goto('https://squoosh.app/', {waitUntil: 'networkidle0'});

  // Wait for first demo-image button, then open it.
  const demoImageSelector = 'ul[class*="demos"] button';
  await page.waitForSelector(demoImageSelector);
  await flow.snapshot({stepName: 'Page loaded'});
  await page.click(demoImageSelector);

  // Wait for advanced settings button in UI, then open them.
  const advancedSettingsSelector = 'form label[class*="option-reveal"]';
  await page.waitForSelector(advancedSettingsSelector);
  await flow.snapshot({stepName: 'Demo loaded'});
  await page.click(advancedSettingsSelector);

  await flow.snapshot({stepName: 'Advanced settings opened'});

  browser.close();

  const report = await flow.generateReport();
  fs.writeFileSync('flow.report.html', report);
  open('flow.report.html', {wait: false});
}

captureReport();

הדוח שנוצר מראה שהתוצאות טובות באופן כללי, אבל יכול להיות שיש כמה קריטריונים של נגישות שצריך לבדוק באופן ידני:

דוח תהליכים של Lighthouse שמוצגת בו קבוצה של תמונות מצב שצולמו

טווחי זמן

אחד ההבדלים הגדולים ביותר בין תוצאות הביצועים בשטח (למשל מ-CrUX) לבין תוצאות הביצועים במעבדה (למשל מ-Lighthouse) הוא היעדר קלט מהמשתמש. כאן יכול לעזור מצב "טווח זמן" – המצב האחרון של מסלול המשתמש.

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

בניווט רגיל ב-Lighthouse, ערך ה-CLS יהיה 0. עם זאת, כשגוללים בדף, מתרחשים שינויים בעייתיים בפריסה וערך ה-CLS עולה.

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

async function captureReport() {
  const browser = await puppeteer.launch({headless: false});
  const page = await browser.newPage();
  // Get a session handle to be able to send protocol commands to the page.
  const session = await page.target().createCDPSession();

  const testUrl = 'https://pie-charmed-treatment.example.com/';
  const flow = await startFlow(page, {name: 'CLS during navigation and on scroll'});

  // Regular Lighthouse navigation.
  await flow.navigate(testUrl, {stepName: 'Navigate only'});

  // Navigate and scroll timespan.
  await flow.startTimespan({stepName: 'Navigate and scroll'});
  await page.goto(testUrl, {waitUntil: 'networkidle0'});
  // We need the ability to scroll like a user. There's not a direct puppeteer function for this, but we can use the DevTools Protocol and issue a Input.synthesizeScrollGesture event, which has convenient parameters like repetitions and delay to somewhat simulate a more natural scrolling gesture.
  // https://chromedevtools.github.io/devtools-protocol/tot/Input/#method-synthesizeScrollGesture
  await session.send('Input.synthesizeScrollGesture', {
    x: 100,
    y: 600,
    yDistance: -2500,
    speed: 1000,
    repeatCount: 2,
    repeatDelayMs: 250,
  });
  await flow.endTimespan();

  await browser.close();

  const report = await flow.generateReport();
  fs.writeFileSync('flow.report.html', report);
  open('flow.report.html', {wait: false});
}

captureReport();

כך נוצר דוח שמשווה בין ניווט רגיל לבין טווח זמן שכולל גם ניווט וגם גלילה לאחר מכן:

דוח תהליכים של Lighthouse שמוצגת בו קבוצה של תמונות מצב שצולמו

אם נתעמק בכל שלב, בשלב הניווט בלבד מוצג CLS של 0. אתר מעולה!

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

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

דוח Lighthouse שכולל ניווט בדפים וגלילה עם CLS שנכשל

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

רוצה לשלוח משוב?

ממשקי ה-API החדשים של מסלול המשתמש ב-Lighthouse יכולים לעשות הרבה דברים חדשים, אבל עדיין יכול להיות מסובך למדוד את סוג התרחישים שהמשתמשים נתקלים בהם.

אם יש לכם שאלות, אתם יכולים לפנות אלינו בפורומים לדיונים של Lighthouse. אם נתקלתם בבאגים או שיש לכם הצעות, אתם יכולים לדווח עליהם בIssue Tracker.