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

Если кнопка «Назад» вернула старые данные, проверьте событие pageshow и его persisted: значение true указывает на восстановление страницы из bfcache. После такого возврата перечитайте изменяемые данные, сохранив пользовательский черновик. Обычная очистка HTTP-кеша не объясняет, какой именно механизм вернул старый экран.

Почему экран вернулся без обычной загрузки

Bfcache сохраняет снимок страницы в памяти, включая состояние JavaScript. Это отличается от HTTP-кеша с ответами на запросы: браузер может восстановить уже существовавший документ. Различие описано в руководстве web.dev. Поэтому код, рассчитанный только на первоначальную загрузку, не всегда решает задачу актуализации после возврата.

Признак старых данных сам по себе ещё не диагноз. Похожий результат бывает у клиентского хранилища, ответа из другого слоя кеширования или перехода внутри приложения. Сначала восстановите точный маршрут: откуда ушли, куда перешли и какой кнопкой вернулись. Без него можно исправить не тот участок.

Что зафиксировать в одном воспроизведении

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

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

Учебный маршрут: карточка изменилась, черновик остался

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

Не стирайте всю форму ради обновления одного статуса. Разделите серверные сведения и локальные изменения. Если обновившаяся запись влияет на возможность сохранить комментарий, покажите понятное состояние конфликта, а не принимайте тихо решение за пользователя.

Какие данные требуют повторного чтения

Выберите поля по смыслу операции: статус, наличие ресурса, разрешённые действия или результат фоновой обработки. Текст справки не обязательно перечитывать вместе с ними. Чем яснее граница изменяемой части, тем проще обновить экран без потери рабочего контекста.

Для каждого ответа определите, к какой записи и попытке чтения он относится. Пока запрос выполняется, пользователь может открыть другой объект. Старый ответ не должен перезаписать уже новую карточку. Это отдельное условие корректности обновления, а не свойство, которое bfcache обеспечит за приложение.

Если проверка не удалась, не скрывайте это за прежними данными. Можно сохранить экран с отметкой неподтверждённой актуальности и доступным повтором. Для действий, которым требуется точное состояние, задайте отдельное ограничение до получения результата по принятой логике продукта.

Что сервер всё равно проверяет сам

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

Не превращайте повторное чтение при возврате в повторную отправку команды. Получить текущий статус и ещё раз выполнить прежнее изменение — разные операции. Возвращение к карточке не является новым согласием пользователя на действие с последствиями.

Почему принудительная перезагрузка не всегда подходит

Перезагрузка может убрать видимый старый экран, но одновременно потерять ввод и место работы. Если делать её безусловно на каждом событии, получится труднообъяснимое поведение. Сначала проверьте, достаточно ли обновить нужные данные и обозначить результат проверки.

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

Как принять исправление

1. Подготовьте учебную запись и отдельно набранный, но не отправленный черновик.
2. Откройте карточку, зафиксируйте исходное состояние и выполните реальный переход на другой документ.
3. Измените серверное состояние контролируемым способом в тестовой среде.
4. Вернитесь кнопкой браузера и сохраните фактическое событие с persisted.
5. Проверьте обновление нужных полей, сохранность черновика и отсутствие повторной команды.
6. Повторите сценарий без восстановления из bfcache и с недоступным повторным чтением.

Проверку проводите в используемых браузерах и на согласованных маршрутах. Один успешный возврат не доказывает все сочетания навигации, черновиков и изменившихся прав. В протоколе перечислите именно выполненные сценарии; эта статья предлагает план проверки, а не сообщает о проведённом тесте вашего сайта.

Что передать разработчику

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

Когда статус приходит из другой системы, правила API-интеграции должны объяснять, какой ответ подтверждает актуальное состояние. Тогда исправление можно принять по результату: нужные сведения обновились, незавершённая работа сохранилась, лишняя команда не отправилась.