גרסת מקור חדשה לניסיון של ניווטים רכים

Barry Pollard
Michal Mocny

תאריך פרסום: 31 ביולי 2025

החל מ-Chrome 139,‏ Chrome משיק גרסת מקור לניסיון חדשה עבור Soft Navigations API, שכבר ביצענו איתו ניסויים. במסגרת תקופת הניסיון הזו, אתרים יכולים לנסות את ה-API באתר שלהם עם משתמשים אמיתיים כדי לבדוק אותו בשטח ולספק משוב לצוות Chrome.

מהן העברות רכות?

ניווט רך מתרחש כש-JavaScript מיירט ניווט (לדוגמה, לחיצה על קישור) ומעדכן את התוכן בדף הקיים, במקום לטעון דף חדש ואז לעדכן את כתובת ה-URL בסרגל הכתובות (עם מצב היסטוריה שמאפשר ניווט רך קדימה ואחורה). למשתמשים, הניווטים האלה נראים כמו ניווטים רגילים, אבל מבחינת הדפדפן, הדף הוא עדיין הדף המקורי.

למה צריך את Soft Navigation API

‫Soft Navigations API הוא API מוצע שמאפשר זיהוי היוריסטי של מה שנקרא 'ניווטים רכים' כפי שנעשה שימוש בהם באתרים של אפליקציות דף יחיד (SPA). בניווט רך לא מתבצע ניווט בפועל בדף, ולכן צריך לנהל ידנית באמצעות JavaScript פעולות מסוימות שבדרך כלל מתבצעות בניווט. אפשר לבצע חלק מהפעולות, כמו ניהול היסטוריית הניווט, באמצעות ממשקי ה-API הנוכחיים. עם זאת, אי אפשר לבצע פעולות אחרות, כמו מדידת Core Web Vitals, במעברים האלה.

‫Soft Navigation API מאפשר מעקב אחר ניווטים רכים. בעוד ש-JavaScript שמתחיל את הניווט הרך (בדרך כלל JavaScript framework) יודע מתי מתרחש ניווט, סקריפט JavaScript אחר והדפדפן עצמו לא יודעים.

Core Web Vitals ו-SPA

אחת המטרות העיקריות של Soft Navigation API היא לאפשר מדידה של מדדי ה-Core Web Vitals באתרי SPA. Core Web Vitals נמדדים על ידי הדפדפן (כדי להציג אותם בכלי כמו דוח על חוויית המשתמש ב-Chrome‏ (CrUX)) ועל ידי ספריות JavaScript של ניטור משתמשים אמיתיים (RUM).

יכול להיות שחלק מהמדדים של Core Web Vitals יימדדו על ידי מסגרות JavaScript. במיוחד מהירות התגובה לאינטראקציה הבאה (INP) ושינוי פריסה מצטבר (CLS) מבוססים על פרימיטיבים (Event Timing API ו-Layout Instability API בהתאמה) שאפשר למדוד בכל טווח זמן כדי לחשב את מדדי ה-INP וה-CLS. עם זאת, מכיוון שהדפדפן מדווח על המהירות שבה נטען רכיב התוכן הכי גדול (LCP) ומסיים את המדידה שלו על סמך ניווטים ואינטראקציות בדף, למסגרות JavaScript אין נראות לגבי שום דבר מלבד ביצועי הטעינה הראשוניים של דפי SPA.

איך Soft Navigation API מאפשר מדידה של Core Web Vitals עבור SPAs

באיטרציה הראשונה של Soft Navigation API, ההיוריסטיקה של הניווט הרך שולבה עם איפוס של LCP. אחרי האיפוס, אפשר לשלוח מחדש את מדד ה-LCP לניווטים רכים עבור צביעה חדשה של תוכן, וכך למדוד את המדד הזה עבור ניווטים רכים.

בגרסה האחרונה הזו יש גישה שונה, והמושגים האלה מופרדים ל-Soft Navigation API ולרשומה חדשה של ביצועים שנקראת Interaction to Contentful Paint (מהירות התגובה לאינטראקציה באתר). הערך interaction-contentful-paint מודד את ה-"contentful paint" אחרי אינטראקציות. בשלב הזה, האירוע הזה מופעל רק כשמדובר בניווטים רכים, אבל אם הוא יופעל לכל האינטראקציות, יהיו לו עוד תרחישי שימוש פוטנציאליים מעבר ל-LCP.

בנוסף, ה-API הרחיב כל אחת מהרשומות של ביצועי largest-contentful-paint, interaction-contentful-paint, event-timing ו-layout-shift כך שיכללו מזהה של הניווט שאליו מתייחסת הרשומה. רשומות הביצועים מופקות אחרי האירוע שהן מודדות – בדרך כלל בזמן שהמערכת לא פעילה. כלומר, כתובת ה-URL כבר תשתנה בדרך כלל עד שהנתונים על הביצועים יועברו. הכללת הניווט עם הרשומה מקלה מאוד על מדידת מדדי ה-Core Web Vitals עבור כתובת ה-URL הנתונה, בלי שתצטרכו להתאים בין זמני הרשומה של הביצועים לבין זמני הרשומה של הניווט הרך.

