ניטור ביצועי אתרים: מדריך מלא (2026)

מבוא: שיפרתם הכל — ועכשיו מה?

אם עקבתם אחרי הסדרה שלנו, כבר עברתם דרך ארוכה. כיסינו את Core Web Vitals, אופטימיזציית תמונות, JavaScript, CSS ופונטים, TTFB עם CDN ו-Caching, Speculation Rules API, סקריפטים של צד שלישי, ו-Resource Hints עם Fetch Priority. ארגז כלים רציני, אין ספק.

אבל הנה השאלה שרוב המפתחים לא שואלים מספיק מוקדם: איך אתם יודעים שהאופטימיזציות באמת עובדות אצל המשתמשים האמיתיים?

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

אז מה נעשה במדריך הזה? נבנה יחד מערכת ניטור שלמה — נתחיל מספריית web-vitals לאיסוף נתונים אמיתיים, נעבור ל-CrUX API לגישה לנתונים שגוגל עצמה משתמשת בהם לדירוג, ונסיים עם Lighthouse CI שמונע רגרסיות עוד לפני שהקוד מגיע לפרודקשן. יאללה, נתחיל.

נתוני שדה מול נתוני מעבדה: למה ציון Lighthouse לא מספיק

מה ההבדל בפועל?

נתוני מעבדה (Lab Data) נאספים בסביבה מבוקרת — מכונה ספציפית, חיבור רשת סימולטי, ללא הרחבות דפדפן. Lighthouse, WebPageTest ו-Chrome DevTools כולם מייצרים נתוני מעבדה. היתרון: תוצאות עקביות ושחזור קל. החיסרון: הן פשוט לא משקפות את המציאות.

נתוני שדה (Field Data) זה סיפור אחר לגמרי. הם נאספים ממשתמשים אמיתיים בזמן אמת — מכשירים שונים, חיבורים שונים, מיקומים גיאוגרפיים שונים, והתנהגויות שלא תמיד ניתן לחזות. וזה בדיוק מה שגוגל משתמשת בו לדירוג באלגוריתם החיפוש.

למה יש פער?

הנה דוגמה אמיתית שנתקלתי בה: אתר קיבל ציון LCP של 1.8 שניות ב-Lighthouse, אבל ב-CrUX הנתון היה 3.2 שניות ב-p75. מה קרה? 60% מהתנועה הגיעה ממכשירי אנדרואיד זולים עם מעבדים חלשים, והשרת הגיש תמונות כבדות למשתמשים שהיו רחוקים מה-CDN. פער של כמעט כפליים — וזה בכלל לא מקרה חריג.

נקודה חשובה: גוגל מחשבת את Core Web Vitals לפי פרסנטיל 75 — כלומר, 75% מהמשתמשים צריכים לקבל חוויה "טובה". אם 30% מהמשתמשים שלכם חווים LCP של מעל 4 שניות, זה מספיק כדי למשוך את הציון למטה גם אם הרוב מקבלים חוויה מצוינת.

ספריית web-vitals: השלב הראשון לניטור אמיתי

מה זה ולמה זה חשוב

ספריית web-vitals היא ספרייה קלילה (~2KB לאחר דחיסת Brotli) מבית Google שמודדת את Core Web Vitals ישירות אצל המשתמשים שלכם. הדבר הכי חשוב לדעת עליה — היא משתמשת באותה מתודולוגיה שגוגל מפעילה ב-CrUX, אז הנתונים שתקבלו יהיו עקביים עם מה שגוגל רואה.

הגרסה הנוכחית היא web-vitals v5, והיא מודדת חמישה מדדים:

LCP (Largest Contentful Paint) — ביצועי טעינה
INP (Interaction to Next Paint) — תגובתיות
CLS (Cumulative Layout Shift) — יציבות ויזואלית
FCP (First Contentful Paint) — הצגה ראשונה
TTFB (Time to First Byte) — תגובת השרת

התקנה ושימוש בסיסי

ההתקנה פשוטה:

npm install web-vitals

והשימוש הבסיסי — מדידה ושליחה לשרת Analytics:

