פורסם: 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 כאל אות להימנע מהצבת הדף במטמון bfcache. זו הסיבה העיקרית לכך שלא נעשה שימוש במטמון הדפדפן, בכ-17% מהניווטים בהיסטוריה בנייד וב-7% מהניווטים בהיסטוריה במחשב. המשמעות היא שהדפים האלה לא נהנים מהשחזורים המהירים, והם צריכים לטעון מחדש את הדף באופן מלא, כולל קריאות לרשת, הפעלת JavaScript ורינדור.
לרוב, הערך Cache-Control: no-store מוגדר כדי למנוע בעיות במטמון כשהאתר משתנה, אבל הסיבה הזו פחות רלוונטית כשמשתמשים במטמון לדף הקודם/הבא, כי הדף המלא משוחזר כמעט כאילו הוא נשאר פתוח כל הזמן.
איך Chrome משנה את ההתנהגות הזו
ב-Chrome הודיעו על כוונה לשנות את ההתנהגות הזו, אבל הם נוקטים גישה זהירה לגבי השינוי הזה. אנחנו מריצים ניסויים מאז Chrome 116, ומגדילים בהדרגה את אחוז טעינות הדפים. אנחנו צופים שהאחוז הזה יגיע ל-100% במרץ ובאפריל 2025.
מידע אישי רגיש
הניתוח שלנו מראה שרוב הניווטים אחורה או קדימה לא כוללים נתונים רגישים, ולכן הם עומדים בדרישות לשימוש במטמון לדף הקודם/הבא. עם זאת, יש מקרים שבהם לא כדאי להשתמש במטמון לדף הקודם/הבא. לדוגמה, אחרי התנתקות, לא אמורה להיות אפשרות לאחזר דף שבוצע בו לוגין באמצעות ניווט קדימה או אחורה.
כדי למנוע את זה, Chrome יסיר דף ממטמון הדפים הקודמים אם יחולו שינויים בקובצי Cookie או בשיטות הרשאה אחרות.
בנוסף, שימוש בממשקי ה-API הבאים בדפים שנעשה בהם שימוש ב-Cache-Control: no-store ימשיך למנוע את האפשרות לשמור את הדפים האלה במטמון לדף הקודם/הבא:
בנוסף, אם דף Cache-control: no-store שולח בקשת אחזור או XHR ומקבל בתגובה 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 – הדף לא יוכל להשתמש במטמון לדף הקודם/הבא, והסיבה לכך תהיה Pages whose main resource has Cache-Control: no-store cannot enter back/forward cache. (דפים שהמשאב הראשי שלהם הוא 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, ראינו שיפורים משמעותיים במדדי הליבה לבדיקת חוויית המשתמש באתר, ועכשיו אנחנו רוצים להחיל את אותם שיפורים על אתרים נוספים.
בעלי אתרים עשויים לראות שיפור במדדי הליבה לבדיקת חוויית המשתמש באתר כשהתכונה הזו תושק, והם יוכלו למדוד את השימוש במטמון 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 לעוד הרבה דפים כדי לשפר את חוויית המשתמש. בדקנו את השינוי הזה לעומק, והגישה שלנו היא להשיק אותו בצורה בטוחה ככל האפשר. אנחנו מקווים שהמידע הזה יעזור למפתחים להבין את השינוי ולבצע את השינויים הנדרשים כדי להימנע מבעיות כשהשינוי יתבצע.