מדידת הביצועים באמצעות מודל ה-RAIL

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

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

התמקדות במשתמש

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

תפיסת המשתמשים לגבי עיכובים בביצועים

‫0 עד 16 אלפיות השנייה	המשתמשים טובים מאוד במעקב אחרי תנועה, והם לא אוהבים אנימציות לא חלקות. הם תופסים את האנימציות כחלקות כל עוד מוצגים 60 פריים חדשים בכל שנייה. זה אומר 16 אלפיות השנייה לכל פריים, כולל הזמן שלוקח לדפדפן לצייר את הפריים החדש על המסך, כך שנשארות לאפליקציה כ-10 אלפיות השנייה ליצירת פריים.
‫0 עד 100 אלפיות השנייה	התגובה לפעולות של המשתמשים מתבצעת בתוך חלון הזמן הזה, והמשתמשים מרגישים שהתוצאה מיידית. אם משך הזמן ארוך יותר, הקשר בין הפעולה לתגובה נשבר.
‫100 עד 1,000 אלפיות השנייה	בחלון הזה, התחושה היא שהדברים הם חלק מרצף טבעי ומתמשך של משימות. עבור רוב המשתמשים באינטרנט, טעינת דפים או שינוי תצוגות מייצגים משימה.
‫1,000 אלפיות השנייה או יותר	מעבר ל-1,000 מילישניות (שנייה אחת), המשתמשים מאבדים את המיקוד במשימה שהם מבצעים.
‫10,000 אלפיות השנייה או יותר	מעל 10,000 מילישניות (10 שניות), המשתמשים מתוסכלים וסביר להניח שהם ינטשו את המשימות. יכול להיות שהם יחזרו מאוחר יותר.

יעדים והנחיות

במסגרת RAIL, למונחים יעדים והנחיות יש משמעויות ספציפיות:

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

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

תגובה: עיבוד אירועים תוך פחות מ-50 אלפיות השנייה

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

הנחיות:

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

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

• לפעולות שנמשכות יותר מ-50 אלפיות השנייה, תמיד צריך לספק משוב.

‫50 אלפיות השנייה או 100 אלפיות השנייה?

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

אנימציה: יצירת פריים ב-10 אלפיות השנייה

יעדים:

• צריך ליצור כל פריים באנימציה ב-10 אלפיות השנייה או פחות. מבחינה טכנית, התקציב המקסימלי לכל פריים הוא 16 אלפיות השנייה (1,000 אלפיות השנייה חלקי 60 פריימים בשנייה ≈ 16 אלפיות השנייה), אבל דפדפנים צריכים כ-6 אלפיות השנייה כדי לעבד כל פריים, ולכן ההנחיה היא 10 אלפיות השנייה לכל פריים.

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

הנחיות:

• בנקודות לחץ גבוהות כמו אנימציות, העיקרון הוא לא לעשות כלום איפה שאפשר, ולעשות את המינימום האפשרי איפה שאי אפשר. כשאפשר, כדאי להשתמש בתגובה של 100 ms כדי לבצע מראש חישובים מורכבים, וכך להגדיל את הסיכוי להגיע ל-60 fps.

• במאמר ביצועי רינדור מפורטות אסטרטגיות שונות לאופטימיזציה של אנימציות.

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

מצב המתנה: ניצול מיטבי של זמן ההמתנה

המטרה: להאריך את זמן ההמתנה כדי להגדיל את הסיכוי שהדף יגיב לקלט של המשתמש תוך 50 אלפיות השנייה.

הנחיות:

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

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

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

טעינה: הצגת תוכן ואינטראקטיביות תוך פחות מ-5 שניות

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

יעדים:

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

• בטעינות הבאות, מומלץ שהדף ייטען תוך פחות מ-2 שניות.

הנחיות:

• כדאי לבדוק את ביצועי הטעינה במכשירים ניידים ובחיבורי רשת שמשותפים למשתמשים שלכם. אתם יכולים להשתמש בדוח על חוויית המשתמש ב-Chrome ‏(CrUX) כדי לגלות את התפלגות החיבורים של המשתמשים שלכם. אם הנתונים לא זמינים באתר שלכם, The Mobile Economy 2019 מציע קו בסיס גלובלי טוב: טלפון Android בינוני, כמו Moto G4, ורשת 3G איטית (מוגדרת כ-400 ms RTT ומהירות העברה של 400 kbps). השילוב הזה זמין ב-WebPageTest.

