pageshow.persisted가 true인 복원에서 데이터를 무조건 처음부터 다시 fetch해야 하나요?

무조건 전체 fetch를 다시 하지는 않습니다. persisted:true는 history 문서가 bfcache 복원 경로로 표시됐을 가능성을 알려 주는 신호이지, 보관된 데이터가 모두 무효라는 뜻은 아닙니다. 복원 화면은 우선 보여 주되 데이터별 최신성 계약을 적용합니다. 검색 목록은 기존 결과를 즉시 보여 주고 ETag 조건부 요청으로 확인할 수 있지만, 가격·권한·예약 가능 여부처럼 행동을 결정하는 값은 버튼을 활성화하거나 변경 요청을 처리할 때 서버가 현재 상태를 다시 검사해야 합니다.

상태를 숫자로 추적하면 전체 재fetch와 선택 검증의 차이가 명확합니다. 복원 직후 화면 세대 7, account A, 목록 ETag "v7"에서 검증 요청 A를 보냅니다. 사용자가 응답 전에 계정을 B로 바꾸면 화면 세대 8이 되고 B용 요청도 시작합니다. A가 먼저 304 Not Modified로 도착해도 세대 7 또는 account A와 연결된 응답이므로 폐기합니다. B 응답만 세대 8 화면에 반영합니다. 조건부 요청은 전송량을 줄일 뿐, 계정 namespace와 세대 검사를 대신하지 않습니다.

persisted:false의 최초 진입도 같은 진입 함수를 통과하게 하되, 복원에서만 stale 표시를 허용할지 정책을 다르게 둘 수 있습니다. 반대로 모든 pageshow에서 입력과 화면을 초기화하면 bfcache가 보존한 검색어·스크롤을 덮습니다. 개인정보나 권한을 pageshow만으로 보호한다고 말해서도 안 됩니다. 먼저 DOM이 잠시 그려질 수 있고, 실제 개인 데이터 반환의 최종 경계는 매 API 요청의 서버 인가입니다. 예를 들어 목록은 200ms 안에 기존 화면을 유지하면서 검증하고, 결제 가능 여부는 검증 전 unknown으로 두어 클릭을 서버에 보내지 않습니다. 데이터별 허용 stale 시간과 실패 시 표시 문구를 정하면 전체 fetch보다 사용자 경험과 비용을 함께 조정할 수 있습니다.