bfcache в SPA: как не потерять мгновенный back/forward UX и не проснуться со старым сос... — 17 июня 2026 г. в 12:07:05
bfcache в SPA: как не потерять мгновенный back/forward UX и не проснуться со старым состоянием bfcache - не кэш данных, а заморозка всей страницы: DOM, JS heap, scroll, router state и React/Vue-приложение. В production он ускоряет возврат назад/вперед, но часто ломается из-за cleanup «на всякий случай» или восстанавливает устаревшую сессию. Диагностика восстановления Главный сигнал - pageshow. При возврате из bfcache load не сработает, поэтому bootstrap, завязанный только на DOMContentLoaded / load, пропустит важную логику. window.addEventListener('pageshow', e => { if (e.persisted) { revalidateCriticalQueries(); syncAuthState(); reconnectRealtime(); resumeTimers(); } }); window.addEventListener('pagehide', e => { if (e.persisted) { pausePolling(); closeEphemeralConnections(); } }); Что блокирует bfcache Частые причины: * unload handler; * лишний beforeunload; * WebSocket, WebRTC, BroadcastChannel, Web Locks; * незавершенные IndexedDB-транзакции; * активные fetch/stream-операции; * Cache-Control: no-store; * сторонние скрипты с unload. Типичная ошибка SPA - вешать unload для cleanup. Используйте pagehide, но не уничтожайте store и router state, если event.persisted === true. Как искать причины В Chrome DevTools откройте Application - Back/forward cache и запустите тест навигации. DevTools покажет blockers: active connection, unsupported feature, unload handler. Для логов используйте pageshow.persisted и pagehide.persisted. performance.getEntriesByType('navigation')[0].type === 'back_forward' полезен, но не гарантирует успешный restore из bfcache. Что восстанавливать после pageshow Проверяйте только внешнее состояние: auth/session, критичные query cache, realtime, polling, feature flags, time-based данные и синхронизацию вкладок. Вывод: bfcache - это продолжение жизни страницы, поэтому надежная SPA не перезапускается целиком, а точечно возобновляет ресурсы и пересинхронизирует данные.