תאריך פרסום: 20 באפריל 2026
בהמשך השנה, Chrome מתכננת להשיק את Soft Navigations API שעליו ערכנו ניסויים בעבר. כדי להתכונן לכך, אנחנו מציעים עוד גרסת מקור לניסיון החל מ-Chrome 147 ועד Chrome 149. בגרסת הניסיון הזו שילבנו משוב מגרסאות ניסיון קודמות, כדי להגיע לצורה הסופית הצפויה של ה-API. אנחנו ממליצים לבעלי אתרים שמתעניינים בתכונה הזו לבצע בדיקה סופית של הצורה הסופית הצפויה של ה-API לפני ההשקה שלו.
מהן העברות רכות?
"ניווט רך" הוא מצב שבו JavaScript מיירט ניווט (לדוגמה, לחיצה על קישור) ומעדכן את התוכן בדף הקיים, במקום לטעון דף חדש, בזמן שכתובת ה-URL עדיין מתעדכנת בסרגל הכתובות. למשתמשים, המעברים האלה נראים כמו מעברים רגילים, אבל מנקודת המבט של הדפדפן, הדף הוא עדיין הדף המקורי.
למה צריך את Soft Navigation API
Soft Navigations API הוא API מוצע לזיהוי ניווטים רכים שבהם נעשה שימוש באתרים של אפליקציות דף יחיד (SPA). בניווט רך לא מתבצע ניווט בפועל בדף, ולכן JavaScript צריך לנהל באופן ידני פעולות מסוימות שבדרך כלל מתבצעות בניווט. אפשר לבצע חלק מהפעולות, כמו ניהול היסטוריית הניווט, באמצעות ממשקי ה-API הנוכחיים. עם זאת, אי אפשר לבצע פעולות אחרות, כמו מדידת Core Web Vitals, במעברים האלה.
Soft Navigation API מאפשר מעקב אחרי ניווטים רכים. קוד ה-JavaScript שמתחיל את הניווט הרך (בדרך כלל JavaScript framework) יודע מתי מתרחש ניווט, אבל קוד JavaScript אחר שבו האתר משתמש (לדוגמה, סקריפטים של Analytics) והדפדפן עצמו לא יודעים על כך.
Core Web Vitals ו-SPA
אחת המטרות העיקריות של Soft Navigation API היא לאפשר מדידה של מדדי ה-Core Web Vitals באתרי SPA. Core Web Vitals נמדדים על ידי הדפדפן (כדי להופיע בכלים כמו דוח על חוויית המשתמש ב-Chrome (CrUX)) ועל ידי בעלי האתר באמצעות פתרונות לניטור משתמשים אמיתיים (RUM).
בעזרת מסגרות JavaScript אפשר למדוד היבטים מסוימים של Core Web Vitals עבור דפי SPA. בפרט, מהירות התגובה לאינטראקציה הבאה (INP) ושינוי פריסה מצטבר (CLS) מבוססים על פרימיטיבים (Event Timing API ו-Layout Instability API בהתאמה) שאפשר למדוד בכל טווח זמן כדי לחשב את המדדים האלה. עם זאת, מדדים אחרים כמו המהירות שבה נטען רכיב התוכן הכי גדול (LCP) מופקים רק על ידי הדפדפן – על סמך ניווטים בדף והם מסתיימים לאחר אינטראקציה.
איך ה-API מאפשר מדידה של Core Web Vitals עבור SPAs
ב-Soft Navigation API הוספנו שני רשומות חדשות של ביצועים:
- רשומה של
SoftNavigationEntryשמופקת כשכל הדרישות לניווט רך מתקיימות. הם כולליםinteractionIdלאינטראקציה שגרמה לניווט הרך,navigationIdייחודי וnameשמוגדר לכתובת ה-URL החדשה, וגם זמני ציור שונים שאפשר להשתמש בהם כדי למדוד את זמן הצגת התוכן הראשון בניווט הרך. InteractionContentfulPaintרשומה שמאפשרת למדוד כמה פעמים שהתוכן הוצג, בגדלים הולכים וגדלים, אחרי אינטראקציות, כדי למדוד את ה-LCP עבור מעברים רכים.
אפשר לראות את הרשומות החדשות האלה באמצעות PerformanceObserver, באמצעות הסוגים soft-navigation ו-interaction-contentful-paint בהתאמה.
בנוסף, ה-API מרחיב כל אחת מהרשומות של הביצועים largest-contentful-paint, interaction-contentful-paint, event-timing ו-layout-shift (ואחרות) כך שיכללו מזהה, navigationId, שמייצג את הניווט שאליו מתייחסת הרשומה. מכיוון ש-PerformanceObserver לא עוקב אחרי רשומות של ביצועים עד שהדף בלי פעילות, יכול לעבור זמן בין האירוע שיצר את רשומת הביצועים לבין המעקב שלכם אחריו. זה נכון במיוחד כשהדף עמוס מאוד, למשל במהלך ניווטים רכים. הערך navigationId עוזר לשייך רשומות לניווט הנכון.
חלק מהערכים ביומן interaction-contentful-paint יכולים להופיע לפני הניווט וחלק אחריו. במקום לעקוב אחרי כל הציורים שיכולים להוביל לניווט רך, הרשומה soft-navigation כוללת רשומה של largestInteractionContentfulPaint שהיא הציור הגדול ביותר שנראה עד עכשיו.
המדדים האלה מאפשרים למדוד את ה-Core Web Vitals עבור:
- LCP: שימוש ב-
largest-contentful-paintלטעינת הדף הראשונית ובערכים החדשיםinteraction-contentful-paintו-soft-navigationלניווטים רכים. - CLS: שימוש בערכי
layout-shiftוחלוקה שלהם על סמך ערכיsoft-navigationלניווטים רכים. - INP: שימוש בערכים של
eventופילוח שלהם על סמך הערכים שלsoft-navigationלניווטים רכים. - FCP: שימוש ב-
first-contentful-paintלטעינת הדף הראשונית ובפרטי התזמון של הצביעה ברשומות החדשות שלsoft-navigationלניווטים רכים.
פרטים נוספים זמינים במסמכי התיעוד בנושא ניווט רך.
איך מופעלות ניווטים רכים?
ה-API של ניווט רך מפעיל ניווט רך כשמתרחשים הדברים הבאים:
- מתרחשת אינטראקציה של משתמש,
- … מה שמוביל לציור גלוי של התוכן למשתמש,
- … ומתבצע עדכון של כתובת ה-URL.
הגישה הזו נבחרה ב-API במקום לאפשר ל-JavaScript framework "לפלוט" ניווט רך, או להסתמך על Navigation API, משתי סיבות:
- קודם כל, זה כולל את כל אתרי ה-SPA הקיימים בלי שנדרשים שינויים באתרים האלה.
- שנית, הוא מאפשר להבין באופן עקבי מהי ניווט רך, בלי קשר לאופן שבו מסגרת או מפתח מטפלים בניווטים.
פלטפורמות או מפתחים יכולים לעדכן את כתובת ה-URL של ניווט רך גם בלי אינטראקציה של המשתמש או עדכון של ה-DOM שהמשתמשים יחשיבו כניווט. הם יכולים גם לעדכן את כתובת ה-URL בזמנים שונים: בתחילת האינטראקציה, רק בסוף כשהיא מסתיימת, או בכל שלב ביניהם.
במקום להסתמך על מסגרת ועל בחירות של מפתחים, בניית זיהוי של ניווט רך בדפדפן יוצרת הגדרה קנונית שמאפשרת מדידה של Core Web Vitals עבור ניווטים רכים בהיקף נרחב, והשוואה של המדידות האלה בהיקף נרחב.
גם מסגרות ומפתחים יכולים להתעלם מ-Soft Navigations API ולהשתמש ב-Event Timing, ב-Layout Instability APIs וב-InteractionContentfulPaint performance entry החדש כדי למדוד מדדי ביצועים נוספים לפי בחירתם. עם זאת, מומלץ להשתמש ב-API למדידת מדדי Core Web Vitals כדי לאפשר מדידה עקבית באתרים ובכלים.
נדרשת עזרה בבדיקה של Soft Navigation API
אנחנו צריכים את העזרה שלך כדי לבדוק את Soft Navigations API ולקבוע אם הוא תואם לציפיות שלך לגבי מקרים שבהם מתרחשת ניווט רך. האם ה-API לא מדווח על מעברים רכים כשאתם חושבים שהם התרחשו? לחלופין, האם ה-API מדווח על יותר מדי ניווטים שלדעתכם לא נחשבים ניווטים?
מה השתנה מאז גרסת המקור לניסיון הקודמת
השינוי העיקרי באיטרציה האחרונה הזו הוא הפרדה של InteractionContentfulPaint מהניווטים הרכים כדי לאפשר תרחישי שימוש אחרים לרשומה הזו של הביצועים, והוספה של מאפיין largestInteractionContentfulPaint ל-SoftNavigationEntry.
מנקודת המבט של האתר, ה-API כולל עכשיו גם replaceState כמעברים רכים, כי קיבלנו מכם משוב שלפיו חשוב להתייחס לזה כאל מעבר בנסיבות רבות. נשמח לשמוע על מקרים נוספים שבהם ה-API לא מזהה ניווט רך.
ביצענו גם שיפורים רבים אחרים בהטמעה. אם אתם רוצים לדעת בדיוק מה השתנה בגרסה האחרונה, תוכלו לעיין בהיסטוריה המפורטת של כל השינויים ביומן השינויים של Soft Navigations.
אנחנו רוצים שה-API יהיה שימושי ככל האפשר, ומוכנים לבצע בו שינויים נוספים כדי להשיג את המטרה הזו. הרבה יותר קל להטמיע שינויים ב-API לפני ההשקה שלו ולפני שהאתרים מתחילים להסתמך על הטמעה. לכן, אנחנו מבקשים ממפתחי SPA ומכל מי שמעוניין למדוד את ביצועי האתרים האלה לבדוק את ה-API הזה ולספק עליו משוב.
איך בודקים
אפשר לבדוק את ה-API באופן מקומי באמצעות תכונות ניסיוניות של Chrome או אפשרויות של שורת הפקודה. בנוסף, אפשר לבדוק את התכונה בשטח באמצעות גרסת מקור לניסיון (מידע נוסף על גרסאות מקור לניסיון).
פרטים טכניים נוספים על ה-API, במיוחד איך למדוד את Core Web Vitals, זמינים במסמכים שלנו או במאגר ב-GitHub.
בנוסף, ב-GitHub וב-npm זמינה גרסת ניסוי של ספריית web-vitals עם ניווט רך.
כדי לבצע בדיקה פשוטה יותר, החל מ-Chrome 145, בחלונית Performance של כלי הפיתוח ל-Chrome מוצגת ניווט רך במעקב אחר ביצועים, גם בלי להפעיל את התכונה:
משוב
משוב על ה-API צריך להישלח כבעיות ב-GitHub, ודיווח על באגים בהטמעה של Chromium צריך להישלח דרך מעקב הבעיות של Chrome. אם אתם לא בטוחים לאיזו קטגוריה המשוב שייך, אל דאגה. אנחנו מעדיפים לקבל משוב באחד מהמקומות האלה, ונמיין את הבעיות בשני המקומות ונפנה אותן למיקום הנכון.