import { onLCP, onINP, onCLS, onFCP, onTTFB } from 'web-vitals';

function sendToAnalytics(metric) {
  const body = JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating, // "good" | "needs-improvement" | "poor"
    delta: metric.delta,
    id: metric.id,
    navigationType: metric.navigationType,
  });

  // sendBeacon לא חוסם את הדף ועובד גם בזמן סגירת הטאב
  if (navigator.sendBeacon) {
    navigator.sendBeacon('/api/vitals', body);
  } else {
    fetch('/api/vitals', { body, method: 'POST', keepalive: true });
  }
}

// רישום כל המדדים
onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);
onFCP(sendToAnalytics);
onTTFB(sendToAnalytics);

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

טעינה ללא npm — דרך CDN

לא משתמשים ב-npm? (למשל, באתר סטטי או WordPress) אפשר לטעון ישירות:

<script type="module">
  import { onCLS, onINP, onLCP } from
    'https://unpkg.com/web-vitals@5?module';

  function sendMetric(metric) {
    navigator.sendBeacon('/api/vitals',
      JSON.stringify({ name: metric.name, value: metric.value, rating: metric.rating })
    );
  }

  onCLS(sendMetric);
  onINP(sendMetric);
  onLCP(sendMetric);
</script>

Attribution Build: מציאת שורש הבעיה

למה הבילד הרגיל לא מספיק

הבילד הסטנדרטי אומר לכם ש-LCP הוא 3.5 שניות. טוב, נחמד לדעת. אבל זה לא אומר לכם למה.

האם הבעיה היא בשרת? בטעינת תמונה? ב-render-blocking CSS? כאן נכנס ה-Attribution Build — גרסה מעט גדולה יותר (כ-1.5KB נוספים) שמוסיפה מידע אבחוני מפורט לכל מדד. וזה, בכנות, עושה את כל ההבדל.

import { onLCP, onINP, onCLS } from 'web-vitals/attribution';

onLCP((metric) => {
  const { element, url, timeToFirstByte, resourceLoadDelay,
          resourceLoadDuration, elementRenderDelay } = metric.attribution;

  console.log('LCP Element:', element);      // למשל: "img#hero-image"
  console.log('TTFB:', timeToFirstByte);      // זמן תגובת השרת
  console.log('Resource Load Delay:', resourceLoadDelay);  // עיכוב בגילוי המשאב
  console.log('Resource Load Duration:', resourceLoadDuration); // זמן הורדת המשאב
  console.log('Element Render Delay:', elementRenderDelay);    // עיכוב ברינדור

  sendToAnalytics({
    name: metric.name,
    value: metric.value,
    ...metric.attribution,
  });
});

onINP((metric) => {
  const { eventTarget, eventType, inputDelay,
          processingDuration, presentationDelay } = metric.attribution;

  console.log('INP Target:', eventTarget);   // למשל: "button#add-to-cart"
  console.log('Event Type:', eventType);      // "click", "keydown", וכו'
  console.log('Input Delay:', inputDelay);    // עיכוב לפני עיבוד
  console.log('Processing:', processingDuration); // זמן עיבוד האירוע
  console.log('Presentation:', presentationDelay); // עיכוב הצגה ויזואלית
});

onCLS((metric) => {
  const { largestShiftTarget, largestShiftValue,
          largestShiftTime } = metric.attribution;

  console.log('CLS Element:', largestShiftTarget); // האלמנט שזז הכי הרבה
  console.log('Shift Value:', largestShiftValue);
  console.log('Shift Time:', largestShiftTime);    // מתי זה קרה
});

עם הנתונים האלה אתם יכולים לבנות דשבורד שמראה בדיוק מה גורם לבעיות. למשל: "70% מהמקרים שבהם LCP גרוע נגרמים מתמונת Hero שנטענת מאוחר בגלל resourceLoadDelay גבוה." פתאום אתם יודעים בדיוק מה לתקן ולא סתם מנחשים.

בניית Endpoint לאיסוף נתונים

שרת Node.js פשוט לקליטת מדדים

