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

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

Annie Sullivan

Hongbo Song

Nicolás Peña Moreno

נקודה חשובה: המאמר הזה נכתב במהלך תקופה שבה פיתחנו מדד חדש של רספונסיביות כדי למדוד את זמן האחזור מקצה לקצה בדפי אינטרנט. הושק המדד החדש הזה, והוא נקרא Interaction to Next Paint (INP). בנוסף, מדד INP החליף באופן רשמי את 'השהיה לאחר קלט ראשון' (FID), והוא כעת מדד ליבה לבדיקת חוויית המשתמש באתר.

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

פוסט זה יעסוק בשני נושאים עיקריים:

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

מהו השהיה לאחר קלט ראשון?

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

• click
• keydown
• mousedown
• pointerdown (רק אם אחריה מופיע pointerup)

התרשים הבא מתאר FID:

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

למה בחרנו ב-FID?

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

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

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

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

הערה: אם אתם רוצים להתעמק בנתונים של כמה מהמדדים שבדקנו, בקישורים הבאים תוכלו למצוא מחקר על TBT ומחקר על 'מרכז העסקים המקומי'.

הערה על מדידת TTI בשדה

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

אילו שיפורים אנחנו שוקלים?

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

אנחנו רוצים שהמדד החדש:

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

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

תיעוד משך הזמן המלא של האירוע

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

יש שלבים שונים במחזור החיים של אירוע, כפי שמתואר בתרשים הזה:

כדי לעבד קלט, Chrome מבצע את הפעולות הבאות:

1. הקלט מהמשתמש קורה. השעה שבה זה מתרחש היא timeStamp של האירוע.
2. הדפדפן מבצע בדיקת התאמות כדי להחליט לאיזו מסגרת HTML (מסגרת ראשית או iframe מסוים) שייך אירוע מסוים. לאחר מכן הדפדפן שולח את האירוע לתהליך הרינדור המתאים שאחראי על מסגרת ה-HTML הזו.
3. הכלי לרינדור מקבל את האירוע ומצרף אותו לתור, כדי שיוכל לעבד כשהוא יהיה זמין לביצוע.
4. הכלי לעיבוד מעבד את האירוע על ידי הפעלת ה-handlers שלו. רכיבי ה-handler האלה עשויים להוסיף עוד עבודות אסינכרוניות, כמו setTimeout ואחזורים, שהן חלק מהטיפול בקלט. אבל בשלב הזה, העבודה סנכרונית הושלמה.
5. נצבע על המסך מסגרת שמשקפת את התוצאה של הפעלת רכיבי ה-handler של האירועים. שימו לב שמשימות אסינכרוניות שהגורם המטפל באירועים עדיין עשוי להיות לא גמור.

הזמן שבין השלבים (1) ו-(3) שמתואר למעלה הוא העיכוב של האירוע, וזהו הזמן שנמדד ב-FID.

הזמן בין השלבים (1) ו-(5) שמתואר למעלה הוא משך הזמן של האירוע. את זה ימדד המדד החדש.

משך האירוע כולל את ההשהיה, אבל הוא כולל גם את העבודה שמתרחשת ברכיבי ה-handler של האירועים ואת העבודה שהדפדפן צריך לעשות כדי לצבוע את הפריים הבא אחרי שרכיבי ה-handler האלה פעלו. משך הזמן של אירוע זמין כרגע ב-Event Timing API באמצעות המאפיין duration של הרשומה.

הערה לגבי משימות אסינכרוניות

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

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

קיבוץ אירועים לאינטראקציות

הרחבת מדידת המדד מ-delay ל-duration היא שלב ראשון טוב, אבל עדיין יש פער קריטי במדד: הוא מתמקד באירועים בודדים ולא בחוויית המשתמש באינטראקציה עם הדף.

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

סוג אינטראקציה

נקודה חשובה: התוכן בקטע הזה נכתב בתקופה שבה אנחנו עדיין מפתחים את התכונה 'Interaction to Next Paint (INP)'. במדד הנוכחי רק מובאים בחשבון אירועי מקלדת, עכבר ומגע, לא כולל העברת העכבר או גלילה במהלך חישוב ה-INP.

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

אירועי DOM לכל סוג אינטראקציה.

אינטראקציה	התחלה / סיום	אירועים במחשב	אירועים לנייד
מקלדת	בוצעה לחיצה על מקש	keydown	keydown
		keypress	keypress
	המפתח שוחרר	keyup	keyup
מקישים או גוררים	יש להקיש על 'התחלה' או על 'גרירה'	pointerdown	pointerdown
		mousedown	touchstart
	יש להקיש למעלה או לגרור את הקצה	pointerup	pointerup
		mouseup	touchend
		click	mousedown
			mouseup
			click
גלילה	לא רלוונטי

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

הערה על ההתחלה והסיום

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

מקלדת

אינטראקציה במקלדת מורכבת משני חלקים: כשהמשתמש לוחץ על המקש וכשהוא משחרר אותו. לאינטראקציה הזו של המשתמש יש שלושה אירועים משויכים: keydown, keyup ו-keypress. התרשים הבא ממחיש את העיכובים ומשך הזמן של keydown ושל keyup באינטראקציה עם מקלדת:

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

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

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

