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

Demián Renzulli

Barry Pollard

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

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

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

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

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

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

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

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

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

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

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

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

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

כלי פיתוח ל-Chrome

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

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

1. בדף, פותחים את DevTools ועוברים אל Application‏ > Background services‏ > Back/forward cache.

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

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

Reporting API

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

פרטים נוספים זמינים במאמר שימוש ב-Reporting API כדי למצוא הורדות

Bfcache notRestoredReasons API

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

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

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

דגלים של Chrome ומאפיינים של שורת הפקודה

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

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

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

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

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

סיכום

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

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

תודות

תודה ל-Kenji Baheux,‏ Fergal Daly,‏ Adriana Jara ו-Jeremy Wagner על העזרה בבדיקת המאמר הזה.

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