מה חדש ב-Lighthouse 6.0

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

Connor Clark
Connor Clark

אנחנו משיקים היום את גרסה 6.0 של Lighthouse!

Lighthouse הוא כלי אוטומטי לבדיקת אתרים שעוזר למפתחים לזהות הזדמנויות ואבחונים לשיפור חוויית המשתמש באתרים שלהם. הוא זמין ב-Chrome DevTools, ב-npm (כמודול Node ו-CLI) או כתוסף לדפדפן (ב-Chrome וב-Firefox). הוא מניע שירותים רבים של Google, כולל PageSpeed Insights.

Lighthouse 6.0 זמין באופן מיידי ב-npm וב-Chrome Canary. שירותים אחרים של Google שמשתמשים ב-Lighthouse יקבלו את העדכון עד סוף החודש. התכונה תגיע לגרסת Chrome Stable בגרסת Chrome 84 (אמצע יולי).

כדי לנסות את ה-CLI של Lighthouse Node, משתמשים בפקודות הבאות: bash npm install -g lighthouse lighthouse https://www.example.com --view

בגרסה הזו של Lighthouse יש מספר רב של שינויים שמפורטים בהיסטוריית השינויים של גרסה 6.0. במאמר הזה נסקור את הנקודות העיקריות.

מדדים חדשים

מדדי Lighthouse 6.0.

ב-Lighthouse 6.0 נוספו לדוח שלושה מדדים חדשים. שניים מהמדדים החדשים האלה – Largest Contentful Paint (LCP) ו-Cumulative Layout Shift (CLS) הם הטמעות Lab של מדדי ליבה לבדיקת חוויית המשתמש באתר.

Largest Contentful Paint (LCP)

Largest Contentful Paint ‏ (LCP) הוא מדד של חוויית הטעינה שחושבים שהמשתמשים חווים. הוא מסמן את הנקודה במהלך טעינת הדף שבה התוכן הראשי – או 'הגדול ביותר' – נטען ומוצג למשתמש. המדד LCP הוא תוספת חשובה למדד 'הצגת תוכן ראשוני (FCP)', שמתעד רק את תחילת חוויית הטעינה. מדד LCP מספק למפתחים אות לגבי המהירות שבה משתמש יכול לראות בפועל את תוכן הדף. ציון LCP של פחות מ-2.5 שניות נחשב ל 'טוב'.

למידע נוסף, אפשר לצפות בסקירה המפורטת הזו על LCP מאת Paul Ireland (פול אירלנד).

Cumulative Layout Shift (CLS)

מדד היציבות החזותית (CLS) הוא מדידה של יציבות חזותית. המדד הזה מתייחס למיקום החזותי של התוכן בדף. ציון CLS נמוך הוא סימן למפתחים שהמשתמשים שלהם לא חווים שינויי תוכן לא רצויים. ציון CLS נמוך מ-0.10 נחשב 'טוב'.

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

מידע נוסף זמין בסרטון הזה על CLS של Annie Sullivan.

זמן החסימה הכולל (TBT)

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

בנוסף, ל-TBT יש מתאם גבוה עם מדד השדה מהירות התגובה לאינטראקציה ראשונה (FID), שהוא מדד ליבה לבדיקת חוויית המשתמש באתר.

עדכון של דירוג הביצועים

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

שלב שם המדד משקל מדד
מוקדם (15%) First Contentful Paint (FCP) 15%
חלק אמצעי (40%) מדד מהירות (SI) 15%
Largest Contentful Paint (LCP) 25%
מאוחר (15%) הזמן עד לפעילות מלאה (TTI) 15%
Thread ראשי (25%) זמן החסימה הכולל (TBT) 25%
יכולת חיזוי (5%) Cumulative Layout Shift (CLS) 5%

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

לשם השוואה, הנה הציון של גרסה 5:

שלב שם המדד משקל
מוקדם (23%) First Contentful Paint (FCP) 23%
בינונית (34%) מדד מהירות (SI) 27%
הצגת התוכן העיקרי (FMP) 7%
הסתיימה (46%) הזמן עד לפעילות מלאה (TTI) 33%
זמן ההמתנה הראשון של המעבד (FCI) 13%
Thread ראשי עיכוב הקלט הראשון המקסימלי הפוטנציאלי 0%

שינויים בשיטת הדירוג של Lighthouse בין הגרסאות 5 ו-6.

