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

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

Jeremy Wagner
Jeremy Wagner

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הקלטת נתיב

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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