RAIL הוא מודל ביצועים ממוקד-משתמש שמספק מבנה לחשיבה על ביצועים. המודל מפרק את חוויית המשתמש לפעולות עיקריות (לדוגמה, הקשה, גלילה, טעינה) ועוזר לכם להגדיר יעדי ביצועים לכל אחת מהן.
RAIL מייצג ארבעה היבטים שונים של מחזור החיים של אפליקציית אינטרנט: תגובה (Response), אנימציה (Animation), חוסר פעילות (Idle) וטעינה (Load). למשתמשים יש ציפיות שונות לגבי הביצועים בכל אחד מההקשרים האלה, ולכן יעדי הביצועים מוגדרים על סמך ההקשר ומחקר UX על האופן שבו משתמשים תופסים עיכובים.
התמקדות במשתמש
המשתמשים צריכים להיות המוקד של מאמצי הביצועים שלכם. בטבלה הבאה מתוארים מדדים מרכזיים שקשורים לאופן שבו המשתמשים תופסים עיכובים בביצועים:
תפיסת המשתמשים לגבי עיכובים בביצועים| 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 אלפיות השנייה ומהירות העברה של 400Kbps). השילוב הזה זמין ב-WebPageTest.
חשוב לזכור שלמרות שבמכשיר של משתמש טיפוסי בנייד יכול להיות שמוצג חיבור 2G, 3G או 4G, בפועל מהירות החיבור האפקטיבית בדרך כלל איטית יותר באופן משמעותי, בגלל אובדן מנות ושינויים ברשת.
לא צריך לטעון את כל התוכן תוך פחות מ-5 שניות כדי ליצור תחושה של טעינה מלאה. כדאי לשקול טעינה מדורגת של תמונות, פיצול קוד של חבילות JavaScript ואופטימיזציות אחרות שמוצעות ב-web.dev.
כלים למדידת RAIL
יש כמה כלים שיכולים לעזור לכם לבצע מדידות RAIL באופן אוטומטי. הבחירה בכלי תלויה בסוג המידע שאתם צריכים ובסוג תהליך העבודה שאתם מעדיפים.
כלי פיתוח ל-Chrome
כלי הפיתוח ל-Chrome מספקים ניתוח מעמיק של כל מה שקורה בזמן שטעינת הדף או הפעלתו. כדי להכיר את ממשק המשתמש של החלונית Performance, קראו את המאמר תחילת העבודה עם ניתוח ביצועי זמן הריצה.
התכונות הבאות של כלי הפיתוח רלוונטיות במיוחד:
ויסות הנתונים של המעבד (CPU) כדי לדמות מכשיר פחות חזק.
הגבילו את רוחב הפס של הרשת כדי לדמות חיבורים איטיים יותר.
הצגת הפעילות בשרשור הראשי כדי לראות כל אירוע שהתרחש בשרשור הראשי בזמן ההקלטה.
הצגת הפעילויות של ה-thread הראשי בטבלה כדי למיין את הפעילויות לפי משך הזמן שהן נמשכו.
ניתוח קצב הפריימים (FPS) כדי לבדוק אם האנימציות פועלות בצורה חלקה.
מעקב אחרי השימוש במעבד (CPU), גודל ה-heap של JS, צומתי DOM, פריסות לשנייה ועוד בזמן אמת באמצעות הכלי למעקב אחר ביצועים.
הצגת בקשות לאחזור מהרשת שהתרחשו בזמן ההקלטה בקטע רשת.
צלמו צילומי מסך בזמן ההקלטה כדי להפעיל מחדש בדיוק איך שהדף נראה בזמן טעינת הדף, או כשאנימציה הופעלה וכו'.
הצגת אינטראקציות כדי לזהות במהירות מה קרה בדף אחרי שמשתמש ביצע בו אינטראקציה.
איתור בעיות בביצועי הגלילה בזמן אמת על ידי הדגשת הדף בכל פעם שמופעל מאזין שעלול להיות בעייתי.
צפייה באירועי רינדור בזמן אמת כדי לזהות אירועי רינדור שדורשים משאבים רבים ועלולים לפגוע בביצועים של האנימציות.
Lighthouse
Lighthouse זמין בכלי הפיתוח ל-Chrome, ב-PageSpeed Insights, כתוסף ל-Chrome, כמודול Node.js וב-WebPageTest. אתם מזינים כתובת URL, והכלי מדמה מכשיר בטווח בינוני עם חיבור איטי של דור שלישי, מריץ סדרה של בדיקות בדף, ואז מספק דוח על ביצועי הטעינה והצעות לשיפור.
הבדיקות הבאות רלוונטיות במיוחד:
תגובה
השהיה אפשרית מקסימלית לאחר קלט ראשוני. הערכה של משך הזמן שייקח לאפליקציה להגיב לקלט של משתמשים, על סמך זמן חוסר הפעילות של ה-Thread הראשי.
לא נעשה שימוש בפונקציות event listener פסיביות כדי לשפר את ביצועי הגלילה.
סה"כ זמן חסימה (TBT). מודד את משך הזמן הכולל שבו הדף חסום לתגובה לקלט של משתמשים, כמו קליקים בעכבר, הקשות על המסך או לחיצות על המקלדת.
מהירות ההגעה לפונקציונליות מלאה (TTI). מודד מתי משתמש יכול לבצע אינטראקציה עם כל רכיבי הדף באופן עקבי.
טעינה
לא רושם קובץ שירות (service worker) ששולט בדף וב-start_url. קובץ Service Worker יכול לשמור במטמון משאבים נפוצים במכשיר של המשתמש, וכך לקצר את הזמן שנדרש כדי לאחזר משאבים דרך הרשת.
עיכוב הטעינה של תמונות שלא מופיעות במסך. דחיית הטעינה של תמונות מחוץ למסך עד שהן נחוצות.
הגדירו את גודל התמונות בצורה נכונה. אל תציגו תמונות שגדולות משמעותית מהגודל שמוצג באזור התצוגה בנייד.
הימנעו מנפח DOM גדול מדי. כדי לצמצם את צריכת הבייטים ברשת, כדאי להעביר רק את צומתי ה-DOM שנדרשים לעיבוד הדף.
WebPageTest
WebPageTest הוא כלי לבדיקת ביצועים באינטרנט שמשתמש בדפדפנים אמיתיים כדי לגשת לדפי אינטרנט ולאסוף מדדי תזמון. מזינים כתובת URL ב-webpagetest.org/easy כדי לקבל דוח מפורט על ביצועי הטעינה של הדף במכשיר Moto G4 אמיתי עם חיבור 3G איטי. אפשר גם להגדיר אותו כך שיכלול ביקורת של Lighthouse.
סיכום
מודל RAIL הוא עדשה שדרכה אפשר לבחון את חוויית המשתמש באתר כמסע שמורכב מאינטראקציות נפרדות. כדי להגדיר יעדי ביצועים שישפיעו הכי הרבה על חוויית המשתמש, אתם צריכים להבין איך המשתמשים תופסים את האתר שלכם.
לשים את המשתמש במרכז.
להגיב לקלט של המשתמש תוך פחות מ-100 אלפיות השנייה.
יצירת פריים בפחות מ-10 אלפיות השנייה בזמן אנימציה או גלילה.
מגדילים את זמן חוסר הפעילות של ה-thread הראשי.
טעינת תוכן אינטראקטיבי תוך פחות מ-5,000 אלפיות השנייה.