No Unload Listeners

Why It Matters

• Unload listeners disable bfcache. The back-forward cache lets browsers instantly restore a page when users navigate back or forward. Unload listeners signal that the page needs special cleanup, so the browser skips caching and forces a full reload instead.
• Full reloads are slow. Without bfcache, going "back" means re-downloading resources, re-executing JavaScript, and re-rendering the page from scratch. Users expect the back button to be instant, and a multi-second reload feels broken.
• The unload event is unreliable anyway. On mobile browsers, the unload event does not fire consistently. Closing a tab, switching apps, or the browser being killed by the OS can all skip the unload event entirely, so your cleanup code may never run.
• It hurts Core Web Vitals. Pages that cannot be served from bfcache have worse navigation timing. Since bfcache restorations are essentially zero-cost page loads, losing them means higher average load times across your site.

How to Fix It

1. Replace unload with pagehide. The pagehide event fires in the same situations as unload but does not prevent bfcache. Move your cleanup code from unload to pagehide for identical functionality without the performance penalty.
2. Use visibilitychange for analytics. If you are using unload to send analytics data when users leave, switch to the visibilitychange event instead. It fires more reliably across browsers and devices, especially on mobile.
3. Use sendBeacon for last-moment data. The navigator.sendBeacon() method is designed specifically for sending small amounts of data as the page unloads. It is non-blocking and works reliably without preventing bfcache.
4. Search for unload in your codebase. Look for addEventListener('unload' and window.onunload in your own scripts and third-party libraries. Remove or replace every instance you find.
5. Check third-party scripts. Analytics libraries, chat widgets, and ad scripts sometimes register unload listeners. Check their documentation for newer integration methods that avoid the unload event, or contact the provider for updated code.

Common Mistakes

• Confusing unload with beforeunload. The beforeunload event (used for "are you sure you want to leave?" prompts) is a separate issue. While it can also affect bfcache, it has legitimate uses for unsaved form data. The unload event rarely has a valid modern use case.
• Not checking third-party code. Your own code might be clean, but a third-party script could be registering an unload listener behind the scenes. Test your page's bfcache eligibility to catch hidden unload handlers.
• Assuming unload fires reliably on mobile. Mobile browsers aggressively manage memory and may terminate pages without firing the unload event. Any cleanup logic that depends on unload is fundamentally unreliable on mobile devices.
• Keeping unload "just in case." Some developers leave unload listeners in place as a safety net alongside newer alternatives. Even an empty unload listener can prevent bfcache. Remove them completely.