הנה דוגמה מינימלית לשרת שקולט את נתוני web-vitals ושומר אותם. בפרודקשן כמובן תרצו לשלוח את הנתונים למסד נתונים או לשירות Analytics (BigQuery, InfluxDB, ואפילו CSV פשוט כנקודת התחלה):

import express from 'express';

const app = express();
app.use(express.json());

// Endpoint לקליטת מדדי web-vitals
app.post('/api/vitals', (req, res) => {
  const { name, value, rating, delta, id, navigationType } = req.body;

  const logEntry = {
    timestamp: new Date().toISOString(),
    metric: name,
    value: Math.round(value),
    rating,
    delta: Math.round(delta),
    sessionId: id,
    navigationType,
    userAgent: req.headers['user-agent'],
  };

  console.log('[Web Vital]', JSON.stringify(logEntry));
  res.status(204).end();
});

app.listen(3000);

שליחה ל-Google Analytics 4

אם אתם כבר משתמשים ב-GA4, אפשר לשלוח את המדדים כאירועים מותאמים — בלי צורך בשרת נפרד:

import { onLCP, onINP, onCLS } from 'web-vitals';

function sendToGA4(metric) {
  // gtag כבר צריך להיות מוגדר בדף
  gtag('event', metric.name, {
    value: Math.round(metric.name === 'CLS' ? metric.delta * 1000 : metric.delta),
    event_category: 'Web Vitals',
    event_label: metric.id,
    non_interaction: true,
  });
}

onLCP(sendToGA4);
onINP(sendToGA4);
onCLS(sendToGA4);

טיפ קטן: שימו לב שב-CLS אנחנו מכפילים ב-1000 כי GA4 מצפה למספרים שלמים, ו-CLS הוא בדרך כלל מספר עשרוני קטן מאוד (כמו 0.05). בלי הכפלה הזו, GA4 יעגל הכל לאפס וזה... לא שימושי במיוחד.

CrUX API: גישה לנתונים שגוגל משתמשת בהם לדירוג

מה זה CrUX ולמה זה חשוב

Chrome User Experience Report (CrUX) הוא מאגר נתונים ענקי שגוגל אוספת ממשתמשי Chrome אמיתיים — כאלה שמחוברים לחשבון Google, הפעילו דיווח סטטיסטיקות, ומשתמשים ב-Chrome. הנקודה המרכזית: אלה הנתונים שגוגל משתמשת בהם לדירוג. אז אם יש מדד אחד שאתם חייבים לעקוב אחריו, זה הוא.

חשוב לדעת: CrUX לא זמין לכל אתר. נדרש מינימום תנועה כדי שהנתונים יהיו מובהקים סטטיסטית. אתרים קטנים עלולים לראות נתונים ברמת ה-origin (דומיין שלם) אבל לא ברמת URL ספציפי. זה לא באג — זה בכוונה.

הגדרת מפתח API

לפני הכל, צריך מפתח API. החדשות הטובות — זה חינמי לגמרי:

היכנסו ל-Google Cloud Console
חפשו "Chrome UX Report API" והפעילו אותו
עברו ל-Credentials → Create Credentials → API Key
שמרו את המפתח

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

שליפת נתוני CrUX בקוד

הנה סקריפט Node.js שמושך נתוני Core Web Vitals מ-CrUX API:

const CRUX_API_KEY = process.env.CRUX_API_KEY;
const CRUX_API_URL = 'https://chromeuxreport.googleapis.com/v1/records:queryRecord';

async function fetchCrUXData(urlOrOrigin, formFactor = 'PHONE') {
  const body = {
    formFactor,
    metrics: [
      'largest_contentful_paint',
      'interaction_to_next_paint',
      'cumulative_layout_shift',
    ],
  };

  // בדיקה אם מדובר ב-URL ספציפי או origin
  if (urlOrOrigin.includes('/', 9)) {
    body.url = urlOrOrigin;
  } else {
    body.origin = urlOrOrigin;
  }

  const response = await fetch(
    `${CRUX_API_URL}?key=${CRUX_API_KEY}`,
    {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(body),
    }
  );

  if (!response.ok) {
    const error = await response.json();
    throw new Error(`CrUX API Error: ${error.error.message}`);
  }

  return response.json();
}

