האירוע unload יוצא משימוש בהדרגה. לשם כך, אנחנו משנים בהדרגה את ברירת המחדל כך שהגורמים המטפלים באירועים מסוג unload יפסיקו להפעיל אותם בדפים, אלא אם הבעלים של הדף יאשרו מפורשות להפעיל אותם מחדש.
ציר הזמן להוצאה משימוש
שמנו לב שההתנהגות של הסרת הנתונים שנטענו עשויה להיות כפופה לשינויים כבר בינואר 2019, כאשר הודענו על הכוונה שלנו להטמיע מטמון לדף הקודם/הבא. במקביל לעבודות ההטמעה, ערכנו קמפיין נרחב ליצירת קשר עם משתמשים, שהביא לירידה משמעותית בשימוש בהורדת נתונים. כדי להשלים את הפעילות הזו, התחלנו גם להציע דרכים לבדוק את ההשפעה של ההוצאה משימוש של 'פריקה' מ-Chrome 115:
- בדיקה בשטח באמצעות Permission-Policy API for unload ב-Chrome 115 (יולי 2023)
- בדיקה מקומית על ידי הפעלת דגל ב-Chrome 117 (ספטמבר 2023)
לאחר שלבי ההפצה והניסוי, כך אנחנו מצפים להשקה של ההוצאה משימוש משימוש:
- שלב מוגבל שבו הפעולה 'פריקה' תפסיק לפעול בהדרגה ב-50 האתרים הפופולריים ביותר (מקור המידע נכון למועד כתיבת המאמר).
- נתחיל עם 1% מהמשתמשים מ-Chrome 120 (סוף נובמבר 2023).
- עד 100% מהמשתמשים עד סוף הרבעון השלישי של 2024
- בנוסף, החל מרבעון שלישי של שנת 2024, אנחנו מתכוונים להתחיל שלב כללי שבו הפונקציה unload תפסיק לפעול בהדרגה בכל האתרים, החל מ-1% מהמשתמשים ועד 100% מהמשתמשים עד סוף הרבעון הראשון של שנת 2025.
חשוב לדעת שאנחנו מציעים גם תפריט של אפשרויות ביטול ההסכמה למקרה שתקופת ההוצאה משימוש בהדרגה לא מספקת לכם מספיק זמן להפסיק להשתמש ב-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 כוללים בדיקה של back-forward-cache שבעזרתה אפשר לזהות בעיות שעשויות למנוע את האפשרות לשמור את הדף במטמון לדף הקודם/הבא, כולל השימוש במטפל unload.
כדי לבדוק את התכונה 'מטמון לדף הקודם/הבא', פועלים לפי השלבים הבאים:
בדף, פותחים את DevTools ועוברים אל Application > Background services > Back/forward cache.
לוחצים על בדיקת מטמון לדף הקודם/הבא Chrome מעביר באופן אוטומטי אל
chrome://terms/וחוזר לדף. לחלופין, אפשר ללחוץ על הלחצנים 'הקודם' ו'הבא' בדפדפן.
אם הדף לא עומד בדרישות לשמירה במטמון לדף הקודם/הבא, בכרטיסייה מטמון לדף הקודם/הבא תוצג רשימה של בעיות. בקטע פעולות שאפשר לבצע תוכלו לראות אם אתם משתמשים ב-unload:
Reporting API
אפשר להשתמש ב-Reporting API בשילוב עם מדיניות הרשאות לקריאה בלבד כדי לזהות את השימוש ב-unload על ידי משתמשי האתר.
פרטים נוספים זמינים במאמר שימוש ב-Reporting API כדי למצוא הורדות
Bfcache notRestoredReasons API
הנכס notRestoredReasons – שנוסף לכיתה PerformanceNavigationTiming – מדווח אם מסמכים נחסמו משימוש ב-bfcache בניווט, ומסביר למה. הוראות השימוש זמינות כאן. זוהי דוגמה לאופן שבו נראית האזהרה של אובייקט התגובה מ-listenen unload קיים:
{
children: [],
id: null,
name: null,
reasons: [
{"reason", "unload-handler"}
],
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 ישנה את ברירת המחדל כך שהם לא יופעלו בעתיד. כאן מוסבר איך להמשיך לאפשר ל-handlers של הסרת הנתונים שנטענו עבור האתר שלכם. ההסכמה הזו לא תישאר לתמיד, וצריך להשתמש בה כדי לתת לאתרים זמן לעבור מהמפעילים של 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