כולנו יודעים כמה חשובים הביצועים. אבל כשאנחנו מדברים על ביצועים ועל 'מהירות' של אתרים, מה אנחנו מתכוונים במדויק?
האמת היא שהביצועים הם יחסיים:
- יכול להיות שאתר ייטען מהר אצל משתמש אחד (ברשת מהירה עם מכשיר חזק) אבל לאט אצל משתמש אחר (ברשת איטית עם מכשיר פשוט).
- יכול להיות ששני אתרים יסתיימו לטעינת התוכן באותו פרק זמן, אבל אחד מהם ייראה כאילו הוא נטען מהר יותר (אם הוא טוען את התוכן בהדרגה במקום להמתין עד הסוף כדי להציג משהו).
- יכול להיות שנראה שהאתר נטען במהירות, אבל לאחר מכן הוא מגיב לאיטיות (או בכלל לא) לאינטראקציה של המשתמשים.
כשמדברים על ביצועים, חשוב להיות מדויקים ולהתייחס לביצועים במונחים של מדדים. קריטריונים אובייקטיביים שאפשר למדוד באופן כמותי, אבל חשוב גם לוודא שהמדדים שאתם מודדים שימושיים.
הגדרת מדדים
בעבר, הביצועים באתר נמדדו באמצעות האירוע load. עם זאת, למרות ש-load הוא רגע מוגדר היטב במחזור החיים של הדף, הרגע הזה לא בהכרח תואם למשהו שחשוב למשתמש.
לדוגמה, שרת יכול להגיב בדף מינימלי ש "נטען" באופן מיידי, אבל לאחר מכן הוא דוחה את אחזור התוכן או הצגת כל דבר בדף עד כמה שניות אחרי שהאירוע load מופעל. מבחינה טכנית, זמן הטעינה של דף כזה הוא מהיר, אבל הזמן הזה לא תואם לחוויית הטעינה של המשתמש.
בשנים האחרונות, חברי צוות Chrome – בשיתוף עם קבוצת העבודה של W3C בנושא ביצועי אינטרנט – עבדו על סטנדרטיזציה של קבוצה של מדדים וממשקי API חדשים שמאפשרים למדוד בצורה מדויקת יותר את חוויית המשתמשים בביצועים של דף אינטרנט.
כדי לוודא שהמדדים רלוונטיים למשתמשים, אנחנו מסדרים אותם סביב כמה שאלות מפתח:
| האם זה קורה? | האם הניווט התחיל בהצלחה? האם השרת הגיב? |
| האם המידע הזה מועיל? | האם המערכת עיבדה מספיק תוכן כדי שהמשתמשים יוכלו ליצור איתו אינטראקציה? |
| האם אפשר להשתמש בו? | האם משתמשים יכולים ליצור אינטראקציה עם הדף או שהוא עסוק? |
| האם הוא מהנה? | האם האינטראקציות חלקות וטבעיות, ללא השהיה? |
איך נמדדים המדדים
בדרך כלל, מדדי הביצועים נמדדים באחת משתי דרכים:
- במעבדה: שימוש בכלים כדי לדמות את טעינת הדף בסביבה עקבית ומבוקרת
- בשטח: על משתמשים אמיתיים שמטעינים את הדף ומקיימים איתו אינטראקציה
אף אחת מהאפשרויות האלה לא בהכרח טובה או גרועה יותר מהשנייה – למעשה, בדרך כלל מומלץ להשתמש בשתיהן כדי להבטיח ביצועים טובים.
במעבדה
בדיקת הביצועים במעבדה חיונית לפיתוח תכונות חדשות. לפני שמפיצים תכונות בסביבת הייצור, אי אפשר למדוד את מאפייני הביצועים שלהן אצל משתמשים אמיתיים. לכן, הדרך הטובה ביותר למנוע נסיגה בביצועים היא לבדוק אותן ב-Labs לפני שהן יושקו.
בשדה
מצד שני, בדיקה במעבדה היא מדד סביר לביצועים, אבל היא לא משקפת בהכרח את חוויית המשתמשים בפועל באתר.
הביצועים של אתר יכולים להשתנות באופן משמעותי בהתאם ליכולות של המכשיר של המשתמש ולתנאי הרשת שלו. הוא יכול להשתנות גם בהתאם לכך שמשתמש מבצע אינטראקציה עם הדף (או לא מבצע אינטראקציה) או בהתאם לאופן שבו הוא מבצע אינטראקציה.
גם טעינת הדפים לא תמיד ניתנת לחיזוי. לדוגמה, באתרים שמציגים תוכן או מודעות בהתאמה אישית, מאפייני הביצועים עשויים להיות שונים מאוד בין משתמש למשתמש. בדיקת מעבדה לא תתעד את ההבדלים האלה.
הדרך היחידה לדעת באמת איך האתר שלכם עובד עבור המשתמשים היא למדוד את הביצועים שלו בזמן שהמשתמשים מעלים את האתר ומקיימים איתו אינטראקציה. סוג המדידה הזה נקרא בדרך כלל מעקב אחר משתמשים אמיתיים (RUM).
סוגי מדדים
יש כמה סוגים נוספים של מדדים שרלוונטיים לאופן שבו המשתמשים תופסים את הביצועים.
- מהירות הטעינה שחושבים שהיא קיימת: המהירות שבה דף יכול לטעון ולעבד את כל הרכיבים החזותיים שלו במסך.
- מהירות הטעינה: כמה מהר הדף יכול לטעון ולבצע את כל קוד ה-JavaScript הנדרש כדי שהרכיבים יגיבו במהירות לאינטראקציה של המשתמש
- רספונסיביות בסביבת זמן הריצה: כמה מהר הדף יכול להגיב לאינטראקציה של המשתמש אחרי הטעינה שלו.
- יציבות חזותית: האם רכיבים בדף זזים בדרכים שהמשתמשים לא מצפים להן ויכולים להפריע לאינטראקציות שלהם?
- חלקות: האם המעברים והאנימציות מוצגים בקצב אחיד של פריימים ומעברים בצורה חלקה ממצב אחד למצב הבא?
אחרי שרואים את כל סוגי מדדי הביצועים האלה, ברור שאף מדד יחיד לא מספיק כדי לתעד את כל מאפייני הביצועים של דף.
מדדים חשובים למדידה
- הצגת תוכן ראשוני (FCP): המדד הזה מודד את הזמן מתחילת הטעינה של הדף ועד לשלב שבו חלק כלשהו מתוכן הדף עבר עיבוד במסך. (lab, field)
- Largest Contentful Paint (LCP): המדד הזה מודד את הזמן מתחילת הטעינה של הדף ועד לעיבוד של בלוק הטקסט או רכיב התמונה הגדולים ביותר במסך. (lab, field)
- מאינטראקציה ועד הצגת התגובה (INP): המדד הזה מודד את זמן האחזור של כל הקשה, קליק או אינטראקציה עם המקלדת שמתבצעים בדף, ובתאם למספר האינטראקציות, בוחרים את זמן האחזור הכי ארוך של אינטראקציה בדף (או זמן האחזור הקרוב ביותר לזמן האחזור הארוך ביותר) כערך יחיד מייצג שמתאר את רמת הרספונסיביות הכוללת של הדף. (lab, field)
- משך החסימה הכולל (TBT): מדד של משך הזמן הכולל בין הצגת התוכן הראשוני (FCP) לבין הזמן עד לפעילות מלאה (TTI), שבו ה-thread הראשי נחסם למשך מספיק זמן כדי למנוע תגובות לקלט. (lab)
- Cumulative Layout Shift (CLS): המדד הזה מודד את הניקוד המצטבר של כל התזוזות הבלתי צפויות בפריסת הדף שמתרחשות בין הזמן שבו הדף מתחיל להיטען לבין הזמן שבו מצב מחזור החיים שלו משתנה ל'מוסתרת'. (lab, field)
- זמן עד בייט ראשון (TTFB): המדד הזה מודד את הזמן שלוקח לרשת להגיב לבקשת משתמש עם הבייט הראשון של המשאב. (lab, field)
במקרים מסוימים, נציג מדדים חדשים כדי לכסות אזורים חסרים, אבל במקרים אחרים המדדים הטובים ביותר הם מדדים שמותאמים במיוחד לאתר שלכם.
מדדים מותאמים אישית
מדדי הביצועים שתיארנו למעלה עוזרים לכם להבין באופן כללי את מאפייני הביצועים של רוב האתרים באינטרנט. הן גם מאפשרות לכם להשתמש בקבוצה משותפת של מדדים כדי להשוות בין ביצועי האתר שלכם לביצועי האתרים של המתחרים.
עם זאת, יכול להיות שבמקרים מסוימים אתר ספציפי יהיה ייחודי באופן כלשהו, כך שיהיה צורך במדדים נוספים כדי לקבל תמונה מלאה של הביצועים. לדוגמה, מדד ה-LCP נועד למדוד את הזמן שבו הטעינה של התוכן הראשי של הדף מסתיימת, אבל יכולים להיות מקרים שבהם האלמנט הגדול ביותר הוא לא חלק מהתוכן הראשי של הדף, ולכן מדד ה-LCP עשוי להיות לא רלוונטי.
כדי לטפל במקרים כאלה, קבוצת העבודה בנושא ביצועי האינטרנט גם קבעה תקנים לממשקי API ברמה נמוכה יותר שיכולים להיות שימושיים להטמעה של מדדים מותאמים אישית:
- User Timing API
- Long Tasks API
- Long Animation Frames API
- Element Timing API
- Navigation Timing API
- Resource Timing API
- תזמון שרת
במדריך בנושא מדדים מותאמים אישית מוסבר איך להשתמש ב-API האלה כדי למדוד מאפייני ביצועים ספציפיים לאתר שלכם.