После кнопки «Назад» сайт показывает старые данные: как проверить bfcache

Если после кнопки «Назад» сайт показывает прежний статус заказа, старую корзину или уже недействующие данные профиля, причина может быть не в сервере. Браузер способен вернуть страницу из bfcache — памяти для переходов назад и вперёд — вместе с DOM и состоянием JavaScript, не выполняя обычную загрузку заново.

Сначала подтвердите восстановление из bfcache через событие pageshow и флаг persisted. Затем обновляйте только данные, которые могли измениться, либо перезагружайте страницу, если безопасно синхронизировать состояние частично нельзя. Отключать bfcache для всего сайта обычно не нужно.

Чем bfcache отличается от обычного кеша

HTTP-кеш хранит ответы на запросы, а bfcache сохраняет снимок страницы целиком. Когда пользователь возвращается по истории, браузер может продолжить работу со старым DOM и объектами JavaScript с того места, где они были приостановлены.

Поэтому очистка кеша ресурсов не всегда меняет результат. Обработчики load и DOMContentLoaded при восстановлении снимка повторно не запускаются, а интерфейс может остаться таким, каким был до перехода на другую страницу.

Подозревать bfcache стоит, если проблема возникает именно после «Назад» или «Вперёд» и исчезает после обычного обновления страницы. Если устаревшие данные видны также в новой вкладке, приватном окне или на другом устройстве, проверяйте сервер, CDN, service worker и прикладной кеш.

Как подтвердить причину

1. Запишите точный сценарий

Не начинайте с случайного обновления страницы: оно уничтожит нужное состояние. Зафиксируйте исходный URL, действие, после которого данные меняются, страницу перехода и результат после возврата.

Например: открыть корзину, перейти к изменению количества товара, сохранить его и нажать «Назад». Для личного кабинета отдельно проверьте возврат после выхода из учётной записи.

2. Проверьте событие pageshow

Временно добавьте диагностический обработчик:

window.addEventListener('pageshow', (event) => {
  console.log('pageshow', { persisted: event.persisted });
});

persisted: true означает, что страница восстановлена из bfcache. Отсутствие нового запроса документа в Network — полезный признак, но само по себе это ещё не доказательство: ориентируйтесь на событие.

3. Используйте проверку браузера

В Chrome откройте DevTools → Application → Background services → Back/forward cache и запустите тест. Панель покажет, восстановилась ли страница из bfcache и какие причины мешают этому. Повторите реальный пользовательский маршрут вручную: встроенный тест проверяет пригодность страницы, но не знает бизнес-логику вашего интерфейса.

4. Сравните четыре источника старого состояния

• pageshow.persisted === true, а интерфейс устарел — обновляйте состояние после восстановления;
• документ загрузился заново, но ответ старый — проверяйте HTTP-заголовки и CDN;
• запросы перехватывает service worker — проверяйте его стратегию кеширования и смену версии;
• API уже возвращает старое значение — причина находится на сервере или в прикладном кеше.

Такой порядок не даёт списать любую проблему со словом «кеш» на браузер и очищать всё хранилище без диагноза.

Как обновить данные после возврата

Подпишитесь на pageshow и при persisted: true запросите только критичное состояние: статус заказа, состав корзины, права пользователя, актуальность сессии. Ниже условный пример — адрес API и функцию отображения нужно заменить на реальные:

window.addEventListener('pageshow', async (event) => {
  if (!event.persisted) return;

  const response = await fetch('/api/cart/summary', { cache: 'no-store' });
  if (!response.ok) {
    location.reload();
    return;
  }

  renderCart(await response.json());
});

Параметр cache: 'no-store' здесь относится к одному запросу свежих данных. Он не требует запрещать bfcache для всего документа.

Если частичное обновление может оставить противоречивый интерфейс, после восстановления лучше выполнить один полный location.reload(). Для страницы после выхода из аккаунта сначала скройте чувствительный блок, перепроверьте сессию и только потом показывайте данные. Сервер всё равно обязан заново проверять авторизацию для каждого защищённого действия: исправление интерфейса не является границей безопасности.

Какие исправления создают новые проблемы

• Не добавляйте unload ради принудительного сброса состояния. Событие ненадёжно, а его обработчик может мешать использованию bfcache.
• Не ставьте Cache-Control: no-store на весь сайт без отдельной причины. Это ухудшает быстрые переходы и не исправляет ошибку синхронизации данных.
• Не очищайте cookies, Local Storage и Cache Storage всем пользователям. Сначала установите, где именно хранится устаревшее значение.
• Не обновляйте страницу при каждом pageshow: событие происходит и при обычной загрузке. Проверяйте event.persisted.
• Не считайте исправление завершённым после теста в одном браузере. Правила сохранения и вытеснения страниц различаются, поэтому нужен прогон в целевых браузерах и на мобильных устройствах.

Чек-лист перед выпуском исправления

1. Сценарий «изменить данные → перейти → вернуться» показывает актуальное состояние.
2. Возврат после выхода не раскрывает прежние персональные данные.
3. Кнопки и формы не отправляют действие повторно из старого состояния.
4. Обычная загрузка и возврат из bfcache различаются в журнале диагностики.
5. При ошибке API интерфейс не изображает успешную синхронизацию.
6. Сервер проверяет сессию и права независимо от состояния страницы.
7. Аналитика не теряет и не удваивает переходы после возврата.

После релиза повторите весь маршрут, а не только открытие URL. Дополнительный чек-лист проверки сайта после обновления поможет проверить формы, редиректы, мобильную версию и другие соседние риски.

Где здесь помогает мониторинг

Внешний мониторинг не нажимает кнопку «Назад» и не видит DOM конкретного пользователя, поэтому он не заменяет браузерный тест bfcache. Его роль другая: отделить ошибку жизненного цикла страницы от реальной недоступности URL или API и сохранить историю ответа сервера.

Если критичная страница должна оставаться доступной после исправления, добавьте её в мониторинг Web-Puls. Сценарий возврата проверяйте в браузерных тестах, а доступность адреса — отдельной внешней проверкой.

Вывод

Старые данные после кнопки «Назад» исправляют не тотальным запретом кеша, а синхронизацией состояния. Подтвердите bfcache через pageshow.persisted, определите данные, которые обязаны обновиться, выберите точечный запрос или полную перезагрузку и повторите реальный маршрут в целевых браузерах.