תשובות לשאלות נפוצות בנושא SPA, מדדי ליבה לבדיקת חוויית המשתמש באתר, והתוכנית של Google להתמודד עם מגבלות המדידה הנוכחיות.
מאז שהשקנו את היוזמה Web Vitals במאי 2020, קיבלנו הרבה שאלות ומשוב על התוכנית.
אולי הנושא שקיבלנו הכי הרבה שאלות לגביו, וסביר להניח שהשאלה הכי קשה לענות עליו, הוא איך למדוד את מדדי הליבה לבדיקת חוויית המשתמש באתר באפליקציה בדף יחיד (SPA), וגם איך הארכיטקטורות של SPA משפיעות על הציונים בדוח המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals).
קשה לענות על שאלות אלה מפני שהבעיה מגוונת מאוד, ולכן בפוסט הזה נעשה כמיטב יכולתנו להשיב על השאלות הנפוצות ביותר, ולספק כמה שיותר פרטים והקשר.
עם זאת, לפני שנכנסים לפרטים, חשוב לציין של-Google אין העדפה לגבי הארכיטקטורה או הטכנולוגיה שישמשו לבניית האתר. אנחנו מאמינים ש-SPA ואפליקציות מרובות דפים (MPA) יכולות לספק למשתמשים חוויות באיכות גבוהה, והכוונה שלנו במיזם Web Vitals היא לספק מדדים שמודדים את החוויה ללא תלות בטכנולוגיה. כיום זה לא אפשרי בכל מקרה (בגלל מגבלות בפלטפורמת האינטרנט), אבל אנחנו פועלים לצמצום הפערים האלה.
שאלות נפוצות
האם מדדי הליבה לבדיקת חוויית המשתמש באתר כוללים מעברים בין נתיבים של SPA?
לא. כל אחד מהמדדים של מדדי הליבה לבדיקת חוויית המשתמש באתר נמדד ביחס לניווט הנוכחי ברמה העליונה בדף. אם דף טוען באופן דינמי תוכן חדש ומעדכן את כתובת ה-URL של הדף בסרגל הכתובות, לא תהיה לכך השפעה על אופן המדידה של מדדי הליבה לבדיקת חוויית המשתמש באתר. לא מתבצע איפוס של ערכי המדדים, וכתובת ה-URL שמשויכת לכל מדידה של מדד היא כתובת ה-URL שהמשתמש עבר אליה שגרמה לטעינת הדף.
האם המדדים של מדדי הליבה לבדיקת חוויית המשתמש באתר יכולים להתייחס לשינויים במסלולים של SPA כמו לטעינות דפים רגילות?
לצערי לא. עדיין לא.
כיום אין דרך סטנדרטית לבנות SPA, וגם בין ספריות ה-SPA והניתובים הפופולריות, חוויית המשתמש יכולה להיות שונה לגמרי מאפליקציה לאפליקציה:
- יש אפליקציות SPA שמעדכנות את כתובת ה-URL רק כשטוענים תוכן חדש מסוג 'דף מלא', ואילו אתרים אחרים מעדכנים את כתובת ה-URL כדי לבצע שינויים קטנים בתוכן, או אפילו רק לשינויים במצב של ממשק המשתמש.
- יש אפליקציות SPA שמעדכנות את כתובת ה-URL באמצעות History API, ואילו אחרות משתמשות בשינויי גיבוב כדי לתמוך בדפדפנים ישנים יותר (ואחרות לא מעדכנות את כתובת ה-URL בכלל).
- יש אפליקציות SPA שטוענים תוכן ולאחר מכן מעדכנים את כתובת ה-URL. יש כאלה שמעדכנים את כתובת ה-URL לפני טעינת התוכן.
- יש אפליקציות SPA שטוענים את התוכן בבת אחת באופן סינכרוני במשימת JavaScript אחת, ואילו אחרות מעבירות תוכן באופן אסינכרוני בין משימות מרובות (ללא אירוע ברור לסיום המעבר).
- אפליקציות SPA מסוימות תמיד טוענים תוכן מהרשת, ויש כאלה שטוענים מראש את כל התוכן מראש כדי ששינויי המסלול ייטענו באופן מיידי מהזיכרון.
ההבדלים האלה מקשים על הגדרה וזיהוי של שינוי נתיב SPA, או אפילו על ה-SPA עצמו, בקנה מידה נרחב.
במקרים מסוימים, שינוי מסלול של SPA זהה מבחינה לוגית לטעינת דף באמצעות MPA, ובמקרים כאלה כדאי להשתמש במדדים הקיימים של מדדי הליבה לבדיקת חוויית המשתמש באתר.
עם זאת, ללא היוריסטיקה מוצקה לזיהוי אמין של שינויים "אמיתיים" במסלול מכל שאר השינויים בכתובות ה-URL, כמו גם אותות ברורים שמסמנים את ההתחלה והסוף של מעברים כאלה – במקרים כאלה דיווח על מדדים של מדדי ליבה לבדיקת חוויית המשתמש באתר יסתירו את הנתונים ויהפכו אותם לפחות שימושיים או לא מייצגים את חוויית המשתמש האמיתית באתר.
האם קשה יותר לאפליקציות SPA להשיג ביצועים טובים במדדי ליבה לבדיקת חוויית המשתמש באתר מאשר ל-MPA?
אין שום דבר מובנה בארכיטקטורת ה-SPA שיכול למנוע מדף ב-SPA להיטען באותה מהירות – וכך לתת ניקוד זהה לכל המדדים של מדדי הליבה לבדיקת חוויית המשתמש באתר – כמו דף דומה ב-MPA.
עם זאת, ל-MPA שהם עברו אופטימיזציה נכונה יש כמה יתרונות בעמידה בדרישות הסף של מדדי ליבה לבדיקת חוויית המשתמש באתר, שלא ניתן לעשות זאת בשלב זה. הסיבה לכך היא שבארכיטקטורת ה-MPA, כל 'דף' נטען כניווט של דף מלא (ולא באחזור דינמי של תוכן והוספתו לדף הקיים). כלומר, משתמשים שמבקרים ב-MPA הם בסבירות גבוהה יותר יטענו יותר מדף אחד מהאתר, וכתוצאה מכך אחוז גדול יותר של ההתפלגות של כל טעינות המטמון של ה-MPA הוא חלק ממשאבי המשנה או כולם.
עם זאת, כדי ש-MPA יניב ביצועים טובים יותר במדדים של מדדי ליבה לבדיקת חוויית המשתמש באתר, בהשוואה ל-SPA, נדרשים כמה דברים כדי להתקיים:
- ל-MPA יש צורך באופטימיזציה של שמירה במטמון של משאבי משנה, כדי להבטיח שהטעינה של דף מאותו מקור תהיה מהירה יותר מטעינה של דפים ממקורות שונים באחוזון ה-75.
- משתמשים שמבקרים ב-MPA צריכים לבקר במספר דפים כדי שהאתר יקבל את יתרונות השמירה במטמון שמובילים לטעינה מהירה יותר של הדפים.
מכיוון שההערכות של מדדי הליבה לבדיקת חוויית המשתמש באתר מביאות בחשבון את האחוזון ה-75 של הביקורים בדפים, כמות גדולה יותר של ביקורים בדפים עם ביצועים טובים תגביר את הסבירות שהביקור באחוזון ה-75 של ההתפלגות יהיה בתוך ערכי הסף המומלצים.
שימו לב שכשמשווים את הציונים במדדי הליבה לבדיקת חוויית המשתמש באתר, חשוב לקחת בחשבון את אופן הצבירה של הנתונים. כלומר, האם מערך הנתונים בהתפלגות כולל את כל הדפים מהאתר או המקור שלכם, או רק טעינות של דף מסוים לכתובת URL מסוימת של דף.
בצבירה של הציונים של כל הדפים במקור, דפים מהירים נפרדים יכולים לשפר את האחוזון ה-75 של המקור כולו. עם זאת, בצבירה לפי דפים נפרדים, הציונים של דף אחד לא ישפיעו על הציון של הדף הבא. במילים אחרות, בצבירה של הציונים של MPA לפי דף, טעינות מהירות במטמון שמוצג בדף התשלום לא ישפרו את הציון של טעינות ראשוניות איטיות שמופיעות בדף הנחיתה של האתר.
אפשר לבדוק את הציון של האתר בשיטות צבירה שונות באמצעות PageSpeed Insights או API של דוח חוויית המשתמש ב-Chrome, שמדווח על ציונים גם לכתובות URL נפרדות של דפים וגם למקור כולו.
דרך נוספת שארכיטקטורת SPA יכולה להשפיע על הציונים בדוח מדדי הליבה לבדיקת חוויית המשתמש באתר היא מדדים שמביאים בחשבון את משך החיים המלא של הדף. מכיוון שמשתמשים שמבקרים ב-SPA נוטים להישאר באותו "דף" לכל הסשן, המדדים שנצברים לאורך זמן עלולים להיות קשים יותר לשימוש ב-SPA מאשר ב-MPA.
באפריל 2021 הודענו על שינויים במדד CLS שטיפלו באופן חלקי בבעיה הזו. בעבר, נתוני CLS היו מצטברים לאורך כל משך החיים של הדף, ועכשיו הם מצטברים רק בחלון זמן מסוים – ובעצם הרצף הגרוע ביותר של שינויי פריסה בדף נתון.
עם זאת, גם עם הגדרת ה-CLS החדשה, SPA עדיין בחסרונות כי ערך ה-CLS לא "מתאפס" אחרי מעברים בין נתיבים כמו במקרה של טעינות דף מלא ב-MPA. דבר זה עלול גם לגרום לבלבול, כי שינויים בפריסה שמתרחשים לאחר מעבר במסלול ישויכו לכתובת ה-URL של הדף בזמן הטעינה, ולא לכתובת ה-URL בסרגל הכתובות במועד המעבר (פרטים נוספים בהמשך).
אם הארכיטקטורות של SPA משפרות את חוויית המשתמש, האם השיפור הזה לא אמור לבוא לידי ביטוי במדדים?
כן. כפי שצוין קודם, קשה למדוד עד כמה החוויה השתפרה בקנה מידה נרחב, בגלל כל הדרכים השונות שבהן SPA מיושמים באינטרנט.
האמת היא שתעשיית ביצועי האינטרנט (כולל Google) בעבר לא השקיעה כמעט זמן ומאמץ בפיתוח מדדים ממוקדי משתמש לביצועים של דף לאחר טעינה, כמו גם לטעינת הדף עצמה. זה לא משום שהביצועים לאחר הטעינה לא חשובים, אלא שחוויית המשתמש והאינטראקציות לאחר הטעינה הן הרבה יותר מגוונות ופחות מוגדרות, ולכן קשה לתכנן עבורן מדדים.
אבל גם אם היו לנו מדדים מוגדרים היטב אחרי הטעינה כדי למדוד את ביצועי ה-SPA, אנחנו לא רוצים להתעלם מחוויית הטעינה רק כי החוויה של טעינת הפוסט השתפרה.
אחת המטרות של מיזם Web Vitals היא לקדם ולתמרץ חוויות משתמש טובות בכמה שיותר היבטים של טעינת דף אינטרנט והשימוש בו. אנחנו לא רוצים לעודד תרחישים שבהם חוויות שליליות מוצדקות אם יש מספיק חוויות טובות כדי לפצות עליהן. המשתמשים רוצים שדפים ייטענו במהירות וגם עוברים במהירות לתוכן חדש. לכן, ניסינו לעצב מדדים שמעדיפים להשתמש בחוויות כאלה.
כך שלמרות שגרסת MPA של אתר עשויה להניב ביצועים טובים יותר במדדי הליבה לבדיקת חוויית המשתמש באתר באחוזון ה-75, בהשוואה לגרסת SPA של אותו אתר בדיוק, גרסת ה-SPA עדיין אמורה לעמוד בסף ה"טוב". גם אם גרסת ה-SPA לא עומדת בסף 'טוב' אצל רוב המשתמשים, סביר להניח שחוויית הטעינה הראשונית עדיין לא נחשבת כטובה – גם אם חוויית הניווט בדף לאחר מכן היא מצוינת.
בעתיד אנחנו מתכננים לפתח מדדים שיעודדו חוויה מעולה לאחר הטעינה, ואנחנו מאמינים שזו הדרך הטובה ביותר לתמרץ שירותי SPA באיכות גבוהה באופן שלא יפגע בחוויית הטעינה הראשונית. כבר הצגנו מדד חדש בשם Interaction to Next Paint (INP) שמודד את זמן האחזור של האינטראקציה לכל אורך מחזור החיים של הדף, ואנחנו עובדים בקפדנות על מדדים אחרים לאחר הטעינה, כולל מדדים שמודדים מעברים בין נתיבים של SPA (ראו בהמשך).
העברנו את האתר מ-MPA ל-SPA, והציונים שלנו ירדו. כך זה אמור לעבוד?
לשאלה הזו יש כמה תשובות אפשריות. יכולות להיות כמה סיבות לשינויים בציונים אחרי העברה משמעותית של ארכיטקטורה, אבל ירידה במספר הטעינות של המטמון החמימים עשויה להוביל לחלק מהשינוי.
דרך מהירה לבדוק זאת היא לבדוק גם גרסת MPA וגם גרסת SPA של אחד מדפי הנחיתה באמצעות Lighthouse. אם הציון של Lighthouse נמוך יותר באחד מהמדדים של מדדי הליבה לבדיקת חוויית המשתמש באתר של גרסת ה-SPA, סביר להניח שחוויית הטעינה אכן הצטמצמה אחרי העדכון.
האם כדאי להחליף את האתר שלי מ-SPA ל-MPA כדי לקבל ציון טוב יותר במדדי הליבה לבדיקת חוויית המשתמש באתר?
סביר להניח שלא. כדאי לעבור מ-SPA ל-MPA רק אם אתם לא מרוצים מסטאק ה-SPA ויש לכם סיבה להאמין ש-MPA יספק חוויית משתמש טובה יותר.
עם הזמן, ככל שהמדדים של מדדי הליבה לבדיקת חוויית המשתמש באתר ימשיכו להשתפר, וצוותים עם SPA בנויים היטב שמספקים חוויית משתמש מעולה, הם אמורים לראות את הציון הזה במדדי הליבה לבדיקת חוויית המשתמש באתר.
אם הציונים במדדי הליבה לבדיקת חוויית המשתמש באתר מדווחים רק לגבי דפי נחיתה של שירות SPA, איך אפשר לנפות באגים בבעיות שמתרחשות ב"דפים" אחרי מעבר למסלול?
הכלים של Google שמדווחים על נתוני שדות לגבי המדד 'מדדי ליבה לבדיקת חוויית המשתמש באתר' (כמו מסוף Search ו-PageSpeed Insights) מקבלים את הנתונים מהדוח 'חוויית המשתמש ב-Chrome' (CrUX). בנוסף, ב-CrUX נתונים נצברים נתונים לפי מקור או לפי כתובת ה-URL של הדף (כלומר, כתובת ה-URL של הדף בזמן הטעינה).
בגלל כל הסיבות שמפורטות למעלה, ל-CrUX אין אפשרות לצבור נתונים לפי נתיב SPA. עם זאת, כבעלי אתרים שמכירים את הארכיטקטורה שלכם, אתם יכולים למדוד זאת בעצמכם, וכלים רבים לניתוח נתונים מאפשרים לכם לאותת על שינוי במסלול של ה-SPA ולעדכן את נתוני המדידה בהתאם.
כשמודדים מדדים של Web Vitals באמצעות כלי ניתוח נתונים, חשוב לוודא שאתם מודדים גם את כתובת ה-URL הנוכחית של הנתיב וגם את כתובת ה-URL המקורית של הדף. כך תוכלו לנפות באגים בבעיות ספציפיות שמתרחשות במהלך מחזור החיים של הדף וגם לבצע צבירה לפי כתובת ה-URL המקורית של הדף, כדי להתאים את האופן שבו הכלים של Google מודדים את המדדים ומדווחים עליהם.
לפרטים נוספים ושיטות מומלצות בנושא הזה, קראו את המאמר ניפוי באגים של ביצועים בשדה.
מה Google עושה כדי להבטיח של-MPA אין יתרון לא הוגן בהשוואה לספקי SPA?
כפי שצוין למעלה, סביר להניח ש-MPA שעבר אופטימיזציה נכונה יכול לדווח על ציונים טובים יותר במדדי Web Vitals באחוזון ה-75, כי סביר להניח שיהיו לו אחוז גבוה יותר של ביקורים במטמון בדף. לעומת זאת, נכון לעכשיו לא מתבצע תיעוד של שיפורים אמיתיים בחוויית המשתמש, באפליקציות עם אופטימיזציה מתאימה בצורה נכונה, באמצעות אף אחד מהמדדים של מדדי הליבה לבדיקת חוויית המשתמש באתר.
אנחנו ב-Google מבינים שהדבר יוצר תמריצים שלא תואמים באופן מלא ליעדים של היוזמה Web Vitals, ואנחנו מחפשים באופן פעיל דרכים לפתור את הבעיה. בשלב זה אנחנו בוחנים שני פתרונות פוטנציאליים, אחד לטווח קצר ואחד ארוך יותר:
- הערכה של ביקורים בדפים ממקורות שונים וביקורים בדפים מאותו מקור בנפרד.
- עיצוב ממשקי API חדשים שמאפשרים מדידת SPA טובה יותר.
הערכה של ביקורים בדפים ממקורות שונים וביקורים בדפים מאותו מקור בנפרד
כיום, המדדים של מדדי הליבה לבדיקת חוויית המשתמש באתר צוברים את כל הביקורים בדפים לקטגוריה אחת – הם לא מבחינים בין ביקורים חדשים לעומת ביקורים חוזרים או דפי נחיתה לבין דפי תשלום או כל סוג אחר של צבירת נתונים שבו מצב המטמון יכול להשפיע על הביצועים.
אחת הדרכים לנרמל את ההבדלים בין הביצועים של SPA ושל MPA היא להחיל שקלולים שונים על סוגים שונים של ביקורים, ואולי אפילו עם המלצות סף שונות לחלוטין.
אנחנו בהחלט רוצים לתגמל הטמעות אפקטיביות של מטמון, אבל אנחנו לא רוצים שניווטים מהירים בתוך האתר יוכלו להתמודד עם טעינות איטיות של דפי נחיתה. אנחנו גם לא רוצים לתמרץ אתרים לפצל דפים ארוכים לאוסף של דפים קצרים יותר, רק כדי לשפר את ציוני המדדים.
על ידי הערכה נפרדת של ביקורים בדפים ממקורות שונים וממקורות זהים ניתן להבטיח ששני סוגי החוויות חשובים, בלי לאפשר לפופולריות היחסית של סוג אחד באתר נתון להטות את ההתפלגות של מדד מסוים.
עיצוב ממשקי API חדשים שמאפשרים מדידת SPA טובה יותר
פתרון נוסף שאנחנו עובדים עליו באופן פעיל (במקביל לגרסה הקודמת) הוא App History API חדש, שבעזרתו אפשר לקבוע תקן לדפוסי SPA קיימים, וכדי שיהיה קל יותר למדוד ולהבין את השימוש ב-SPA בקנה מידה נרחב.
App History API כולל אירוע navigate חדש, שכולל שתי תכונות עיקריות שספציפיות למדידת SPA:
- דגל
userInitiated, שיוגדר כ-true רק אם הניווט התחיל בלחיצה על קישור, שליחת טופס או דרך ממשק המשתמש למעבר אחורה או קדימה בדפדפן. - שיטה
transitionWhile(), שכוללת הבטחה שמאפשרת למפתח לסמן אם העבודה שהוא התחיל לבצע את הניווט הושלמה.
הדגל userInitiated מאפשר לקבוע נקודת התחלה סמנטית למעבר מסלול SPA, כדי לציין כוונה ברורה למשתמשים. פתרון ההבטחה transitionWhile() יכול לעזור לדפדפן להתאים בין צבעים לבין המעבר הספציפי במסלול, וכך אולי לקבוע מהו ה-LCP גדול ביותר של תוכן שקשור למעבר הזה.
בהמשך לרעיון שהוצג בקטע הקודם, יכול להיות שאפשר אפילו לצבור את זמן המעבר של נתיב ה-SPA לאותה קטגוריה בזמן שדף המקור הזה נטען ב-MPA. זה מלהיב כי כך אתר שעובר מ-MPA ל-SPA יכול להשוות בפועל את הביצועים לפני ואחרי.
כמובן, יש צורך במחקר נוסף לפני שנוכל לדעת אם אנחנו יכולים להגיע להחלטות האלה בצורה מדויקת. אם יש לכם הצעות או משוב לגבי ההצעות האלה, תוכלו לשלוח אימייל לכתובת web-vitals-feedback@googlegroups.com.
מחשבות סופיות
Google מחויבת מאוד לשיפור המדדים של מדדי חוויית המשתמש באתר, וכדי להבטיח שהם ימדדו את חוויות השימוש באיכות גבוהה שחשובות למשתמשים ויעודדו אותם. עם זאת, ברור לנו שכבר קיימים פערים במדידה. המדדים לא מכסים כרגע את כל ההיבטים של חוויית המשתמש, אבל אנחנו פועלים כדי לסגור את הפערים האלה.
למרות המגבלות הנוכחיות, אנחנו מאמינים שהתחומים שהמדדים הקיימים מתעדים הם קריטיים לתקינות ולהצלחה של האינטרנט, ובמידה שאתרים (ללא קשר לארכיטקטורה) לא עומדים בדרישות הסף המומלצות, אנחנו מאמינים שיש מקום לשיפור.
אני מקווה שהפוסט הזה עזר לכם להבהיר את הנושא המורכב והניואנסי הזה. כמו תמיד, אם יש לכם משוב על מדדים קיימים או עתידיים של Web Vitals, אתם יכולים לשלוח אימייל לכתובת web-vitals-feedback@googlegroups.com.