ריכזנו כאן כמה מהשינויים העיקריים בשיטת הדירוג בין גרסאות 5 ו-6 של Lighthouse:

  • המשקל של TTI הופחת מ-33% ל-15%. השינוי הזה בוצע בתגובה ישירה למשוב ממשתמשים לגבי התנודתיות של TTI, וגם לאי-עקביות באופטימיזציה של המדדים, שהובילו לשיפורים בחוויית המשתמש. מדד ה-TTI הוא עדיין אות שימושי למקרים שבהם דף הוא אינטראקטיבי לגמרי, אבל עם TBT כהשלמה, השונות פוחתת. אנחנו מקווים שהשינוי הזה בשיטת הדירוג יעודד את המפתחים לבצע אופטימיזציה בצורה יעילה יותר כדי לשפר את האינטראקטיביות של המשתמשים.
  • המשקל של FCP ירד מ-23% ל-15%. המדידה רק כשהפיxel הראשון צויר (FCP) לא נתנה לנו תמונה מלאה. שילוב של המדד הזה עם המדד 'זמן טעינה עד לחשיפה לתוכן הכי רלוונטי' (LCP) משקף טוב יותר את חוויית הטעינה.
  • ה-Max Potential FID הוצא משימוש. הוא לא מוצג יותר בדוח, אבל עדיין זמין ב-JSON. עכשיו מומלץ להשתמש ב-TBT כדי למדוד את האינטראקטיביות במקום ב-mpFID.
  • המדד 'הצגת התוכן העיקרי (FMP)' הוצא משימוש. המדד הזה היה תנודתי מדי ולא היה לו נתיב ריאלי לסטנדרטיזציה, כי ההטמעה שלו ספציפית לרכיבים הפנימיים של הרינדור ב-Chrome. יש צוותים שמוצאים שהתזמון של FMP משתלם באתר שלהם, אבל לא נערוך שיפורים נוספים במדד.
  • First CPU Idle הוצא משימוש כי הוא לא ייחודי מספיק מ-TTI. עכשיו, המדדים TBT ו-TTI הם המדדים המובילים למדידת האינטראקטיביות.
  • המשקל של CLS נמוך יחסית, אם כי אנחנו צופים להעלות אותו בגרסה ראשית עתידית.

שינויים בציוני המודעות

איך השינויים האלה משפיעים על הדירוגים של אתרים אמיתיים? פרסמנו ניתוח של השינויים בציון על סמך שני מערכי נתונים: קבוצה כללית של אתרים וקבוצה של אתרים סטטיים שנוצרו באמצעות Eleventy. לסיכום, בכ-20% מהאתרים יש ציונים גבוהים באופן משמעותי, בכ-30% כמעט אין שינוי ובכ-50% ירידה של לפחות חמש נקודות.

אפשר לחלק את השינויים בציון לשלושה רכיבים עיקריים:

  • שינויים במשקל הסולם
  • תיקוני באגים בהטמעות של המדדים הבסיסיים
  • שינויים בעקומת הציון הנפרדת

רוב השינויים בציונים הכוללים נובעים משינויים במשקל של הקריטריונים ומהוספת שלושה מדדים חדשים. מדדים חדשים שהמפתחים עדיין לא ביצעו להם אופטימיזציה משפיעים באופן משמעותי על דירוג הביצועים בגרסה 6. בעוד שציון הביצועים הממוצע של מאגר הנתונים לבדיקה בגרסה 5 היה כ-50, הציונים הממוצעים של המדדים החדשים 'זמן החסימה הכולל' ו-Largest Contentful Paint היו כ-30. שני המדדים האלה מהווים יחד 50% מהמשקל של ציון הביצועים של Lighthouse בגרסה 6, ולכן באופן טבעי, אצל אחוז גדול מהאתרים נרשמה ירידה.

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

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

מחשבון למתן ציונים

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

מחשבון הדירוג של Lighthouse.
תודה רבה ל-Ana Tudor על השדרוג של מדד הביצועים!

ביקורות חדשות

JavaScript שלא בשימוש

אנחנו משתמשים בכיסוי הקוד של DevTools בבדיקה חדשה: JavaScript לא בשימוש.

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

בדיקות נגישות

ב-Lighthouse נעשה שימוש בספרייה הנהדרת axe-core כדי להפעיל את הקטגוריה 'נגישות'. בגרסה 6.0 של Lighthouse הוספנו את הבדיקות הבאות:

  • aria-hidden-body
  • aria-hidden-focus
  • aria-input-field-name
  • aria-toggle-field-name
  • form-field-multiple-labels
  • heading-order
  • duplicate-id-active
  • duplicate-id-aria

סמל שניתן להתאמה (maskable)

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

הצהרת Charset

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

Lighthouse CI

בCDS בנובמבר הכרזנו על Lighthouse CI, ה-CLI והשרת של Node בקוד פתוח שעוקבים אחרי התוצאות של Lighthouse בכל התחייבות בצינור עיבוד הנתונים של השילוב הרציף. התקדמנו מאוד מאז השקת האלפא. ב-Lighthouse CI יש עכשיו תמיכה במספר ספקי CI, כולל Travis, Circle, GitLab ו-GitHub Actions. תמונות docker מוכנות לפריסה שמאפשרות להגדיר את הכלי בקלות, ועיצוב מחדש של לוח הבקרה מאפשר לראות מגמות בכל קטגוריה ובכל מדד ב-Lighthouse לצורך ניתוח מפורט.

