דף זה תורגם על ידי Cloud Translation API.

מטמון לדף הקודם והבא

Philip Walton

Barry Pollard

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

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

תאימות דפדפן

bfcache נתמכת ב-Firefox וב-Safari במשך שנים רבות, במחשבים ובניידים.

החל מגרסה 86, Chrome תומך במטמון לדף הקודם/הבא לניווט בין אתרים ב-Android לאחוז קטן מהמשתמשים. בגרסאות הבאות, התמיכה הנוספת הושקה בהדרגה. מגרסה 96, ההגדרה bfcache מופעלת לכל משתמשי Chrome במחשבים ובניידים.

מידע בסיסי על bfcache

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

בסרטון הבא אפשר לראות עד כמה מטמון לדף הקודם/הבא יכול לזרז את הניווט:

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

נתוני השימוש ב-Chrome מראים ש-1 מכל 10 ניווטים במחשב ו-1 מכל 5 ניווטים בנייד הם אחורה או קדימה. לכן ל-bfcache יש פוטנציאל לחסוך הרבה זמן ושימוש בנתונים.

איך פועל 'מטמון'

'מטמון' שבו נעשה שימוש ב-bfcache שונה ממטמון HTTP, שתפקידו להאצת הניווטים החוזרים. bfcache הוא תמונת מצב של כל הדף בזיכרון, כולל ערימת ה-JavaScript, ואילו מטמון ה-HTTP מכיל רק את התגובות לבקשות קודמות. מכיוון שזה נדיר מאוד בכל הבקשות לטעון דף כדי שיהיה ניתן למלא אותו ממטמון ה-HTTP, ביקורים חוזרים באמצעות שחזור bfcache תמיד מהירים יותר מהניווטים הטובים ביותר שאינם מטמון לדף הקודם/הבא.

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

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

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

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

המטמון לדף הקודם/הבא ואפליקציות בדף יחיד (SPA)

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

ממשקי API לצפייה במטמון לדף הקודם/הבא

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

האירועים העיקריים שמשמשים לצפייה במטמון לדף הקודם/הבא הם אירועי מעבר דפים pageshow ו-pagehide, שנתמכים על ידי רוב הדפדפנים.

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

לראות מתי דף משוחזר ממטמון לדף הקודם/הבא

האירוע pageshow מופעל מיד אחרי האירוע load כשהדף נטען לראשונה ובכל פעם שהדף שוחזר מהמטמון לדף הקודם/הבא. לאירוע pageshow יש מאפיין persisted, שהוא true אם הדף שוחזר מהמטמון לדף הקודם/הבא וגם false. אפשר להשתמש במאפיין persisted כדי להבחין בין טעינות דפים רגילות לבין שחזורים של מטמון לדף הקודם/הבא. למשל:

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    console.log('This page was restored from the bfcache.');
  } else {
    console.log('This page was loaded normally.');
  }
});

בדפדפנים שתומכים ב-Page Lifecycle API, האירוע resume מופעל כשדפים משוחזרים מהמטמון לדף הקודם/הבא (מיד לפני האירוע pageshow) וכשמשתמש נכנס שוב לכרטיסיית רקע שקופאת ברקע. אם רוצים לעדכן מצב של דף אחרי שהוא קפוא (כולל דפים במטמון לדף הקודם/הבא), אפשר להשתמש באירוע resume, אבל אם רוצים למדוד את שיעור ההיטים של המטמון לדף הקודם/הבא של האתר, צריך להשתמש באירוע pageshow. במקרים מסוימים, יכול להיות שתצטרכו להשתמש בשניהם.

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

לראות מתי דף עובר למטמון לדף הקודם/הבא

האירוע pagehide מופעל כשמתבצעת הסרה של דף שנטענו או כשהדפדפן מנסה להוסיף אותו למטמון לדף הקודם/הבא.