למה כדאי להשתמש בהיוריסטיקה?

ה-API של ניווט רך מתייחס לניווט רך במקרים הבאים:

  • מתרחשת אינטראקציה מבוססת-משתמש (עדכוני כתובות URL ללא אינטראקציה של משתמש לא נספרים)
  • … מה שגורם לשינוי ב-DOM ולרנדור
  • … ומתבצע עדכון של כתובת ה-URL
  • עדכון כתובת URL, כולל שינוי בהיסטוריה.

ה-API משתמש בגישה הזו שמבוססת על היוריסטיקה, במקום לאפשר ל-JavaScript framework "לפלוט" ניווט רך, או להתבסס על Navigation API. כך אפשר להבין באופן עקבי מה נחשב לניווט רך, בלי קשר ל-framework או לאופן שבו מפתחים משתמשים בו.

יכול להיות שמסגרות או מפתחים יעדכנו את כתובת ה-URL לניווט רך גם בלי אינטראקציה של משתמש או עדכון של ה-DOM, שאנחנו מחשיבים כניווט שמשתמש יראה. יכול להיות שהם גם יעדכנו את כתובת ה-URL בזמנים שונים – בתחילת האינטראקציה או רק בסוף כשהיא תושלם – או בכל שלב ביניהם.

במקום להסתמך על בחירות של מסגרות, בניית זיהוי הניווט הרך בדפדפן יוצרת 'היוריסטיקות' קנוניות (עם המשוב שלכם מגרסת המקור לניסיון הזו), שיאפשרו לנו למדוד את Core Web Vitals עבור ניווטים רכים בהיקף נרחב, ולהשוות בין המדידות האלה בהיקף נרחב.

גם framework ומפתחים יכולים להתעלם מהיוריסטיקה של Soft Navigations API ולהשתמש בממשקי ה-API הבסיסיים Event Timing,‏ Layout Instability ו-Interaction to Contentful Paint כדי למדוד מדדי ביצועים נוספים לפי הצורך, אבל אנחנו ממליצים להשתמש ב-Core Web Vitals באמצעות היוריסטיקה כדי לאפשר מדידה באתרים שונים.

נדרשת עזרה בבדיקה של Soft Navigation API

אנחנו צריכים עזרה בבדיקת Soft Navigations API כדי לבדוק אם ההיוריסטיקה תואמת לציפיות שלכם לגבי המקרים שבהם מתרחשת ניווט רך. האם יש מקרים שבהם ה-API לא מדווח על מעברים רכים כשאתם חושבים שהם התרחשו? לחלופין, האם ממשק ה-API מזהה ניווטים חוזרים שאתם לא מחשיבים כניווטים רכים?

דוגמאות לבעיות שנתקלנו בהן כוללות מצבים שבהם כתובת URL מתעדכנת באמצעות replaceState במקום להוסיף היסטוריה, או כשמתרחש ניווט שלא מתחיל על ידי המשתמש (לדוגמה, יציאה מהחשבון בגלל זמן קצוב לתפוגה). בשני המקרים האלה, ההסבר הוא שהתוכן לא תואם להיוריסטיקה, וצוות Chrome לא רואה בעיה בכך שהתוכן לא נכלל, אבל אנחנו רוצים לשמוע ממפתחי אתרים אם הם מסכימים. במיוחד נשמח לשמוע על מקרים שבהם נראה שהיוריסטיקה מתקיימת, אבל ה-API עדיין לא מזהה את הניווט הרך.

בנוסף, אנחנו רוצים להבין אם ה-API הזה, והפרימיטיב החדש Interaction to Contentful Paint, נותנים מענה לתרחיש השימוש העיקרי של מדידת Core Web Vitals עבור SPAs.

אנחנו רוצים שממשק ה-API יהיה שימושי ככל האפשר, וקל יותר להשיג את זה לפני ההשקה שלו ולפני שאתרים מתחילים להסתמך על הטמעה שלו. לכן, אנחנו מבקשים ממפתחי SPA ומכל מי שמתעניין במדידת ביצועי אתרים להשתמש ב-API הזה ולעדכן אותנו איך הוא עובד בשבילכם.

איך בודקים

אפשר לבדוק את ה-API באופן מקומי באמצעות תכונות ניסיוניות של Chrome או אפשרויות של שורת הפקודה. בנוסף, אפשר לבדוק אותו בשטח באמצעות גרסת המקור לניסיון.

פרטים טכניים נוספים על ה-API, ובמיוחד הסברים על מדידת Core Web Vitals, זמינים במסמכי העזרה שלנו או במאגר ב-GitHub. בנוסף, זמינה גרסת ניסוי של ספריית web-vitals עם ניווט רך.

משוב

אנחנו מבקשים משוב על הניסוי הזה במקומות הבאים:

אם אתם לא בטוחים, אל תדאגו יותר מדי. אנחנו מעדיפים לקבל את המשוב בכל אחד מהמקומות האלה, ונשמח לטפל בבעיות בשני המקומות ולהפנות אותן למיקום הנכון.