מדידת מעברים רכים בין דפים

Barry Pollard

Michal Mocny

פורסם: 1 בפברואר 2023, עדכון אחרון: 2 בספטמבר 2026

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

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

הרבה מסגרות JavaScript משתמשות במודל הזה, אבל כל אחת בדרך אחרת. מכיוון שהפעולה הזו לא נכללת במה שהדפדפן מזהה באופן מסורתי כ'דף', תמיד היה קשה למדוד אותה: איפה עובר הגבול בין אינטראקציה בדף הנוכחי לבין התייחסות לפעולה הזו כאל דף חדש?

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

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

מהי ניווט רך?

הגדרנו את המושג ניווט רך באופן הבא:

• הניווט מתחיל בעקבות פעולה של משתמש.
• הניווט מוביל לשינוי גלוי בכתובת ה-URL עבור המשתמש.
• האינטראקציה גורמת לציור גלוי.

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

תמיכה בניווט רך בכלי DevTools

הוספנו תמיכה בניווטים רכים לחלונית הביצועים בכלי הפיתוח בתצוגה מדדים בזמן אמת, ובתצוגת המעקב עם תובנות ותמיכה בסמנים:

איך Chrome מטמיע ניווטים רכים למפתחי אתרים?

אחרי שמפעילים את התכונה 'ניווט רך' (מידע נוסף על כך מופיע בקטע הבא), Chrome ישנה את האופן שבו הוא מדווח על חלק ממדדי הביצועים:

• אירוע soft-navigation PerformanceTiming יופק אחרי שזוהה כל ניווט רך.
• הערך soft-navigation יכלול את navigationId, את כתובת ה-URL החדשה במאפיין name ואת interactionId של האינטראקציה הראשונית.
• אחרי אינטראקציות שגורמות לציור עם תוכן, יופקו רשומה אחת או יותר של interaction-contentful-paint. הוא יכיל רשומה של largestContentfulPaint שאפשר להשתמש בה כדי למדוד את המהירות שבה נטען רכיב התוכן הכי גדול (LCP) עבור ניווטים רכים.
• המאפיין navigationId מתווסף לכל אחד מהתזמונים של הביצועים (first-paint,‏ first-contentful-paint,‏ largest-contentful-paint,‏ interaction-contentful-paint,‏ first-input-delay,‏ event ו-layout-shift). המאפיין הזה תואם לרשומה של הניווט שבה האירוע הופק. שימו לב: אם הרשומות האלה מתייחסות לניווטים רכים, הן עשויות להכיל את הערך הקודם או הבא של navigationId, בהתאם למועד יצירת הרשומה. מידע נוסף על כך מופיע בקטע דיווח המדדים ביחס לכתובת ה-URL המתאימה.
• הפונקציה soft-navigation תכלול פונקציה getLargestInteractionContentfulPaint() לאחזור הערך הגדול ביותר של interaction-contentful-paint עבור הניווט הזה. אפשר להשתמש בערך הזה כערך LCP הראשוני של הניווט הזה, ואז לעדכן את ערך ה-LCP ככל שמתקבלות עוד רשומות interaction-contentful-paint של האינטראקציה הזו. הערה: המאפיין הזה מחליף מאפיין largestInteractionContentfulPaint שהיה זמין בניסויי מקור קודמים.
• יכול להיות שחלק מהערכים של interaction-contentful-paint יתרחשו לפני הניווט הרך (אם עדכון כתובת ה-URL לא יקרה עד אחרי הצביעות האלה). במקרים כאלה, הפונקציה getLargestInteractionContentfulPaint() לא צריכה לבצע אחסון זמני (באפרינג) ולחפש רשומות ישנות אחרי סיום הניווט הרך. שימו לב שהערך שמוחזר על ידי getLargestInteractionContentfulPaint() הוא עותק מדויק של הערך הכי גדול של interaction-contentful-paint בזמן הפליטה, ולכן יכול להיות שהערך הזה השתמש ב-navigationId הקודם כי זה הזמן שבו התרחש הציור, אבל צריך למדוד את הציורים האלה לפי navigationId החדש.
• הערך soft-navigation יכלול גם את הערכים paintTime ו-presentationTime כערכי ה-FCP של הניווט הזה.
• חשוב לדעת שגם אחרי אינטראקציות נוספות ייפלטו ערכים של interaction-contentful-paint, אבל כדי לא לכלול אותם, צריך להגביל את LCP של כתובת URL לערכים של interaction-contentful-paint שתואמים לניווטים הרכים interactionId, וגם רק למאפיינים של largestContentfulPaint בתוך הניווטים האלה.

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