לאירוע pagehide יש גם נכס persisted. אם מדובר ב-false, תוכלו להיות בטוחים שדף זה לא עומד להיכנס למטמון לדף הקודם/הבא. עם זאת, הערך persisted שמופיע ב-true לא מבטיח שדף מסוים יישמר במטמון. המשמעות היא שהדפדפן intends לשמור את הדף במטמון, אבל ייתכן שיש גורמים אחרים שבגללם לא ניתן לשמור אותו במטמון.

window.addEventListener('pagehide', (event) => {
  if (event.persisted) {
    console.log('This page *might* be entering the bfcache.');
  } else {
    console.log('This page will unload normally and be discarded.');
  }
});

באופן דומה, האירוע freeze מופעל מיד אחרי האירוע pagehide אם persisted הוא true, אבל המשמעות היא רק שהדפדפן intends לשמור את הדף במטמון. יכול להיות שהוא עדיין יצטרך למחוק אותה, מכמה סיבות שמפורטות בהמשך.

אופטימיזציה של הדפים למטמון לדף הקודם/הבא

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

שימוש ב-`pagehide` במקום ב-`unload`

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

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

במחשב, ב-Chrome וב-Firefox, דפים עם מאזינים של unload לא עומדים בדרישות לשמירה במטמון לדף הקודם/הבא, מה שמפחית את הסיכון אבל גם גורם לדפים רבים לא להישמר במטמון, ולכן נטען מחדש לאט יותר. מערכת Safari מנסה לשמור חלק מהדפים במטמון עם פונקציות event listener של unload, אבל כדי לצמצם את הסיכון לשיבושים, היא לא מריצה את האירוע unload כשמשתמש מנווט למקום אחר, וכתוצאה מכך מאזינים של unload לא מהימנים.

בנייד, Chrome ו-Safari מנסים לשמור דפים במטמון עם פונקציות event listener של unload, כי חוסר האמינות של unload בנייד מקטין את הסיכון לשיבושים. ב-Firefox לנייד, דפים שנעשה בהם שימוש ב-unload נחשבים לדפים שלא מתאימים לשמירה במטמון לדף הקודם/הבא, למעט ב-iOS, שבו כל הדפדפנים צריכים להשתמש במנוע הרינדור WebKit, ולכן ההתנהגות שלו תהיה זהה ל-Safari.

כדי לקבוע אם JavaScript בדפים שלכם משתמש ב-unload, מומלץ להשתמש בביקורת no-unload-listeners ב-Lighthouse.

למידע על התוכנית של Chrome להוצאה משימוש של unload, קראו את המאמר הוצאה משימוש של אירוע הסרת הנתונים שנטענו.

שימוש במדיניות הרשאות כדי למנוע שימוש ב-handlers שנטענו בדף

יש סקריפטים ותוספים של צד שלישי שיכולים להוסיף לדף רכיבי handler של הסרת נתונים שנטענו לדף, וכתוצאה מכך האתר לא יהיה כשיר לשמירה במטמון לדף הקודם/הבא. כדי למנוע זאת ב-Chrome בגרסה 115 ואילך, צריך להשתמש במדיניות הרשאות.

Permission-Policy: unload()

הוספת `beforeunload` מאזינים בלבד לפי תנאי

בעקבות האירוע beforeunload, הדפים שלך לא עומדים בדרישות לשמירה במטמון לדף הקודם/הבא. עם זאת, היא לא אמינה, ולכן מומלץ להשתמש בה רק כאשר זה הכרחי.

לדוגמה, בתרחיש beforeunload מוצגת אזהרה למשתמש לגבי שינויים שלא נשמרו, הוא יאבד אם הוא יעזוב את הדף. במקרה זה, מומלץ להוסיף פונקציות beforeunload listener רק אם למשתמש יש שינויים שלא נשמרו, ולאחר מכן להסיר אותם מיד לאחר שהשינויים שלא נשמרו נשמרים, כמו בקוד הבא:

function beforeUnloadListener(event) {
  event.preventDefault();
  return event.returnValue = 'Are you sure you want to exit?';
};

