מדדי ביצועים שמתמקדים במשתמשים

פיליפ וולטון

כולנו שמענו עד כמה הביצועים חשובים, אבל כשאנחנו מדברים על ביצועים ועל הפיכת אתרים ל"מהירים" - למה אנחנו מתכוונים בדיוק?

למעשה, הביצועים הם יחסיים:

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

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

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

הגדרת מדדים

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

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

בשנים האחרונות, חברים בצוות Chrome, בשיתוף עם W3C Web Performance Group, עבדו על סטנדרטיזציה של קבוצת ממשקי API ומדדים חדשים שמודדים בצורה מדויקת יותר את חוויית המשתמשים של הביצועים של דפי אינטרנט.

כדי לוודא שהמדדים רלוונטיים למשתמשים, אנחנו מנסחים אותם סביב כמה שאלות מרכזיות:

איך מתבצעת המדידה של המדדים

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

• בשיעור ה-Lab: שימוש בכלים כדי לדמות טעינת דף בסביבה עקבית ומבוקרת
• בשטח: על משתמשים אמיתיים שטוענים את הדף ומקיימים איתו אינטראקציה.

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

במעבדה

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

בשדה

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

הביצועים של אתרים יכולים להשתנות באופן משמעותי בהתאם ליכולות המכשיר של המשתמש ולתנאי הרשת שלו. הם יכולים גם להשתנות בהתאם לאינטראקציה של המשתמש עם הדף (או לאופן שבו הוא יוצר אינטראקציה).

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

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

סוגי מדדים

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

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

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

מדדים שחשוב למדוד

• הצגת תוכן ראשוני (FCP): מודדת את הזמן שעובר מהרגע שבו הדף מתחיל להיטען ועד שחלק מהתוכן של הדף עובר רינדור במסך. (lab, שדה)
• LCP (המהירות שבה נטען רכיב התוכן הכי גדול): מדד של הזמן שעובר מהרגע שבו הדף מתחיל להיטען ועד לעיבוד של גוש הטקסט הגדול ביותר או רכיב התמונה הגדול ביותר במסך. (lab, שדה)
• השהיה לאחר קלט ראשוני (FID): מודדת את הזמן שעובר מהרגע שבו משתמש יוצר אינטראקציה ראשונה עם האתר (למשל, לחיצה על קישור, הקשה על לחצן או שימוש בפקד מותאם אישית שמופעל על ידי JavaScript) עד לרגע שבו הדפדפן יכול להגיב לאינטראקציה. (שדה)
• Interaction to Next Paint (INP): מדידה של זמן האחזור של כל הקשה, לחיצה או אינטראקציה באמצעות המקלדת שבוצעו עם הדף. בנוסף, על סמך מספר האינטראקציות – האפשרות לבחור את זמן האחזור הגרוע ביותר של אינטראקציה בדף (או הקרוב ביותר) כערך מייצג אחד שמתאר את רמת הרספונסיביות הכוללת של הדף. (lab, שדה)
• סה"כ זמן חסימה (TBT): מודד את משך הזמן הכולל בין FCP ל-TTI, שבו ה-thread הראשי נחסם למשך מספיק זמן כדי למנוע תגובה לקלט. (מעבדה)
• Cumulative Layout Shift (CLS): המדד הזה מודד את הציון המצטבר של כל שינויי הפריסה הבלתי צפויים בפריסה שמתרחשים בין המועד שבו הדף מתחיל להיטען לבין מצב מחזור החיים שלו משתנה ל'מוסתר'. (lab, שדה)
• Time to First Byte (TTFB): מדד של משך הזמן שעובר עד שהרשת מגיבה לבקשת משתמש לפי הבייט הראשון של כל משאב. (lab, שדה)

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

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

מדדים מותאמים אישית

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

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

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

• User Timing API
• Long Tasks API
• Element Timing API
• Navigation Timing API
• Resource Timing API
• תזמון שרת

במדריך על Custom Metrics מוסבר איך להשתמש בממשקי ה-API האלה כדי למדוד מאפייני ביצועים ספציפיים לאתר.