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