ה-Soft Navigations API ב-Chrome 151 מאפשר סוף סוף לאפליקציות בעמוד אחד (SPAs) לדווח על Core Web Vitals עבור כל ניווט בתוך האפליקציה, אך מאגר הנתונים CrUX של גוגל עדיין מתעד רק את ה-hard load הראשון, מה שמותיר מפתחים עם שתי תמונות ביצועים שונות.

מדוע המדדים של SPA נותרו מאחור

ה-Core Web Vitals—Largest Contentful Paint (LCP), Interaction-to-Next-Paint (INP) ו-Cumulative Layout Shift (CLS)—הוגדרו סביב hard navigations. hard navigation שולף מסמך חדש לחלוטין ומוותר על המצב (state) של הדף הקודם.

SPAs שנבנו עם React, Vue, Next.js או פריימוורקים דומים כמעט ולא מפעילים hard navigations. לחיצה על קישור מעדכנת את ה-URL באמצעות ה-History API, שולפת נתונים ברקע ומחליפה תוכן ללא טעינה מחדש מלאה. ה-Performance API הקיים לוכד רק את טעינת הדף הראשונית, כך ש-LCP ו-INP לעולם לא מזהים את השיהוי (latency) שהמשתמשים חשים כשהם עוברים מנתיב (route) אחד למשנהו.

נקודת עיוורון זו מעוותת לוחות בקרה (dashboards) ששואבים נתונים מה-Performance Timeline או מדו"ח ה-Chrome User Experience Report (CrUX) של גוגל. הם מציגים לעיתים קרובות LCP מצוין עבור דף ה-"shell", תוך התעלמות מטעינות איטיות יותר עמוק יותר בתוך האפליקציה, מה שיוצר תחושה שגויה של תקינות הביצועים.

ה-Soft Navigations API של Chrome

Chrome 151 הציג את ה-Soft Navigations API, סט של היוריסטיקות המתייחסות לאינטראקציות מסוימות ב-SPA כניווטים אמיתיים. ה-API עוקב אחר שלושה אותות:

  • אינטראקציה שהופעלה על ידי משתמש (לחיצה, הקשה, אירוע מקלדת)
  • שינוי ב-URL באמצעות ה-History API
  • אירועי paint עוקבים המרנדרים תוכן חדש

כאשר שלושתם מתואמים, Chrome מתעד soft navigation ב-Performance Timeline, וה-Core Web Vitals מחושבים עבור המעבר הזה בדיוק כמו עבור hard navigation. הספרייה בקוד פתוח web-vitals הוסיפה תמיכה ב-21 ביולי, כך שמפתחים יכולים להתחיל לשלוף את המספרים הללו באמצעות אותו API שהם כבר משתמשים בו.

בפועל, ניתן לראות כעת ערך LCP עבור כל שינוי נתיב, INP המשקף את השיהוי האמיתי של קלט המשתמש האחרון, ו-CLS שתופס תזוזות פריסה (layout shifts) לאחר soft navigation.

פיצול הנתונים: Chrome לעומת CrUX

ה-CrUX (Chrome User Experience Report) של גוגל מניע את PageSpeed Insights, את Search Console ובאופן עקיף גם את אותות הדירוג (ranking signals). CrUX עדיין מרכז נתונים של hard-navigation בלבד.

כתוצאה מכך, נוצרים שני זרמי נתונים עקביים אך שונים:

  • כלים פנימיים הקוראים את ה-Performance Timeline מציגים כעת LCP, INP ו-CLS ברמת הנתיב (route-level), מה שנותן תמונה ריאליסטית של מה שהמשתמשים חווים ב-SPA.
  • מאגרי הנתונים הציבוריים של גוגל ממשיכים להציג מדדים עבור טעינת הדף הראשונית בלבד, וזה מה ש-Search Console מדווח ומה שאליו מתייחסות אלגוריתמי הדירוג של גוגל.

שניהם נכונים; הם פשוט מודדים רגעים שונים. הסתמכות בלעדית על Search Console עלולה להסתיר נסיגות בביצועים (performance regressions) המתרחשות לאחר הטעינה הראשונית, בעוד שלוחות בקרה פנימיות לבדן לא ישקפו את נקודת הייחוס (baseline) שגוגל משתמשת בה לצורך SEO.

מה מפתחים צריכים לעקוב אחריו

  • תמיכה בדפדפנים – ה-Soft Navigations API קיים כיום רק בדפדפנים מבוססי Chromium. ל-Safari ו-Firefox אין מקבילה, לכן עליכם לשמור על לוגיקת fallback עבור חלק מהקהל שלכם.
  • מגבלות היוריסטיות – ה-API מחליט על soft navigation על סמך סט של רמזים. אם האפליקציה שלכם מעדכנת תוכן מבלי לשנות את ה-URL (למשל, modal overlays או infinite scroll), ה-API עלול לפספס את המעברים הללו, מה שישאיר פערים בנתונים.
  • בדיקה לפני אמון – מכיוון שהזיהוי הוא היוריסטי, הריצו סדרה של אינטראקציות בעולם האמיתי באפליקציה שלכם והשוו את המדדים המדווחים מול תזמון ידני (למשל, באמצעות performance.mark). רק לאחר אישור הדיוק, כדאי לבסס החלטות אופטימיזציה על המספרים החדשים.

שורה תחתונה

Chrome 151 מעניק למפתחי SPA את היכולת המיוחלת למדוד LCP, INP ו-CLS עבור כל שינוי נתיב בתוך האפליקציה, אך נתוני הדירוג של גוגל עדיין משקפים רק את ה-hard load הראשון. עד ש-CrUX יתעדכן, צוותים יצטרכו לתמרן בין שני סטים מקבילים של נתונים: אחד שמספר את סיפור המשתמש האמיתי, ואחר שמניע את דירוגי החיפוש. איזון בין שניהם – והכנה לתמיכה רחבה יותר בדפדפנים – יהיה המפתח לשמירה על SPAs שמתעדפות ביצועים (performance-first) במערכת אקולוגית תחרותית של רשת האינטרנט.