מוציאים משימוש את אירוע הסרת הנתונים שנטענו

Demián Renzulli

Barry Pollard

תאריך פרסום: 10 באוגוסט 2023, תאריך עדכון אחרון: 11 במרץ 2025

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

ציר הזמן להוצאה משימוש

עדכון: לוח הזמנים הזה עודכן ב-11 במרץ 2025.

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

• בדיקה בשטח באמצעות Permission-Policy API לפריקה ב-Chrome 115 (יולי 2023)
• בדיקה מקומית על ידי הפעלת דגל ב-Chrome 117 (ספטמבר 2023)

במהלך שנת 2024 טיפלנו בכמה בעיות שחסמו את תחילת ההשקה.

זהו ציר הזמן הנוכחי להוצאה משימוש של האירוע unload:

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

Milestone	תאריך אבן הדרך	50 האתרים המובילים	% ממקורות אחרים
135	26 במרץ 2025	1 (www.google.com)	0
136	23 באפריל 2025	5	0
137	21 במאי 2025	25	0
138	18 ביוני 2025	50	0

לוח הזמנים להוצאה משימוש של 50 האתרים המובילים

אחרי שנסיים להשיק את התכונה ב-50 האתרים המובילים, נשהה את ההשקה ונאפשר לה להיקלט במשך ציון דרך אחד או שניים, ולאחר מכן נקבל אישור נוסף להשיק אותה לכל מקורות הנתונים, במהלך 8 ציוני הדרך הבאים (או כ-32 שבועות). לוח הזמנים המשוער הוא:

Milestone	תאריך אבן הדרך	50 האתרים המובילים	% ממקורות אחרים
140	27 באוגוסט 2025	50	1
141	24 בספטמבר 2025	50	5
142	22 באוקטובר 2025	50	10
143	19 בנובמבר 2025	50	20
144	17 בינואר 2026	50	40
145	4 בפברואר 2026	50	60
146	4 במרץ 2026	50	80
147	1 באפריל 2026	50	100

ציר הזמן להוצאה משימוש של כל האתרים

לתשומת ליבכם: אנחנו מציעים גם תפריט של אפשרויות ביטול הסכמה למקרה שתקופת ההוצאה משימוש לא מספקת לכם מספיק זמן להפסיק להשתמש ב-unload. המטרה שלנו היא להשתמש בהוצאה משימוש חלקית הזו כדי לקבוע את ציר הזמן לשלב האחרון (הוצאה משימוש מלאה של ביטול ההורדה) שבו ההחרגות האלה יוסרו או יצומצמו.

ציר הזמן להוצאה משימוש של 'פריקה'.

רקע

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

תרחישים שבהם האירוע הזה היה בשימוש הנפוץ ביותר כוללים:

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

עם זאת, האירוע unload לא מהימן במיוחד.

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

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

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

למה אנחנו מוציאים משימוש את האירוע unload?

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

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

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

חלופות לאירועים מסוג unload

במקום unload מומלץ להשתמש ב-:

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

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

פרטים נוספים זמינים בטיפים האלה לגבי שימוש ב-handler unload.

זיהוי השימוש ב-unload

יש כלים שונים שיעזרו לכם למצוא את האירוע unload בדפים. כך אתרים יכולים לבדוק אם הם משתמשים באירוע הזה – בקוד שלהם או באמצעות ספריות – ולכן עשויים להיות מושפעים מההוצאה משימוש הקרובה.

כלי פיתוח ל-Chrome

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

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

1. בדף, פותחים את DevTools ועוברים אל Application‏ > Background services‏ > Back/forward cache.

2. לוחצים על בדיקת המטמון לדף הקודם/הבא. Chrome יעביר אתכם אוטומטית אל chrome://terms/ ואז חזרה לדף שלכם. לחלופין, אפשר ללחוץ על הלחצנים 'הקודם' ו'הבא' בדפדפן.

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

כלי בדיקת המטמון של 'כלי הפיתוח ל-Chrome': 'קדימה'/'לאחור'.

Reporting API

אפשר להשתמש ב-Reporting API בשילוב עם מדיניות הרשאות לקריאה בלבד כדי לזהות את השימוש ב-unload על ידי משתמשי האתר.

פרטים נוספים זמינים במאמר שימוש ב-Reporting API כדי למצוא הורדות

Bfcache notRestoredReasons API

הנכס notRestoredReasons – שנוסף לכיתה PerformanceNavigationTiming – מדווח אם מסמכים נחסמו משימוש ב-bfcache בניווט, ומסביר למה. זוהי דוגמה לאזהרה באובייקט התגובה של מאזין unload קיים:

{
   children: [],
   id: null,
   name: null,
   reasons: [
     {"reason", "unload-listener"}
   ],
   src: null,
   url: "https://www.example.com/page/"
}

שליטה בגישה ל-unload

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

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

• מדיניות הרשאות: ממשק API לפלטפורמה שמאפשר לבעלי אתרים לשלוט בגישה לתכונות, ברמת האתר או ברמת הדף הספציפי, באמצעות כותרות HTTP.
• מדיניות ארגונית: כלים לאדמינים ב-IT להגדרת Chrome לארגון או לעסק שלהם. אפשר להגדיר אותם באמצעות לוח אדמין, כמו מסוף Google Admin.
• דגלים של Chrome: האפשרות הזו מאפשרת למפתח בודד לשנות את הגדרת ההוצאה משימוש של unload כדי לבדוק את ההשפעה על אתרים שונים.

מדיניות ההרשאות

מדיניות הרשאות נוספה מ-Chrome 115 כדי לאפשר לאתרים לבטל את ההסכמה לשימוש במטפלים של unload וליהנות באופן מיידי מ-bfcache כדי לשפר את ביצועי האתר. כאן מפורטות דוגמאות להגדרה של האפשרות הזו באתר. כך אתרים יכולים להתכונן מראש להוצאה משימוש של unload.

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

מדיניות הארגון

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

דגלים של Chrome ומאפיינים של שורת הפקודה

בנוסף למדיניות הארגון, אפשר להשבית את ההוצאה משימוש למשתמשים ספציפיים באמצעות הדגלים של Chrome והמתגים של שורת הפקודה:

הגדרת chrome://flags/#deprecate-unload כ-enabled תקדיש את ברירת המחדל להוצאה משימוש ותימנע הפעלה של מנהלי unload. עדיין אפשר לשנות אותם בכל אתר בנפרד באמצעות מדיניות ההרשאות, אבל הם ימשיכו לפעול כברירת מחדל.

אפשר גם לשלוט בהגדרות האלה באמצעות מתגים בשורת הפקודה.

השוואה בין האפשרויות

בטבלה הבאה מפורט סיכום של השימושים השונים באפשרויות שצוינו למעלה:

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

סיכום

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

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

תודות

תודה ל-Kenji Baheux,‏ Fergal Daly,‏ Adriana Jara ו-Jeremy Wagner על העזרה בבדיקת המאמר הזה.

תמונה ראשית (Hero) של Anja Bauermann ב-Unsplash