נכתב על ידי דני צ'רניאק, DigiKnowledge. נבדק לאחרונה: 4.11.2026

גוגל השלימה את ההוצאה משימוש של אירוע unload בכרום. לפי הבלוג של Chrome מ-16 באוקטובר 2026, החל מ-Chrome 155 קוד שמאזין ל-unload כבר לא רץ כברירת מחדל. כל תג מדידה שנשען על האירוע הזה, למשל תג Custom HTML ב-Google Tag Manager ששולח "יציאה מהעמוד", זמן שהייה או נטישת טופס ברגע העזיבה, הפסיק לשלוח נתונים מרוב הגולשים בכרום. התיקון: לשלוח את הנתונים כשהעמוד עובר למצב hidden באירוע visibilitychange. בקוד ששולח לשרת שלכם משתמשים ב-navigator.sendBeacon().

מה בדיוק השתנה בכרום?

במשך שנים אתרים השתמשו באירוע unload כדי לבצע פעולה אחרונה רגע לפני שהגולש עוזב את העמוד. אחד השימושים הנפוצים היה לשלוח נתוני אנליטיקה. גוגל הודיעה עוד ב-2023 שהיא מוציאה את האירוע משימוש, בעיקר כי הוא חוסם את ה-back/forward cache (bfcache) שמאפשר חזרה מיידית לעמוד הקודם.

ההוצאה משימוש נעשתה בהדרגה. לפי הבלוג של Chrome היא נמשכה ממרץ 2025 עד ספטמבר 2026: קודם ב-50 אתרים גדולים ואחר כך בכל האתרים, לפי אחוז מטעינות העמודים בכרום. לפי טבלת הזמנים הרשמית, ב-Chrome 146 (מרץ 2026) זה חל על 1% מטעינות העמודים, ב-Chrome 152 (אוגוסט 2026) על 80% וב-Chrome 155 על 100%. מאז, לפי התיעוד של Chrome, "אירוע unload לא יופעל יותר כברירת מחדל ו-handlers של unload לא ירוצו", אלא אם האתר ביקש במפורש להחזיר אותם.

שלושה פרטים חשובים מופיעים במקורות הרשמיים. השינוי יופעל בקרוב כברירת מחדל גם בקוד של Chromium, כך שגם דפדפנים אחרים שמבוססים עליו יקבלו אותו אם לא ישנו את ברירת המחדל. בכרום ל-iOS האירוע עדיין עשוי לפעול, כי שם כרום משתמש במנוע WebKit של ספארי. לפי גוגל השימוש ב-unload ירד במהלך ההפצה מ-18% מהניווטים לפחות מ-4%.

לפי התיעוד הרשמי של Chrome

איך unload הפסיק לפעול בכרום

2025הפצה הדרגתית ב-50 אתרים גדולים
Chrome 146, מרץ 20261% מטעינות העמודים בכל האתרים
Chrome 152, אוגוסט 202680% מטעינות העמודים
Chrome 155100%: unload לא מופעל כברירת מחדל
ההפצה חושבה לפי טעינות עמודים ולא לפי משתמשים או אתרים. מקור: Deprecating the unload event, Chrome for Developers.

אילו תגי מדידה נפגעו?

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

  • תג Custom HTML ב-GTM עם window.addEventListener('unload', ...) או window.onunload שדוחף ל-dataLayer אירוע כמו page_exit.
  • מדידת זמן שהייה "אמיתי" שנשלח רק כשהגולש עוזב את העמוד.
  • מדידת נטישת טופס: אילו שדות מולאו לפני שהגולש יצא בלי לשלוח.
  • סיכום של עומק גלילה או של אחוז צפייה בווידאו שנשלח פעם אחת ביציאה.
  • קוד מדידה בתבנית האתר או בספריית צד שלישי. גוגל מציינת במפורש שהשימוש יכול להיות "בקוד שלכם או בספריות".

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

איך בודקים אם האתר שלכם מושפע?

  1. מחפשים בקונטיינר של GTM. ב-Admin לוחצים Export Container, בוחרים את הגרסה שפורסמה ומורידים את קובץ ה-JSON. מחפשים בקובץ את המחרוזות unload, onunload ו-beforeunload. כל תג שמופיעה בו אחת מהן צריך בדיקה.
  2. מריצים את בדיקת ה-bfcache בכרום. פותחים את העמוד, נכנסים ל-DevTools, עוברים ל-Application, Background services, Back/forward cache ולוחצים Test back/forward cache. אם יש מאזין ל-unload הוא יופיע תחת Actionable.
  3. בודקים מה מונע bfcache אצל גולשים אמיתיים. המאפיין notRestoredReasons ב-PerformanceNavigationTiming מחזיר את הסיבה unload-listener כשמאזין כזה קיים בעמוד.
  4. מסתכלים על הנתונים ב-GA4. ב-Exploration שמים את שם האירוע, מימד הדפדפן וחודש. בודקים אם אירוע היציאה ירד בכרום במהלך 2026 בזמן שבספארי הוא יציב. זה הסימן הכי ברור לכך שהאירוע נשען על unload.

איך מתקנים את תג המדידה?

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

הנה תג Custom HTML ל-GTM שמחליף מאזין unload ישן. הוא דוחף ל-dataLayer אירוע אחד בכל פעם שהעמוד מוסתר ומאפס את עצמו אם הגולש חוזר לעמוד מה-bfcache:

<script>
(function () {
  var sent = false;
  function sendOnce(reason) {
    if (sent) return;
    sent = true;
    window.dataLayer = window.dataLayer || [];
    window.dataLayer.push({ event: 'page_hidden', hide_reason: reason });
  }
  document.addEventListener('visibilitychange', function () {
    if (document.visibilityState === 'hidden') sendOnce('visibilitychange');
  });
  window.addEventListener('pagehide', function () { sendOnce('pagehide'); });
  window.addEventListener('pageshow', function (e) {
    if (e.persisted) sent = false;
  });
})();
</script>

