상품 상세를 보고 뒤로 가기를 눌렀는데 목록이 처음부터 다시 로딩되고 스크롤 위치까지 사라진다면, 브라우저의 뒤로/앞으로 캐시(bfcache)가 막혀 있을 가능성이 큽니다.
bfcache가 동작하면 이전 페이지가 메모리에 통째로 남아 있다가 거의 즉시 복원됩니다. 크롬 개발자 도구로 막는 원인을 확인하고 하나씩 걷어내는 순서를 정리했습니다.

1. 크롬 개발자 도구로 막힌 이유부터 확인

추측으로 코드를 고치기 전에 원인부터 확인합니다. 크롬에서 해당 페이지를 열고 F12 → Application 탭 → 왼쪽 메뉴의 Back/forward cache로 들어가 Test back/forward cache 버튼을 누르면, 페이지를 잠깐 이동했다가 돌아오면서 복원 성공 여부와 막힌 사유를 목록으로 보여 줍니다.

사유 중 직접 고칠 수 있는 항목만 보면 됩니다. 실무에서 가장 자주 보는 원인은 아래 세 가지였습니다.

2. unload 대신 pagehide 쓰기

오래된 통계 스크립트나 "페이지를 떠날 때 저장" 같은 코드에 unload 이벤트가 남아 있는 경우가 많습니다. 이 이벤트가 등록돼 있으면 bfcache 대상에서 빠지는 브라우저가 많고, 크롬은 unload 이벤트 자체를 단계적으로 없애는 중입니다. 같은 일을 pagehide에서 하면 됩니다.

/* 이전 방식: bfcache를 막음 */
window.addEventListener('unload', saveState);

/* 권장 방식 */
window.addEventListener('pagehide', saveState);

외부 위젯이나 오래된 플러그인이 범인인 경우도 많으니, 소스에서 unload를 한 번 검색해 보세요.

3. no-store 헤더는 꼭 필요한 페이지에만

서버나 보안 플러그인이 모든 페이지에 Cache-Control: no-store를 붙이는 경우가 있습니다. 이 헤더가 붙은 페이지는 대부분의 브라우저에서 bfcache 대상에서 제외됩니다. 마이페이지나 결제 화면처럼 개인정보가 보이는 곳은 그대로 두고, 회사 소개나 상품 목록처럼 누구에게나 같은 페이지는 빼 주는 것이 맞습니다. 헤더는 개발자 도구 Network 탭에서 문서 요청을 눌러 Response Headers로 확인할 수 있습니다.

4. 복원된 페이지에서 화면 갱신하기

bfcache로 돌아오면 페이지가 새로 로딩되지 않으니 DOMContentLoaded나 load도 다시 일어나지 않습니다. 장바구니 개수처럼 최신 값이 필요한 부분은 pageshow 이벤트의 persisted 값으로 구분해서 갱신합니다.

window.addEventListener('pageshow', (e) => {
  if (e.persisted) {
    /* bfcache에서 복원된 경우 */
    updateCartCount();
  }
});

고친 뒤에는 다시 Test back/forward cache를 눌러 "Successfully served from back/forward cache" 문구가 나오는지 확인하면 끝입니다.