// A function that invokes a callback when the page has unsaved changes.
onPageHasUnsavedChanges(() => {
  window.addEventListener('beforeunload', beforeUnloadListener);
});

// A function that invokes a callback when the page's unsaved changes are resolved.
onAllChangesSaved(() => {
  window.removeEventListener('beforeunload', beforeUnloadListener);
});

צמצום השימוש ב-`Cache-Control: no-store`

Cache-Control: no-store הוא כותרת HTTP ששרתי אינטרנט יכולים להגדיר בתגובה לתגובות, שמנחה את הדפדפן לא לשמור את התגובה באף מטמון HTTP. השירות משמש למשאבים שמכילים מידע רגיש על המשתמש, כמו דפים מאחורי פרטי התחברות.

אמנם bfcache הוא לא מטמון HTTP, אבל בעבר דפדפנים לא כללו דפים ממטמון לדף הקודם/הבא כש-Cache-Control: no-store מוגדר במשאב הדף (אבל לא בכל משאב משנה). ב-Chrome אנחנו פועלים לשינוי ההתנהגות הזו תוך שמירה על פרטיות המשתמשים, אבל כברירת מחדל, דפים שמשתמשים ב-Cache-Control: no-store לא מתאימים לשמירה במטמון לדף הקודם/הבא.

כדי לבצע אופטימיזציה למטמון לדף הקודם/הבא, כדאי להשתמש ב-Cache-Control: no-store רק בדפים שמכילים מידע רגיש שלא ניתן לשמור במטמון.

אם רוצים להציג תמיד תוכן עדכני אבל לא כוללים מידע רגיש, צריך להשתמש ב-Cache-Control: no-cache או ב-Cache-Control: max-age=0. הם מורים לדפדפן לאמת מחדש את התוכן לפני הצגתו, והן לא משפיעות על הכשירות של דף bfcache, כי שחזור דף מ-bfcache לא כולל את המטמון של HTTP.

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

עדכון של מידע לא פעיל או רגיש אחרי שחזור bfcache

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

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

כדי למנוע מצבים כאלה, תמיד צריך לעדכן את הדף אחרי אירוע pageshow אם event.persisted הוא true:

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    // Do any checks and updates to the page
  }
});

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

window.addEventListener('pageshow', (event) => {
  if (event.persisted && !document.cookie.match(/my-cookie)) {
    // Force a reload if the user has logged out.
    location.reload();
  }
});

שחזור מודעות ומטמון לדף הקודם/הבא

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

באתרים שרוצים לרענן מודעות בשחזור המטמון לדף הקודם/הבא, אפשר לרענן רק את המודעות באירוע pageshow כאשר event.persisted הוא true בלי להשפיע על ביצועי הדף, כמו בדוגמה הזו של תג Google Publishing. למידע נוסף על השיטות המומלצות לאתר שלכם, פנו לספק המודעות.

הימנעות מהפניות של `window.opener`

בדפדפנים ישנים, אם דף נפתח באמצעות window.open() מקישור עם target=_blank, בלי לציין rel="noopener", הדף הפותח יכלול הפניה לאובייקט החלון של הדף הפתוח.

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

כדי להימנע מהסיכונים האלה, צריך להשתמש ב-rel="noopener" על מנת למנוע יצירה של קובצי עזר מסוג window.opener. זוהי התנהגות ברירת המחדל בכל הדפדפנים המודרניים. אם באתר שלכם צריך לפתוח חלון ולשלוט בו באמצעות window.postMessage() או על ידי הפניה ישירה לאובייקט החלון, גם החלון הפתוח וגם חלון הפתיחה לא עומדים בדרישות לשמירה במטמון לדף הקודם/הבא.

סגירת החיבורים הפתוחים לפני שהמשתמש מנווט למקום אחר

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

אם המשימות המתוזמנות האלה של JavaScript ניגשות רק ל-DOM APIs או לממשקי API אחרים שמבודדים את הדף הנוכחי, השהיית המשימות האלה בזמן שהדף לא גלוי למשתמש לא גורם לבעיות.

