האירוע unload יוצא משימוש בהדרגה על ידי שינוי הדרגתי של ברירת המחדל, כך שמטפלי unload יפסיקו לפעול בדפים, אלא אם בדף יש הסכמה מפורשת להפעיל אותם מחדש.
ציר הזמן להוצאה משימוש
שמנו לב שהתנהגות הסרת הנתונים שנטענו עשויה להשתנות כבר בחודש ינואר 2019, כשהודענו על הכוונה שלנו להטמיע מטמון לדף הקודם/הבא. במקביל לתהליך ההטמעה, ערכנו היקף חשיפה נרחב, שגרם לירידה משמעותית בהסרת הנתונים שנטענו. בנוסף להסבר הזה, התחלנו להציע דרכים לבדוק את ההשפעה של ההוצאה משימוש של הסרת הנתונים שנטענו מ-Chrome 115:
- בבדיקות הטבע דרך Permission-Policy API for unload ב-Chrome 115 (יולי 2023)
- בדיקה מקומית על ידי הפעלת דגל ב-Chrome 117 (ספטמבר 2023)
אחרי שלבי ההסבר והניסוי, אנחנו מצפים להוצאה משימוש של השירות:
- שלב בהיקף שבו הסרת הנתונים שנטענו תפסיק לפעול בהדרגה עבור 50 האתרים הפופולריים המובילים (הפניה נכון למועד הכתיבה).
- החל מ-1% מהמשתמשים בגרסה 120 של Chrome (סוף נובמבר 2023).
- סיום עם 100% מהמשתמשים עד סוף הרבעון השלישי של 2024
- בנוסף, החל מהרבעון השלישי של שנת 2024, אנחנו מתכננים להתחיל שלב כללי שבו הסרת הנתונים שנטענו תופסק בהדרגה לפעולה בכל האתרים, ויתחיל ב-1% מהמשתמשים ויסתיים ב-100% מהמשתמשים עד סוף הרבעון הראשון של 2025.
חשוב לשים לב שאנחנו מציעים גם תפריט של אפשרויות לביטול הסכמה, למקרה שציר הזמן להוצאה הרכה לא מספק מספיק זמן להפסקה מהסרת הנתונים שנטענו. המטרה שלנו היא להשתמש בהוצאה משימוש הרכה כדי לעדכן את לוח הזמנים לשלב האחרון (הוצאה משימוש משמעותית של הסרת הנתונים שנטענו) שבו יוסרו או יצומצמו האפשרויות האלה.
רקע
unload תוכנן לפעול לאחר הורדת המסמך. באופן כללי, אפשר להשתמש בו כדי להריץ קוד בכל פעם שמשתמש יוצא מדף כלשהו, או כסיום של קריאה חוזרת (callback).
התרחישים שבהם האירוע הזה היה השימוש הנפוץ ביותר כוללים:
- שמירת נתוני משתמש: שומרים את הנתונים לפני שיוצאים מהדף.
- ביצוע משימות ניקוי: סגירת משאבים פתוחים לפני נטישה של הדף.
- שליחת ניתוח הנתונים: שליחת נתונים שקשורים לאינטראקציות של משתמשים בסוף הסשן.
עם זאת, האירוע unload לא אמין מאוד.
ב-Chrome וב-Firefox למחשבים שולחניים, גרסת unload אמינה במידה סבירה, אבל יש לה השפעה שלילית על ביצועי האתר כי היא מונעת את השימוש ב-bfcache (מטמון לדף הקודם/הבא).
בדפדפנים בנייד, בדרך כלל 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 בדפים. כך אתרים יכולים לגלות אם הם משתמשים באירוע הזה – בקוד שלהם או באמצעות ספריות – וייתכן שהם יושפעו מההוצאה משימוש המתוכננת.
מגדלור
ב-Lighthouse יש ביקורת של no-unload-listeners, שמזהירה מפתחים אם כל JavaScript בדפים שלהם (כולל זה מספריות של צד שלישי) מוסיף פונקציות event listener של unload.
כלי פיתוח ל-Chrome
כלי הפיתוח ל-Chrome כוללים ביקורת של back-foward-cache שעוזרת לזהות בעיות שעלולות למנוע את ההתאמה של הדף לשמירה במטמון לדף הקודם/הבא, כולל שימוש ב-handler של unload.
כדי לבדוק את התכונה 'מטמון לדף הקודם/הבא', פועלים לפי השלבים הבאים:
בדף, פותחים את כלי הפיתוח, ואז עוברים אל Application (אפליקציה) > Background Services (שירותים ברקע) > Back/Nextנ' (מטמון לדף הקודם/הבא).
לוחצים על בדיקת מטמון לדף הקודם/הבא ב-Chrome, המערכת מעבירה אתכם באופן אוטומטי אל
chrome://terms/וחזרה לדף שלכם. לחלופין, אפשר ללחוץ על הלחצנים 'הקודם' ו'הבא' בדפדפן.
אם הדף לא מתאים לשמירה במטמון לדף הקודם/הבא, בכרטיסייה מטמון לדף הקודם/הבא תוצג רשימה של בעיות. בקטע פעולות לביצוע, תוכלו לראות אם אתם משתמשים ב-unload:
Reporting API
אפשר להשתמש ב-Reporting API בשילוב עם מדיניות הרשאות לקריאה בלבד כדי לזהות שימוש ב-unload ממשתמשי האתר.
לפרטים נוספים קראו את המאמר שימוש ב-Reporting API לאיתור טעינות תוכן.
ממשק API של notRestoredReasons במטמון לדף הקודם/הבא
הנכס notRestoredReasons — שנוסף למחלקה PerformanceNavigationTiming, כולל דיווח לגבי הסיבה לכך שהמסמכים נחסמים לשימוש במטמון לדף הקודם/הבא בניווט, והסיבות לכך. הוראות שימוש זמינות כאן. זוהי דוגמה לאופן שבו נראית האזהרה של אובייקט התגובה של מאזין unload קיים:
{
blocked: true,
children: [],
id: "",
name: "",
reasons: [ "Internal Error", "Unload handler" ],
src: "",
url: "a.com"
}
שליטה בגישה אל unload
Chrome יוציא משימוש את האירוע unload בהדרגה. בינתיים, אפשר להשתמש בכלים שונים כדי לשלוט בהתנהגות הזו ולהתכונן לקראת ההוצאה משימוש. חשוב לזכור שאין להסתמך על הטכניקות האלה בטווח הארוך, ובמקום זאת לעבור להשתמש בחלופות בהקדם האפשרי.
בעזרת האפשרויות הבאות, אפשר להפעיל או להשבית רכיבי handler של unload כדי לבדוק איך האתר יעבוד בלעדיהם, כהכנה לקראת ההוצאה משימוש הקרובה. יש סוגים שונים של מדיניות:
- מדיניות הרשאות: זהו פלטפורמה API שמאפשרת לבעלי אתרים לשלוט בגישה לתכונות, ברמת האתר או ברמת הדף, באמצעות שימוש בכותרות HTTP.
- מדיניות ארגונית: כלים לאדמינים ב-IT שבאמצעותם הם יכולים להגדיר את Chrome לארגון או לעסק שלהם. אפשר להגדיר אותם דרך חלונית ניהול, כמו מסוף Google Admin.
- דגלים ב-Chrome: מאפשרים למפתח ספציפי לשנות את הגדרת ההוצאה משימוש של
unloadכדי לבדוק את ההשפעה על אתרים שונים.
מדיניות ההרשאות
נוספה מדיניות הרשאות מ-Chrome 115 כדי לאפשר לאתרים לבטל את ההסכמה לשימוש ברכיבי handler של unload, ולהפיק תועלת מיידית מהמטמון לדף הקודם/הבא כדי לשפר את ביצועי האתר. כאן מפורטות דוגמאות לאופן ההגדרה של האתר באתר. כך אתרים יכולים להתכונן לפני ההוצאה משימוש של unload.
ההגדרה תורחב ב-Chrome 117 כדי לאפשר לאתרים לעשות משהו הפוך, ולהביע הסכמה להמשיך לנסות להפעיל את ה-handlers של unload. הסיבה לכך היא ש-Chrome משנה את ברירת המחדל כדי שהיא לא תופעל בעתיד. עיינו בדוגמאות האלה כדי להמשיך לאפשר ל-handlers של הסרת הנתונים שנטענו להפעיל באתר שלכם. ההסכמה הזו לא תישאר לתמיד, ויש להשתמש בה כדי לתת לאתרים זמן לצאת מרכיבי ה-handler של unload.
מדיניות הארגון
ארגונים שיש להם תוכנות שתלויות באירוע unload כדי לפעול באופן תקין יכולים להשתמש במדיניות ForcePermissionPolicyUnloadDefaultEnabled כדי למנוע הוצאה משימוש הדרגתית של מכשירים שנמצאים בשליטתם. לאחר הפעלת המדיניות הזו, unload ימשיך להיות מופעל כברירת מחדל לכל המקורות. אם הדף רוצה זאת, הוא עדיין יכול להגדיר מדיניות מחמירה יותר. בדומה לביטול ההסכמה למדיניות בנושא הרשאות, זהו כלי לצמצום שינויים שעלולים לגרום לכשלים, אך אין להשתמש בו ללא הגבלת זמן.
תכונות ניסיוניות של Chrome ומתגי שורת פקודה
בנוסף למדיניות הארגון, אפשר להשבית את ההוצאה משימוש של משתמשים ספציפיים באמצעות הדגלים של Chrome ושורת הפקודה:
אם קובעים במדיניות chrome://flags/#deprecate-unload את הערך enabled, ברירת המחדל להוצאה משימוש תמנע הפעלה של רכיבי handler של unload. עדיין אפשר לשנות כל אתר בנפרד באמצעות מדיניות ההרשאות, אבל הן ימשיכו לפעול כברירת מחדל.
אפשר לשלוט בהגדרות האלה גם באמצעות מתגי שורת פקודה.
השוואת אפשרויות
הטבלה הבאה מסכמת את השימושים השונים באפשרויות שתיארנו קודם:
| קדם את תהליך ההוצאה משימוש | קדם את ההוצאה משימוש (עם חריגים) | מניעת ההוצאה משימוש כדי להבטיח זמן להעברה | |
|---|---|---|---|
| מדיניות הרשאות (חלה על דפים/אתרים) |
כן | כן | כן |
| מדיניות ארגונית (חלה על מכשירים) |
לא | לא | כן |
| סימונים ל-Chrome (מתייחס למשתמשים ספציפיים) |
כן | לא | לא |
| החלפה של שורת הפקודה ב-Chrome (חל על משתמשים ספציפיים) |
כן | לא | כן |
סיכום
אנחנו מוציאים משימוש את רכיבי ה-handler של unload. הם לא היו אמינים במשך זמן רב, ולא בטוח שהם יופצו בכל מקרה שבו מסמך הושמד. בנוסף, רכיבי ה-handler של unload לא תואמים ל-bfcache.
אתרים שמשתמשים כרגע ברכיבי handler של unload צריכים להתכונן להוצאה משימוש המתוכננת באמצעות בדיקה של רכיבי handler קיימים של unload, הסרה או העברה שלהם, או כמוצא אחרון, השהיה של ההוצאה משימוש במקרה שיידרש זמן נוסף.
אישורים
תודה קנג'י באהו, פרגל דיילי, אדריאנה חארה וג'רמי וגנר על העזרה בסקירת המאמר הזה.
תמונה ראשית (Hero) מאת אניה באורן ב-UnFlood