האירוע unload יצא משימוש בהדרגה על ידי שינוי הדרגתי של ברירת המחדל כך שרכיבי handler של unload יפסיקו להפעיל אותם בדפים, אלא אם בדף התקבלה הסכמה מפורשת להפעיל אותם מחדש.
ציר הזמן להוצאה משימוש
שמנו לב שההתנהגות של הסרת הנתונים שנטענו עשויה להיות כפופה לשינויים כבר בינואר 2019, כאשר הודענו על הכוונה שלנו להטמיע מטמון לדף הקודם/הבא. במקביל להטמעה, ערכנו הפצה נרחבת שגרמה לירידה משמעותית בהסרת הנתונים שנטענו. כדי להשלים את התמיכה הזו, התחלנו גם להציע דרכים לבדוק את ההשפעה של ההוצאה משימוש של הסרת הנתונים שנטענו מ-Chrome 115:
- בדיקות כלליות באמצעות Permissions-Policy API להסרת נתונים שנטענו ב-Chrome 115 (יולי 2023)
- בדיקה מקומית באמצעות הפעלת דגל ב-Chrome 117 (ספטמבר 2023)
לאחר שלבי ההפצה והניסוי, כך אנחנו מצפים להשקה של ההוצאה משימוש של השדרוג:
- שלב בהיקף שבו 'הסרת הנתונים שנטענו' תפסיק לפעול בהדרגה ב-50 האתרים הפופולריים המובילים (מידע נוסף נכון לזמן הכתיבה).
- החל מ-1% מהמשתמשים ב-Chrome 120 (סוף נובמבר 2023).
- סיום עם 100% מהמשתמשים עד סוף הרבעון השלישי של 2024
- בנוסף, החל מהרבעון השלישי של שנת 2024, אנחנו מתכוונים להתחיל שלב כללי שבו הסרת הנתונים שנטענו תפסיק בהדרגה לפעול באתרים כלשהם, החל מ-1% מהמשתמשים ועד ל-100% מהמשתמשים עד סוף הרבעון הראשון של 2025.
שימו לב שאנחנו מציעים גם תפריט של אפשרויות לביטול הסכמה למקרה שציר הזמן של ההוצאה משימוש הרך לא מספיק זמן למעבר מהסרת הנתונים שנטענו. המטרה שלנו היא להשתמש בההוצאה משימוש הרכה כדי ליצור לוח זמנים לשלב האחרון (הוצאה משימוש משמעותית של הסרת הנתונים שנטענו) שבו ביטולי ההסכמה האלה יוסרו או יקוצרו.
רקע
unload תוכנן לפעול כשמתבצעת טעינה של המסמך. באופן תיאורטי, אפשר להריץ את הקוד בכל פעם שמשתמש מנווט אל מחוץ לדף, או בתור קריאה חוזרת (callback) בסוף הסשן.
התרחישים שבהם האירוע הזה היה בשימוש הכי הרבה כוללים:
- שמירת נתוני משתמש: שמירת נתונים לפני שיוצאים מהדף.
- ביצוע משימות ניקוי: סגירת משאבים פתוחים לפני נטישה של הדף.
- שליחת ניתוח נתונים: שליחת נתונים שקשורים לאינטראקציות של המשתמשים בסוף הסשן.
עם זאת, האירוע unload לא מהימן במיוחד.
ב-Chrome למחשב וב-Firefox, unload הוא מהימן במידה סבירה, אבל יש לו השפעה שלילית על ביצועי האתר על ידי מניעת השימוש במטמון לדף הקודם/הבא.
בדפדפנים לנייד unload בדרך כלל לא פועל, כי בדרך כלל הכרטיסיות עוברות ברקע ואז נמחקות. לכן דפדפנים בוחרים לתת עדיפות לשמירה במטמון לדף הקודם/הבא בנייד על פני unload, ולכן הם עוד יותר לא אמינים. Safari משתמשת בהתנהגות הזו גם במחשב.
בצוות Chrome, מאמינים ששימוש במודל לנייד של תעדוף המטמון לדף הקודם/הבא על פני 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 כוללים ביקורת של back-forward-cache כדי לעזור לכם לזהות בעיות שעלולות למנוע את כשירות הדף לשמירה במטמון לדף הקודם/הבא, כולל שימוש ב-handler של unload.
כדי לבדוק את התכונה 'מטמון לדף הקודם/הבא', מבצעים את השלבים הבאים:
בדף, פותחים את כלי הפיתוח ועוברים אל Application > שירותים הפועלים ברקע > מטמון לדף הקודם/הבא.
לוחצים על בדיקת מטמון לדף הקודם/הבא Chrome מעביר באופן אוטומטי אל
chrome://terms/וחוזר לדף. לחלופין, אפשר ללחוץ על הלחצנים 'הקודם' ו'הבא' בדפדפן.
אם הדף לא מתאים לשמירה במטמון לדף הקודם/הבא, בכרטיסייה מטמון לדף הקודם/הבא תוצג רשימה של בעיות. בקטע פעולה לביצוע, אפשר לראות אם משתמשים ב-unload:
Reporting API
אפשר להשתמש ב-Reporting API בשילוב עם מדיניות הרשאות לקריאה בלבד כדי לזהות שימוש ב-unload ממשתמשי האתר.
לפרטים נוספים, אפשר לעיין במאמר בנושא שימוש ב-Reporting API לאיתור פריטים שנטענו.
API של notRestoredReasons במטמון Bfcache
הנכס notRestoredReasons – שנוסף למחלקה PerformanceNavigationTiming – כולל מידע על חסימת השימוש של מסמכים במטמון לדף הקודם/הבא בניווט והסיבה לכך. הוראות לשימוש זמינות כאן. זוהי דוגמה לאופן שבו נראית האזהרה של אובייקט התגובה מ-listenen unload קיים:
{
children: [],
id: null,
name: null,
reasons: [
{"reason", "unload-handler"}
],
src: null,
url: "https://www.example.com/page/"
}
שליטה בגישה אל unload
המערכת של Chrome תוציא משימוש את האירוע unload בהדרגה. בינתיים, אפשר להשתמש בכלים שונים כדי לשלוט בהתנהגות הזו ולהתכונן להוצאה משימוש הקרובה. חשוב לזכור שלא כדאי להסתמך על הטכניקות האלה בטווח הארוך, וכדאי לתכנן את המעבר לחלופות בהקדם האפשרי.
בעזרת האפשרויות הבאות אפשר להפעיל או להשבית handlers של unload כדי לבדוק איך האתר שלך יפעל בלעדיהם, ולהתכונן להוצאה משימוש הקרובה. יש כמה סוגים של כללי מדיניות:
- מדיניות הרשאות: זהו API של פלטפורמה שמאפשר לבעלי אתרים לשלוט בגישה לתכונות ברמת האתר או ברמת דף ספציפי, באמצעות שימוש בכותרות HTTP.
- מדיניות ארגונית: כלים לאדמינים ב-IT להגדרת Chrome עבור הארגון או העסק שלהם. אפשר להגדיר אותם דרך חלונית ניהול, כמו מסוף Google Admin.
- סימונים של Chrome: ההגדרה הזו מאפשרת למפתח לשנות את הגדרת ההוצאה משימוש של
unloadכדי לבדוק את ההשפעה באתרים שונים.
מדיניות ההרשאות
מדיניות הרשאות נוספה מ-Chrome 115 כדי לאפשר לאתרים לבטל את ההסכמה לשימוש ב-handlers של unload וליהנות באופן מיידי מהמטמון לדף הקודם/הבא כדי לשפר את ביצועי האתר. מומלץ לעיין בדוגמאות האלה כדי להגדיר את זה באתר שלכם. כך אתרים יכולים להתכונן להוצאה משימוש של unload.
ההגדרה הזו יורחבה בגרסה 117 של Chrome כדי לאפשר לאתרים לשנות את המצב ולהסכים להמשיך לנסות להפעיל handlers של unload, כי ב-Chrome מוגדר ברירת המחדל שלא להפעיל אותם בעתיד. כאן מוסבר איך להמשיך לאפשר ל-handlers של הסרת הנתונים שנטענו עבור האתר שלכם. הבעת ההסכמה הזו לא תישמר לתמיד, וצריך להשתמש בה כדי לתת לאתרים מספיק זמן לעבור מרכיבי handler של unload.
מדיניות הארגון
ארגונים שיש להם תוכנה שתלויה באירוע unload כדי לפעול באופן תקין יכולים להשתמש במדיניות ForcePermissionPolicyUnloadDefaultEnabled כדי למנוע הוצאה הדרגתית משימוש במכשירים שבשליטתם. כשמפעילים את המדיניות הזו, unload ימשיך להיות מופעל כברירת מחדל בכל המקורות. דף עדיין יכול להגדיר מדיניות מחמירה יותר אם הוא רוצה בכך. כמו במקרה של ביטול ההסכמה למדיניות ההרשאות, זהו כלי שמצמצם שינויים שעלולים לגרום לכשל, אבל לא כדאי להשתמש בו ללא הגבלת זמן.
תכונות ניסיוניות ב-Chrome ומתגי שורת פקודה
בנוסף למדיניות הארגון, אפשר להשבית את ההוצאה משימוש של משתמשים ספציפיים באמצעות התכונות הניסיוניות של Chrome ומתגי שורות הפקודה:
הגדרת הערך של chrome://flags/#deprecate-unload לערך enabled תפעיל את ברירת המחדל להוצאה משימוש ותמנע הפעלה של handlers של unload. עדיין אפשר לשנות אותן בכל אתר בנפרד באמצעות מדיניות ההרשאות, אבל הפעלת אותן תימשך כברירת מחדל.
אפשר לשלוט בהגדרות האלה גם באמצעות מתגי שורת פקודה.
השוואת אפשרויות
הטבלה הבאה מסכמת את השימושים השונים באפשרויות שפורטו למעלה:
| קידום ההוצאה משימוש | קידום ההוצאה משימוש (עם חריגים) | מניעת הוצאה משימוש כדי להבטיח זמן העברה | |
|---|---|---|---|
| מדיניות ההרשאות (חלה על דפים/אתרים) |
כן | כן | כן |
| מדיניות ארגונית (חלה על מכשירים) |
לא | לא | כן |
| תכונות ניסיוניות של Chrome (חל על משתמשים ספציפיים) |
כן | לא | לא |
| העברת שורת הפקודה ב-Chrome (רלוונטי למשתמשים ספציפיים) |
כן | לא | כן |
סיכום
אנחנו מוציאים משימוש את ה-handlers של unload. הם לא מהימנים במשך זמן רב, ולא בטוח שהם יופעלו בכל המקרים שבהם מסמך מושמד. בנוסף, רכיבי ה-handler של unload לא תואמים ל-bfcache.
אתרים שמשתמשים כרגע ב-handlers של unload צריכים להתכונן להוצאה משימוש הקרובה: לבדוק אם יש handlers קיימים ל-unload ולהסיר או להעביר אותם. כמובן, כדי לעכב את ההוצאה משימוש אם נדרש זמן נוסף.
אישורים
תודה לקנג'י בהו, פרגל דאלי, אדריאנה ג'ארה וג'רמי וגנר על העזרה בקריאת המאמר הזה.
תמונה ראשית (Hero) של אניה באוארמן בסרטון Un פעילות