עם זאת, במקרה שהמשימות האלה מקושרות לממשקי API שניתן לגשת אליהם גם מדפים אחרים באותו מקור (לדוגמה: IndexedDB, Web Lock ו-WebSockets), השהיה שלהם עלולה לשבש את הדפים האלו, על ידי מניעת ההפעלה של קוד בדפים האלה.

כתוצאה מכך, דפדפנים מסוימים לא ינסו להוסיף דף למטמון לדף הקודם/הבא אם הוא מכיל אחד מהמצבים הבאים:

חיבור IndexedDB פתוח
בתהליך fetch() או XMLHttpRequest
חיבור פתוח של WebSocket או WebRTC

אם בדף נעשה שימוש באחד מממשקי ה-API האלה, מומלץ מאוד לסגור את החיבורים ולהסיר או לנתק צופים במהלך האירוע pagehide או freeze. כך הדפדפן יכול לשמור את הדף במטמון באופן בטוח, בלי להסתכן בהשפעה על כרטיסיות פתוחות אחרות. לאחר מכן, אם הדף שוחזר מהמטמון לדף הקודם/הבא, תוכלו לפתוח מחדש את ממשקי ה-API האלה או להתחבר אליהם מחדש במהלך האירוע pageshow או resume.

הדוגמה הבאה ממחישה איך לוודא שדפים שמשתמשים ב-IndexedDB עומדים בדרישות לשמירה במטמון לדף הקודם/הבא על ידי סגירת חיבור פתוח בהאזנה לאירוע של pagehide:

let dbPromise;
function openDB() {
  if (!dbPromise) {
    dbPromise = new Promise((resolve, reject) => {
      const req = indexedDB.open('my-db', 1);
      req.onupgradeneeded = () => req.result.createObjectStore('keyval');
      req.onerror = () => reject(req.error);
      req.onsuccess = () => resolve(req.result);
    });
  }
  return dbPromise;
}

// Close the connection to the database when the user leaves.
window.addEventListener('pagehide', () => {
  if (dbPromise) {
    dbPromise.then(db => db.close());
    dbPromise = null;
  }
});

// Open the connection when the page is loaded or restored from bfcache.
window.addEventListener('pageshow', () => openDB());

בדיקה כדי לוודא שניתן לשמור את הדפים

בעזרת כלי הפיתוח ל-Chrome אפשר לבדוק את הדפים כדי לוודא שהם מותאמים למטמון לדף הקודם/הבא, ולזהות בעיות שעלולות למנוע את הכשירות שלהם.

כדי לבדוק דף:

עוברים לדף ב-Chrome.
בכלי הפיתוח, עוברים אל Application (אפליקציה) > Back-forward cache.
לוחצים על הלחצן הפעלת בדיקה. לאחר מכן, כלי הפיתוח מנסים לצאת מהדף ולחזור אליו, כדי לבדוק אם ניתן לשחזר את הדף מהמטמון לדף הקודם/הבא.

החלונית 'מטמון לדף הקודם/הבא' בכלי הפיתוח — החלונית **Back-forward cache** בכלי הפיתוח.

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

אם הסיבה היא משהו שאפשר לטפל בו כמפתח, החלונית תסומן כ-Actionable.

הדיווח של כלי הפיתוח נכשל בשחזור דף מהמטמון לדף הקודם/הבא — בדיקת bfcache נכשלה עם תוצאה שניתן לפעול לפיה.

בתמונה הזו, השימוש ב-event listener unload הופך את הדף ללא כשיר לשמירה במטמון לדף הקודם/הבא. כדי לפתור את הבעיה, אפשר לעבור מ-unload לשימוש ב-pagehide:

מה מותר לעשות

window.addEventListener('pagehide', ...);

מה אסור לעשות

window.addEventListener('unload', ...);

ב-Lighthouse 10.0 נוספה גם ביקורת bfcache, שמבצעת בדיקה דומה. למידע נוסף, אפשר לעיין במסמכי הביקורת של bfcache.

