תשובות לשאלות נפוצות על דפי SPA, על Core Web Vitals ועל האופן שבו Core Web Vitals מתייחסים לדפים האלה.
פורסם: 14 בספטמבר 2021, עדכון אחרון: 11 באוגוסט 2026
מאז שהשקנו את יוזמת Web Vitals במאי 2020, קיבלנו בצוות Chrome הרבה שאלות ומשוב מעולים לגבי התוכנית.
יכול להיות שהנושא שקיבלנו עליו הכי הרבה שאלות, וגם הכי קשה לענות עליו, הוא איך למדוד את מדדי ה-Core Web Vitals באפליקציית דף יחיד (SPA), ואיך ארכיטקטורות של SPA משפיעות על הציונים של מדדי ה-Core Web Vitals.
קשה לענות על השאלות האלה כי הבעיה מורכבת, ולכן בפוסט הזה ננסה לענות על השאלות הנפוצות ביותר, ונספק כמה שיותר פרטים והקשר.
לפני שנעבור לפרטים, חשוב לציין של-Google אין העדפה לגבי הארכיטקטורה או הטכנולוגיה שמשמשות לבניית אתר. אנחנו מאמינים שאפליקציות SPA ואפליקציות מרובות דפים (MPA) יכולות לספק למשתמשים חוויה איכותית, והמטרה שלנו ביוזמת Web Vitals היא לספק מדדים למדידת החוויה בלי קשר לטכנולוגיה.
שאלות נפוצות
ריכזנו כאן כמה מהשאלות הנפוצות ביותר בנושא. נשמח לקבל משוב כדי להוסיף שאלות ותשובות ל-FAQ הזה. אפשר לעשות זאת בקבוצת המשוב שלנו או על ידי דיווח על בעיה.
האם המדדים של Core Web Vitals כוללים מעברים בין נתיבים ב-SPA?
כשמדדי הנתונים הבסיסיים על החוויה באינטרנט הוצגו לראשונה, כל אחד מהם נמדד ביחס לניווט הנוכחי בדף ברמה העליונה. אם דף טען באופן דינמי תוכן חדש ועדכן את כתובת ה-URL של הדף בסרגל הכתובות, לא תהיה לכך השפעה על אופן המדידה של מדדי Core Web Vitals.
ערכי המדדים לא אותחלו, וכתובת ה-URL שמשויכת לכל מדידה של מדד היא כתובת ה-URL שהמשתמש עבר אליה והפעיל את טעינת הדף.
ב-Chrome 151 הוספנו ממשקי API חדשים שמאפשרים למדוד את Core Web Vitals במהלך מעברים בין נתיבים באפליקציות SPA. בזמן כתיבת המאמר הזה (אוגוסט 2026), רק מתחילים להשתמש בממשקי ה-API האלה בספריות מדידה כמו web-vitals, בפתרונות RUM ובכלים כמו כלי פיתוח ל-Chrome. צוות Chrome עדיין לא פרסם את לוחות הזמנים לשילוב המדדים האלה בדוח על חוויית המשתמש ב-Chrome (CrUX). בנוסף, מנועי דפדפן אחרים עדיין לא תומכים בממשקי ה-API החדשים האלה, ולכן אפשר למדוד את מדדי ה-Core Web Vitals רק בטעינות של דפים מלאים בדפדפנים האלה.
למה זו הייתה בעיה קשה לפתרון?
אין כיום דרך סטנדרטית לבניית SPA, ואפילו בין ספריות ה-SPA והניתוב הפופולריות, חוויית המשתמש יכולה להיות שונה מאוד מאפליקציה לאפליקציה:
- יש אתרים מסוג SPA שמעדכנים את כתובת ה-URL רק כשנטען תוכן חדש של 'דף מלא', ויש אתרים שמעדכנים את כתובת ה-URL גם כשמתבצעים שינויים קטנים בתוכן או אפילו רק שינויים במצב ממשק המשתמש.
- חלק מאפליקציות ה-SPA מעדכנות את כתובת ה-URL באמצעות History API, ואחרות משתמשות בשינויים בגיבוב כדי לתמוך בדפדפנים ישנים יותר (ויש אפליקציות שלא מעדכנות את כתובת ה-URL בכלל).
- יש אתרים מסוג SPA שטוענים תוכן ואז מעדכנים את כתובת ה-URL, ויש אתרים שמעדכנים את כתובת ה-URL לפני שהם טוענים תוכן.
- יש אפליקציות SPA שבהן התוכן נטען בבת אחת, באופן סינכרוני, במשימת JavaScript אחת, ויש אפליקציות שבהן התוכן עובר באופן אסינכרוני בין כמה משימות (בלי אירוע ברור של סיום המעבר).
- חלק מה-SPA תמיד טוענים תוכן מהרשת, ואחרים טוענים מראש את כל התוכן כדי ששינויים במסלול ייטענו באופן מיידי מהזיכרון.
ההבדלים האלה מקשים מאוד על הגדרה וזיהוי של מה שנחשב לשינוי נתיב ב-SPA, או אפילו של מה שנחשב ל-SPA, בסדר גודל גדול.
במקרים מסוימים, שינוי נתיב ב-SPA זהה מבחינה לוגית לטעינת דף ב-MPA. במקרים כאלה, כדאי להשתמש במדדים הקיימים של Core Web Vitals.
עם זאת, בלי היוריסטיקה מוצקה לזיהוי מהימן של שינויים בנתיב שהם "אמיתיים" מכל שאר השינויים בכתובות ה-URL, וגם בלי אותות ברורים שמסמנים את ההתחלה והסוף של מעברים כאלה, הדיווח על מדדי Core Web Vitals במקרים האלה יטשטש את הנתונים ויפגע בשימושיות שלהם או בייצוג שלהם את חוויית המשתמש האמיתית באתר.
העבודה על ניווט רך סיפקה פתרון לכך באמצעות שני ממשקי API חדשים לביצועים:
PerformanceSoftNavigationשמודד מתי אינטראקציה של משתמש מובילה גם לציור וגם לשינוי בכתובת ה-URL. השילוב של שלושת הדברים האלה מספק הגדרה סטנדרטית של 'ניווט רך' בלי קשר למסגרת שבה נעשה שימוש, ולמרות חלק מההבדלים שצוינו קודם. כך אפשר לפצל את ציר הזמן של הביצועים ל'ניווטים' נפרדים, ולמדוד את CLS ואת INP לכל ניווט.-
InteractionContentfulPaintשבו נמדדים 'רכיבי תוכן' אחרי אינטראקציה, וכך אפשר למדוד את FCP ו-LCP עבור הניווטים הרכים האלה.
השילוב של שני ממשקי ה-API האלה מאפשר למדוד את מדדי ה-Core Web Vitals גם בטעינות מלאות של דפים וגם במעברים רכים.
האם שינויים בנתיבים של SPA זהים לטעינות מלאות של דפים מבחינת Core Web Vitals?
לא, עדיין יש הרבה הבדלים בין סוגי הניווט האלה, שיכולים לגרום להבדלים במדדי הליבה לבדיקת חוויית המשתמש באתר.
בניווט רך יש תוכן בדף, וחלק מהתוכן או כולו מתעדכן כדי להציג את ה "דף" החדש. במובנים רבים, זה דומה להבדל בין טעינת דף מלאה שלא נשמר במטמון לבין טעינת דף כשחלק ממשאבי הדף או כולם נשמרים במטמון, אבל במצב קיצוני יותר, כי יכול להיות שחלק מהתוכן יישאר מעובד.
באופן תיאורטי, ההבדל העיקרי יהיה הפוטנציאל לניווטים רכים להיות מהירים הרבה יותר. אבל יש גם הבדלים אחרים, יותר עדינים.
ממשקי ה-API החדשים של ניווט רך מתייחסים רק לתוכן חדש. לכן, אם בדף מתעדכנים התוכן של <h1> ושל הטקסט, אבל תמונת הגיבור נשארת זהה בין הדפים, היא לא תיחשב כמועמדת ל-LCP אם היא לא נצבעה מחדש. הדבר יוביל להבדלים ברכיבים שמשמשים לחישוב זמן ה-LCP, בהתאם לשאלה אם אותו דף נטען כטעינת דף מלאה או כניווט רך מדף קיים אחר.
באופן דומה, יכול להיות שערך ה-INP יהיה נמוך יותר במעברים רכים, כי הרבה קוד JavaScript שנדרש להפעלת האתר כבר ייטען. באופן דומה, בניווט רך יכול להיות פחות (או יותר!) CLS אם אותו תוכן גורם ל-CLS בטעינת דף מלאה, אבל לא צריך לטעון אותו או לעבד אותו מחדש בניווט רך.
יש גם הבדלים קלים במועד שבו מתבצעות המדידות בטעינות מלאות של דפים (החל מהשלב שאחרי עיבוד אינטראקציית הניווט) לעומת ניווטים רכים (החל מזמן התחלת האינטראקציה).
כמו שצוין קודם, הרבה מההבדלים האלה דומים להבדלים בין דפים שלא נשמרו במטמון לבין דפים שנשמרו במטמון, והקונספט של מה שמדדי Core Web Vitals מנסים למדוד עדיין רלוונטי. עם זאת, כדאי להבין את ההבדלים הדקים האלה כשבודקים בעיות שקשורות למדדי הליבה לבדיקת חוויית המשתמש באתר.
האם קשה יותר לאתרי SPA להשיג תוצאות טובות במדדי הליבה לבדיקת חוויית המשתמש באתר מאשר לאתרי MPA?
אין שום דבר בארכיטקטורה של SPA שמונע מדף באפליקציית SPA להיטען באותה מהירות כמו דף דומה באפליקציית MPA, ולקבל ציון זהה בכל מדדי Core Web Vitals.
עם זאת, לאפליקציות MPA שעברו אופטימיזציה נכונה יש כמה יתרונות בהשגת סף המדדים הבסיסיים של חוויית המשתמש, שלא קיימים באפליקציות SPA. הבעיה הזו נפתרה במידה רבה בעקבות העבודה על ניווטים רכים שדיברנו עליהם קודם, אבל היא עדיין יכולה לקרות אם עדיין לא נעשה שימוש בממשקי ה-API החדשים האלה. הסיבה לכך היא שבארכיטקטורת MPA, כל 'דף' נטען כניווט לדף מלא (במקום לאחזר תוכן באופן דינמי ולהוסיף אותו לדף הקיים). המשמעות היא שמשתמשים שמבקרים באתר MPA צפויים לטעון יותר מדף אחד מהאתר, ולכן אחוז גדול יותר מההתפלגות של כל טעינות הדפים באתר MPA יכלול חלק ממשאבי המשנה או את כולם במטמון.
כדי שדף MPA ישיג ביצועים טובים יותר במדדי Core Web Vitals בהשוואה לדף SPA, צריך לוודא כמה דברים:
- כדי לוודא שטעינות דפים מאותו מקור אכן מהירות יותר מטעינות דפים ממקורות שונים באחוזון ה-75, צריך להפעיל במערכת ה-MPA אופטימיזציה של שמירת משאבי משנה במטמון.
- משתמשים שנכנסים לאתרי MPA צריכים לבקר בכמה דפים כדי שהאתר ייהנה מהיתרונות של השמירה במטמון, שמובילה לטעינה מהירה יותר של הדפים.
מכיוון שההערכות של Core Web Vitals מתבססות על האחוזון ה-75 של הביקורים בדף, ככל שיש יותר ביקורים בדף שמניבים ביצועים טובים בקבוצת הנתונים, כך גדל הסיכוי שהביקור באחוזון ה-75 של ההתפלגות יהיה במסגרת ערכי הסף המומלצים.
חשוב לשים לב: כשמשווים בין ציוני Core Web Vitals, צריך להבין איך הנתונים נצברים – כלומר, אם קבוצת הנתונים בהתפלגות כוללת את כל הדפים מהאתר או מהמקור, או רק טעינות של דף מסוים בכתובת URL מסוימת.
כשמצטברים הציונים של כל הדפים במקור, דפים מהירים יכולים לשפר את האחוזון ה-75 של המקור כולו. עם זאת, כשמבצעים צבירה לפי דפים נפרדים, הציונים של דף אחד לא משפיעים על הציונים של הדף הבא. במילים אחרות, כשמצטברים הציונים של MPA לפי דף, טעינות מהירות של מטמון בדף התשלום לא ישפרו את הציונים של טעינות ראשוניות איטיות שמתרחשות בדף הנחיתה של האתר.
אפשר לבדוק את הניקוד של האתר בשיטות שונות של צבירה באמצעות PageSpeed Insights או Chrome User Experience Report API, שמדווח על ניקוד של כתובות URL של דפים ספציפיים ושל המקור כולו.
דרך נוספת שבה ארכיטקטורת ה-SPA יכולה להשפיע על ציוני ה-Core Web Vitals היא במדדים שמתייחסים למשך החיים המלא של דף. משתמשים שמבקרים באתרי SPA נוטים להישאר באותו 'דף' לאורך כל הסשן, ולכן מדדים שמצטברים לאורך זמן יכולים להיות נמוכים יותר באתרי SPA מאשר באתרי MPA.
בעקבות העבודה על מעברים רכים, אנחנו מאמינים שאין יותר חסרונות ל-SPA מבחינת האופן שבו אפשר למדוד את Core Web Vitals. עם זאת, ייקח זמן עד שה-API האלה ישולבו באופן מלא בכל הפתרונות של כלי הדיווח.
אם ארכיטקטורות של SPA משפרות את חוויית המשתמש, למה השיפור הזה לא משתקף במדדים?
כן, זה אמור לקרות. קשה לכמת את מידת השיפור בחוויה בקנה מידה גדול, בהתחשב בכל הדרכים השונות שבהן מיושמים היום דפי SPA באינטרנט. עכשיו יש לנו פתרון לבעיית המדידה, ואם משתמשים בממשקי ה-API החדשים האלה, כל השיפורים שמתקבלים מהמעבר לאפליקציות SPA יבואו לידי ביטוי במדדים.
האמת היא שבעבר, תעשיית ביצועי האתרים (כולל Google) לא השקיעה כמעט זמן ומאמץ בפיתוח מדדים שמתמקדים במשתמשים לגבי הביצועים של דף אחרי הטעינה, כמו שהיא השקיעה בטעינת הדף עצמו. זה לא אומר שהביצועים אחרי הטעינה לא חשובים, אלא שחוויית המשתמש והאינטראקציות אחרי הטעינה הרבה יותר מגוונות ופחות מוגדרות – ולכן קשה לעצב מדדים עבורן.
אבל גם עכשיו, כשיש לנו יותר מדדים אחרי הטעינה למדידת הביצועים של SPA, אנחנו לא רוצים להתעלם מחוויית הטעינה רק בגלל שחוויית השימוש אחרי הטעינה השתפרה.
אחת המטרות של יוזמת Web Vitals היא לקדם ולתמרץ חוויית משתמש טובה ככל האפשר, בכל ההיבטים של טעינת דף אינטרנט ושימוש בו. אנחנו לא רוצים לעודד תרחישים שבהם חוויה גרועה מוצדקת אם אפשר ליצור מספיק חוויות טובות שיפצו על כך. המשתמשים רוצים שהדפים ייטענו במהירות ושהמעבר לתוכן חדש יהיה מהיר, ולכן ניסינו לעצב מדדים שמעדיפים חוויות כאלה.
החלפנו את האתר שלנו מ-MPA ל-SPA והציונים שלנו ירדו. האם זה צפוי?
לשאלה הזו יש כמה תשובות אפשריות. יכולות להיות כמה סיבות לשינוי בציונים אחרי העברה משמעותית של הארכיטקטורה, אבל ירידה במספר הטעינות של מטמון חם יכולה להסביר חלק מהשינוי.
דרך מהירה לבדוק היא להריץ בדיקה של גרסת MPA וגרסת SPA של אחד מדפי הנחיתה שלכם באמצעות Lighthouse. אם הציון ב-Lighthouse נמוך יותר באחד ממדדי ה-Core Web Vitals בגרסת ה-SPA, סביר להניח שחוויית הטעינה השתפרה אחרי העדכון.
האם כדאי להחליף את האתר שלי מאפליקציית דף יחיד (SPA) לאפליקציה מרובת דפים (MPA) כדי לקבל ציון טוב יותר במדדי ה-Core Web Vitals?
סביר להניח שלא. כדאי לעבור מ-SPA ל-MPA רק אם אתם לא מרוצים מה-SPA stack שלכם ויש לכם סיבה להאמין ש-MPA יספק חוויית משתמש טובה יותר.
אנחנו מאמינים שפתרנו את בעיות המדידה באמצעות העבודה על ניווט רך, ולכן אין טעם לעבור רק בגלל זה.
עם זאת, אם יש לכם סיבה להאמין שהביצועים ישתפרו, ולא רק המדידות, יכול להיות שזה יהיה שיקול למעבר מ-SPA ל-MPA (או להיפך!).
אם מדדי ה-Core Web Vitals מדווחים רק על דפי הנחיתה של SPA, איך אפשר לנפות באגים בבעיות שמתרחשות ב'דפים' אחרי מעבר מסלול?
הנתונים בכלי Google שמדווחים על נתוני שדות למדד Core Web Vitals (כמו Search Console ו-PageSpeed Insights) מגיעים מהדוח על חוויית המשתמש ב-Chrome (CrUX). ב-CrUX הנתונים נצברים לפי מקור או לפי כתובת URL של הדף (כלומר, כתובת ה-URL של הדף בזמן הטעינה).
אנחנו פועלים כדי לאפשר ל-CrUX לכלול בנתונים המצטברים שלו נתונים לפי נתיב SPA. עם זאת, בעלי אתרים יכולים להשתמש עכשיו בממשקי ה-API החדשים כדי למדוד את מדדי ה-Core Web Vitals לפי נתיב SPA מראש, כדי להבין איך הניקוד שלהם עשוי להשתנות.
פרטים נוספים ושיטות מומלצות בנושא זמינים במאמר מדידת מעברים רכים.
מה Google עושה כדי לוודא שלדפי MPA אין יתרון לא הוגן בהשוואה לדפי SPA?
כפי שציינו קודם, בעקבות העבודה שביצענו בנושא ניווטים רכים, אנחנו מאמינים שאין יותר חסרונות לאפליקציות SPA בהקשר הזה, אבל ייקח זמן עד שנשלים את השילוב בכל הפתרונות של כלי הדיווח.
הערכת ביקורים בדפים ממקורות שונים ומאותו מקור בנפרד
נכון לעכשיו, מדדי Core Web Vitals מסכמים את כל הביקורים בדף בקטגוריה אחת – הם לא מבחינים בין ביקורים חדשים לבין מבקרים חוזרים, בין דפי נחיתה לבין דפי התשלום או בין כל סוג אחר של צבירה שבה מצב המטמון יכול להשפיע על הביצועים.
דרך אחת לנרמל את ההבדלים בין הביצועים של SPA ו-MPA היא להחיל משקלים שונים על סוגים שונים של ביקורים, ואולי אפילו להשתמש בהמלצות שונות לחלוטין לגבי סף.
אנחנו רוצים לתגמל הטמעות יעילות של מטמון, אבל לא רוצים שזמני טעינה מהירים של דפי נחיתה יפצו על זמני טעינה איטיים של דפים אחרים באתר. בנוסף, אנחנו לא רוצים לעודד אתרים לפצל דפים ארוכים לקבוצה של דפים קצרים יותר רק כדי לשפר את ציוני המדדים.
הערכה נפרדת של ביקורים בדפים ממקורות שונים ומאותו מקור עוזרת לנו לוודא ששני סוגי החוויות חשובים, בלי שהפופולריות היחסית של סוג אחד באתר מסוים תשפיע על החלוקה של מדד מסוים.
מחשבות לסיכום
Google מחויבת מאוד לשיפור מדדי ה-Web Vitals, ולוודא שהם מודדים חוויית משתמש איכותית שחשובה למשתמשים, ומעודדים אותה. עם זאת, אנחנו מודעים לכך שקיימים היום פערים במדידה. המדדים יכולים עכשיו לכסות מעברים במסלולי SPA, וכך לטפל באחד הפערים העיקריים.
בנוסף, אנחנו מאמינים שיש לממשקי ה-API החדשים האלה (במיוחד InteractionContentfulPaint) שימושים נוספים ויתרונות פוטנציאליים מעבר למדידת ה-Core Web Vitals עבור ניווטים רכים. אנחנו שמחים מאוד להמשיך לפתח את התכונות האלה עכשיו, אחרי שטיפלנו בסיבה העיקרית להשקה שלהן.
אני מקווה שהפוסט הזה עזר להבהיר את הנושא המורכב והניואנסי הזה. כמו תמיד, אם יש לכם משוב על מדדי Core Web Vitals הנוכחיים או העתידיים, אתם יכולים לשלוח אימייל אל web-vitals-feedback@googlegroups.com.