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

Demián Renzulli

Barry Pollard

פורסם: 10 באוגוסט 2023, עדכון אחרון: 29 ביוני 2026

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

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

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

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

במהלך שנת 2024 טיפלנו בכמה בעיות שמנעו את תחילת ההשקה, ובמהלך שנת 2025 השקנו את ההוצאה משימוש ב-50 האתרים המובילים:

בשנת 2026 התחלנו להשיק את התכונה הזו לכל המקורות, במהלך 8 אבני דרך (או כ-32 שבועות), כפי שמפורט בטבלה הבאה.

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

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

רקע

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

תרחישים שבהם האירוע הזה שימושי במיוחד:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כלי פיתוח ל-Chrome

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

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

1. בדף, פותחים את כלי הפיתוח ועוברים אל Application (אפליקציה) > Background services (שירותי רקע) > Back/forward cache (מטמון של חזרה/מעבר קדימה).

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

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

.

Reporting API

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

מידע נוסף זמין במאמר שימוש ב-Reporting API כדי למצוא נתונים על הסרת תגים

‫notRestoredReasons API של Bfcache

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

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

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

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

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

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

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

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

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

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

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

תכונות ניסיוניות של Chrome ומתגי שורת הפקודה

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

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

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

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

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

סיכום

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

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

תודות

תודה לקנג'י באהו, פרגל דיילי, אדריאנה חארה וג'רמי וגנר על המשוב המועיל שקיבלנו מהם.

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