// שימוש
async function checkVitals() {
  const data = await fetchCrUXData('https://example.com', 'PHONE');
  const metrics = data.record.metrics;

  const thresholds = {
    largest_contentful_paint: { good: 2500, poor: 4000 },
    interaction_to_next_paint: { good: 200, poor: 500 },
    cumulative_layout_shift: { good: 0.1, poor: 0.25 },
  };

  for (const [name, metric] of Object.entries(metrics)) {
    const p75 = metric.percentiles.p75;
    const threshold = thresholds[name];
    const status = p75 <= threshold.good ? 'GOOD'
      : p75 <= threshold.poor ? 'NEEDS_IMPROVEMENT' : 'POOR';

    console.log(`${name}: p75=${p75} [${status}]`);
  }
}

checkVitals();

CrUX History API: מעקב אחרי מגמות

ה-CrUX API הרגיל נותן snapshot של 28 הימים האחרונים. לא רע, אבל אם אתם רוצים לראות מגמות לאורך זמן — למשל, האם ה-LCP השתפר אחרי שהוספתם CDN — תצטרכו את ה-CrUX History API:

const CRUX_HISTORY_URL =
  'https://chromeuxreport.googleapis.com/v1/records:queryHistoryRecord';

async function fetchCrUXHistory(origin) {
  const response = await fetch(
    `${CRUX_HISTORY_URL}?key=${CRUX_API_KEY}`,
    {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        origin,
        formFactor: 'PHONE',
        metrics: ['largest_contentful_paint'],
      }),
    }
  );

  const data = await response.json();
  const lcpHistory = data.record.metrics.largest_contentful_paint;

  // הדפסת מגמת LCP ל-40 השבועות האחרונים
  lcpHistory.percentilesTimeseries.p75s.forEach((value, index) => {
    const date = lcpHistory.collectionPeriods[index].lastDate;
    const dateStr = `${date.year}-${String(date.month).padStart(2, '0')}-${String(date.day).padStart(2, '0')}`;
    console.log(`${dateStr}: LCP p75 = ${value}ms`);
  });
}

fetchCrUXHistory('https://example.com');

ה-History API מתעדכן שבועית ומספק נתונים ל-40 תקופות שבועיות אחורה — כמעט 10 חודשים של היסטוריה. מושלם לזיהוי רגרסיות הדרגתיות, מהסוג שלא תופסים בבדיקה חד-פעמית אלא רק כשמישהו שואל "רגע, למה האתר יותר איטי מלפני שלושה חודשים?"

CrUX Vis: דשבורד ויזואלי ללא קוד

מעדיפים לראות את הנתונים בצורה ויזואלית בלי לכתוב קוד? CrUX Vis הוא כלי חינמי מבית Google שמציג את נתוני ה-CrUX History API בתרשימים אינטראקטיביים. פשוט מזינים את ה-URL ומקבלים גרף מגמות עם חלוקה לפי "טוב", "צריך שיפור" ו-"גרוע".

בהשוואה ל-PageSpeed Insights ו-Search Console, CrUX Vis כולל גם נתונים על סוגי ניווט ונתוני RTT (Round Trip Time) — מידע שפשוט לא זמין בכלים האחרים. שווה לבדוק.

Lighthouse CI: מניעת רגרסיות לפני שהן מגיעות לפרודקשן

הרעיון המרכזי

עד כאן דיברנו על ניטור בפרודקשן — לתפוס בעיות אחרי שהן כבר קרו. אבל מה אם אפשר למנוע רגרסיות לפני שהן מגיעות למשתמשים? בדיוק בשביל זה קיים Lighthouse CI. הוא מריץ Lighthouse audit על כל Pull Request ומכשיל את ה-build אם הציונים יורדים מתחת לסף שהגדרתם. פשוט וחזק.

התקנה והגדרה שלב-אחר-שלב

שלב 1: התקנת Lighthouse CI:

npm install --save-dev @lhci/cli

