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

Demián Renzulli

Barry Pollard

האירוע 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 לא מהימן במיוחד.

ב-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.

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

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

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

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

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

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

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

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

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

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

סיכום

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

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

תודות

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

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