רוצים להתחיל להשתמש ב-Lighthouse CI בפרויקט שלכם? תוכלו להיעזר במדריך למתחילים.

Lighthouse CI.
Lighthouse CI.
Lighthouse CI.

שינוי השם של חלונית כלי הפיתוח ל-Chrome

שינינו את השם של החלונית בדיקות לחלונית Lighthouse. דיברתי

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

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

  1. מקישים על Control+Shift+J (או על Command+Option+J ב-Mac) כדי לפתוח את DevTools.
  2. מקישים על Control+Shift+P (או על Command+Shift+P ב-Mac) כדי לפתוח את התפריט Command.
  3. מתחילים להקליד 'Lighthouse'.
  4. מקישים על Enter.

אמולציה של נייד

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

  • הדמיה של תנאים של רשת איטית ותנאי מעבד (CPU) (דרך מנוע סימולציה בשם Lantern).
  • הדמיה של מסך המכשיר (התכונה הזו קיימת גם בכלי הפיתוח ל-Chrome).

מאז תחילת השימוש ב-Lighthouse, המכשיר ששימש כנקודת ייחוס היה Nexus 5X. בשנים האחרונות, רוב מהנדסי הביצועים השתמשו ב-Moto G4 למטרות בדיקה. עכשיו Lighthouse עושה את זה ומשנה את מכשיר העזר ל-Moto G4. בפועל, השינוי הזה לא בולט במיוחד, אבל אלה כל השינויים שדף אינטרנט יכול לזהות:

  • גודל המסך השתנה מ-412x660 פיקסלים ל-360x640 פיקסלים.
  • מחרוזת סוכן המשתמש משתנה מעט, החלק של המכשיר שהיה בעבר Nexus 5 Build/MRA58N יהיה עכשיו Moto G (4).

החל מגרסה 81 של Chrome, מכשיר Moto G4 זמין גם ברשימת הדמיות המכשירים של כלי הפיתוח של Chrome.

רשימת אמולציית מכשירי Chrome של כלי פיתוח עם Moto G4.

תוסף לדפדפן

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

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

  • לא ניתן לבצע ב-PageSpeed Insights ביקורת של אתרים לא ציבוריים, כי הכלי פועל דרך שרת מרוחק ולא דרך מכונה מקומית של Chrome. אם אתם צריכים לבדוק אתר לא ציבורי, תוכלו להשתמש בלוח Lighthouse של DevTools או ב-Node CLI.
  • אין ערובה שמערכת PageSpeed Insights תשתמש בגרסה האחרונה של Lighthouse. אם רוצים להשתמש בגרסה העדכנית ביותר, צריך להשתמש ב-Node CLI. העדכון לתוסף הדפדפן יהיה זמין כ-1-2 שבועות אחרי השקת הגרסה החדשה.
  • PageSpeed Insights הוא Google API, והשימוש בו מהווה הסכמה לתנאי השירות של Google API. אם אתם לא רוצים או לא יכולים לאשר את התנאים וההגבלות, תוכלו להשתמש בחלונית Lighthouse של DevTools או ב-Node CLI.

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

תקציבים

ב-Lighthouse 5.0 הושק תקציב ביצועים, שמאפשר להוסיף ערכי סף לכמות של כל סוג משאב (כמו סקריפטים, תמונות או CSS) שדף יכול להציג.

בגרסה 6.0 של Lighthouse נוספה תמיכה במדדי תקציב, כך שאפשר עכשיו להגדיר ערכי סף למדדים ספציפיים כמו FCP. נכון לעכשיו, התקציבים זמינים רק ל-Node CLI ול-Lighthouse CI.

קישורים למיקום המקור

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

כלי הפיתוח חושפים את שורת הקוד המדויקת שגורמת לבעיה.

מה צפוי בעתיד

חברת Lighthouse התחילה לנסות לאסוף מפות מקור כדי להפעיל תכונות חדשות, כמו:

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

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

lighthouse https://web.dev --view --preset experimental

תודה!

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

מה אפשר לעשות עכשיו?

  • פותחים את Chrome Canary ומנסים את החלונית Lighthouse.
  • משתמשים ב-Node CLI: npm install -g lighthouse && lighthouse https://yoursite.com --view.
  • איך מפעילים את Lighthouse CI בפרויקט.
  • מסמכי התיעוד של ביקורת Lighthouse
  • תהנו מהעשייה שלכם לשיפור האינטרנט!

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