שלב 2: יצירת קובץ lighthouserc.json בשורש הפרויקט:

{
  "ci": {
    "collect": {
      "startServerCommand": "npm run build && npm run start",
      "url": [
        "http://localhost:3000/",
        "http://localhost:3000/products",
        "http://localhost:3000/checkout"
      ],
      "numberOfRuns": 3,
      "settings": {
        "preset": "desktop"
      }
    },
    "assert": {
      "assertions": {
        "categories:performance": ["error", { "minScore": 0.85 }],
        "categories:accessibility": ["warn", { "minScore": 0.9 }],
        "categories:seo": ["warn", { "minScore": 0.9 }],
        "largest-contentful-paint": ["error", { "maxNumericValue": 2500 }],
        "cumulative-layout-shift": ["error", { "maxNumericValue": 0.1 }],
        "total-blocking-time": ["error", { "maxNumericValue": 300 }]
      }
    },
    "upload": {
      "target": "temporary-public-storage"
    }
  }
}

טיפ חשוב מניסיון: הגדירו numberOfRuns ל-3 לפחות. Lighthouse נותן תוצאות שונות בין ריצות (כן, גם בסביבת CI), ושלוש ריצות מייצרות חציון אמין יותר. גם כדאי להתחיל עם סף ריאלי — אם האתר שלכם מקבל 80 בביצועים, אל תגדירו סף של 95 כי כל build ייכשל ותוך שבוע הצוות יתעלם מהבדיקה לגמרי. תתחילו ב-80 ותעלו בהדרגה.

שלב 3: הגדרת GitHub Actions workflow:

# .github/workflows/lighthouse-ci.yml
name: Lighthouse CI

on:
  pull_request:
    branches: [main]

jobs:
  lighthouse:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Run Lighthouse CI
        uses: treosh/lighthouse-ci-action@v12
        with:
          configPath: './lighthouserc.json'
          uploadArtifacts: true
          temporaryPublicStorage: true

מרגע שזה מוגדר, כל Pull Request מקבל אוטומטית בדיקת ביצועים. אם מישהו מוסיף סקריפט כבד או תמונה לא-אופטימלית — ה-CI יתפוס את זה לפני שהקוד מגיע ל-main. ואני חייב להגיד, פעם ראשונה שזה תופס רגרסיה אמיתית זה רגע מספק מאוד.

Performance Budgets: קווים אדומים שלא חוצים

בנוסף ל-Lighthouse assertions, אפשר להגדיר Performance Budgets — מגבלות על גודל משאבים ספציפיים. צרו קובץ budget.json:

[
  {
    "path": "/*",
    "timings": [
      { "metric": "interactive", "budget": 3000 },
      { "metric": "first-contentful-paint", "budget": 1500 }
    ],
    "resourceSizes": [
      { "resourceType": "script", "budget": 200 },
      { "resourceType": "image", "budget": 300 },
      { "resourceType": "stylesheet", "budget": 50 },
      { "resourceType": "total", "budget": 600 }
    ],
    "resourceCounts": [
      { "resourceType": "third-party", "budget": 5 }
    ]
  }
]

והוסיפו ב-lighthouserc.json את ההפניה:

{
  "ci": {
    "collect": {
      "settings": {
        "budgetsPath": "./budget.json"
      }
    }
  }
}

למה זה כל כך חשוב? כי בלי תקציבי ביצועים, הביצועים מתדרדרים לאט לאט. כל מפתח מוסיף "רק עוד סקריפט קטן", ותוך חצי שנה האתר כבד ב-50%. ראיתי את זה קורה שוב ושוב. Performance Budgets שומרים על משמעת — וזה אחד הדברים הכי פשוטים שאפשר לעשות עם ההשפעה הכי גדולה.

אסטרטגיית ניטור מומלצת: שלוש שכבות הגנה

אז איך מחברים את כל מה שדיברנו עליו למערכת אחת שעובדת? הנה הגישה שאני ממליץ עליה:

