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