מהן ההשלכות של הפעלת מעברים רכים ב-Chrome?

אלה חלק מהשינויים שבעלי אתרים צריכים לקחת בחשבון אחרי שמפעילים את התכונה הזו:

• מעקב אחרי רשומות soft-navigation מאפשר 'לפלח' את רשומות הביצועים לכל 'ניווט'.
• כבר עכשיו אפשר לפלח את המדדים CLS ו-INP לפי שיקול דעתכם, במקום למדוד אותם לאורך כל מחזור החיים של הדף. אבל התכונה 'ניווט רך' מספקת מדד סטנדרטי של מתי זה קורה, בלי קשר לטכנולוגיה הבסיסית שבה נעשה שימוש.
• הערך של largest-contentful-paint נקבע סופית באינטראקציה (שנדרשת כדי להתחיל ניווט רך), ולכן אפשר להשתמש בו רק כדי למדוד את ה-LCP של הניווט הראשוני 'הקשה'. המשמעות היא שהערך הזה לא ישתנה כשמודדים ניווטים רכים, כך שאפשר למדוד את LCP לטעינת הדף של הניווט הקשיח הראשוני, כמו תמיד.
• אפשר להשתמש בערך החדש interaction-contentful-paint שיוחזר מאינטראקציות כדי למדוד את מדד LCP עבור מעברים רכים בין דפים. לשם כך, צריך לבדוק את המאפיין largestContentfulPaint בערך הזה. עם זאת, יש כמה שיקולים לגבי אופן השימוש בערך הזה, ונדון בהם במאמר הזה.
• שימו לב שלא כל המשתמשים יוכלו להשתמש בתכונה הזו של ניווט רך, במיוחד משתמשים בדפדפנים אחרים או בגרסאות של Chrome לפני גרסה 151. חשוב לדעת שיש משתמשים שלא מדווחים על מדדים שמבוססים על ניווט רך, גם אם הם מדווחים על Core Web Vitals.

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

מידע נוסף על מדידת המדדים של מעברים רכים זמין בקטע מדידת Core Web Vitals לפי מעברים רכים.

איך מפעילים ניווטים רכים ב-Chrome?

התכונה 'מעברים רכים' מופעלת כברירת מחדל החל מגרסה 151 של Chrome.

זיהוי תמיכה ב-API של ניווטים רכים

אפשר להשתמש בקוד הבא כדי לבדוק אם ה-API נתמך:

if (PerformanceObserver.supportedEntryTypes.includes('soft-navigation')) {
  // Monitor Soft Navigations
}

אפשרות נוספת:

if ('SoftNavigationEntry' in window) {
  // Monitor Soft Navigations
}

איך אפשר למדוד מעברים רכים?

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

דיווח על ניווטים רכים

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

const observer = new PerformanceObserver(console.log);
observer.observe({ type: "soft-navigation", buffered: true });

אפשר להשתמש בזה כדי להשלים את המדדים של הדף הקודם בניווט.

דיווח על המדדים ביחס לכתובת ה-URL המתאימה

כשמתרחשת ניווט רך, צריך לסיים את המדידה של Core Web Vitals בדף הקודם, לדווח עליהם עבור כתובת ה-URL הקודמת ולהתחיל מדידה חדשה עבור כתובת ה-URL החדשה.

המאפיין name של הרשומה המתאימה soft-navigation יכיל את כתובת ה-URL החדשה שאליה יש לדווח על מדדים, והמאפיין navigationId יהיה ההפניה הייחודית לניווט הזה (כי יכול להיות שכתובת ה-URL תהיה זהה לכמה דפים באפליקציית דף יחיד).

צריך להגדיר את הערך הזה כערך של כל רשומה מסוג soft-navigation ולהשתמש בו כדי לדווח על מדדים עד לקבלת הרשומה הבאה מסוג soft-navigation.

דיווח על כתובת ה-URL הנכונה של interaction-contentful-paint

