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

Barry Pollard

Michal Mocny

תאריך פרסום: 1 בפברואר 2023, תאריך עדכון אחרון: 20 בספטמבר 2026

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

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

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

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

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

מה זה ניווט רך?

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

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

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

תמיכה בכלי הפיתוח לניווטים רכים

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

איך 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.

זיהוי תכונות לתמיכה ב-Soft Navigations 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 באמצעות ניווטים "רכים".

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

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

המדד LCP לניווטים קלים (מחושב מ-interaction-contentful-paint) ימדוד רק רינדורים חדשים, ורק רינדורים שמשויכים לאינטראקציה שגרמה לניווט. כתוצאה מכך, יכול להיות הבדל בין ה-LCP של טעינה מההתחלה (cold load) של הניווט החלקי לבין ה-LCP של טעינה חלקית (soft 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 נפרדים לשיטה החדשה.

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

שימוש בספרייה 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 ברשומות שסופקו לקריאה החוזרת (callback).

הספרייה web-vitals מדווחת על המדדים הבאים של ניווטים דינמיים:

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

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

איך המעברים החלקים ידווחו ב-CrUX?

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

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

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

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

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

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

משוב

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

• משוב על ה-API צריך להעלות כבעיות ב-GitHub.
• אם נתקלתם בבאגים בהטמעה של Chromium, אתם יכולים לדווח עליהם ב-Issue Tracker של Chrome, אם הם עדיין לא מופיעים ברשימת הבעיות הידועות.
• אפשר לשלוח משוב כללי על מדדי חוויית המשתמש לכתובת web-vitals-feedback@googlegroups.com.

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

יומן שינויים

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

סיכום

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

תודות

התמונה הממוזערת צולמה על ידי ג'ורדן מדריד ופורסמה ב-Unsplash

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