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

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

Jeremy Wagner

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

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

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

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

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

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

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

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

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

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

הקלטת מעקב

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

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

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

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

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

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

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

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

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

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

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

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

התוסף Web Vitals ל-Chrome

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

לאחר ההתקנה של התוסף Web Vitals, נתוני האינטראקציות יוצגו במסוף כלי הפיתוח במקרים הבאים:

  1. ב-Chrome, לוחצים על סמל התוספים שמשמאל לסרגל הכתובות.
  2. מאתרים את תוסף Web Vitals בתפריט הנפתח.
  3. לוחצים על הסמל שמשמאל כדי לפתוח את ההגדרות של התוסף.
  4. לוחצים על אפשרויות.
  5. מפעילים את תיבת הסימון Console Log במסך שנפתח ולוחצים על Save.

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

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

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

איך לזהות איזה חלק באינטראקציה איטי

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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