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

Demián Renzulli

Barry Pollard

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

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

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

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

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

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

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

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

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

רקע

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

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

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

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

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

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

צוות Chrome מאמין שהשימוש במודל לנייד של מתן עדיפות ל-bfcache על פני unload במחשב יגרום לשיבושים, כי הוא יהפוך את השימוש ב-bfcache ללא אמין גם שם, כשבעבר הוא היה אמין למדי ב-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 כוללים back-forward-cache ביקורת שיכולה לעזור לכם לזהות בעיות שעשויות למנוע מהדף שלכם להיות כשיר לשמירה במטמון לדף הקודם/הבא, כולל השימוש ב-handler של unload.

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

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

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

אם הדף לא עומד בדרישות לשמירה במטמון לדף הקודם/הבא, בכרטיסייה מטמון לדף הקודם/הבא מוצגת רשימה של בעיות. בקטע ניתן לביצוע אפשר לראות אם אתם משתמשים ב-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

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

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

• מדיניות הרשאות: זהו 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 ימשיך להיות מופעל כברירת מחדל לכל המקורות. דף עדיין יכול להגדיר מדיניות מחמירה יותר אם הוא רוצה. בדומה לביטול ההסכמה למדיניות ההרשאות, זהו כלי לצמצום הסיכון לשינויים שעלולים לשבור את האתר. שוב, אנחנו ממליצים לבעלי אתרים להפסיק להסתמך על רכיבי handler של unload, אבל Chrome מתכנן לתמוך בהשבתה הזו בגרסת Enterprise בעתיד הנראה לעין, עבור אתרים שצריכים להשתמש בה.

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

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

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

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

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

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

סיכום

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

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

תודות

תודה לקנג'י באהו (Kenji Baheux), פרגל דיילי (Fergal Daly), אדריאנה חארה (Adriana Jara) וג'רמי וגנר (Jeremy Wagner) על העזרה בבדיקת המאמר הזה.

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