פורסם: 21 באוקטובר 2024, עדכון אחרון: 9 בספטמבר 2025
אנחנו מבצעים שינוי ב-Chrome כדי לאפשר שימוש במטמון של חזרה קדימה (bfcache) בדפים שמשתמשים ב-Cache-Control: no-store, כשזה בטוח לעשות זאת. כאן אפשר לקרוא מה זה אומר למפתחים.
רקע
הגדרת Cache-Control: no-store ככותרת HTTP היא אות לכך שהדף לא צריך להישמר במטמון HTTP. צריך להשתמש בהנחיה הזו בדפים שמכילים נתונים רגישים – לדוגמה, בדפים שמוצגים למשתמשים כשהם מחוברים – אבל לעיתים קרובות משתמשים בהנחיה no-store בדפים שלא מכילים נתונים רגישים.
במקום להרוס דף כשמשתמש מנווט ממנו, אנחנו דוחים את ההרס ומשהים את הביצוע של JavaScript. אם המשתמש חוזר לדף במהירות, אנחנו הופכים את הדף לגלוי שוב ומבטלים את ההשהיה של ביצוע ה-JS. כך המשתמש יכול לנווט בין הדפים כמעט באופן מיידי.
למרות שאין דרישה כזו במפרט HTML, דפדפנים בדרך כלל מתייחסים ל-Cache-Control: no-store כאל אות להימנע מהצבת הדף במטמון לדף הקודם/הבא. זו הסיבה העיקרית לכך שלא נעשה שימוש במטמון הדפדפן, בכ-17% מהניווטים בהיסטוריה בנייד וב-7% מהניווטים בהיסטוריה במחשב. המשמעות היא שהדפים האלה לא נהנים מהשחזורים המהירים, והם צריכים לטעון מחדש את הדף באופן מלא, כולל קריאות לרשת, הפעלת JavaScript ועיבוד.
לרוב, הערך של Cache-Control: no-store מוגדר כדי למנוע בעיות במטמון כשהאתר משתנה, אבל הסיבה הזו פחות רלוונטית כשמשתמשים במטמון לדף הקודם/הבא, כי הדף המלא משוחזר כמעט כאילו הוא נשאר פתוח כל הזמן.
איך Chrome משנה את ההתנהגות הזו
ב-Chrome הודיעו על כוונה לשנות את ההתנהגות הזו, אבל הם נוקטים גישה זהירה לגבי השינוי הזה. אנחנו מריצים ניסויים מאז Chrome 116, ומגדילים בהדרגה את אחוז טעינות הדפים. אנחנו צופים שהאחוז הזה יגיע ל-100% במרץ ובאפריל 2025.
מידע אישי רגיש
הניתוח שלנו מראה שברוב המקרים של ניווט אחורה או קדימה לא נכללים נתונים רגישים, ולכן הדפים האלה אמורים להיות כשירים לשימוש במטמון לדף הקודם/הבא. עם זאת, יש מקרים שבהם לא כדאי להכניס דפים למטמון הזה. לדוגמה, אחרי התנתקות, לא אמורה להיות אפשרות לאחזר דף שבוצע בו לוגין באמצעות ניווט קדימה או אחורה.
כדי למנוע את זה, Chrome יסיר דף ממטמון הדפים הקודמים אם יחולו שינויים בקובצי Cookie או בשיטות הרשאה אחרות.
בנוסף, שימוש בממשקי ה-API הבאים בדפים שנעשה בהם שימוש ב-Cache-Control: no-store ימשיך למנוע את האפשרות לשמור את הדפים האלה במטמון לדף הקודם/הבא:
חשוב לשים לב: זו לא רשימה מלאה של ממשקי API שמונעים שימוש ב-bfcache, אלא רק של ממשקי ה-API שחוסמים את השימוש ב-bfcache בדפי Cache-Control: no-store גם אם הם לא בשימוש בזמן היציאה מהדף.
כדי לצמצם עוד יותר את הסיכון, גם הזמן הקצוב לתפוגה של המטמון לדף הקודם/הבא עבור דפי Cache-Control: no-store קוצר ל-3 דקות (לעומת 10 דקות בדפים שלא נעשה בהם שימוש ב-Cache-Control: no-store).
ביטול הסכמה ב-Enterprise
בארגונים יש לעיתים קרובות תוכנות שקשה לעדכן ומכשירים משותפים. אפשר להשבית את המדיניות AllowBackForwardCacheForCacheControlNoStorePageEnabled כדי להמשיך למנוע שימוש ב-bfcache בדפי Cache-Control: no-store.
בדיקת השינוי
מפתחים יכולים לבדוק את השינוי הזה באמצעות הדגל הבא:
--enable-features=CacheControlNoStoreEnterBackForwardCache:level/restore-unless-cookie-change
אם חל אחד מהחריגים הקודמים – למשל, שינוי בקובצי Cookie – הדף לא יוכל להשתמש במטמון לדף הקודם/הבא, והסיבה לכך תהיה 'דפים שהמשאב הראשי שלהם הוא Cache-Control: no-store לא יכולים להיכנס למטמון לדף הקודם/הבא'. הסיבה הזו תוצג בכלי לבדיקת מטמון לדף הקודם/הבא בכלי הפיתוח של Chrome.
אתם יכולים להשתמש בדף הבדיקה של מטמון הדפדפן כדי לבדוק עם הדגל הזה ובלי הדגל הזה.
מה מפתחים צריכים לדעת
המפתחים לא צריכים לבצע שינויים כדי שהמשתמשים שלהם ייהנו משימוש נרחב יותר במטמון הדף הקודם, אבל יש כמה דברים שכדאי להם לקחת בחשבון כתוצאה מכך. אלה שיקולים דומים שאולי נתקלו בהם באתרים אחרים בהשקה הראשונית של bfcache בדצמבר 2021.
האם מפתחים עדיין צריכים לשאוף לצמצם את השימוש ב-Cache-Control: no-store?
ה-bfcache מופעל עבור Cache-Control: no-store בנסיבות המוגבלות שצוינו קודם, ורק ב-Chrome. דפדפנים אחרים עדיין עשויים לחסום את השימוש ב-bfcache כשמשתמשים ב-Cache-Control: no-store.
השיטה המומלצת היא לצמצם את השימוש ב-Cache-Control: no-store במקום להסתמך על ההיוריסטיקות האלה.
השפעה על הביצועים
אנחנו מבצעים את השינוי הזה כדי לשפר את חוויית המשתמשים בדף באינטרנט. כששחררנו לראשונה את bfcache, ראינו שיפורים משמעותיים במדדי ה-Core Web Vitals, ועכשיו אנחנו רוצים להחיל את אותם שיפורים על אתרים נוספים.
בעלי אתרים עשויים לראות שיפור במדדי הליבה לבדיקת חוויית המשתמש באתר כשהתכונה הזו תושק, והם יוכלו למדוד את השימוש במטמון bfcache ב-CrUX, כולל ב-CrUX Vis.
ניתוח השפעות
דפים שמשוחזרים מהמטמון לדף הקודם/הבא מבצעים 'שחזור' של הדף הישן (כולל ה-heap של JavaScript) במקום לטעון מחדש את הדף. הרבה ספקי שירותים פופולריים לניתוח נתונים לא מודדים שחזורים של מטמון bfcache כצפיות חדשות בדף, כי הם מפעילים צפיות בדף רק כשהדף נטען בפעם הראשונה.
לכן, יכול להיות שבעלי אתרים יבחינו בירידה במספר טעינות הדפים בניתוח הנתונים שלהם כשהם מתחילים להשתמש לראשונה במטמון הדפדפן. מומלץ להתייחס לאירועים האלה כאל צפיות בדף. לשם כך, צריך להגדיר מאזינים לאירוע pageshow ולבדוק את המאפיין persisted:
// Send a pageview when the page is first loaded.
gtag('event', 'page_view');
// Send another pageview if the page is restored from bfcache.
window.addEventListener('pageshow', (event) => {
if (event.persisted) {
// Page was restored from bfcache, sent another page view.
gtag('event', 'page_view');
}
});
טיפול בעדכונים בשחזור דף
יכול להיות שאתרים יראו עכשיו שימוש במטמון לדף הקודם/הבא, למרות שלא ראו את זה קודם, ושהדף נטען מחדש באופן מלא עם נתונים חדשים. לכן, מפתחים צריכים לשקול רענון של נתונים בשחזור מהמטמון לדף הקודם/הבא.
אפשר להפעיל עדכונים באופן דומה לרישום ביומן של צפיות נוספות בדפים לצורך ניתוח באמצעות האירוע pageshow ובדיקת המאפיין persisted.
חשוב לציין שלא צריך לעדכן את כל התוכן, ויכול להיות שהמשתמשים יעדיפו לחזור לתוכן שראו קודם. לדוגמה, אם המשתמש חוזר לצפות במאמר מסוים, יכול להיות שאחרי רענון של רשימת המאמרים הוא כבר לא יראה אותו.
ההשפעה על מודעות
בדומה להשפעה על ניתוח הנתונים, יכול להיות שיהיה באתרים פחות חשיפות למודעות אם המודעות נטענות רק בזמן טעינת הדף. אפשר לרענן מודעות באופן פרוגרמטי כשמתבצעת שחזור מ-bfcache כדי לוודא שהן תואמות לטעינות של דפים מלאים. גם כאן נעשה שימוש באירוע pageshow ובמאפיין persisted, אבל לא תמיד זה הדבר הנכון לעשות. כדאי לעיין במסמכי התיעוד של ספק המודעות כדי להבין איך להפעיל טעינה מחדש של מודעות.
מידע נוסף על bfcache
מידע נוסף על bfcache זמין במדריך הטכני המקיף שלנו בנושא bfcache.
משוב
נשמח לקבל משוב על השינוי הזה. אפשר לשלוח משוב בכלי למעקב אחרי בעיות ב-Chrome באמצעות רכיב bfcache.
סיכום
אנחנו שמחים להרחיב את השימוש ב-bfcache לעוד הרבה דפים כדי לשפר את חוויית המשתמש. בדקנו את השינוי הזה לעומק, והגישה שלנו היא להשיק אותו בצורה בטוחה ככל האפשר. אנחנו מקווים שהמידע שסיפקנו כאן יעזור למפתחים להבין את השינוי הזה ולבצע את השינויים הנדרשים כדי להימנע מבעיות כשהשינוי יתבצע.