뒤로 가기 하면 페이지가 처음부터 다시 뜰 때, bfcache 막는 원인 찾는 법
상품 상세를 보고 뒤로 가기를 눌렀는데 목록이 처음부터 다시 로딩되고 스크롤 위치까지 사라진다면, 브라우저의 뒤로/앞으로 캐시(bfcache)가 막혀 있을 가능성이 큽니다.
bfcache가 동작하면 이전 페이지가 메모리에 통째로 남아 있다가 거의 즉시 복원됩니다. 크롬 개발자 도구로 막는 원인을 확인하고 하나씩 걷어내는 순서를 정리했습니다.
💡 뒤로 가기 속도가 왜 그렇게 중요할까요?
쇼핑몰이나 게시판처럼 목록 → 상세 → 다시 목록을 반복하는 사이트에서는 뒤로 가기가 가장 자주 쓰이는 이동 중 하나입니다. 매번 서버에 다시 요청하고 스크립트를 새로 실행하면, 사용자는 같은 화면을 여러 번 기다리게 됩니다. bfcache는 별도 설정 없이 브라우저가 알아서 해 주는 기능이라, 막고 있는 코드만 정리해도 체감 속도가 확 달라집니다.
1. 크롬 개발자 도구로 막힌 이유부터 확인
추측으로 코드를 고치기 전에 원인부터 확인합니다. 크롬에서 해당 페이지를 열고 F12 → Application 탭 → 왼쪽 메뉴의 Back/forward cache로 들어가 Test back/forward cache 버튼을 누르면, 페이지를 잠깐 이동했다가 돌아오면서 복원 성공 여부와 막힌 사유를 목록으로 보여 줍니다.
사유 중 직접 고칠 수 있는 항목만 보면 됩니다. 실무에서 가장 자주 보는 원인은 아래 세 가지였습니다.
| 막는 원인 | 대응 방법 |
|---|---|
| unload 이벤트 | pagehide 이벤트로 교체 |
| Cache-Control: no-store | 개인정보 없는 페이지는 no-store 제거 |
| 열어 둔 연결(WebSocket 등) | pagehide에서 닫고 pageshow에서 다시 연결 |
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" 문구가 나오는지 확인하면 끝입니다.
"빠른 사이트는 앞으로 갈 때만이 아니라 돌아올 때도 빨라야 합니다."
나눔웹은 리뉴얼과 유지관리 때 이런 보이지 않는 이동 속도까지 함께 점검합니다.
방문자가 자주 오가는 화면일수록 작은 설정 하나가 큰 차이를 만듭니다.