• חשוב לזכור שלמרות שבמכשיר של משתמש טיפוסי בנייד יכול להיות שמוצג חיבור 2G,‏ 3G או 4G, במציאות מהירות החיבור האפקטיבית לרוב איטית משמעותית, בגלל אובדן מנות ושונות ברשת.

• הסרת משאבים שחוסמים עיבוד.

• לא צריך לטעון הכול תוך פחות מ-5 שניות כדי ליצור תחושה של טעינה מלאה. כדאי להשתמש בטעינה מדורגת של תמונות, בפיצול קוד של חבילות JavaScript ובאופטימיזציות אחרות שמוצעות ב-web.dev.

כלים למדידת RAIL

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

כלי פיתוח ל-Chrome

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

התכונות הבאות בכלי הפיתוח רלוונטיות במיוחד:

• ויסות הנתונים של המעבד (CPU) כדי לדמות מכשיר חלש יותר.

• הגבלת רוחב הפס ברשת כדי לדמות חיבורים איטיים יותר.

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

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

• ניתוח של פריימים לשנייה (FPS) כדי למדוד אם האנימציות פועלות בצורה חלקה.

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

• הדמיה של בקשות רשת שהתרחשו בזמן ההקלטה באמצעות הקטע Network.

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

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

• זיהוי בעיות בביצועי הגלילה בזמן אמת על ידי הדגשת הדף בכל פעם שמופעל מאזין שעלול לגרום לבעיות.

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

Lighthouse

Lighthouse זמין בכלי הפיתוח ל-Chrome, ב-PageSpeed Insights, כתוסף ל-Chrome, כמודול Node.js וב-WebPageTest. מזינים כתובת URL, הכלי מדמה מכשיר בינוני עם חיבור 3G איטי, מריץ סדרה של בדיקות בדף ואז מספק דוח על ביצועי הטעינה, וגם הצעות לשיפור.

הביקורות הבאות רלוונטיות במיוחד:

תשובה

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

• לא נעשה שימוש ברכיבי listener פסיביים לשיפור ביצועי הגלילה.

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

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

טעינה

• לא רושם קובץ שירות (service worker) ששולט בדף וב-start_url. ‫Service worker יכול לשמור במטמון משאבים נפוצים במכשיר של המשתמש, וכך לקצר את הזמן שנדרש לאחזור משאבים ברשת.

• טעינת הדף לא מהירה מספיק ברשתות סלולריות.

• הסרת משאבים שחוסמים עיבוד.

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

• הגדרת גודל תמונות בצורה נכונה. אל תציגו תמונות שגדולות משמעותית מהגודל שמוצג באזור התצוגה בנייד.

• הימנעות משרשור של בקשות קריטיות.

• לא נעשה שימוש ב-HTTP/2 עבור כל משאבי הדף.

• קידוד תמונות ביעילות.

• הפעלת דחיסת טקסט.

• הימנעו ממטען ייעודי (payload) גדול מדי ברשת.

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

WebPageTest

‫WebPageTest הוא כלי לניתוח ביצועי אתרים שמשתמש בדפדפנים אמיתיים כדי לגשת לדפי אינטרנט ולאסוף מדדי תזמון. מזינים כתובת URL בכתובת webpagetest.org/easy כדי לקבל דוח מפורט על ביצועי הטעינה של הדף במכשיר Moto G4 אמיתי עם חיבור 3G איטי. אפשר גם להגדיר אותו כך שיכלול ביקורת של Lighthouse.

סיכום

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

• לשים את המשתמש במרכז.

• להגיב לקלט של המשתמשים תוך פחות מ-100 אלפיות השנייה.

• יצירת פריים בפחות מ-10 אלפיות השנייה בזמן אנימציה או גלילה.

• ממקסמים את משך הזמן שה-thread הראשי לא פעיל.

• טעינת תוכן אינטראקטיבי תוך פחות מ-5,000 אלפיות השנייה.