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 אלפיות השנייה כדי לחשב מראש עבודה יקרה, כדי להגדיל את הסיכויים להגיע ל-60 פריימים לשנייה.
בקטע ביצועי עיבוד מפורטות אסטרטגיות שונות לאופטימיזציה של אנימציה.
- אנימציות חזותיות, כמו כניסות ויציאות, שלב ביניים ואינדיקטורים לטעינה.
- גלילה. האיסור הזה כולל הנפה, כלומר הנפנות, כלומר המשתמש מתחיל לגלול ואז משחרר אותו והדף ממשיך לגלול.
- גרירה. אנימציות עוקבות בדרך כלל אחרי אינטראקציות של משתמשים, כמו הזזת מפה או צביטה לשינוי מרחק התצוגה.
לא פעיל: מקסימום זמן ללא פעילות
מטרה: הגדלת משך הזמן ללא פעילות כדי להגדיל את הסיכויים שהדף יגיב לקלט של משתמש תוך 50 אלפיות השנייה.
הנחיות:
יש להשתמש בזמן ללא פעילות כדי להשלים עבודה שנדחית. לדוגמה, בטעינה הראשונית של הדף, טוענים כמה שפחות נתונים, ואז משתמשים בזמן לא פעיל כדי לטעון את השאר.
ביצוע עבודה במשך זמן לא פעיל של 50 אלפיות השנייה לכל היותר. לפרק זמן ארוך יותר, אתם עלולים להפריע ליכולת של האפליקציה להגיב לקלט של משתמשים תוך 50 אלפיות השנייה.
אם משתמש יוצר אינטראקציה עם הדף במהלך העבודה במצב לא פעיל, האינטראקציה של המשתמש תמיד צריכה לקבל את העדיפות הגבוהה ביותר ולהפסיק את משך הזמן ללא פעילות.
טעינה: אפשר להציג תוכן ולהפוך לאינטראקטיבי תוך פחות מ-5 שניות
כשהדפים נטענים באיטיות, תשומת הלב של המשתמש משוטטת והמשתמשים רואים שהמשימה לא תקינה. לאתרים שנטענים במהירות יש סשנים ממוצעים ארוכים יותר, שיעורי עזיבה נמוכים יותר וניראות גבוהה יותר של מודעות.
יעדים:
אופטימיזציה לביצועי טעינה מהירה ביחס ליכולות המכשיר והרשת של המשתמשים. בשלב זה, יעד טוב לטעינות ראשונות הוא לטעון את הדף ולהיות אינטראקטיבי תוך 5 שניות או פחות במכשירים ניידים בטווח הביניים עם חיבורי 3G איטיים.
בטעינות הבאות, יעד טוב הוא לטעון את הדף תוך פחות מ-2 שניות.
הנחיות:
בודקים את ביצועי העומסים במכשירים הניידים ובחיבורי הרשת המשותפים למשתמשים. ניתן להשתמש בדוח חוויית המשתמש ב-Chrome כדי לגלות את התפלגות החיבור של המשתמשים. אם אין נתונים זמינים לאתר שלכם, לפי The Mobile Economy 2019 מציין שנקודת בסיס גלובלית טובה היא טלפון Android בטווח בינוני, כמו Moto G4, ורשת 3G איטית (שמוגדרת בתור RTT של 400 אלפיות שנייה ומהירות העברה של 400 kbps). השילוב הזה זמין ב-WebPageTest.
חשוב לזכור: למרות שהמכשיר הטיפוסי של משתמש נייד עשוי לטעון שהוא מחובר לרשת 2G, 3G או 4G, בפועל, מהירות החיבור האפקטיבית לרוב איטית יותר באופן משמעותי, בגלל אובדן מנות והבדלים ברשת.
לא צריך לטעון הכול תוך פחות מ-5 שניות כדי ליצור תפיסה של טעינה מלאה. כדאי לשקול טעינה מדורגת של תמונות, פיצול קוד של חבילות JavaScript ואופטימיזציות אחרות שמוצעות ב-web.dev.
כלים למדידת RAIL
יש כמה כלים שיעזרו לכם להפוך את מדידות ה-RAIL לאוטומטיות. אופן השימוש תלוי בסוג המידע שאתם צריכים ובסוג תהליך העבודה המועדף עליכם.
כלי פיתוח ל-Chrome
כלי הפיתוח ל-Chrome מספקים ניתוח מעמיק של כל מה שמתרחש בזמן שהדף נטען או פועל. קראו את המאמר תחילת העבודה עם ניתוח ביצועים של זמן ריצה כדי להכיר את ממשק המשתמש של החלונית Performance (ביצועים).
התכונות הבאות של כלי הפיתוח רלוונטיות במיוחד:
כדאי לווסת את המעבד (CPU) כדי לדמות מכשיר פחות חזק.
ויסות נתונים של הרשת כדי לדמות חיבורים איטיים יותר.
הצגת הפעילות בשרשור הראשי כדי להציג כל אירוע שהתרחש ב-thread הראשי בזמן ההקלטה.
הצגת הפעילויות של ה-thread הראשי בטבלה, כדי למיין את הפעילויות לפי האירועים שצברו את הזמן הרב ביותר.
ניתוח פריימים לשנייה (FPS) כדי לבדוק אם האנימציות באמת פועלות בצורה חלקה.
מעקב בזמן אמת אחרי השימוש במעבד (CPU), גודל הערימה של JS, צומתי DOM, פריסות לשנייה ועוד באמצעות Performance Monitor.
בקטע Network (רשת) תוכלו להציג בקשות רשת שהתרחשו בזמן ההקלטה.
צלמו צילומי מסך בזמן הצילום כדי להציג בדיוק איך הדף נראה בזמן טעינת הדף, או כשהאנימציה הופעלה וכו'.
צפייה באינטראקציות כדי לזהות במהירות מה קרה בדף אחרי שמשתמשים קיימו איתו אינטראקציה.
זיהוי בעיות בביצועי הגלילה בזמן אמת על ידי הדגשת הדף בכל פעם שמופעל האזנה שעלולה להיות בעייתית.
צפייה באירועי הצגת תמונה בזמן אמת כדי לזהות אירועים יקרים של הצגת תוכן שעלול לפגוע בביצועים של האנימציות.
מגדלור
Lighthouse זמין בכלי הפיתוח ל-Chrome, ב-PageSpeed Insights, כתוסף ל-Chrome, כמודול Node.js ומתוך WebPageTest. מזינים כתובת URL, מדמה מכשיר בטווח בינוני עם חיבור 3G איטי, מריץ סדרה של ביקורות בדף ואז מספק דוח על ביצועי הטעינה והצעות לשיפור.
הביקורות הבאות רלוונטיות במיוחד:
תשובה
השהיה אפשרית מקסימלית לאחר קלט ראשוני. הערכה של משך הזמן שייקח לאפליקציה להגיב לקלט של משתמשים, על סמך זמן חוסר הפעילות ב-thread הראשי.
זמן החסימה הכולל. מדד של משך הזמן הכולל שבו הדף חסום כך שלא יוכל להגיב לקלט של משתמשים, כמו קליקים על העכבר, הקשות על המסך או לחיצות על המקלדת.
זמן לאינטראקציה. מודד מתי משתמש יכול ליצור אינטראקציה בעקביות עם כל האלמנטים בדף.
טעינה
לא רושם קובץ שירות (service worker) ששולט בדף ובכתובת start_url. קובץ שירות (service worker) יכול לשמור במטמון משאבים נפוצים במכשיר של המשתמש, וכך לקצר את הזמן שנדרש לשליפת משאבים ברשת.
לעיכוב הטעינה של תמונות שלא מופיעות במסך. עכבו את הטעינה של תמונות שלא מופיעות במסך עד שיש בהן צורך.
קביעת גודל תקין של תמונות. אין להציג תמונות שגדולות באופן משמעותי מהגודל שמוצג באזור התצוגה בנייד.
להימנע מנפח DOM גדול מדי. מצמצמים את הבייטים של הרשת על ידי משלוח של צומתי DOM הנדרשים לעיבוד הדף.
WebPageTest
WebPageTest הוא כלי לביצועי אינטרנט שמשתמש בדפדפנים אמיתיים כדי לגשת לדפי אינטרנט ולאסוף מדדי תזמון. הזינו כתובת URL בכתובת webpagetest.org/easy כדי לקבל דוח מפורט על ביצועי הטעינה של הדף במכשיר אמיתי של Moto G4 עם חיבור איטי לרשת 3G. אפשר גם להגדיר אותו כך שיכלול ביקורת של Lighthouse.
סיכום
RAIL היא עדשה לבחינת חוויית המשתמש באתר כמסע שמורכב מאינטראקציות נפרדות. עליך להבין כיצד המשתמשים תופסים את האתר שלך, כדי להגדיר יעדי ביצועים עם ההשפעה הגדולה ביותר על חוויית המשתמש.
לשים את המשתמש במרכז.
להגיב לקלט של משתמשים תוך פחות מ-100 אלפיות השנייה.
יצירת מסגרת בפחות מ-10 אלפיות השנייה בזמן אנימציה או בגלילה.
הגדלת משך הזמן ללא פעילות ב-thread הראשי.
טעינת תוכן אינטראקטיבי בפחות מ-5,000 אלפיות שנייה.