שכבה 1: מניעה (CI/CD) — Lighthouse CI עם Performance Budgets מונע רגרסיות לפני שהקוד מגיע לפרודקשן. זה הקו הראשון.
שכבה 2: ניטור בזמן אמת (RUM) — ספריית web-vitals עם Attribution Build אוספת נתונים מהמשתמשים האמיתיים. אם משהו קרה שה-CI לא תפס (למשל, CDN שנפל או שינוי בהתנהגות המשתמשים), תדעו על זה מהר.
שכבה 3: מגמות ודירוג (CrUX) — CrUX API ו-History API לבדיקה שבועית שהנתונים שגוגל רואה תואמים למה שאתם מצפים. כי בסוף, זה מה שמשפיע על הדירוג.

התראות חכמות

הגדירו התראות ב-80% מסף גוגל:

LCP: התראה מעל 2.0 שניות (הסף של גוגל: 2.5 שניות)
INP: התראה מעל 160 מילישניות (הסף של גוגל: 200ms)
CLS: התראה מעל 0.08 (הסף של גוגל: 0.1)

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

כלי RUM מסחריים שכדאי להכיר

אם אתם צריכים פתרון מוכן ומתקדם יותר מ-web-vitals + endpoint משלכם, הנה הכלים שבולטים ב-2026:

Datadog RUM — מתחבר ל-backend monitoring לקורלציה מלאה. הדף Optimization שלהם לזיהוי שורש הבעיה ממש שווה.
Sentry — משלב RUM עם Session Replay, כך שאפשר לצפות בדיוק במה שהמשתמש חווה כשהמדד היה גרוע. לפעמים זה שווה יותר מאלף גרפים.
SpeedCurve — מתמחה בביצועים עם השוואת מתחרים ודשבורדים מותאמים ל-Core Web Vitals.
RUMvision — תובנות Core Web Vitals בזמן אמת, בלי העיכוב של 28 יום שיש ב-Search Console.
DebugBear — משלב ניטור סינתטי ו-RUM עם מעקב אחר שינויים ב-Lighthouse לאורך זמן.

שאלות נפוצות

מה ההבדל בין נתוני Lighthouse לנתוני CrUX?

Lighthouse מייצר נתוני מעבדה — מדידה חד-פעמית בסביבה מבוקרת עם חיבור רשת סימולטי ומכשיר קבוע. CrUX אוסף נתוני שדה ממיליוני משתמשי Chrome אמיתיים לאורך 28 יום. גוגל משתמשת ב-CrUX לדירוג בתוצאות החיפוש. Lighthouse מצוין לדיבאג, אבל CrUX הוא מה שמשפיע על ה-SEO שלכם.

כמה תנועה צריך כדי לראות נתונים ב-CrUX?

גוגל לא מפרסמת מספר מדויק, אבל בפועל אתרים עם פחות מכמה מאות ביקורים ביום בדרך כלל לא מופיעים ב-CrUX ברמת URL ספציפי. נתונים ברמת origin דורשים פחות תנועה. אם האתר שלכם קטן מדי ל-CrUX, ספריית web-vitals עם endpoint משלכם היא הדרך הטובה ביותר לאסוף נתוני שדה.

האם ספריית web-vitals משפיעה על ביצועי האתר?

ההשפעה זניחה. הספרייה שוקלת כ-2KB לאחר דחיסת Brotli (כ-3.5KB עם Attribution Build). היא משתמשת ב-PerformanceObserver שרץ אסינכרונית מחוץ ל-main thread, והשליחה מתבצעת דרך navigator.sendBeacon שלא חוסם את הדף. בקיצור — אין סיבה לא להוסיף את זה.

איך Lighthouse CI מתמודד עם תוצאות לא-עקביות בין ריצות?

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

כל כמה זמן כדאי לבדוק את נתוני CrUX?

נתוני CrUX API מתעדכנים יומית, אבל מכיוון שהם מבוססים על חלון של 28 יום, שינויים מתבטאים לאט. בדיקה שבועית עם מעקב דרך ה-History API היא הגישה הנכונה. אם עשיתם שינוי משמעותי (כמו הוספת CDN), תנו לזה לפחות 2-3 שבועות לפני שאתם בודקים את ההשפעה ב-CrUX.