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

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

בדקו את הגרסה לפני פירוש המשקלים

הגרסה האחרונה שהופיעה ברשימת גרסאות התוכנה של Lighthouse בבדיקה ב-17 באוקטובר 2026 הייתה v13.5.0. אין בכך הוכחה שזו הגרסה שבה השתמשה בקשת PageSpeed Insights מסוימת או התקנת Chrome מקומית. לוחות ההפצה והדפדפן המותקן עשויים להיות שונים. לצורך ההשוואה קובעת הגרסה הרשומה בדוח.

חשוב לשמור גם על הבחנה בתיעוד. עמוד הניקוד הכללי של Chrome עדיין מסמן את טבלת המשקלים המוכרת כ-Lighthouse 10. קובץ ההגדרות בענף הראשי שנבדק לצורך המאמר מכיל את אותם חמישה משקלים שאינם אפס. לא התאפשר לאמת את קובץ ההגדרות המתויג v13.5.0. לכן הטבלה מתארת את הענף הראשי שנבדק ואת המודל המתועד של Lighthouse 10, ולא הגדרת v13.5.0 שאומתה בנפרד. בבדיקה עם גרסה קבועה, בדקו את קובץ ה-JSON שלה כפי שמוצג בהמשך.

אלה המשקלים שאומתו בשני המקורות האלה.

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

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

המירו מדידות לציונים לפני חישוב הממוצע

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

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

לדוגמה חשבונית בלבד, נניח שכל ציוני המדדים נשארים קבועים ורק הציון המנורמל של TBT משתפר ב-10 נקודות בסולם של 0 עד 100. במשקל של 30%, תרומתו לציון הכולל גדלה ב-3 נקודות לפני העיגול. זהו חישוב היפותטי, לא תוצאת בדיקת ביצועים ולא הבטחה לגבי שינוי מסוים בקוד.

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

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

אזהרות מצביעות על סיבות ולא על קנסות קבועים

לקובץ CSS שחוסם רינדור אין קנס אוניברסלי של מספר נקודות קבוע. השפעתו תלויה בשאלה אם הוא מעכב תוכן שנכלל במדידות. גם אזהרת JavaScript לא מנוצל מצביעה על עבודה שאולי אפשר להסיר; הכותרת שלה אינה מדד משוקלל נוסף.

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

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

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

שלטו בתנאים שגורמים לתנודות

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

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

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

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

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

הריצו השוואה שניתנת לשחזור משורת הפקודה

ה-CLI מאפשר לשמור יחד את הפקודה, גרסת החבילה והפלט. נדרשות התקנות תואמות של Node.js ושל Chrome או Chromium. בדקו את דרישות סביבת הריצה של החבילה שבחרתם לפני ההתקנה. הפקודות הבאות מקבעות את הגרסה שנמצאה במחקר; הן דוגמאות ולא הורצו מול example.com לצורך המאמר.

שמרו חמישה דוחות JSON נפרדים עם גרסה קבועה והגדרת המובייל הרגילה.

mkdir -p lighthouse-reports
for run in 1 2 3 4 5; do
  npx --yes [email protected] https://example.com/     --only-categories=performance     --chrome-flags="--headless"     --output=json     --output-path="lighthouse-reports/mobile-${run}.json"
done

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

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

// inspect-lighthouse.mjs
import { readFileSync } from 'node:fs';

const file = process.argv[2];
if (!file) throw new Error('Pass a Lighthouse JSON report path.');
const report = JSON.parse(readFileSync(file, 'utf8'));
const performance = report.categories.performance;
console.log('Lighthouse version:', report.lighthouseVersion);
console.log('Performance score:', performance.score);
console.table(performance.auditRefs.filter(({ weight }) => weight > 0));

הריצו את הסקריפט על הדוח הראשון.

node inspect-lighthouse.mjs lighthouse-reports/mobile-1.json

הציון ב-JSON מנורמל, ולכן 0.9 מקביל ל-90 לפני עיצוב התצוגה. שמרו דוחות מלאים ולא רק ציונים. הם כוללים הגדרות ומדדים הנחוצים להסבר הבדלים בהמשך. לבדיקת מחשב צרו סדרה נפרדת עם --preset=desktop, ואל תערבבו אותה עם סדרת המובייל.

השתמשו בחציון בלי להסתיר את הפיזור

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

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

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

PageSpeed Insights, DevTools וה-CLI עשויים להשתמש בגרסאות ובסביבות שונות. המדריך ל-PageSpeed Insights מסביר את הדוח הזה. כששני כלים חלוקים, השוו קודם הגדרות ומצבים; ציון נמוך יותר אינו מוכיח שהכלי שגוי.

הפכו את הציון למדידה המועילה הבאה

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

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

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