게시일: 2024년 10월 21일, 최종 업데이트: 2025년 9월 9일
Chrome에서는 안전한 경우 Cache-Control: no-store를 사용하는 페이지에서 뒤로/앞으로 캐시 (bfcache)를 사용할 수 있도록 변경하고 있습니다. 개발자에게 어떤 의미가 있는지 알아보세요.
배경
Cache-Control: no-store을 HTTP 헤더로 설정하면 페이지가 HTTP 캐시에 저장되지 않아야 한다는 신호가 됩니다. 이는 민감한 데이터가 포함된 페이지(예: 사용자가 로그인한 페이지)에 사용해야 하지만 민감한 데이터가 없는 페이지에도 no-store 지시어가 자주 사용됩니다.
bfcache를 사용하면 사용자가 이동할 때 페이지를 소멸하는 대신 소멸을 연기하고 JS 실행을 일시중지합니다. 사용자가 곧 다시 탐색하는 경우 페이지를 다시 표시하고 JS 실행을 일시중지 해제합니다. 따라서 사용자는 거의 즉시 페이지를 탐색할 수 있습니다.
HTML 사양에서는 요구하지 않지만 브라우저는 일반적으로 Cache-Control: no-store를 페이지를 bfcache에 배치하지 않도록 하는 신호로 간주합니다. 이는 bfcache가 사용되지 않는 가장 큰 이유로, 모바일의 기록 탐색 중 약 17%, 데스크톱의 기록 탐색 중 약 7% 를 차지합니다. 즉, 이러한 페이지는 빠른 복원의 이점을 누릴 수 없으며 네트워크 호출, JavaScript 실행, 렌더링을 포함하여 페이지를 완전히 새로고침해야 합니다.
사이트가 변경될 때 캐싱 문제를 방지하기 위해 Cache-Control: no-store가 설정되는 경우가 많지만, bfcache가 사용되면 전체 페이지가 처음부터 열려 있었던 것처럼 거의 복원되므로 이 이유는 관련성이 떨어집니다.
Chrome에서 이 동작을 변경하는 방법
Chrome은 이 동작을 변경할 의도를 발표했지만 이 변경사항에 신중하게 접근하고 있습니다. Chrome 116부터 페이지 로드 비율을 점진적으로 늘리는 실험을 진행해 왔으며, 2025년 3월과 4월에 100% 에 도달할 것으로 예상됩니다.
민감한 정보
Google 분석에 따르면 대부분의 뒤로 또는 앞으로 탐색에는 민감한 데이터가 포함되지 않으므로 bfcache에 적합하지만, 페이지를 bfcache에 배치해서는 안 되는 경우도 있습니다. 예를 들어 로그아웃 시 뒤로 또는 앞으로 탐색하여 로그인한 페이지를 가져올 수 없어야 합니다.
이를 방지하기 위해 Chrome은 쿠키 또는 기타 승인 방법이 변경되면 bfcache에서 페이지를 삭제합니다.
또한 Cache-Control: no-store를 사용하는 페이지에서 다음 API를 사용하면 해당 페이지에서 뒤로-앞으로 캐시를 사용할 수 없게 됩니다.
이는 bfcache 사용을 방지하는 API의 전체 목록이 아니라 페이지를 떠날 때 사용되지 않더라도 Cache-Control: no-store 페이지에서 bfcache를 차단하는 API입니다.
Cache-Control: no-store 페이지의 뒤로-앞으로 캐시 시간 제한도 위험을 더욱 줄이기 위해 3분 (Cache-Control: no-store를 사용하지 않는 페이지에 사용되는 10분에서)으로 단축됩니다.
Enterprise 선택 해제
기업은 업데이트하기 어려운 소프트웨어와 공유 기기를 사용하는 경우가 많습니다. AllowBackForwardCacheForCacheControlNoStorePageEnabled 정책을 사용 중지하여 Cache-Control: no-store 페이지의 bfcache 사용을 계속 방지할 수 있습니다.
변경사항 테스트
개발자는 다음 플래그를 사용하여 이 변경사항을 테스트할 수 있습니다.
--enable-features=CacheControlNoStoreEnterBackForwardCache:level/restore-unless-cookie-change
이전 예외 중 하나(예: 쿠키 변경)가 적용되면 페이지에서 bfcache를 사용할 수 없게 되며 Chrome DevTools bfcache 테스터에 '기본 리소스에 Cache-Control: no-store가 있는 페이지는 뒤로-앞으로 캐시에 들어갈 수 없습니다'라는 이유가 표시됩니다.
이 bfcache 테스트 페이지를 사용하여 이 플래그를 사용하거나 사용하지 않고 테스트할 수 있습니다.
개발자가 알아야 할 사항
개발자는 사용자가 더 많은 bfcache 사용의 이점을 누릴 수 있도록 변경할 필요가 없지만 이로 인해 고려해야 할 사항이 있습니다. 이는 2021년 12월에 bfcache가 처음 출시되었을 때 다른 사이트에서 경험했을 수 있는 고려사항과 유사합니다.
개발자는 여전히 Cache-Control: no-store 사용량을 줄여야 하나요?
bfcache는 앞에서 언급한 제한된 상황에서 Chrome에만 Cache-Control: no-store에 대해 사용 설정됩니다. Cache-Control: no-store를 사용하는 경우 다른 브라우저에서 bfcache 사용을 차단할 수 있습니다.
이러한 휴리스틱에 의존하기보다는 Cache-Control: no-store 사용을 최소화하는 것이 좋습니다.
성능에 미치는 영향
이번 변경은 웹 사용자의 페이지 경험을 개선하기 위해 이루어집니다. bfcache를 처음 출시했을 때 코어 웹 바이탈이 눈에 띄게 개선되었으며, 이제 더 많은 사이트에 동일한 개선사항을 적용하고자 합니다.
사이트 소유자는 이 기능이 출시되면 핵심 웹 바이탈이 개선되는 것을 확인할 수 있으며 CrUX Vis를 비롯한 CrUX에서 bfcache 사용량을 측정할 수 있습니다.
영향 분석
bfcache에서 복원된 페이지는 페이지를 새로고침하는 대신 이전 페이지 (JavaScript 힙 포함)를 '복원'합니다. 인기 있는 많은 분석 제공업체는 bfcache 복원을 새 페이지 조회로 측정하지 않습니다. 처음 로드될 때만 페이지 조회를 트리거하기 때문입니다.
따라서 사이트에서 bfcache를 처음 사용하기 시작하면 분석에서 페이지 로드가 감소할 수 있습니다. pageshow 이벤트의 리스너를 설정하고 persisted 속성을 확인하여 이를 페이지 조회수로 간주하는 것이 좋습니다.
// Send a pageview when the page is first loaded.
gtag('event', 'page_view');
// Send another pageview if the page is restored from bfcache.
window.addEventListener('pageshow', (event) => {
if (event.persisted) {
// Page was restored from bfcache, sent another page view.
gtag('event', 'page_view');
}
});
페이지 복원 시 업데이트 처리
이제 사이트에서 이전에는 표시되지 않았던 뒤로-앞으로 캐시 사용량이 표시될 수 있으며, 페이지가 최신 데이터로 완전히 새로고침될 수 있으므로 개발자는 뒤로-앞으로 캐시 복원 시 데이터를 새로고침하는 것을 고려할 수 있습니다.
pageshow 이벤트를 사용하고 persisted 속성을 확인하여 애널리틱스의 추가 페이지 조회수를 로깅하는 것과 유사한 방식으로 업데이트를 트리거할 수 있습니다.
모든 콘텐츠를 업데이트해야 하는 것은 아니며 사용자는 이전에 본 콘텐츠로 돌아가는 것을 선호할 수 있습니다. 예를 들어 기사 목록을 새로고침하면 사용자가 다시 보려고 했던 기사가 더 이상 표시되지 않을 수 있습니다.
광고에 미치는 영향
분석 영향과 마찬가지로 광고가 페이지 로드 시에만 로드되는 경우 사이트의 광고 노출수가 감소할 수 있습니다. bfcache 복원 시 광고를 프로그래매틱 방식으로 새로고침하여 전체 페이지 로드와 동등성을 유지할 수 있습니다. 이 경우에도 pageshow 이벤트를 사용하고 persisted 속성을 확인하지만 항상 올바른 방법은 아닙니다. 광고 다시 로드를 트리거하는 방법은 광고 제공업체의 문서를 참고하세요.
bfcache에 관한 추가 정보
bfcache에 관한 자세한 내용은 종합적인 bfcache 기술 가이드를 참고하세요.
의견
이 변경사항에 대한 의견을 기다리고 있습니다. 의견은 bfcache 구성요소를 사용하여 Chrome의 문제 추적기에 제공해 주세요.
결론
Google은 더 많은 페이지에 bfcache의 이점을 제공하여 사용자의 페이지 환경을 개선하고자 합니다. Google은 이번 변경사항을 신중하게 고려했으며, 최대한 안전한 방식으로 출시하기 위해 노력하고 있습니다. 이 정보가 개발자가 이번 변경사항을 이해하고 이러한 상황이 발생할 때 문제를 방지하는 데 필요한 변경사항을 적용하는 데 도움이 되기를 바랍니다.