אנחנו מבצעים שינוי ב-Chrome כדי לאפשר שימוש במטמון 'הקודם'/'הבא' (bfcache) בדפים שמשתמשים ב-Cache-Control: no-store כשהדבר בטוח. מה המשמעות של השינוי הזה למפתחים?
רקע
הגדרת Cache-Control: no-store ככותרת HTTP היא אות לכך שהדף לא צריך להישמר במטמון ה-HTTP. צריך להשתמש בהוראה הזו בדפים שמכילים מידע אישי רגיש – לדוגמה, בדפים שבהם משתמש מחובר לחשבון – אבל לעיתים קרובות משתמשים בהוראה no-store בדפים ללא מידע אישי רגיש.
כשמשתמשים ב-bfcache, במקום למחוק דף כשהמשתמש מנווט אל דף אחר, אנחנו דוחים את המחיקה ומשהים את ביצוע ה-JS. אם המשתמש יחזור לדף בקרוב, נחזיר את הדף לסטטוס גלוי ונבטל את ההשהיה של ביצוע ה-JS. כתוצאה מכך, המשתמש יכול לנווט בין הדפים כמעט באופן מיידי.
אמנם אין דרישה כזו במפרט HTML, אבל בדרך כלל דפדפנים מתייחסים ל-Cache-Control: no-store כאות להימנע משימוש במטמון לדף הקודם/הבא. זו הסיבה העיקרית לכך שלא נעשה שימוש במטמון לדף הקודם/הבא – כ-17% מהניווטים בהיסטוריה בנייד ו-7% מהניווטים בהיסטוריה במחשב. המשמעות היא שהדפים האלה לא יפיקו תועלת מהשחזורים המהירים והם יצטרכו לטעון מחדש את הדף במלואו, כולל קריאות רשת, הפעלות של JavaScript ועיבוד.
לעיתים קרובות, הערך של Cache-Control: no-store מוגדר כדי למנוע בעיות במטמון כשהאתר משתנה, אבל הסיבה הזו רלוונטית פחות כשמשתמשים ב-bfcache, כי הדף המלא משוחזר כמעט כאילו הוא נשאר פתוח כל הזמן.
איך אנחנו משנים את ההתנהגות הזו ב-Chrome
ב-Chrome הודיעו על כוונה לשנות את ההתנהגות הזו, אבל הם מתייחסים לשינוי הזה בזהירות. אנחנו מריצים ניסויים מאז גרסה 116 של Chrome, ועד לאחרונה הם הופעלו ב-5% מהטעינות של דפים.
העלינו את השיעור הזה ל-10% מהטעינות של דפים ב-2 באוקטובר, ואנחנו מתכוונים להגדיל אותו ל-20% מהטעינות של דפים בנובמבר, ל-50% בתחילת השנה הבאה ולהשיק את התכונה במלואה זמן קצר לאחר מכן. בהמשך מוסבר על אפשרויות מסוימות לביטול ההסכמה.
מידע אישי רגיש
הניתוח שלנו מראה שרוב הניווטים לאחור או קדימה לא כוללים מידע רגיש, ולכן הם אמורים לעמוד בדרישות להוספה למטמון לדף הקודם/הבא. עם זאת, יש מקרים שבהם לא כדאי להוסיף דפים למטמון לדף הקודם/הבא. לדוגמה, כשמתנתקים מהחשבון, לא אמורה להיות אפשרות לאחזר דף שמחובר לחשבון על ידי ניווט הלוך ושוב.
כדי למנוע זאת, Chrome יסיר דף מה-bfcache אם יהיו שינויים בקובצי cookie או בשיטות הרשאה אחרות.
בנוסף, השימוש בממשקי ה-API הבאים בדפים שמשתמשים ב-Cache-Control: no-store ימשיך למנוע מהדפים האלה לעמוד בדרישות לשמירה במטמון לדף הקודם/הבא:
חשוב לשים לב שזו לא רשימה מקיפה של ממשקי API שמונעים שימוש במטמון לדף הקודם/הבא, אלא ממשקי ה-API שחוסמים את המטמון לדף Cache-Control: no-store גם אם לא נעשה בהם שימוש בזמן היציאה מהדף.
גם הזמן הקצוב לתפוגה של bfcache עבור דפים Cache-Control: no-store הוא 3 דקות (מ-10 דקות בשימוש עבור דפים שלא משתמשים ב-Cache-Control: no-store) כדי לצמצם עוד יותר את הסיכון.
ביטול הסכמה לארגונים
לרוב, לארגונים יש תוכנות ומכשירים משותפים שקשה לעדכן. אפשר להשבית את המדיניות AllowBackForwardCacheForCacheControlNoStorePageEnabled כדי להמשיך למנוע את השימוש במטמון לדף הקודם/הבא של Cache-Control: no-store.
בדיקת השינוי
מפתחים יכולים לבדוק את השינוי הזה באמצעות הדגל הבא:
--enable-features=CacheControlNoStoreEnterBackForwardCache:level/restore-unless-cookie-change
אם אחד מההחרגות הקודמות רלוונטי – למשל, שינוי של קובצי cookie – הדף לא יוכל להשתמש ב-bfcache, והסיבה לכך תופיע בבודק ה-bfcache של Chrome DevTools: "דפים שהמשאב הראשי שלהם מכיל את Cache-Control: no-store לא יכולים להיכנס למטמון לדף הקודם/הבא".
אתם יכולים להשתמש בדף הבדיקה של bfcache כדי לבדוק עם הדגל הזה או בלעדיו.
מידע למפתחים
המפתחים לא יצטרכו לבצע שינויים כדי שהמשתמשים שלהם יוכלו ליהנות מהשימוש המוגבר ב-bfcache, אבל יש כמה דברים שהם עשויים להצטרך לקחת בחשבון כתוצאה מכך. אלה היו שיקולים דומים שעשויים להיות רלוונטיים לאתרים אחרים במהלך ההשקה הראשונית של bfcache בדצמבר 2021.
ההשפעה על הביצועים
אנחנו מבצעים את השינוי הזה כדי לשפר את חוויית השימוש בדף למשתמשים באינטרנט. כשהשקנו את bfcache בפעם הראשונה, ראינו שיפורים ניכרים במדדי הליבה לבדיקת חוויית המשתמש באתר. עכשיו אנחנו רוצים להביא את אותם שיפורים לאתרים נוספים.
בעלי אתרים עשויים לראות שיפור במדדי הליבה לבדיקת חוויית המשתמש באתר במהלך ההשקה, ויכולים למדוד את השימוש ב-bfcache ב-CrUX, כולל בלוח הבקרה של CrUX.
ניתוח ההשפעה
דפים שמוחזרים מהמטמון לדף הקודם/הבא 'משחזרים' את הדף הישן (כולל אשכול ה-JavaScript) במקום לטעון מחדש את הדף. ספקי ניתוח נתונים פופולריים רבים לא מודדים שחזור של bfcache כצפיות חדשות בדפים, כי הם מפעילים צפיות בדפים רק כשהם נטענים בפעם הראשונה.
לכן, יכול להיות שבאתרים שיתחילו להשתמש ב-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.
סיכום
אנחנו שמחים להביא את היתרון של המטמון לדף הקודם/הבא לעוד דפים רבים כדי לשפר את חוויית המשתמשים בדף. התייחסנו לשינוי הזה בכובד ראש, והגישה שלנו היא להשיק אותו בצורה הבטוחה ביותר האפשרית. אנחנו מקווים שהמידע הזה יעזור למפתחים להבין את השינוי הזה ולבצע את השינויים הנדרשים כדי למנוע בעיות במקרה כזה.