תשובות לשאלות נפוצות על אפליקציות SPA, על המדדים הבסיסיים של חוויית המשתמש ועל התוכנית של Google לטיפול במגבלות הנוכחיות של המדידה.
מאז ההשקה הראשונה של היוזמה Web Vitals במאי 2020, קיבלנו בצוות Chrome הרבה שאלות ותגובות נהדרות על התוכנית.
אחד הנושאים שקיבלנו עליו הכי הרבה שאלות, וכנראה גם אחד הנושאים הכי קשים להשיב עליהם, הוא איך מודדים את המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals) באפליקציה של דף יחיד (SPA), ואיך הארכיטקטורות של SPA משפיעות על הציונים של המדדים הבסיסיים של חוויית המשתמש.
קשה לענות על השאלות האלה כי הבעיה מורכבת, ולכן נשתדל לענות על השאלות הנפוצות ביותר במאמר הזה, ונציג כמה שיותר פרטים והקשר.
עם זאת, לפני שנכנס לפרטים, חשוב לציין של-Google אין העדפה לגבי הארכיטקטורה או הטכנולוגיה שבהן משתמשים כדי ליצור אתר. אנחנו מאמינים שגם אפליקציות SPA וגם אפליקציות עם כמה דפים (MPA) יכולות לספק למשתמשים חוויה איכותית, והמטרה של יוזמת Web Vitals היא לספק מדדים למדידת החוויה ללא קשר לטכנולוגיה. בשלב הזה, לא ניתן לעשות זאת בכל המקרים (בגלל מגבלות בפלטפורמת האינטרנט), אבל אנחנו פועלים באופן פעיל כדי למלא את הפערים האלה.
שאלות נפוצות
האם מדדי הליבה לבדיקת חוויית המשתמש באתר כוללים מעברים בין מסלולים ב-SPA?
לא. כל אחד מהמדדים של Core Web Vitals נמדד ביחס לניווט הנוכחי ברמת הדף העליונה. אם דף טוען תוכן חדש באופן דינמי ומעדכן את כתובת ה-URL של הדף בסרגל הכתובות, לא תהיה לכך השפעה על אופן המדידה של מדדי Core Web Vitals. ערכי המדדים לא מתאפסים, וכתובת ה-URL שמשויכת לכל מדידת מדד היא כתובת ה-URL שהמשתמש עבר אליה וגרמה לטעינת הדף.
האם המדדים של Core Web Vitals מתייחסים לשינויים במסלולים של SPA כמו לטעינות דפים רגילות?
לצערנו, לא. לפחות לא בשלב הזה.
אין היום דרך סטנדרטית לפתח אפליקציית SPA, וגם בין ספריות ה-SPA והניתוב הפופולריות, חוויית המשתמש יכולה להיות שונה מאוד מאפליקציה לאפליקציה:
- בחלק מה-SPAs, כתובת ה-URL מתעדכנת רק כשמתבצע טעינת תוכן חדש של 'דף מלא', ואילו באתרים אחרים כתובת ה-URL מתעדכנת גם כשיש שינויים קטנים בתוכן או אפילו רק שינויים במצב של ממשק המשתמש.
- חלק מה-SPAs מעדכנים את כתובת ה-URL באמצעות History API, וחלק משתמשים בשינויי גיבוב כדי לתמוך בדפדפנים ישנים יותר (ויש כאלה שלא מעדכנים את כתובת ה-URL בכלל).
- בחלק מה-SPAs התוכן נטען ואז כתובת ה-URL מתעדכנת, ואילו בחלק מהם כתובת ה-URL מתעדכנת לפני טעינת התוכן.
- בחלק מה-SPAs, התוכן נטען בבת אחת, באופן סינכרוני, במשימה יחידה של JavaScript, ואילו בחלק מה-SPAs, התוכן מועבר באופן אסינכרוני במספר משימות (ללא אירוע ברור לסיום המעבר).
- בחלק מה-SPAs התוכן נטען תמיד מהרשת, ואילו בחלק מהם כל התוכן נטען מראש כדי ששינויים במסלול ייטענו באופן מיידי מהזיכרון.
ההבדלים האלה מקשים מאוד להגדיר ולזהות מהו שינוי מסלול ב-SPA, או אפילו את ה-SPA עצמו, בכמות גדולה.
במקרים מסוימים, שינוי מסלול ב-SPA זהה מבחינה לוגית לטעינת דף ב-MPA, ובמקרים כאלה כדאי מאוד להחיל את המדדים הקיימים של Core Web Vitals.
עם זאת, ללא שיטות ניתוח חזקות שיעזרו לזהות בצורה מהימנה שינויים 'אמיתיים' במסלול מכל שינויי כתובות ה-URL האחרים, וגם ללא אותות ברורים שמסמנים את תחילת המעבר ואת סופו, דיווח על מדדי Core Web Vitals במקרים כאלה יטשטש את הנתונים ויגרום להם להיות פחות שימושיים או פחות מייצגים את חוויית המשתמש האמיתית באתר.
האם קשה יותר לאתרים מסוג SPA להשיג תוצאות טובות במדדי הליבה לבדיקת חוויית המשתמש באתר בהשוואה לאתרים מסוג MPA?
אין בארכיטקטורה של אפליקציות SPA דבר מהותי שימנע טעינה מהירה של דף ב-SPA, וגם ניקוד דומה בכל המדדים של Core Web Vitals, כמו בדף דומה ב-MPA.
עם זאת, לאתרים מסוג MPA שעברו אופטימיזציה בצורה נכונה יש יתרונות מסוימים שיעזרו להם לעמוד בערכי הסף של המדדים הבסיסיים של חוויית המשתמש, בניגוד לאתרים מסוג SPA שכרגע לא עומדים בערכי הסף האלה. הסיבה לכך היא שבארכיטקטורה של MPA, כל 'דף' נטען כניווט בדף מלא (במקום אחזור דינמי של תוכן והוספה שלו לדף הקיים). כלומר, סביר יותר שמשתמשים שמבקרים ב-MPA יטענו יותר מדף אחד מהאתר, וכתוצאה מכך אחוז גדול יותר מההפצה של כל הטעינות של דפים ב-MPA יכלול חלק מהמשאבים המשניים או את כולם שנשמרים במטמון.
עם זאת, כדי שהאתר שלכם יבצע טוב יותר במדדי Core Web Vitals מאתר SPA, צריכים להתקיים כמה תנאים:
- באתר החדשות צריכה להתבצע אופטימיזציה של שמירת משאבים משניים במטמון כדי לוודא שטעינה של דפים מאותו מקור אכן מהירה יותר מטעינה של דפים ממקורות שונים ב-75% מהמקרים.
- משתמשים שנכנסים לאתרים של MPA צריכים להיכנס לכמה דפים כדי שהאתר ייהנה מהיתרונות של שמירת הנתונים במטמון, וכתוצאה מכך טעינת הדפים תהיה מהירה יותר.
מאחר שההערכות של מדדי הליבה לבדיקת חוויית המשתמש באתר מתבססות על הרבעון ה-75 של הביקורים בדפים, ככל שיהיו יותר ביקורים בדפים עם ביצועים טובים בקבוצת הנתונים, כך יגדל הסיכוי שהביקור ברבעון ה-75 של ההתפלגות יעמוד בערכי הסף המומלצים.
חשוב לזכור שכשמשווים בין הציונים של מדדי Core Web Vitals, חשוב להביא בחשבון את אופן צבירת הנתונים – כלומר, האם מערך הנתונים בחלוקה כולל את כל הדפים מהאתר או מהמקור, או רק את טעינת הדפים של כתובת URL מסוימת.
כשמצבצים את הציונים של כל הדפים במקור, דפים מהירים מסוימים יכולים לשפר את הרבעון ה-75 של המקור כולו. עם זאת, כשמקבצים לפי דפים ספציפיים, הציונים של דף אחד לא ישפיעו על הציונים של הדף הבא. במילים אחרות, כשמקבצים את הציונים של MPA לפי דף, טעינות מהירות מהמטמון שנצפו בדף התשלום לא ישפרו את הציונים של טעינות ראשוניות איטיות שנצפו בדף הנחיתה של האתר.
אתם יכולים לבדוק את הציון של האתר שלכם בשיטות צבירה שונות באמצעות PageSpeed Insights או API של דוח חוויית המשתמש ב-Chrome, שמציג ציונים גם לכתובות URL של דפים ספציפיים וגם למקור כולו.
ארכיטקטורת ה-SPA יכולה להשפיע על הציונים של מדדי Core Web Vitals גם במדדים שמביאים בחשבון את משך החיים המלא של הדף. מכיוון שמשתמשים שמבקרים באתרי 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 נמוך יותר באחד מהמדדים של Core Web Vitals בגרסה של ה-SPA, סביר להניח שחוויית הטעינה כן הידרדרה אחרי העדכון.
האם כדאי להעביר את האתר שלי מ-SPA ל-MPA כדי לקבל ציון גבוה יותר במדדי Core Web Vitals?
סביר להניח שלא. כדאי לעבור מ-SPA ל-MPA רק אם אתם לא מרוצים מסטאק ה-SPA שלכם ויש לכם סיבה להאמין ש-MPA יספק חוויית משתמש טובה יותר.
עם הזמן, ככל שמדדי הליבה לבדיקת חוויית המשתמש באתר ישתפרו ויכללו יותר מחוויות הגלישה המלאה, צוותים עם אפליקציות SPA שנוצרו בצורה טובה ומספקות חוויית משתמש מעולה צפויים לראות שהציונים שלהם במדדי הליבה לבדיקת חוויית המשתמש באתר ישקפו זאת.
אם דיווחים על ציונים של מדדי Core Web Vitals מתקבלים רק לגבי דפי הנחיתה של אפליקציית SPA, איך אפשר לנפות באגים בבעיות שמתרחשות ב'דפים' אחרי מעבר מסלול?
הכלים של Google שמדווחים על נתוני שדה של מדד Core Web Vitals (כמו Search Console ו-PageSpeed Insights) מקבלים את הנתונים שלהם מהדוח לגבי חוויית המשתמש ב-Chrome (CrUX). בנוסף, מערכת CrUX אוספת נתונים לפי מקור או לפי כתובת ה-URL של הדף (כלומר, כתובת ה-URL של הדף בזמן הטעינה).
מכל הסיבות שצוינו למעלה, לא ניתן לצבור נתונים לפי מסלול SPA בדוח CrUX. עם זאת, כבעלים של אתר שמכיר את הארכיטקטורה שלו, אפשר למדוד את זה בעצמכם. כלי ניתוח נתונים רבים מאפשרים לזהות מתי מתרחש שינוי במסלול של SPA ולעדכן את נתוני המדידה בהתאם.
כשמודדים את מדדי Web Vitals באמצעות כלי ניתוח נתונים, חשוב לוודא שמודדים גם את כתובת ה-URL הנוכחית של המסלול וגם את כתובת ה-URL המקורית של הדף. כך תוכלו לנפות באגים בבעיות ספציפיות שמתרחשות במהלך מחזור החיים של הדף, וגם לצבור נתונים לפי כתובת ה-URL המקורית של הדף כדי להתאים את האופן שבו הכלים של Google מודדים את המדדים ומדווחים עליהם.
מידע נוסף ושיטות מומלצות בנושא הזה זמינים במאמר ניפוי באגים של ביצועים בשטח.
מה Google עושה כדי לוודא שלאתרי MPA אין יתרון לא הוגן בהשוואה לאתרי SPA?
כפי שצוין למעלה, בחלק מהמקרים, אתר MPA שעברו אופטימיזציה בצורה נכונה יכול לדווח על ציונים טובים יותר של מדדי Web Vitals ב-75% העליונים, כי סביר להניח שיהיה בו אחוז גבוה יותר של ביקורים בדפים שנשמרו במטמון. לעומת זאת, שיפורים אמיתיים בחוויית המשתמש באתרי SPA שעברו אופטימיזציה בצורה נכונה לא מתועדים כרגע באף אחד מהמדדים של Core Web Vitals.
אנחנו ב-Google מבינים שהמצב הזה יוצר תמריצים שלא תואמים באופן מלא ליעדים של יוזמת Web Vitals, ואנחנו מחפשים דרכים לתקן את המצב. אנחנו בודקים כרגע שני פתרונות אפשריים, אחד לטווח קצר ואחד לטווח ארוך:
- להעריך בנפרד ביקורים בדפים ממקורות שונים ובדפים מאותו מקור.
- תכנון ממשקי API חדשים שמאפשרים מדידה טובה יותר של SPA.
הערכה נפרדת של כניסות לדפים ממקורות שונים ומאותו מקור
נכון לעכשיו, מדדי Core Web Vitals מרכזים את כל הביקורים בדפים בקטגוריה אחת – הם לא מבדילים בין ביקורים חדשים לביקורים חוזרים, בין דפי נחיתה לדפי תשלום או בין כל סוג אחר של צבירת נתונים שבו מצב המטמון יכול להשפיע על הביצועים.
אחת מהדרכים לתקן את ההבדלים בביצועים בין אתר SPA לבין אתר MPA היא להחיל משקל שונה על סוגים שונים של ביקורים, ואולי אפילו עם המלצות שונות לגמרי לסף.
אנחנו בהחלט רוצים לתגמל הטמעות יעילות של מטמון, אבל אנחנו לא רוצים שניווט מהיר בתוך האתר יוכל לכסות על טעינה איטית של דפי נחיתה. אנחנו גם לא רוצים לתת תמריץ לאתרים לפצל דפים ארוכים לאוסף של דפים קצרים רק כדי לשפר את הציונים של המדדים.
כשאנחנו בודקים בנפרד ביקורים בדפים ממקורות שונים ובאותו מקור, אנחנו יכולים לוודא ששני סוגי החוויות חשובים, בלי לאפשר לפופולריות היחסית של סוג אחד באתר נתון להטות את ההפצה של מדד מסוים.
עיצוב ממשקי API חדשים שמאפשרים מדידה טובה יותר של SPA
פתרון נוסף שאנחנו עובדים עליו (במקביל לפתרון שלמעלה) הוא App History API חדש, שיעזור לסטנדרטיזציה של דפוסי ה-SPA הקיימים ויקל על המדידה וההבנה של השימוש ב-SPA בקנה מידה נרחב.
ב-App History API נוסף אירוע חדש, navigate, עם שתי תכונות עיקריות שספציפיות למדידת SPA:
- הדגל
userInitiated, שיוגדר כ-true רק אם הניווט הופעל באמצעות קליק על קישור, שליחת טופס או ממשק המשתמש של הדפדפן כדי לחזור אחורה או להתקדם קדימה. - שיטת
transitionWhile()שמקבלת הבטחה שמאפשרת למפתח לסמן מתי העבודה שהוא יזם לביצוע הניווט הושלמה.
אפשר להשתמש בדגל userInitiated כדי לקבוע נקודת התחלה סמנטית למעבר מסלול ב-SPA, שמציינת כוונה ברורה של המשתמש. פתרון ההבטחה transitionWhile() יכול לעזור לדפדפן לשייך את ה-paints למעבר הספציפי במסלול, כך שיהיה אפשר לקבוע את ה-LCP הגדול ביותר שקשור למעבר הזה.
בהמשך לרעיון שהוצג בקטע הקודם, יכול להיות שאפשר גם לצבור את זמן המעבר של מסלול SPA באותו קטגוריה כמו טעינות של דפים מאותו מקור ב-MPA. זה מרגש כי כך תוכלו להשוות בין הביצועים לפני ואחרי ההעברה של אתר מ-MPA ל-SPA.
כמובן, נצטרך לבצע עוד מחקרים כדי לדעת אם נוכל להגיע למסקנות האלה במדויק. אם יש לכם הצעות או משוב לגבי ההצעות האלה, תוכלו לשלוח אותן לכתובת web-vitals-feedback@googlegroups.com.
מסקנות סופיות
Google מחויבת מאוד לשיפור המדדים של Web Vitals, ולוודא שהם מודדים ומעודדים חוויית משתמש באיכות גבוהה שחשובה למשתמשים. עם זאת, אנחנו מזהים שיש פערים במדידות כיום. בשלב זה המדדים לא מכסים את כל ההיבטים של חוויית המשתמש, אבל אנחנו פועלים באופן פעיל כדי למלא את הפערים האלה.
למרות המגבלות הקיימות, אנחנו מאמינים שהתחומים שהמדדים הקיימים מתעדים הם קריטיים לבריאות ולצלחת של האינטרנט, וככל שהאתרים (ללא קשר לארכיטקטורה) לא עומדים בערכים המומלצים של הספים, אנחנו מאמינים שיש מקום לשיפור.
אני מקווה שהפוסט הזה עזר לך להבין את הנושא המורכב והעדין הזה. כמו תמיד, אם יש לכם משוב על המדדים הנוכחיים או העתידיים של Web Vitals, תוכלו לשלוח אותו לכתובת האימייל web-vitals-feedback@googlegroups.com.