כולנו שמענו כמה ביצועים חשובים להם. אבל כשאנחנו מדברים על ביצועים ועל הפיכת אתרים ל"מהירים", למה אנחנו מתכוונים ספציפית?
האמת היא שביצועים הם יחסיים:
- אתר מסוים עשוי להיות מהיר למשתמש אחד (ברשת מהירה עם מכשיר מתקדם), אבל איטי למשתמש אחר (ברשת איטית עם מכשיר פשוט).
- שני אתרים עשויים לסיים את הטעינה באותו פרק זמן, אבל אחד מהם ייראה מהיר יותר (אם התוכן נטען בהדרגה, במקום להמתין עד שיוצג לסוף הנתונים).
- יכול להיות שאתר ייראה שנטען במהירות, אבל אז מגיב לאט (או לא מגיב בכלל) לאינטראקציה של המשתמש.
כשמדברים על ביצועים, חשוב להיות מדויקים במונחים של מדדים. קריטריונים אובייקטיביים שיכולים להיות כמותית אבל חשוב גם לוודא שהמדדים שאתם מודדים שימושי.
הגדרת מדדים
בעבר, ביצועי האינטרנט נמדדו באמצעות האירוע load. עם זאת, למרות ש-load הוא רגע מוגדר היטב במחזור החיים של דף, הרגע הזה לא בהכרח תואם למשהו שחשוב למשתמש.
לדוגמה, שרת יכול להגיב עם דף מינימלי ש"נטענו" באופן מיידי, אבל אז דחיית אחזור תוכן או הצגת תוכן כלשהו בדף עד מספר שניות לאחר הפעלת האירוע load. מבחינה טכנית, לדף כזה יש זמן טעינה מהיר, אבל זמן הטעינה הזה לא מתאים לאופן שבו משתמש חווה את טעינת הדף.
בשנים האחרונות, חברי צוות Chrome - בשיתוף עם קבוצת העבודה לביצועי אינטרנט של W3C - פעלו כדי ליצור סטנדרטיזציה של קבוצה של ממשקי API ומדדים חדשים, שמודדים בצורה מדויקת יותר את האופן שבו משתמשים נהנים מביצועים של דפי אינטרנט.
כדי להבטיח שהמדדים רלוונטיים למשתמשים, אנחנו מגדירים להם כמה שאלות מפתח:
| האם זה קורה? | הניווט התחיל בהצלחה? האם השרת הגיב? |
| האם זה שימושי? | האם יש מספיק תוכן שעבר רינדור כך שהמשתמשים יכולים לבצע בו פעולות? |
| אפשר להשתמש בה? | האם משתמשים יכולים לקיים אינטראקציה עם הדף, או שהוא עמוס? |
| איזה כיף? | האם האינטראקציות חלקות וטבעיות, ללא עיכובים? |
איך המדדים נמדדים
מדדי הביצועים בדרך כלל נמדדים באחת משתי דרכים:
- בשיעור ה-Lab: שימוש בכלים שמדמה טעינת דף בסביבה עקבית ומבוקרת
- בשדה: לגבי משתמשים אמיתיים שטוענים את הדף ומקיימים איתו אינטראקציה
אף אחת מהאפשרויות האלה לא בהכרח טובה יותר או גרועה מהשנייה — למעשה, באופן כללי כדאי להשתמש בשתיהן כדי להבטיח ביצועים טובים.
בשיעור ה-Lab
חשוב מאוד לבדוק את הביצועים במעבדה כשמפתחים תכונות חדשות. לפני שהתכונות מושקות בסביבת ייצור, לא ניתן למדוד את מאפייני הביצועים שלהן בקרב משתמשים אמיתיים, ולכן הדרך הטובה ביותר למנוע רגרסיות בביצועים היא לבדוק אותן בשיעור ה-Lab לפני השקת התכונה.
בשדה
מצד שני, בדיקות בשיעור ה-Lab הן מדד סביר לביצועים, אבל הן לא בהכרח משקפות את החוויה של המשתמשים באתר בפועל.
ביצועי האתר יכולים להשתנות באופן משמעותי בהתאם ליכולות המכשיר של המשתמש ולתנאי הרשת שלו. הנתונים עשויים גם להשתנות בהתאם לאינטראקציה של המשתמש עם הדף (או האופן שבו הוא נמצא).
כמו כן, טעינות של דפים הן לא תמיד דטרמיניסטיות. לדוגמה, באתרים שטוענים תוכן או מודעות בהתאמה אישית, מאפייני הביצועים של משתמשים שונים יכולים להיות שונים לחלוטין. בדיקת מעבדה לא תתעד את ההבדלים האלה.
הדרך היחידה לדעת באמת מהם הביצועים של האתר שלכם מבחינת המשתמשים היא למדוד בפועל את הביצועים שלו בזמן שהמשתמשים האלה טוענים אותו ומקיימים איתו אינטראקציה. סוג המדידה הזה נקרא Real User Monitoring (RUM).
סוגי מדדים
יש כמה סוגים אחרים של מדדים שרלוונטיים לאופן שבו המשתמשים תופסים את הביצועים.
- מהירות הטעינה המוערכת: באיזו מהירות דף יכול לטעון ולעבד את כל הרכיבים החזותיים שלו במסך.
- טעינת רספונסיביות: המהירות שבה דף יכול לטעון ולהפעיל קוד JavaScript נדרש כדי שהרכיבים מגיבים במהירות לאינטראקציה של המשתמש
- מהירות תגובה בזמן ריצה: לאחר טעינת הדף, באיזו מהירות הדף יכול להגיב לאינטראקציה של המשתמש.
- יציבות חזותית: האם הרכיבים בדף משתנים בדרכים שהמשתמשים לא מצפים להן ועלולים להפריע לאינטראקציות?
- החלקה: האם מעברים ואנימציות עוברים עיבוד בקצב פריימים עקבי ועוברים בצורה חלקה ממצב אחד למצב הבא?
לאור כל הסוגים האלה של מדדי ביצועים, ברור לנו שאף מדד יחיד לא מספיק כדי לייצג את כל מאפייני הביצועים של דף כלשהו.
מדדים שחשוב למדוד
- הצגת תוכן ראשוני (FCP): מדידה של הזמן שעובר מהרגע שבו הדף מתחיל להיטען ועד לרינדור של חלק כלשהו מתוכן הדף במסך. (lab, שדה)
- המהירות שבה נטען רכיב התוכן הכי גדול (LCP): מדידה של הזמן שעובר מהרגע שבו הדף מתחיל להיטען ועד לרינדור של רכיב הטקסט או רכיב התמונה הגדול ביותר במסך. (lab, שדה)
- מהירות התגובה לאינטראקציה באתר (INP): מדידת זמן האחזור של כל הקשה, קליק או אינטראקציה במקלדת שבוצעו עם הדף. בנוסף, על סמך מספר האינטראקציות, המערכת בוחרת את זמן האחזור של האינטראקציה הגרועה ביותר בדף (או קרוב ככל האפשר) כערך מייצג יחיד שמתאר את רמת הרספונסיביות הכוללת של דף. (lab, שדה)
- משך חסימה כולל (TBT): מדידה של משך הזמן הכולל בין FCP ל-TTI, שבו ה-thread הראשי נחסם למשך מספיק זמן כדי למנוע תגובות לקלט. (lab)
- Cumulative Layout Shift (CLS): מדד זה מודד את הציון המצטבר של כל השינויים הבלתי צפויים בפריסה שמתרחשים בין זמן תחילת הטעינה של הדף לבין המצב של מחזור החיים שלו מוסתר. (lab, שדה)
- Time to First Byte (TTFB): מדידת הזמן שלוקח לרשת להגיב לבקשת משתמש באמצעות הבייט הראשון של משאב. (lab, שדה)
במקרים מסוימים נשיק מדדים חדשים כדי לכסות את התחומים החסרים, אבל במקרים אחרים המדדים הטובים ביותר הם אלה שמותאמים במיוחד לאתר שלכם.
מדדים מותאמים אישית
מדדי הביצועים שצוינו קודם לכן עוזרים להבין באופן כללי את מאפייני הביצועים של רוב האתרים באינטרנט. התכונה הזו טובה גם אם יש להם קבוצה משותפת של מדדים שמאפשרים לאתרים להשוות את הביצועים שלהם לביצועים של המתחרים.
עם זאת, יכול להיות שיהיו מקרים שבהם אתר ספציפי יהיה ייחודי באופן כלשהו שיחייב מדדים נוספים כדי לקבל את התמונה המלאה של רמת הביצועים. לדוגמה, מדד LCP נועד למדוד מתי התוכן הראשי של דף הסתיים, אבל יכולים להיות מקרים שבהם הרכיב הגדול ביותר הוא לא חלק מהתוכן הראשי של הדף, ולכן טבלת ה-LCP לא תהיה רלוונטית.
כדי לטפל במקרים כאלה, קבוצת העבודה בנושא ביצועים באינטרנט קבעה גם ממשקי API סטנדרטיים ברמה נמוכה יותר שיכולים להיות שימושיים להטמעת מדדים מותאמים אישית משלכם:
- User Timing API
- ממשק API ארוך של Tasks
- API של פריימים ארוכים למסגרות אנימציה
- Element Timing API
- API לתזמון ניווט
- API לתזמון משאבים
- תזמון של השרת
במדריך בנושא מדדים מותאמים אישית מוסבר איך להשתמש בממשקי ה-API האלה כדי למדוד מאפייני ביצועים ספציפיים לאתר שלכם.