חלקי משנה של תמונות LCP ו-RTT זמינים עכשיו ב-CrUX

Barry Pollard

Johannes Henkel

תאריך פרסום: 11 בפברואר 2025

במהדורה של הדוח לגבי חוויית המשתמש ב-Chrome ‏ (CrUX) שפורסמה בפברואר 2025 נוספו כמה מדדים חדשים ומעניינים (וגם מדדים ששונו):

• חלקי משנה וסוגי משאבים של תמונות Largest Contentful Paint (LCP)
• פרטי זמן הלוך ושוב (RTT)
• הסרה של המאפיין 'סוג החיבור בפועל' (ECT)

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

פרטי אבחון של LCP

במקור, הצגנו את המושג של רכיבי משנה של LCP ב-Google I/O 2022 כטכניקה יעילה לפירוט זמן ה-LCP בדפים עם LCP של תמונות לרכיבים קטנים יותר, כדי לוודא שהמאמצים שלכם מושקעים באופטימיזציה של הגורמים הנכונים לזמן LCP ארוך.

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

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

חלקים משניים של תמונות LCP

במסגרת הגרסה הזו, בעלי אתרים יכולים לבדוק את האתרים שלהם כדי למצוא את החלקים המשניים של LCP של תמונות, ברמת המקור או ברמת כתובת ה-URL.

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

הנתונים האלה נוספו ל-CrUX API ול-CrUX History API החל מפברואר 2025 (הערה: לא BigQuery). ב-CrUX History API יש נתונים של שבועיים בזמן ההשקה, והם יתרחבו עם הזמן עד להיסטוריה המלאה של 25 השבועות. ממשקי ה-API מאפשרים להציג את הנתונים כ-75 percentile של כל קבוצת משנה, באלפיות השנייה.

לדוגמה, כדי לקבל את החלקים המשניים של התמונה של LCP עבור https://web.dev/ עבור PHONE צפיות בדפים, אפשר להשתמש בפקודת ה-curl הבאה (מחליפים את API_KEY במפתח שלכם):

curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{ "formFactor": "PHONE",
            "url": "https://web.dev/",
            "metrics": [
              "largest_contentful_paint_image_time_to_first_byte",
              "largest_contentful_paint_image_resource_load_delay",
              "largest_contentful_paint_image_resource_load_duration",
              "largest_contentful_paint_image_element_render_delay"]}'

תקבלו תשובה שדומה לזו:

{
  "record": {
    "key": {
      "formFactor": "PHONE",
      "url": "https://web.dev/"
    },
    "metrics": {
      "largest_contentful_paint_image_element_render_delay": {
        "percentiles": {
          "p75": 2088
        }
      },
      "largest_contentful_paint_image_resource_load_delay": {
        "percentiles": {
          "p75": 828
        }
      },
      "largest_contentful_paint_image_resource_load_duration": {
        "percentiles": {
          "p75": 417
        }
      },
      "largest_contentful_paint_image_time_to_first_byte": {
        "percentiles": {
          "p75": 2385
        }
      }
    },
    "collectionPeriod": {
      "firstDate": {
        "year": 2025,
        "month": 1,
        "day": 12
      },
      "lastDate": {
        "year": 2025,
        "month": 2,
        "day": 8
      }
    }
  }
}

עדכנו את הכלי להצגת נתוני CrUX כך שיכלול את הנתונים האלה, ואנחנו מצפים שגם כלים אחרים של צד שלישי שמשתמשים בממשקי ה-API של CrUX יחשפו את הנתונים החשובים האלה:

חלקי משנה של תמונות LCP בתצוגה החזותית של CrUX

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

ערכים גבוהים בכל רכיב משניים מצביעים על בעיות שונות:

• זמן עד בייט ראשון (TTFB) גבוה בדרך כלל מציין בעיות בשרת, ברשת או בהפניה אוטומטית, כפי שמוסבר במאמר אופטימיזציה של זמן עד בייט ראשון (TTFB).
• עיכוב גבוה בטעינה של משאבים מציין שהדפדפן גילה את תמונת ה-LCP באיחור. לדוגמה, תמונת LCP שהוזרקה על ידי JavaScript בצד הלקוח, ופעולתה נמשכת זמן מה.
• אם משך טעינת המשאב גבוה, כדאי להקטין את גודל קובץ ההורדה של התמונה.
• עיכוב עיבוד ארוך של אלמנט הוא מצב שבו התמונה זמינה (אולי דרך <link rel=preload>, אבל לא נעשה בה שימוש במשך זמן רב – גם במקרה הזה, לרוב בגלל שצריך JavaScript בצד הלקוח כדי להציג את התמונה.

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

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

סוגי משאבים של LCP

מאחר שהכי קל לראות את החלקים המשניים ב-LCP של תמונות, הנתונים האלה מוגבלים ב-CrUX רק לדפים עם תמונות. לכן, חשוב להבין כמה מ-LCPs שלכם הם LCPs של תמונות, לעומת LCPs של טקסט (למשל, כותרות <h1> ופסקאות ארוכות).

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

לדוגמה, כדי לקבל את סוגי המשאבים של LCP עבור https://web.dev/ עבור PHONE צפיות בדף, אפשר להשתמש בפקודה הבאה של curl (שוב, מחליפים את API_KEY במפתח שלכם):

curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{ "formFactor": "PHONE",
            "url": "https://web.dev/",
            "metrics": ["largest_contentful_paint_resource_type"]}'

תקבלו תשובה שדומה לזו:

{
  "record": {
    "key": {
      "formFactor": "PHONE",
      "url": "https://web.dev/"
    },
    "metrics": {
      "largest_contentful_paint_resource_type": {
        "fractions": {
          "image": 0.0155,
          "text": 0.9845
        }
      }
    },
    "collectionPeriod": {
      "firstDate": {
        "year": 2025,
        "month": 1,
        "day": 12
      },
      "lastDate": {
        "year": 2025,
        "month": 2,
        "day": 8
      }
    }
  }
}

גם התצוגה החזותית של CrUX עודכנה כדי להציג את הנתונים הבאים:

סוגי משאבים של LCP בתצוגה החזותית של CrUX

לדוגמה, בדף הבית של web.dev אפשר לראות ש-98.5% מ-LCPs היו למעשה LCPs של טקסט, ולכן חלקי המשנה של תמונות LCP פחות שימושיים בדף הזה. במקרה כזה, נוכל להשתמש במדדים המקוריים של זמן אחזור דף ראשוני (TTFB) ושל אירוע טעינה ראשוני (FCP) כפירוט אבחון טוב יותר.

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

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

פרטי אבחון של RTT

הוספנו גם את מדד זמן האחזור (RTT) שהוצג לראשונה באוגוסט 2024.

תיבות טריאגרמיות של RTT

הוספנו תאים משולשים לממשקי ה-API של CrUX, שמציגים שלוש קבוצות של צפיפות RTT:

זמן אחזור של רשת	התחלה	סיום
נמוכה	0 אלפיות שנייה	פחות מ-75 אלפיות שנייה
בינונית	75 אלפיות שנייה	פחות מ-275 אלפיות שנייה
גבוהה	275 אלפיות שנייה	∞

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

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

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

הקטגוריות האלה זמינות בממשקי ה-API של CrUX. לדוגמה, web.dev עבור PHONE צפיות בדפים (שוב, מחליפים את API_KEY במפתח משלכם):

curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{ "formFactor": "PHONE",
            "url": "https://web.dev/",
            "metrics": ["round_trip_time"]}'

התוצאה אמורה להיות דומה לזו:

{
  "record": {
    "key": {
      "formFactor": "PHONE",
      "url": "https://web.dev/"
    },
    "metrics": {
      "round_trip_time": {
        "histogram": [
          {
            "start": 0,
            "end": 75,
            "density": 0.1524
          },
          {
            "start": 75,
            "end": 275,
            "density": 0.6641
          },
          {
            "start": 275,
            "density": 0.1835
          }
        ],
        "percentiles": {
          "p75": 230
        }
      }
    },
    "collectionPeriod": {
      "firstDate": {
        "year": 2025,
        "month": 1,
        "day": 12
      },
      "lastDate": {
        "year": 2025,
        "month": 2,
        "day": 8
      }
    }
  }
}

התיבות מוצגות בתצוגה החזותית של CrUX כשבוחרים באפשרות distributions:

נתוני RTT בתצוגה החזותית של CrUX

זמן תשובה (RTT) ב-BigQuery

בנוסף להרחבת המדד RTT בממשקי ה-API של CrUX כך שיכלול את הקטגוריות המשולשות, הפכנו את הנתונים לזמינים גם במערך הנתונים החודשי ב-BigQuery, כולל תרשים היסטוגרמה מלא בקטגוריות של 25 אלפיות השנייה בטבלאות הגולמיות וקטגוריות משולשות וערכים של p75 בטבלאות הממומשות.

כך תוכלו להבין טוב יותר את חלוקת הנתונים מעבר לשלוש הקטגוריות הזמינות בממשקי ה-API של CrUX. בנוסף, היא מאפשרת לנו ליצור מחדש את פירוט ה-ECT שהוסרה מ-CrUX החל מהחודש הזה (מידע נוסף על כך בהמשך) – עם שינוי קל של סף של 275 אלפיות השנייה ל-4g במקום הסף הקודם של 270 אלפיות השנייה. פירוטי ה-ECT (שמוצגים עכשיו על סמך נתוני RTT) עדיין זמינים בטבלאות המטא-נתונים של CrUX ב-BigQuery, כך שכלי כמו לוח הבקרה של CrUX יוכלו להמשיך להציג את הפירוט הזה.

מערך הנתונים ב-BigQuery כולל גם נתונים לפי מדינה (כפי שהוגדר על ידי ISO 3166-1). כך אפשר לבצע ניתוח מעמיק יותר, שיכול להסביר למה מדדי הביצועים נמוכים יותר אצל משתמשים מסוימים. לדוגמה, אנחנו יכולים לבדוק את הנתונים של משתמשי Google Phone על ידי בדיקת הנתונים של https://www.google.com:

SELECT
  `chrome-ux-report`.experimental.GET_COUNTRY(country_code) AS geo,
  least(500, p75_rtt) AS capped_p75_rtt,
  p75_rtt
FROM
  `chrome-ux-report.materialized.country_summary`
WHERE
  origin = 'https://www.google.com' AND
  yyyymm = 202501 AND
  device = 'phone'
ORDER BY
  p75_rtt DESC,
  country_code

לאחר מכן, אנחנו מציגים את הנתונים במפה גיאוגרפית:

זמן אחזור הטקסט בזמן אמת (RTT) בטלפון לפי אחוזון 75 לפי מדינה עבור https://www.google.com
(נתוני המקור עם תרשים אינטראקטיבי).

אפשר לראות שבעוד שברוב העולם (במיוחד ב'עולם המערבי') זמני ה-RTT טובים מאוד, באפריקה שמדרום לסהרה, בחלקים מארצות המזרח התיכון ובחלקים מאסיה יש בעיות משמעותיות יותר. למעשה, הגרף מוגבל ל-500 אלפיות השנייה של זמן נסיעות חזרה (RTT), כי השימוש בנתונים המלאים גרם לעיוות הצבעים – במיוחד באריתריאה, שבה ה-75 percentile הוא 3,850 אלפיות השנייה.

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

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

הסרת המאפיין ECT

השינוי האחרון במהדורה של פברואר 2025 הוא הוצאה משימוש של המאפיין 'סוג החיבור בפועל (ECT)' מ-BigQuery (כבר הסרנו את RTT מה-APIs בספטמבר 2024 כשהשקנו את מדד RTT כתחליף).

כפי שצוין קודם לכן בפוסט הזה, המדד RTT מאפשר תצוגה מפורטת יותר של פרטי החיבור של המבקרים באתר. אפשר אפילו ליצור מחדש את הקטגוריות של ECT מההיסטוגרמות האלה. (טכנית, ECT צריך להיות שילוב של RTT ומהירות הורדה, אבל Chrome השתמש רק ב-RTT).

הבדל חשוב הוא ש-ECT היה מאפיין CrUX – כלומר, אפשר היה לפלח את המדדים האחרים לפי ECT. זמן האחזור הוא מדד CrUX ולא מאפיין, לכן אי אפשר להציג את LCP לפי זמן אחזור, למשל, אלא רק לראות את זמני האחזור לפי המאפיינים האחרים (סוג המכשיר והמדינה).

אולי זה נשמע מגביל יותר, אבל המעבר ממאפיין למדד מאפשר לכם לגשת לנתונים נוספים ב-CrUX. הסיבה לכך היא של-CrUX יש תנאי סף מינימלי מסוימים שצריך לעמוד בהם כדי שנוכל להציג נתונים. כבר הפכנו את המאפיינים לאופציונליים בשנת 2022, כלומר הסרנו את ECT או את המכשיר במקרים שבהם היה צורך לדווח ברמה גבוהה יותר, אבל מדדים שלא היו ברוב הטעינות של הדפים (אינטראקציה עד ל-Paint הבא (INP), סוגים שונים של ניווט, ועכשיו חלקים משניים של תמונות LCP) לא היו זמינים לרוב המקורות ב-BigQuery.

צמצום מספר המאפיינים מקטין את חלוקת הנתונים לפלחים, וכך מגדיל את מספר מקורות הנתונים שעומדים בדרישות המינימליות האלה. בינואר, דיווחנו על INP לגבי 68.1% מהמקורות, ואילו בקבוצת הנתונים של דצמבר דיווחנו על INP רק לגבי 64.5% מהמקורות. המנגנון הזה חל גם על סוגי הניווט, על החלקים המשניים של LCP ועל סוגי המשאבים בגרסה הזו – כולם נהנים מההסרה של המאפיין ECT. ב-CrUX APIs, הכיסוי המורחב נכנס לתוקף בתחילת פברואר.

העמודות של ECT יישארו ב-BigQuery כדי לשמור על עקביות עם מערכי נתונים קודמים, ונתוני ECT בתצוגות המפורטות יישארו זמינים, אבל על סמך פרטי ה-RTT (עם הבדל של 5 אלפיות השנייה ב-3g וב-4g כפי שצוין קודם) בנוסף ל-RTT p75 ולתצוגות הטריאגרמטיות החדשות.

סיכום

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

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

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