כדי להעריך ביצועים ביישום עמוד יחיד, מודדים את טעינת המסמך הראשונית, את מעברי הנתיבים בהמשך ואת האינטראקציות שביניהם. אלה חוויות קשורות בעלות גבולות מדידה שונים. תגובה מהירה ללחיצה אינה מוכיחה שתוכן היעד נטען, וציון מוצלח בעמוד הכניסה אינו מתאר כל נתיב שהמבקר יפתח אחר כך.
מגדירים מה הדוח מודד בפועל
ניווט מלא יוצר מסמך חדש. מעבר נתיב טיפוסי ביישום SPA מעדכן את המסמך הקיים. שינוי הכתובת באמצעות History API אינו מגדיר כשלעצמו מדידת ביצועים חדשה בכל דפדפן ובכל מערכת דיווח.
מבדילים בין איסוף לפי מסמך לבין איסוף שתומך במפורש בניווט רך. התמיכה משתנה בין דפדפנים, רכיבי איסוף וסוגי דוחות. כאשר יש מדידות ניווט רך, שומרים את הסיווג שלהן ולא מערבבים אותן ללא הסבר עם תוצאות של טעינת מסמך רגילה. טיימר ייעודי למעבר נתיב הוא אות שימושי נוסף, אך הוא אינו הופך אוטומטית למדד LCP, למדד INP או למדד CLS.
הנחיות Google למדידת יישומי SPA מסבירות מדוע מודל הניווט חשוב. לפני השוואת תוצאות קוראים את הגדרת מערך הנתונים שהכלי מספק. אם חסרה מדידה של נתיב, חסר כיסוי מדידה; אין פירוש הדבר שהנתיב היה מוכן מיד.
מאבחנים בנפרד את נתיב הכניסה
פותחים יעד חשוב ישירות בסשן חדש. בודקים איך הדפדפן מגלה את התוכן המרכזי, מוריד את המשאבים ומריץ את הקוד הדרוש להצגה. רינדור בשרת או יצירת תוכן מראש יכולים להקדים את גילוי התוכן. עם זאת, תהליך ההידרציה עדיין יכול להוסיף עבודה הדרושה לאינטראקטיביות.
מפרידים המתנה לרשת מהרצת קוד ומרינדור. נתיב יכול להוריד מעט מידע ועדיין להיתקע בזמן הרצת JavaScript. מנגד, צמצום הרצת סקריפטים לא יפתור בקשת API שמתחילה רק אחרי תלות מיותרת בעבודות אחרות. המדריך לשיפור LCP מסייע לחקור את הדרך להצגת התוכן במקום להניח שסביבת הפיתוח לבדה קובעת את התוצאה.
מגדירים מתי הנתיב שימושי
במסך מוצר אפשר להגדיר מוכנות כמצב שבו פרטי הזיהוי, המחיר הנוכחי והפעולה העיקרית זמינים. במסך כתבה אפשר להתייחס להופעת הכותרת והטקסט המרכזי במסמך. בוחרים הגדרה שקשורה למשימת המבקר ומיישמים אותה בעקביות. היעלמות של חיווי טעינה אינה מספיקה אם הפעולה הבאה עדיין חסומה.
רושמים את תחילת המדידה באירוע הנתב שמייצג את כוונת המשתמש לנווט. מסיימים רק כשהתנאי שנבחר מתקיים. מבחינים בין ביטולים, כשלים והפניות לבין מעברים מוצלחים. אם ניווט מאוחר מחליף ניווט קודם, אסור לייחס את הסיום המאוחר של הפעולה הקודמת לנתיב החדש.
מוסיפים אות תזמון של היישום
הדוגמה הבאה יוצרת טיימר למעבר נתיב שהושלם. קוראים לפונקציה beginRouteTiming() בתחילת הניווט, ואז מפעילים את הפונקציה שהוחזרה כאשר תנאי המוכנות מתקיים. משתמשים בשם נתיב מנורמל, כגון article, ולא בכתובת שמכילה מידע אישי.
function beginRouteTiming(routeName) {
const id = crypto.randomUUID();
const start = `route:${id}:start`;
const end = `route:${id}:end`;
const name = `route:${id}:ready`;
performance.mark(start);
return function finishRouteTiming() {
performance.mark(end);
const result = performance.measure(name, {
start,
end,
detail: { route: routeName }
});
performance.clearMarks(start);
performance.clearMarks(end);
performance.clearMeasures(name);
return result.duration;
};
}משך הזמן המוחזר נמדד באלפיות שנייה. פונקציית העזר מודדת מרווח בין אותות של היישום. היא אינה מוודאת שפיקסלים הוצגו בפועל או שנחצה סף איכות של Core Web Vitals. מחברים אותה לנתב ולמחזור הרינדור שבשימוש, ומוסיפים ניקוי בעת ביטול ודיווח שגיאות. השמות הייחודיים מפרידים בין מדידות מוצלחות שמתקיימות במקביל, והניקוי מונע את הישארות הרשומות שלהן בציר הזמן.
אישור עדכון של סביבת הפיתוח או קריאת requestAnimationFrame אינם מוכיחים שכל התוכן השימושי כבר הופיע. משווים את אותות התזמון להקלטת ביצועים ולהתנהגות הנראית לעין לפני שקובעים מה המדד מייצג.
מפרידים תגובתיות מטעינת היעד
INP עוסק בתגובה לאינטראקציות משתמש עד לציור הבא של המסך. לחיצה יכולה להציג מיד מצב טעינה בזמן שהיעד עדיין אינו זמין. כלומר, האינטראקציה יכולה להיות תגובתית והנתיב עדיין אטי. שומרים את שתי התצפיות במקום לכנות את כל משך המעבר INP.
בודקים טיפול יקר באירועים, רינדור סינכרוני וחישובי פריסה חוזרים. דוחים עבודה שאינה תורמת לתגובה המיידית ומציגים חיווי התקדמות נאמן למצב בפועל. אם התהליכון הראשי עמוס אחרי הלחיצה, בודקים את ההקלטה לפני שמשנים הגדרות רשת. המדריך לשיפור INP מסייע למקד את האבחון.
טוענים את הנדרש בלי לערער את יציבות המסך
פיצול קוד לפי נתיבים יכול לצמצם עבודה מיותרת בכניסה, אך שרשרת נוספת של בקשות תלויות עלולה לעכב את היעד. מתחילים במקביל עבודות עצמאיות של נתונים וקוד כאשר המבנה מאפשר זאת. מבצעים טעינה מקדימה באופן בררני, משום שעבודה ספקולטיבית עלולה להתחרות בנתיב שהמבקר משתמש בו כעת.
שומרים מקום לתמונות ולאזורים שנטענים באופן אסינכרוני. שומרים על ניווט יציב ונמנעים מהוספת תוכן מאוחר מעל מה שהמבקר קורא. מעבר יכול לכלול תזוזה מפריעה גם אם תזוזה מסוימת אינה נכללת במדד CLS בגלל קלט משתמש שהתרחש לאחרונה. לכן בוחנים את החוויה הנראית לעין לצד המדד.
משווים מסעות שימוש ומערכי נתונים תואמים
בודקים כניסה ישירה, ניווט פנימי, ביקור חוזר באותו נתיב, חזרה ואפשרות קדימה ומעבר כאשר הנתונים מגיעים באטיות. כוללים בקשה שנכשלה ומעבר שננטש. בהשוואת שינויים שומרים על תנאי מכשיר ומצב מטמון דומים. אחרת, נתיב שכבר הוכן עלול להיראות כהוכחה לשיפור שנובע למעשה רק מעבודה קודמת.
גבולות התוצאה הטובה הם LCP של 2.5 s לכל היותר, INP של 200 ms לכל היותר וכן CLS של 0.1 לכל היותר, באחוזון 75 ובהפרדה בין נייד למחשב. הם חלים על המדידות המוגדרות של Core Web Vitals, לא על טיימרים שרירותיים של היישום. בודקים אם הדוח מתייחס לכתובת, למקור האתר, לטעינות מסמך או לניווטים רכים שזוהו.
משייכים את הקשר הנתיב לאינטראקציה או למעבר שיצרו אותו, ולא לכתובת שבמקרה פעילה בעת שליחת הטלמטריה. בוחנים את ההבדל בין נתוני שטח לנתוני מעבדה לפני שמסיקים מהקלטה מקומית מוצלחת על כלל המבקרים. דוח שימושי מאפשר לזהות מסעות שימוש אטיים ולבדוק אם התיקון הועיל.