שני דברים משתנים כשעוברים לשיטה הזו. הראשון הוא המשמעות של האירוע: visibilitychange מופעל גם כשהגולש עובר ללשונית אחרת או ממזער את החלון, כלומר זה כבר לא "יציאה מהאתר" אלא "העמוד הוסתר". לכן כדאי לתת לאירוע שם חדש ולא להמשיך את הסדרה הישנה כאילו כלום לא קרה. השני הוא הבדיקה: אחרי הפרסום מוודאים ב-Preview של GTM שהאירוע נדחף. אחר כך מוודאים ב-DebugView או ב-Realtime של GA4 שהוא באמת מגיע.

אם הקוד שולח נתונים ישירות לשרת שלכם ולא דרך GTM, MDN ממליצה על navigator.sendBeacon() בתוך אותו מאזין. הפונקציה שולחת בקשת POST באופן אסינכרוני, בלי לעכב את המעבר לעמוד הבא. היא מחזירה true אם הנתונים נכנסו לתור. סך הנתונים בתור מוגבל ל-64 KiB. כשצריך שיטה אחרת מ-POST או גישה לתשובת השרת, MDN מפנה ל-fetch() עם keepalive: true.

document.addEventListener('visibilitychange', function () {
  if (document.visibilityState === 'hidden') {
    navigator.sendBeacon('/log', analyticsData);
  }
});

במה מחליפים כל אירוע?

אירועמה המצב היוםמתי להשתמש בו למדידה
unloadלא מופעל כברירת מחדל בכרום מאז Chrome 155. עשוי עדיין לפעול בכרום ל-iOS ובאתרים שביקשו להחזיר אותו.לא להשתמש. להחליף.
visibilitychange (hidden)לפי MDN, האירוע האחרון שאפשר לזהות באופן אמין.הבחירה הראשית לשליחת נתונים בסוף צפייה.
pagehideמופעל בניווט, ברענון ובסגירה. לא חוסם bfcache, כך שהעמוד עשוי לחזור אחריו.השלמה ל-visibilitychange. לא מופעל במעבר לשונית.
beforeunloadלפי Chrome לא אמין, כי הוא לא מופעל כשלשונית ברקע נסגרת על ידי הדפדפן.רק לאזהרה על שינויים שלא נשמרו, רק כשיש צורך. לא למדידה.

מה לא כדאי לעשות?

לא להחזיר את unload דרך Permissions-Policy כפתרון קבוע. גוגל משאירה את האפשרות הזו לאתרים שחייבים אותה, אבל כותבת במפורש שהיא לא הופכת את האירוע לאמין יותר במובייל ושכדאי לעבור ממנו. מדיניות ה-Enterprise בשם ForcePermissionPolicyUnloadDefaultEnabled מיועדת למכשירים מנוהלים בארגון ולא משפיעה על הגולשים שלכם.

לא לעבור ל-beforeunload. לפי התיעוד של Chrome גם הוא לא אמין. גוגל ממליצה להגביל את השימוש בו.

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

שאלות נפוצות

האם זה משפיע על התג הרגיל של GA4 ב-GTM?

השינוי משפיע על קוד שמאזין ל-unload. אם בקונטיינר אין תג או קוד שמאזין לאירוע הזה, החיפוש בקובץ ה-JSON יראה את זה. הבדיקה הזו חשובה במיוחד בקונטיינרים ישנים עם תגי Custom HTML.

מאיזו גרסה של כרום unload לא פועל?

לפי התיעוד של Chrome ההוצאה משימוש הושלמה ב-Chrome 155, אחרי הפצה הדרגתית שהחלה ב-2025. מאז האירוע לא מופעל כברירת מחדל, אלא אם האתר ביקש במפורש להחזיר אותו.

מה עם ספארי ופיירפוקס?

ההודעה של גוגל עוסקת בכרום ובדפדפנים מבוססי Chromium. בכרום ל-iOS האירוע עדיין עשוי לפעול, כי הוא משתמש במנוע WebKit. בכל מקרה גם MDN וגם Chrome ממליצים לא להסתמך על unload בשום דפדפן.

visibilitychange שולח את האירוע גם כשעוברים לשונית. זו בעיה?

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

איך יודעים אם הנתונים הישנים נפגעו?

משווים את האירוע לפי דפדפן ולפי חודש לאורך 2026. ירידה הדרגתית בכרום עם יציבות בספארי מתאימה לקצב ההפצה של גוגל, שעבר מ-1% מטעינות העמודים במרץ 2026 ל-100% ב-Chrome 155.

מה השורה התחתונה?

אם הקונטיינר שלכם נבנה לפני כמה שנים, יש סיכוי טוב שיש בו תג שנשען על unload ושהנתונים שלו נעלמו בשקט במהלך 2026. הבדיקה לוקחת כמה דקות: ייצוא הקונטיינר, חיפוש מחרוזת ובדיקת bfcache בכרום. את שאר הבדיקות של הקונטיינר תמצאו במדריך Google Tag Manager המלא ובצ'קליסט אודיט GA4. אנחנו מבצעים את הבדיקה הזו כחלק משירות הטמעת Google Tag Manager. אם תרצו שנבדוק את הקונטיינר שלכם, כתבו לנו.

מקורות

דני צ'רניאק
דני צ'רניאק
יועץ אנליטיקה דיגיטלית ומייסד DigiKnowledge. מרצה לאנליטיקה דיגיטלית באוניברסיטת תל אביב, באוניברסיטה הפתוחה ובאוניברסיטת אריאל. לעמוד האישי

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *