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부터 실험을 진행했으며 최근까지 페이지 로드의 5% 에서 실험을 실행했습니다.
10월 2일에 이 비율을 페이지 로드의 10%로 늘렸으며, 11월에는 20%, 내년 초에는 50%로 늘릴 계획입니다. 이후 곧 완전히 출시할 예정이며, 특정 선택 해제는 다음에 설명합니다.
민감한 정보
분석에 따르면 대부분의 뒤로 또는 앞으로 탐색에는 민감한 정보가 포함되어 있지 않으므로 bfcache를 사용할 수 있어야 하지만 페이지를 bfcache에 배치해서는 안 되는 경우도 있습니다. 예를 들어 로그아웃할 때 앞뒤로 탐색하여 로그인한 페이지를 검색할 수 없어야 합니다.
이를 방지하기 위해 Chrome은 쿠키 또는 기타 승인 방법이 변경될 때 bfcache에서 페이지를 삭제합니다.
또한 Cache-Control: no-store를 사용하는 페이지에 다음 API를 사용하면 해당 페이지에서 계속 bfcache를 사용할 수 없습니다.
이는 bfcache 사용을 방지하는 API의 포괄적인 목록이 아니라 페이지를 닫을 때 사용되지 않더라도 Cache-Control: no-store 페이지에서 bfcache를 차단하는 API의 목록입니다.
또한 Cache-Control: no-store 페이지의 bfcache 시간 제한도 Cache-Control: no-store를 사용하지 않는 페이지에 사용되는 10분에서 3분으로 줄여 위험을 더욱 줄였습니다.
엔터프라이즈 선택 해제
기업에는 업데이트하기 어려운 소프트웨어와 공유 기기가 있는 경우가 많습니다. 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가 처음 출시되었을 때 다른 사이트에서 경험했을 수 있는 유사한 고려사항입니다.
성능에 미치는 영향
이렇게 변경하는 이유는 웹 사용자의 페이지 경험을 개선하기 위함입니다. bfcache를 처음 출시했을 때 코어 웹 바이탈이 눈에 띄게 개선되었으며, 이제 더 많은 사이트에 동일한 개선사항을 적용하고자 합니다.
사이트 소유자는 이 기능이 출시되면 Core Web Vitals가 개선되는 것을 확인할 수 있으며 CrUX 대시보드 등 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');
}
});
페이지 복원 시 업데이트 처리
이제 사이트에서 이전에는 bfcache 사용량이 표시되지 않았는데 표시되거나 페이지가 최신 데이터로 완전히 새로고침될 수 있으므로 개발자는 bfcache 복원 시 데이터를 새로고침하는 것이 좋습니다.
업데이트는 pageshow 이벤트를 사용하고 persisted 속성을 확인하여 애널리틱스에 페이지 조회수를 추가로 로깅하는 것과 유사한 방식으로 트리거할 수 있습니다.
모든 콘텐츠를 업데이트할 필요는 없으며 사용자가 이전에 본 콘텐츠로 '돌아가'는 것을 선호할 수도 있습니다. 예를 들어 기사 목록을 새로고침하면 사용자가 다시 보려고 했던 기사가 더 이상 표시되지 않을 수 있습니다.
광고에 미치는 영향
분석 영향과 마찬가지로 광고가 페이지 로드 시점에만 로드되는 경우 사이트의 광고 노출수가 감소할 수 있습니다. bfcache 복원 시 pageshow 이벤트를 다시 사용하고 persisted 속성을 확인하여 전체 페이지 로드와 동일성을 유지하도록 광고를 프로그래매틱 방식으로 새로고침할 수 있지만 항상 올바른 방법은 아닙니다. 광고 리로드를 트리거하는 방법은 광고 제공업체의 문서를 참고하세요.
bfcache에 대한 자세한 정보
bfcache에 관한 자세한 내용은 포괄적인 bfcache 기술 가이드를 참고하세요.
의견
이 변경사항에 관한 의견이 있으면 bfcache 구성요소를 사용하는 Chrome의 Issue Tracker에서 알려주세요.
결론
Google은 더 많은 페이지에 bfcache의 이점을 제공하여 사용자의 페이지 환경을 개선할 수 있게 되어 기쁩니다. Google은 이 변경사항을 신중하게 고려했으며 최대한 안전한 방식으로 적용하기 위해 노력하고 있습니다. 이 정보가 개발자가 이번 변경사항을 이해하고 문제가 발생할 때 문제를 방지하기 위해 필요한 변경사항을 적용하는 데 도움이 되기를 바랍니다.