המטמון לדף הקודם/הבא (או BFCache) הוא אופטימיזציה של דפדפן שמאפשרת ניווט מיידי אחורה וקדימה. אנחנו מבצעים שינויים ב-BFCache של Chrome שעשויים להשפיע על תוספים שמשתמשים ביציאות להעברת הודעות. אם יש לכם תוסף ל-Chrome שמשתמש בהעברת הודעות כדי לתקשר בין סקריפטים של תוכן לבין התוסף שלכם, כדאי להמשיך לקרוא כדי ללמוד איך לבדוק ולהתאים את התוסף.
יציאת הודעות של תוסף
תוספים מתקשרים עם סקריפט התוכן או עם תוספים אחרים באמצעות העברת הודעות. אפשר לשלוח הודעות באמצעות בקשות חד-פעמיות על ידי קריאה לפונקציות runtime.sendMessage()
ו-tabs.sendMessage()
, או באמצעות יציאת הודעות לשימוש חוזר. כל עוד היציאה פעילה, גם סקריפט התוכן וגם סקריפט הרקע של התוסף יכולים לעשות בה שימוש חוזר כדי לפרסם הודעות זה לזה.
מידע נוסף זמין במאמר העברת הודעות.
מטמון לדף הקודם/הבא
כשעוברים מדף שעומד בדרישות לשימוש במטמון לדף הקודם/הבא, הדפדפן מאפשר לדף עם כל המצבים שלו להישאר בזיכרון, אבל במצב שאינו פעיל במלואו. אם המשתמש מבצע ניווט בהיסטוריה (חזרה או קדימה) לדף שנשמר במטמון, הדפדפן ינסה לשחזר את הדף מ-BFCache. כך הניווט מהיר יותר וחוויית הגלישה של המשתמש משתפרת.
כשהדף נמצא ב-BFCache, הוא נמצא במצב קפוא שבו אסור להריץ JavaScript. כלומר, הוא לא יכול לעבד הודעות שהוא מקבל.
מידע נוסף זמין במאמר מטמון לדף הקודם/הבא.
ההשפעה של יציאות להודעות של תוספים על BFCache
בקיצור, תוסף ששולח הודעות לדף ב-BFCache עלול לגרום להוצאה של הנתונים מהמטמון ולהשפיע על הביצועים.
כשדף עם יציאה פתוחה להודעות של תוסף נשמר ב-BFCache, היציאה נשארת פתוחה. אחרי שהדף משוחזר מ-BFCache, עובדי השירות של התוסף עדיין יכולים להשתמש בהפניה הישנה של יציאת ההודעות כדי לפרסם הודעות בסקריפט התוכן.
עם זאת, אם התוסף מנסה לפרסם הודעה דרך יציאת ההודעות הזו בזמן שהדף עדיין נמצא ב-BFCache, ההודעה נשלחת אבל לא נמסרת במלואה כי הטיפול בהקובץ מושעה. קשה לתוסף להבין את המצב הזה ולטפל בו, כי גם להוספת ההודעה לתור וגם להשמטת ההודעה יש בעיות משלהם.
כדי למנוע בעיות שקשורות להודעות שאבדו, בהטמעה הנוכחית של Chrome, דף המארח מוסר מ-BFCache וההודעה נמחקת. אם המשתמש יחזור לדף, הוא יטען מחדש, ויאפשר לתוסף להגדיר חיבור חדש.
מצד שני, ההטמעה הזו מגבילה את התרחישים שבהם BFCache רלוונטי, ומגבילה את השיפור בביצועים, במיוחד בתוספים עם מנגנוני שידור או פעימות לב ששולחים הודעות באופן קבוע לכל החיבורים. בנוסף, מכיוון שההוצאה מתבצעת כשהתוסף שולח הודעה לסקריפט התוכן, למפתחי האתרים אין אפשרות למנוע את ההוצאה של הדפים שלהם.
כדי לשפר את הביצועים הכוללים, אנחנו מתכננים להציג התנהגות חדשה של יציאת הודעות.
התנהגות חדשה: סגירת ערוץ ההודעות כשהדף נשמר ב-BFCache
החל מ-Chrome 123, כשדף עם יציאת הודעות פתוחה של תוסף נשמר ב-BFCache, ערוץ ההודעות הבסיסי נסגר באופן יזום מצד סקריפט התוכן. כתוצאה מכך, כל יציאות ההודעות ייסגרו והתוסף יקבל אירוע onDisconnect
.
מכיוון שהערוץ סגור, לא יישלחו הודעות לדף בזמן שהוא במטמון לדף הקודם/הבא. לכן, הדף לא יוסר בגלל התוסף.
גם אחרי שהדף ישוחזר מה-BFCache, ערוץ ההודעות הסגור לא ייפתח מחדש. המומחים ממליצים למפתחי התוספים להאזין לאירועי מחזור החיים של הדף ולהגדיר חיבור חדש כשהדף משוחזר מ-BFCache, כפי שמתואר בדוגמה הבאה.
// content script
let port;
window.addEventListener('pageshow', (event) => {
if (event.persisted) {
// The page is restored from BFCache, set up a new connection.
port = chrome.runtime.connect();
}
});
מידע נוסף על השיחה ב-WECG זמין אצל נציגים של דפדפנים שונים (בבעיה 474).
האם השינוי הזה ישפיע עליי?
ההתנהגות החדשה תהיה זמינה באמצעות דגל ב-Chrome 123, כדי שתוכלו לבדוק את הקוד שלכם. מידע נוסף זמין בלוח הזמנים. פועלים לפי השלבים הבאים כדי לבדוק את התוסף. חשוב לזכור שמדובר רק בבדיקה פשוטה, ואנחנו ממליצים להפעיל את התכונה ב-Chrome למשך זמן מה, כי קשה לחזות אילו תכונות בתוסף עלולות לגרום לבעיות.
בדיקה של ההתנהגות החדשה
כדי להפעיל את הניסוי בכוח ב-Chrome 123:
מריצים את Chrome עם הדגל הבא, שמאלץ את ההתנהגות החדשה:
--enable-features=DisconnectExtensionMessagePortWhenPageEntersBFCache
עוברים לדף ומבצעים אינטראקציה עם התוסף, במידת הצורך, כדי שסקריפט תוכן יפתח יציאה לתוסף.
מנווטים החוצה ובחזרה. עכשיו הדף אמור להתאושש, אבל ערוץ ההודעות בין סקריפט התוכן לבין קובץ השירות (service worker) אמור להתנתק.
בודקים אם התוסף עדיין פועל כרגיל. אם לא, צריך להתחבר מחדש באופן ידני כפי שמתואר בקטע הקודם.
זיהוי בעיות פשוטות באמצעות ההתנהגות הישנה
לפני השינוי הזה, Chrome הציג אזהרה אם ניסיתם לשלוח הודעה לשקע שמשויך לדף ב-bfcache. האפשרות הזו יכולה להיות שימושית לזיהוי חלק מהבעיות שקשורות להעברת הודעות מהרקע לדף, אבל לא את כולן.
- ודאו שגרסת Chrome היא לפחות 123. מומלץ להשתמש ב-Chrome Canary, שמציג אזהרה נוספת כדי להקל על הבדיקה.
מפעילים את Chrome עם הדגל הבא, שמאלץ את ההתנהגות הקודמת:
--disable-features=DisconnectExtensionMessagePortWhenPageEntersBFCache
עוברים לדף שעומד בדרישות לשימוש ב-BFCache בלי להפעיל את התוסף (לדוגמה, אתר פשוט כלשהו כמו https://example.com/). פועלים לפי המדריך בנושא BFCache כדי לוודא שהיא תוחזר מ-BFCache.
מתקינים ומפעילים את התוסף ובודקים שוב את הכשירות ל-BFCache. אפשר לנווט באופן ידני לדף אחר, להמתין זמן מה שיספיק לתוסף לפרסם הודעה בדף BFCached ולנווט חזרה.
אם הדף היה צריך להיטען מחדש במקום מ-BFCache בגלל פינוי, והבעיה שמונעת את השחזור היא 'ExtensionSentMessageToCachedFrame', יכול להיות שהשינוי הזה ישפיע על התוסף.
ב-Chrome Canary בגרסה 124.0.6315.0 ואילך, תוצג גם האזהרה הבאה בדף:
אזהרה שמוצגת כשדף לא משוחזר מ-BFCache.
אחרי שתאשרו שהתוסף מפרסם הודעות בדף BFCache, תוכלו לפעול לפי השלבים בקטע הקודם כדי לאלץ את הפעלת הניסוי ולבדוק אם יש שגיאות לוגיות.
ציר הזמן להשקה
אנחנו מתכננים להרחיב בהדרגה את ההתנהגות החדשה החל מגרסה 123 של Chrome. זו התוכנית המפורטת:
תאריך | אבן דרך מתוכננת |
---|---|
15 בפברואר | מתחילים את הניסוי לגבי ההתנהגות החדשה ב-Chrome 123 Canary וב-Dev. |
7 במרץ | מתחילים את הניסוי לגבי ההתנהגות החדשה ב-Chrome 123 בטא. |
18 במרץ | השקת ההתנהגות החדשה ל-4% מהמשתמשים ב-Chrome 123 Stable. |
25 במרץ | משיקים את ההתנהגות החדשה ל-50% מהמשתמשים ב-Chrome 123 Stable. |
2 באפריל | הניסוי מסתיים וההתנהגות החדשה מוגדרת כברירת מחדל. |