כדי לחשב את ה-LCP מתוך רשומות interaction-contentful-paint, צריך לקחת בחשבון עוד כמה דברים, כי לא כל רשומות interaction-contentful-paint צריכות להיות ממופות באמצעות navigationId ומדווחות כ-LCP עבור כתובת ה-URL הזו:

• הבעיה הראשונה היא שאולי פריטי interaction-contentful-paint יופקו לפני הניווט הרך אם מתבצע רינדור לפני עדכון כתובת ה-URL. במקרים כאלה, הנתונים של navigationId יהיו עבור כתובת ה-URL הישנה. אם כתובת ה-URL מתעדכנת קודם, הציור ישלים את הניווט הרך ובמקרה כזה הרשומה soft-navigation תופק קודם, ולרשומה interaction-contentful-paint תהיה כתובת ה-URL החדשה.
• הבעיה השנייה היא שinteraction-contentful-paint, רשומות ימשיכו להיפלט לאינטראקציות חדשות יותר, כי ההיקף של מדד לבדיקת ביצועים זה חורג מעבר ל-LCP עבור ניווטים רכים. אנחנו רוצים להביא בחשבון רק את הציורים של טעינת הניווט הרך בשביל LCP, ולא את אלה של אינטראקציות עוקבות.

לכן, צריך להשתמש ב-interactionId ולא ב-navigationId כדי למפות רשומות של interaction-contentful-paint ל-soft-navigation-entries ולקבל את כתובת ה-URL הנכונה. הפעולה הזו תטפל בכל הערכים עם navigationId ישנים, ותסנן את כל הערכים של interaction-contentful-paint שלא צריכים להיכלל בחישוב של LCP.

בנוסף, כדאי לעבד קודם את הפונקציה getLargestInteractionContentfulPaint() של רשומות soft-navigation, כדי לטפל ברשומות interaction-contentful-paint שהתרחשו לפני הפעלת soft-navigation entries.

קבלת startTime של ניווטים רכים

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

אפשר לקבל את שעת ההתחלה של הניווט באופן דומה על ידי מיפוי לרשומה המתאימה soft-navigation ושימוש ב-startTime שלה.

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

מדידת Core Web Vitals לכל ניווט רך

כדי למדוד את Core Web Vitals, צריך להאזין לרשומות soft-navigation ולאפס את המדדים כשמקבלים אותן. אפשר להפיק את FCP על סמך הערך presentationTime, ואפשר לאתחל את LCP לערך getLargestInteractionContentfulPaint(). הערכים של INP ו-CLS צריכים להיות מאותחלים ל-0, כמו בטעינת דף.

אחרי כן אפשר למדוד ולעקוב אחרי LCP, ‏ INP ו-CLS כרגיל (למעט שימוש ב-interaction-contentful-paint עבור LCP, בתנאי ש-interactionId תואם). אפשר להשתמש ב-interactionId כדי לתת שם לרשומות של כתובת URL, כפי שהוסבר קודם.

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

באופן מסורתי, חלק מהמדדים נמדדים לאורך כל משך החיים של הדף: לדוגמה, ערך ה-LCP יכול להשתנות עד להתרחשות אינטראקציה. אפשר לעדכן את ערכי ה-CLS וה-INP עד ליציאה מהדף, ללא קשר לאינטראקציות. לכן, המדדים של הניווט הקודם צריכים להיות סופיים בכל פעם שמתבצע ניווט רך חדש. המשמעות היא שהמדדים הראשוניים של ניווט 'קשה' עשויים להיות סופיים מוקדם מהרגיל כשמודדים את Core Web Vitals באמצעות ניווטים 'רכים'.

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

איך צריך להתייחס לתוכן שנשאר זהה בין ניווטים?

הערך LCP עבור מעברים רכים (מחושב מ-interaction-contentful-paint) ימדוד רק צביעות חדשות, ורק צביעות שמשויכות לאינטראקציה שגרמה למעבר. כך יכול להיות שערך ה-LCP יהיה שונה מהפעלה מההתחלה (cold load) של הניווט הרך הזה לטעינה רכה.

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

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

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

איך מודדים TTFB?

הזמן שחולף עד שהבייט הראשון מגיע (TTFB) בטעינה רגילה של דף מייצג את הזמן שחולף עד שהבייטים הראשונים של הבקשה המקורית מוחזרים.

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

