אבחון ידני של אינטראקציות איטיות בשיעור ה-Lab

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

Jeremy Wagner

תאריך פרסום: 9 במאי 2023

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

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

מה קורה אם אין לכם נתוני שדה?

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

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

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

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

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

איך לשחזר אינטראקציות איטיות במעבדה

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

מדדים בזמן אמת בחלונית 'ביצועים' ב-DevTools

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

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

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

הקלטת נתיב

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

1. פותחים את הדף שרוצים לבדוק.
2. פותחים את כלי הפיתוח ל-Chrome ועוברים לחלונית ביצועים.
3. כדי להתחיל את המעקב, לוחצים על הלחצן הקלטה בפינה הימנית העליונה של החלונית.
4. מבצעים את האינטראקציות שבהן רוצים לפתור בעיות.
5. לוחצים שוב על הלחצן הקלטה כדי להפסיק את המעקב.

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

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

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

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

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

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

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

איך מזהים איזה חלק מאינטראקציה מסוימת איטי

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

איך מזהים עיכובים ארוכים בהזנת הקלט

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

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

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

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

איך מזהים משכי עיבוד ארוכים

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

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

1. בודקים אם המשימה שמשויכת לקריאות החוזרות של האירוע היא משימה ארוכה. כדי לחשוף משימות ארוכות בשיעור Lab בצורה אמינה יותר, יכול להיות שתצטרכו להפעיל ויסות נתונים (throttle) במעבד (CPU) בחלונית הביצועים, או לחבר מכשיר Android ברמה נמוכה עד בינונית ולהשתמש בניפוי באגים מרחוק.
2. אם המשימה שמריצה את קריאות החזרה (callbacks) של האירועים היא משימה ארוכה, מחפשים ב-call stack רשומות של טיפול באירועים – לדוגמה, רשומות עם שמות כמו Event: click – שיש להן משולש אדום בפינה השמאלית העליונה של הרשומות.

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

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

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

איך מזהים עיכובים בהצגה

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

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

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

• נפחי DOM גדולים לעיתים קרובות, ככל שגודל ה-DOM של הדף גדל, כך גם עולה נפח העבודה שנדרש לרינדור כדי לעדכן את התצוגה של הדף. מידע נוסף זמין במאמר איך גדלים גדולים של DOM משפיעים על האינטראקטיביות — ומה אפשר לעשות בעניין.
• הזרמות חוזרות מאולצות המצב הזה מתרחש כשמחילים שינויים בסגנון על רכיבים ב-JavaScript, ולאחר מכן שולחים שאילתה מיידית לגבי התוצאות של העבודה הזו. כתוצאה מכך, הדפדפן צריך לבצע את עבודת הפריסה לפני שהוא יכול לבצע כל פעולה אחרת, כדי שיוכל להחזיר את הסגנונות המעודכנים. מידע נוסף טיפים למניעת זרימה מחדש בכפייה זמינים במאמר הימנעות מתצוגות מפורטות גדולות ומורכבות ומרעידת תצוגה.
• ביצוע עבודה מיותרת או מופרזת בקריאות חזרה (callbacks) של requestAnimationFrame. פונקציות ה-callbacks של requestAnimationFrame() מופעלות במהלך שלב העיבוד של לולאת האירועים, והן חייבות להסתיים לפני שאפשר להציג את המסגרת הבאה. אם אתם משתמשים ב-requestAnimationFrame() כדי לבצע עבודה שלא כוללת שינויים בממשק המשתמש, חשוב לדעת שיכול להיות שתגרמו לעיכוב של הפריים הבא.
• פונקציות קריאה חוזרת מסוג ResizeObserver. קריאות חזרה כאלה פועלות לפני העיבוד, ויכול להיות שהן יגרמו לעיכוב בהצגת המסגרת הבאה אם העבודה בהן יקרה. בדומה לקריאות חוזרות של אירועים, כדאי לדחות כל לוגיקה שלא נדרשת לפריים הבא.

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

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

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

פתרון בעיות ב-INP הוא תהליך איטרטיבי

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

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

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