איך המטמון לדף הקודם/הבא משפיע על ניתוח נתונים ומדידת ביצועים

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

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

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

הדוגמה הבאה מראה איך לעשות זאת עם Google Analytics. סביר להניח שכלים אחרים לניתוח נתונים משתמשים בלוגיקה דומה:

// Send a pageview when the page is first loaded.
gtag('event', 'page_view');

window.addEventListener('pageshow', (event) => {
  // Send another pageview if the page is restored from bfcache.
  if (event.persisted) {
    gtag('event', 'page_view');
  }
});

מדידת יחס ההיטים של המטמון לדף הקודם/הבא

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

// Send a navigation_type when the page is first loaded.
gtag('event', 'page_view', {
   'navigation_type': performance.getEntriesByType('navigation')[0].type;
});

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    // Send another pageview if the page is restored from bfcache.
    gtag('event', 'page_view', {
      'navigation_type': 'back_forward_cache';
    });
  }
});

כדי לחשב את יחס ההיט של bfcache, המערכת משתמשת בספירות של ניווטים של back_forward ושל back_forward_cache ניווטים.

סיבות אפשריות לכך שניווט אחורה או קדימה לא ישתמש במטמון לדף הקודם/הבא, כוללות את התנהגות המשתמשים הבאה:

יציאה מהדפדפן והפעלה מחדש.
שכפול כרטיסייה.
סגירה ושחזור של כרטיסייה.

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

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

צוות Chrome עובד על NotRestoredReasons API כדי לחשוף את הסיבות לכך שדפים לא משתמשים במטמון לדף הקודם/הבא, כדי שהמפתחים יוכלו לשפר את שיעורי ההיטים של המטמון לדף הקודם/הבא.

מדידת ביצועים

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

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

יש כמה דרכים להתמודד עם הבעיה הזו. אחת הדרכים היא להוסיף הערות לכל מדדי טעינת הדף בהתאם לסוג הניווט שלהם: navigate, reload, back_forward או prerender. כך תוכלו להמשיך לעקוב אחרי הביצועים בסוגי הניווט האלה, גם אם ההתפלגות הכוללת משתנה לשלילית. הגישה הזו מומלצת למדדי טעינת דפים שלא מתמקדים במשתמש, כמו Time to First Byte (TTFB).

לגבי מדדים שמתמקדים במשתמש, כמו מדדי ליבה לבדיקת חוויית המשתמש באתר, עדיף לדווח על ערך שמייצג בצורה מדויקת יותר את חוויית המשתמש.

ההשפעה על מדדי הליבה לבדיקת חוויית המשתמש באתר

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

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

במאפיין המהירות שבה נטען רכיב התוכן הכי גדול (LCP), צריך להשתמש בדלטה בין חותמת הזמן של האירוע pageshow לבין חותמת הזמן של הפריים הבא, כי כל האלמנטים בתמונה ייצבעו באותו זמן. במקרה של שחזור bfcache, LCP ו-FCP זהים.
בקטע Interaction to Next Paint (INP), ממשיכים להשתמש במציג הביצועים הקיים, אבל מאפסים את ערך ה-CLS הנוכחי ל-0.
בCumulative Layout Shift (CLS), ממשיכים להשתמש במציג הביצועים הקיים, אבל מאפסים את ערך ה-CLS הנוכחי ל-0.

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

מקורות נוספים

שמירה במטמון ב-Firefox (bfcache ב-Firefox)
מטמון דף (bfcache ב-Safari)
מטמון לדף הקודם/הבא: התנהגות החשיפה באינטרנט (הבדלים במטמון לדף הקודם/הבא)
בודק bfcache (בודקים איך אירועים וממשקי API שונים משפיעים על bfcache בדפדפנים)
Performance Game Changer: מטמון לדף הקודם/הבא של הדפדפן (מקרה לדוגמה מ-Smashing Magazine שמציגים שיפורים דרמטיים במדדי הליבה לבדיקת חוויית המשתמש באתר על ידי הפעלת המטמון לדף הקודם/הבא)