הערה: האירוע keypress הוצא משימוש, והוא צריך להיות מופעל באותה משימה כמו האירוע keydown, כך שמשך הזמן שלו תמיד יחפוף למשך הזמן של keydown.

פתק עם לחיצות חוזרות

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

סטפס

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

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

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

אפשר לצמצם עוד את הקהל ל-pointerdown ול-pointerup בלבד?

קודם כל, אנחנו ממליצים להשתמש באירועים pointerdown ו-pointerup, ולהניח שהם מכסים את כל משכי הזמן שמעניינים אותנו. למרבה הצער, זה לא המצב, כפי שמוצג במקרה הקצה הזה. אפשר לנסות לפתוח את האתר הזה בנייד או עם אמולציה לנייד, ואז להקיש במקום שבו מופיע הכיתוב 'אני רוצה ללחוץ'. האתר הזה מפעיל את העיכוב של ההקשה בדפדפן. אפשר לראות ש-pointerdown, pointerup ו-touchend נשלחים במהירות, ואילו mousedown, mouseup ו-click ממתינים לעיכוב לפני שהם נשלחים. כלומר, אם נבדוק רק את pointerdown ואת pointerup, נפספס את משך הזמן מהאירועים הסינתטיים. משך הזמן הזה גבוה בגלל העיכוב בהקשה בדפדפן, וצריך לכלול אותו. לכן עלינו למדוד את pointerdown, pointerup ואת click כדי לכסות את האינטראקציה המלאה.

גרירה

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

אנחנו גם לא שוקלים להשתמש בגרירה שמוטמעת דרך Drag and Drop API, כי הם פועלים רק במחשב.

גלילה

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

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

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

יש מספר אירועים שנשלחים כאשר משתמש גולל, כמו touchstart, touchmove ו-scroll. פרט לאירוע הגלילה, הדבר תלוי ברובו במכשיר שמשמש לגלילה: אירועי מגע נשלחים כאשר גוללים עם האצבע במכשירים ניידים, ואילו אירועי גלגל מתרחשים כאשר גוללים עם גלגל העכבר. אירועי הגלילה מופעלים אחרי שהגלילה הראשונית מסתיימת. באופן כללי, אף אירוע DOM לא חוסם גלילה, אלא אם האתר משתמש בפונקציות event listener לא פסיביות. אנחנו מתייחסים לגלילה כאל הפרדה מוחלטת מאירועי DOM. מה שאנחנו רוצים למדוד הוא הזמן שעובר מהרגע שבו המשתמש זז מספיק כדי ליצור תנועת גלילה עד לפריים הראשון שמציג את הגלילה.

איך מגדירים את זמן האחזור של אינטראקציה?

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

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

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

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

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

כשמדובר בגלילה (שמופיעה רק באירוע משויך אחד), אנחנו רוצים להגדיר את זמן האחזור כזמן שחולף לדפדפן כדי ליצור את הפריים הראשון כתוצאה מהגלילה. כלומר, זמן האחזור הוא הדלתא בין האירוע timeStamp של אירוע ה-DOM הראשון (כמו touchmove, אם משתמשים באצבע) והוא גדול מספיק כדי להפעיל גלילה לבין ה-Parta הראשון שמשקף את הגלילה.

צבירה של כל האינטראקציות בכל דף

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

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

כדי לבצע את הצבירה הזו, עלינו לפתור שתי שאלות:

1. אילו נתונים אנחנו מנסים לצבור?
2. איך אנחנו צוברים את הנתונים האלה?

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

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

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

איך זה נראה בממשקי API של ביצועי אינטרנט?

מה חסר בתזמון האירוע?

לצערנו, לא ניתן לתעד את כל הרעיונות שמוצגים בפוסט באמצעות Event Timing API. באופן ספציפי, אין דרך פשוטה לדעת אילו אירועים משויכים לאינטראקציה מסוימת של המשתמש עם ה-API. לשם כך, הצענו להוסיף interactionID ל-API.

חסרון נוסף של Event Timing API הוא שאין דרך למדוד את האינטראקציה של הגלילה, ולכן אנחנו פועלים להפעלת המדידות האלה (דרך Event Timing או API נפרד).

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

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

let maxTapOrDragDuration = 0;
let maxKeyboardDuration = 0;
const observer = new PerformanceObserver(list => {
  list.getEntries().forEach(entry => {
    switch(entry.name) {
      case "keydown":
      case "keyup":
        maxKeyboardDuration = Math.max(maxKeyboardDuration,
            entry.duration);
        break;
      case "pointerdown":
      case "pointerup":
      case "click":
        maxTapOrDragDuration = Math.max(maxTapOrDragDuration,
            entry.duration);
        break;
    }
  });
});
observer.observe({type: "event", durationThreshold: 16, buffered: true});
// We can report maxTapDragDuration and maxKeyboardDuration when sending
// metrics to analytics.

משוב

נשמח לשמוע מה דעתך. אפשר לשלוח לנו אימייל לכתובת: [e-mail].