שיטה פשוטה יותר היא לדווח על TTFB של 0 לניווטים רכים – בדומה למה שמומלץ לגבי שחזורים של מטמון לדף הקודם/הבא. זו השיטה שבה נעשה שימוש בספריית web-vitals לניווטים רכים, וזו השיטה שאנחנו ממליצים להשתמש בה למדד הזה בשלב הזה.

האם כדאי למדוד את Core Web Vitals באמצעות שתי המתודולוגיות?

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

לכן, כשמדובר ב-LCP, צריך להתייחס רק ל-largest-contentful-paint רשומות בשיטה הנוכחית, ול-largest-contentful-paint ו-interaction-contentful-paint רשומות בשיטה החדשה.

במקרה של CLS ו-INP, המשמעות היא מדידה של המדדים האלה לאורך מחזור החיים של הדף, כמו במדידה הנוכחית, ופיצול ציר הזמן לפי מעברים רכים כדי למדוד ערכי CLS ו-INP נפרדים למעברים החדשים.

לאחר מכן, צריך לשלוח את המדדים באמצעות Beacon ולשמור אותם פעמיים לצורך ניתוח.

שימוש בספריית web-vitals למדידת מדדי חוויית המשתמש הבסיסיים (Core Web Vitals) בניווטים רכים

הדרך הקלה ביותר להתחשב בכל הניואנסים היא להשתמש בספריית JavaScript‏ web-vitals, שתומכת בניווטים רכים החל מגרסה 6.0.0. אפשר למדוד את זה בדרך הבאה (צריך להחליף את doTraditionalProcessing ואת doSoftNavProcessing לפי הצורך):

import {
  onTTFB,
  onFCP,
  onLCP,
  onCLS,
  onINP,
} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';

function doTraditionalProcessing(callback) {
  ...
}

function doSoftNavProcessing(callback) {
  ...
}

onTTFB(doTraditionalProcessing);
onFCP(doTraditionalProcessing);
onLCP(doTraditionalProcessing);
onCLS(doTraditionalProcessing);
onINP(doTraditionalProcessing);

onTTFB(doSoftNavProcessing, {reportSoftNavs: true});
onFCP(doSoftNavProcessing, {reportSoftNavs: true});
onLCP(doSoftNavProcessing, {reportSoftNavs: true});
onCLS(doSoftNavProcessing, {reportSoftNavs: true});
onINP(doSoftNavProcessing, {reportSoftNavs: true});

בנוסף, ספריית web-vitals מוודאת שהמדדים מדווחים ביחס לכתובת ה-URL הנכונה כמו שצוין קודם, כי היא כוללת גם את navigationId וגם את navigationURL ברשומות שמועברות לקריאה החוזרת.

ספריית web-vitals מדווחת על המדדים הבאים לגבי מעברים רכים:

האם השינויים האלה יהפכו לחלק מהמדדים של Core Web Vitals?

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

איך ידווחו ניווטים רכים ב-CrUX?

עדיין לא ברור איך בדיוק ידווחו ניווטים רכים ב-CrUX אחרי השקת התכונה. נפרסם כאן הודעה על השינויים ב-CrUX כשיתווסף מידע.

איך מטפלים בניווטים רכים בדפדפנים אחרים?

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

אפשר להשתמש ב-Navigation API כדי לעקוב אחרי שינויים בכתובות URL, וכך לפלח את מדד ה-INP לפי כתובת URL (באופן דומה אפשר לפלח את מדד ה-CLS, אבל נכון לעכשיו הוא זמין רק ב-Chromium ולכן לא יימדד בכל מקרה). עם זאת, זה לא פותר את הבעיה של מדדי הציור (FCP ו-LCP), שאפשר רק להעריך אותם.

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

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

משוב

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

• משוב על ה-API צריך להישלח כבעיות ב-GitHub.
• אם הבעיה לא מופיעה בבעיות הידועות, צריך לדווח עליה במעקב אחר בעיות ב-Chrome.
• אפשר לשתף משוב כללי על מדדים בסיסיים של חוויית המשתמש בכתובת web-vitals-feedback@googlegroups.com.

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

יומן שינויים

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

סיכום

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

תודות

תמונה ממוזערת מאת Jordan Madrid ב-Unsplash

העבודה הזו היא המשך של עבודה שהתחילה על ידי יואב וייס כשהוא עבד ב-Google. אנחנו מודים ליואב על המאמצים שלו בנוגע ל-API הזה.