이전/다음 페이지 캐시

브라우저 이전/다음 페이지 버튼으로 이동할 때 페이지가 순간적으로 로드되게 최적화 해보자.

원문: 'Back/forward cache' https://web.dev/bfcache - Philip Walton

Back/forward cache(bfcache)는 이전/다음 페이지로 즉시 이동 할 수 있게 해주는 브라우저 최적화다. 이 최적화를 통해 네트워크가 느리거나, 기기의 성능이 느린 사용자들의 탐색 경험을 크게 향상해준다.

웹 개발자라면 모든 브라우저에서 bfcache에 맞게 페이지를 최적화하는 방법을 이해한다. 그래야 방문자들이 앞서 얘기한 장점들을 누릴 것이다.

브라우저 호환성

bfcache는 여러 해 동안 Firefox와 Safari 모두에서 데스크톱과 모바일을 지원했다.

크롬은 86 버전부터 소수의 사용자를 위해 bfcache를 안드로이드에서 cross-site 의 탐색을 가능하게 했다. 크롬 87에서는 bfcache가 안드로이드 사용자 모두에게 제공되어 서로 다른 사이트 사이의 탐색을 지원하며, 이를 통해 가까운 미래에는 same-site의 탐색도 가능하게 할 것이다.

bfcache의 기본

bfcache는 방문자가 다른 곳으로 동하는 순간, 페이지의 전체 스냅숏(자바스크립트 힙 포함)을 저장해주는 메모리 내부의 캐시다. 사용자가 다시 돌아오려 할 때, 브라우저는 메모리에 저장해둔 전체 페이지를 사용해서 페이지를 빠르고 쉽게 복원해준다.

웹 사이트를 방문해서 내가 원하는 페이지가 아니라는 것을 깨닫고 뒤로 가기 버튼을 클릭한 적이 얼마나 많은지 기억해보자. 그 순간 이전 페이지를 띄우는 시간이 bfcache로 인해 얼마나 빨라질 수 있는지 보자.

• bfcache가 활성화되지 않은 경우

  • 이전 페이지를 로드하기 위해 새로운 요청이 시작된다. 해당 페이지가 재방문에 얼마나 최적화되었냐에 따라 다르겠지만, 브라우저는 방금 다운로드한 일부(또는 모든) 리소스를 다시 다운로드하고, 다시 파싱하고, 다시 실행해야 할 수 있다.

• bfcache를 활성화한 경우

  • 이전 페이지 로딩은 기본적으로 즉시 수행되며, 전체 페이지를 메모리에서 복원할 수 있기 때문에 네트워크를 전혀 사용하지 않는다.

bfcache가 탐색을 얼마나 빠르게 만들 수 있는지 알아보려면, bfcache가 작동하는 비디오를 확인해보면 된다.

위 비디오에서 bfcache를 사용한 예제는 bfcache가 없는 예제보다 꽤 빠른 것을 볼 수 있다.

bfcache는 단순히 탐색 속도를 높일 뿐만 아니라, 리소스를 다시 다운로드하지 않기 때문에 데이터 사용량도 줄여준다.

크롬 사용 정보를 보면 데스크톱에서 10번의 탐색 중 1번, 모바일에서 5번의 탐색 중 1번 뒤로/앞으로 이동하는 경향을 보인다. bfcache를 사용한다면 브라우저는 매일 수십억 개의 웹페이지를 불러오는 시간과 데이터 사용량을 줄일 수 있다.

"캐시"의 동작 방식

bfcache가 사용하는 "캐시"는 HTTP 캐시(HTTP 캐시는 반복적인 탐색에 유용하다)와는 다르다. bfcache는 메모리에 있는 페이지 전체의 스냅숏(자바스크립트 힙 포함)인 반면, HTTP 캐시는 이전에 보냈던 요청의 응답만 저장한다. 페이지 로딩에 필요한 모든 리소스를 HTTP 캐시에서 찾는 확률은 희박하다. 따라서, 반복적인 방문을 처리할 때, 최적화된 페이지이지만 bfcache를 사용하지 않는 경우보다 bfcache로 복원하는 게 항상 빠르다.

그러나 페이지의 스냅숏을 메모리에 만들다 보니, 진행 중인 코드를 잘 보존하기 위해 어느 정도 복잡도가 추가된다. 예를 들어, 페이지가 bfcache에 있는 동안 setTimeout() 호출의 완료 시간이 다 되었다면 어떻게 처리해야 할까?

그 대답은 다음과 같다. 브라우저는 일시 정지 중인 타이머 또는 해결되지 않은 프라미스(본질적으로 자바스크립트 태스크 대기열의 모든 보류 중인 태스크) 실행을 일시 중지하고, 페이지가 bfcache에서 복원될 때 다시 작업을 재개한다.

특정 케이스는 복원하는 리스크가 거의 없지만(예를들어, timer나 프라미스), 그렇지 않은 케이스 중에는 매우 혼란스럽거나 예상치 못한 현상이 발생할 수 있다. 예를 들어 브라우저가 인덱싱된 DB 트랜잭션 작업에 필요한 일부 작업을 일시 중지하는 경우, 다른 탭에 이미 열려있던 같은 사이트(same-site)에 영향을 줄 수 있다(여러 탭에서 같은 인덱싱된 DB를 사용할 수 있기 때문). 그래서, 브라우저는 일반적으로 인덱싱된 DB 트랜잭션 실행 도중 페이지를 캐시 하거나, 다른 페이지에 영향을 줄 수 있는 API를 사용하지 않으려고 한다.

다양한 API 사용이 페이지의 bfcache 사용 자격에 미치는 영향을 확인하려면, 아래 "bfcache로 페이지 최적화하기" 목차를 참조하면 된다.

bfcache를 관찰하는 APIs

bfcache는 브라우저가 자동으로 수행하지만, 자신의 페이지를 최적화하거나 그에 따라 메트릭이나 성능 측정을 조정하려면 개발자는 캐싱이 언제 일어나는지 알아야 한다.

bfcache를 관찰하는 데 사용되는 주요 이벤트는 페이지 전환 이벤트(pageshow와 pagehide)로, bfcache가 현재 사용 중인 거의 모든 브라우저에서 지원되고 있다.

새로운 페이지 라이프사이클 이벤트(freeze 와 resume)는 페이지가 bfcache에 들어가고 나갈 때뿐만 아니라, 다른 상황에서도 수행된다. 예를 들어, CPU 사용량을 최소화하기 위해 백그라운드 탭이 동결된 경우가 있다. 참고로, 페이지 라이프사이클 이벤트는 현재 크로미움 기반 브라우저에서만 지원되고 있다.

페이지가 bfcache에서 복원될 때를 관찰하기

pageshow 이벤트는 load 이벤트 직후에 발생하며, 페이지가 처음 로드되거나 bfcache에서 페이지가 복원될 때마다 실행된다. pageshow 이벤트는 페이지가 bfcache에서 복원된 경우 true인 persisted 속성을 가지고 있다(그렇지 않은 경우 false). persisted 속성을 사용해서 일반 페이지 로드와, bfcache 복원을 구분할 수 있다. 다음 예제를 보자.

window.addEventListener('pageshow', function(event) {
  if (event.persisted) {
    console.log('이 페이지는 bfcache로 복원되었다.');
  } else {
    console.log('이 페이지는 정상 로드 되었다.');
  }
});

페이지 라이프사이클 API를 지원하는 브라우저에서는, bfcache에서 페이지가 복원될 때 resume 이벤트도 실행되지만(pageshow 이벤트 직전에), 사용자가 백그라운드에 정지되어있던 탭을 다시 방문할 때도 실행된다. 페이지 상태가 동결된 후 복원하려면(bfcache에 저장된 페이지 포함) resume 이벤트를 사용할 수 있지만, 사이트의 bfcache 적중률을 측정하려면 pageshow 이벤트를 사용해야 한다. 어쩌면 둘 다 사용해야 할 수도 있다.

bfcache 측정 모범 사례에 대한 자세한 내용은 성능 및 분석에 대한 시사점을 참조하십시오.

페이지가 bfcache로 들어갈 때를 관찰하기

pagehide 이벤트는 pageshow 이벤트의 반대되는 이벤트다. pageshow 이벤트는 페이지가 정상적으로 로드되거나 bfcache에서 복원될 때 발생한다. pagehide 이벤트는 페이지가 정상적으로 언로드(unload) 되거나 브라우저가 페이지를 bfcache에 저장하려고 할 때 발생한다.

pagehide 이벤트에도 persisted 속성이 있다. 그 값이 false라면 페이지는 bfcache에 들어가지 않는다. 하지만, persisted 속성이 true라고 해서 페이지가 항상 캐시 되지는 않는다. 브라우저는 페이지를 캐시 하려고 시도하지만, 페이지를 캐시 할 수 없게 만드는 요인이 있을 수 있다는 뜻이다.

window.addEventListener('pagehide', function(event) {
  if (event.persisted === true) {
   console.log('이 페이지는 *아마도* bfcache에 들어갈 것이다.');
  } else {
    console.log('이 페이지는 정상적으로 언로드되고 제거될 것이다.');
  }
});

그리고 비슷하게도, freeze이벤트는 pagehide이벤트 직후에 발생한다(persisted가 true라면). 하지만, 마찬가지로 브라우저가 캐시에 저장 하려고 시도 한다는 뜻이다. 아래에서 설명하는 여러 이유로 페이지가 버려질 수 있다.

bfcache를 위해 페이지 최적화하기

모든 페이지가 bfcache에 저장되는 것은 아니며, 페이지가 bfcache에 저장되더라도 그 페이지가 무한히 메모리에 남아있지는 않을 것이다. 캐시 적중률을 극대화하기 위해 어떤 페이지를 bfcache에 적합(혹은 부적합)하게 만들어야 하는지 알아야 한다.

다음 챕터에서는 브라우저가 페이지를 최대한 캐시하도록 해주는 위한 모범 사례를 간단히 설명하겠다.

unload 이벤트 사용하지 않기

모든 브라우저에서 bfcache를 최적화하는 가장 중요한 방법은 unload 이벤트를 사용하지 않는 것이다. 절대로 사용하지 말아야 한다!

unload 이벤트는 브라우저를 곤란하게 만든다. 왜냐면 unload 이벤트는 bfcache보다 앞서 발생하는 이벤트인데, 인터넷상의 많은 페이지들이 unload 이벤트가 발생한 후에는 페이지가 존재하지 않는다는 (합리적인) 가정하에 작동하기 때문이다. 이러한 페이지 중 상당수는 사용자가 이동할 때마다 unload 이벤트가 발생한다는 가정하에 개발되었다. 이 가정은 이제는 더는 참이 아니다(사실 예전부터 맞는 말이 아니었다).

그래서 브라우저는 딜레마에 빠졌다. 사용자 경험을 발전시킬 것이냐, 페이지를 망가트릴 것이냐!

Firefox는 unload 리스너를 추가하면 bfcache에 적합하지 않은 페이지로 판단하기로 결정했다. 이는 덜 위험하지만 상당히 많은 페이지들도 bfcache에 부적합하게 만든다. Safari는 unload 이벤트 리스너로 일부 페이지를 캐시 하려고 시도한다. 하지만, 잠재적인 오류를 줄이기 위해 사용자가 다른 곳으로 탐색할 때 unload 이벤트를 실행하지 않는다.

Chrome의 페이지 중 65%가 unload 이벤트 리스너를 등록하므로, 가능한 많은 페이지를 캐시 하기 위해 Safari의 구현을 따라가는 것을 선택했다.

unload 이벤트 대신에 pagehide 이벤트를 사용하자. pagehide 이벤트는 현재의 unload 이벤트가 발생하는 모든 경우에 발생한다. 물론 페이지를 bfcache에 넣어도 발생한다.

실제로 Lighthouse v6.2.0은 no-unload-listeners audit를 추가했다. 페이지의 자바스크립트(서드파티 라이브러리도 포함)에 unload 이벤트 리스너를 추가한 개발자들에겐 경고가 보일 것이다.

경고: unload 이벤트 리스너를 추가하면 안 된다! 그 대신에 pagehide 이벤트를 사용해보자. unload 이벤트 리스너를 추가하면 Firefox에서 사이트 속도가 느려지고, Chrome과 Safari에서는 추가했던 대부분의 코드가 실행되지 않는다.

때에 따라 beforeunload 리스너만 추가

beforeunload 이벤트는 페이지를 Chrome이나 Safari에서 bfcache에 부적합하게 만들지는 않는다. 하지만, Firefox에서는 부적합할 수 있으므로 꼭 필요한 경우가 아니면 사용하지 않길 권장한다.

그러나, unload 이벤트와는 달리 beforeunload는 필요한 때도 있다. 예를 들어, 사용자가 페이지를 나가면 변경사항이 손실되므로, 사용자에게 저장되지 않은 변경사항이 있음을 경고하고자 할 때다. 이 경우 사용자가 저장하지 않은 변경사항이 있는 경우에만 beforeunload 이벤트 리스너를 추가하고, 사용자가 저장하지 않은 변경사항을 저장한 후에는 그 리스너를 즉시 삭제하는 것을 추천한다.

안좋은 예

window.addEventListener('beforeunload', (event) => {
  if (pageHasUnsavedChanges()) {
    event.preventDefault();
    return event.returnValue = '정말 나가시겠습니까?';
  }
});

beforeunload 리스너를 무조건 추가하고 있다.

좋은 예

function beforeUnloadListener(event) {
  event.preventDefault();
  return event.returnValue = '정말 나가시겠습니까?';
};

// 페이지에 저장하지 않은 변경이 있는 경우에 실행됨.
onPageHasUnsavedChanges(() => {
  window.addEventListener('beforeunload', beforeUnloadListener);
});

// 페이지에 저장하지 않은 변경 문제가 해결되었을 때 실행됨.
onAllChangesSaved(() => {
  window.removeEventListener('beforeunload', beforeUnloadListener);
});

beforeunload 리스너를 저장되지 않은 변경이 있을 때만 추가한다. 그리고 그렇지 않을 때는 제거한다.

window.opener 참조를 사용하지 않기

일부 브라우저(버전 86 현재 Chrome 포함)에서 window.open()을 사용하여 target=_blank 링크로 페이지를 열었거나, rel="nopener"를 지정하지 않고 페이지를 열었을 경우, 열린 페이지는 자신을 연 페이지의 window 객체의 참조를 사용할 수 있다.

이 경우는 보안 위험이 있을 뿐만 아니라 null이 아닌 window.opener 참조가 있는 페이지는 bfcache에 안전하게 넣을 수 없다. 만약 넣는다고 했을 때, bfcache에 액세스를 시도하는 모든 페이지가 망가질 수 있기 때문이다.

따라서 가능하면 rel="noopener"를 사용하여 window.opener 참조를 만들지 않는 것이 좋다. 만약 새로운 페이지를 열고 window.postMessage()를 통해 그 페이지를 제어하거나 window 객체를 직접 참조해야 한다면, 열린 페이지나 그 페이지를 연 페이지 모두 bfcache에는 부적합하게 된다.

사용자가 다른 페이지를 탐색하기 전에 항상 열려 있는 연결을 종료하기

앞서 언급한 바와 같이, bfcache에 페이지를 넣을 때 예약되어있는 모든 자바스크립트 작업이 일시 중지되었다가, 페이지가 bfcache에서 복원되면 재개된다.

예약된 자바스크립트 작업이 DOM API 또는 현재 페이지에만 한정된 다른 API에만 액세스하는 경우, 페이지가 사용자에게 표시되지 않는 동안 이러한 작업을 일시 중지하더라도 문제가 발생하지 않는다.

그러나, 이런 태스크가 같은 origin의 다른 페이지에서도 액세스할 수 있는 API에 연결된 경우(예를들어, IndexedDB, Web Locks, WebSockets 등), 작업을 일시 중지하면 다른 탭의 코드가 실행되지 않을 수 있기 때문에 문제가 발생할 수 있다.

결과적으로, 대부분의 브라우저는 다음과 같은 시나리오에서 bfcache에 페이지를 넣으려고 시도하지 않을 것이다.

• 완료되지 않은 인덱싱된 DB 트랜잭션이 있는 페이지
• 진행 중인 fetch()나 XMLHttpRequest
• WebSocket 또는 WebRTC 연결이 이어져 있는 페이지

페이지가 위 API 중 하나를 사용하는 경우, pagehide 또는 freeze 이벤트에서 항상 연결을 닫고 관찰자(observer)를 제거하거나 연결을 끊는 것이 가장 좋다. 이렇게 하면 브라우저는 열려있는 다른 탭에 영향을 미치지 않으면서 페이지를 안전하게 캐시 할 수 있다.

그리고, bfcache에서 페이지를 복원한 경우 pageshow 또는 resume 이벤트에서 해당 API를 다시 연결할 수 있다.

위에 나열된 API를 사용하더라도 바로 bfcache 부적격이 되지는 않는다. 사용자가 다른 페이지로 이동하기 전에 그런 API들을 적극적으로 사용하지 않는다면 말이다. 반면에, 현재로서 사용하면 페이지가 캐시 되지 않게 만드는 API(Embedded Plugins, Workers, Broadcast Channel 등등)가 있다. bfcache의 초기 출시 단계에서 Chrome이 의도적으로 보수적인 모습을 보이지만, 장기적인 목표는 bfcache가 최대한 많은 API와 함께 작동하도록 하는 것이다.

페이지가 캐시 될 수 있는지 테스트하기

페이지가 로드되지 않았을 때 페이지가 캐시에 저장되었는지 여부를 확인할 방법은 없지만, 이전/다음 페이지로 탐색해서 캐시에서 페이지를 복원했는지 추측할 수는 있다.

현재 Chrome에서는 페이지를 bfcache에 최대 3분 동안 유지할 수 있으며, 페이지에서 벗어나 뒤로가기 버튼을 클릭한 후 pageshow 이벤트의 persisted 속성이 true인지 확인하는 테스트(puppeteer나 WebDriver 같은 도구를 이용하는 테스트)를 하기 위해서는 충분한 시간이 필요하다.

정상적인 조건에서 페이지는 테스트를 실행할 수 있을 만큼 충분히 오랫동안 캐시에 남아 있어야 하지만, 언제든지 자동으로 제거될 수 있다는 점에 유의하자(예를들어, 시스템이 메모리 부족의 압박을 받는 경우). 테스트 실패가 반드시 페이지를 캐시 할 수 없다는 것을 의미하지는 않으므로, 테스트 또는 실패 기준을 적절하게 구성해야 한다.

꿀팁! Chrome에서는 현재 bfcache가 모바일에서만 활성화되고 있다. 데스크톱에서 bfcache를 테스트하려면 #back-forward-cache 플래그를 활성화 하면 된다.

bfcache에서 벗어나는 방법

페이지가 bfcache에 저장되지 않도록 하려면 최상위 페이지 응답에 있는 Cache-Control 헤더를 no-store으로 설정하여 캐시 되지 않도록 할 수 있다.

Cache-Control: no-store

다른 모든 캐싱 지침(하위 프레임에 no-cache 또는 심지어 no-store 포함)은 페이지의 bfcache 자격에 영향을 미치지 않는다.

이 방법은 효과적이고 모든 브라우저에서 동작하지만, 의도적이지 않게 다른 캐싱과 성능에 영향을 준다. 이를 해결하기 위해, 필요하면 bfcache를 지우는 메커니즘(예를 들어, 사용자가 공동 사용 기기에서 웹사이트 로그아웃하는 경우)을 포함한 더욱 명시적인 opt-out 메커니즘을 추가하자는 제안이 있다.

또한 Chrome에서는 현재 기업 정책 기반의 Opt-out 뿐만 아니라 #back-forward-cache 플래그를 통해 사용자 수준의 Opt-out이 가능하다.

주의: bfcache가 제공하는 훨씬 더 나은 사용자 경험을 고려할 때, opt-out 하는 것은 권장하지 않는다. (사용자가 공동 사용 기기에서 웹사이트 로그아웃하는 경우처럼 사생활 보호를 위해 필요한 경우는 제외)

bfcache가 분석과 성능 측정에 미치는 영향

분석 도구를 사용하여 사이트 방문을 추적하고 있다면, 전체 페이지 뷰 수가 줄어드는 것을 확인할 수 있을 것이다. 그 이유는 Chrome이 더 많은 사용자가 bfcache를 사용하도록 활성화하기 때문이다.

실제로, 이미 bfcache를 구현하는 다른 브라우저들의 페이지뷰를 적게 보고받고 있었을 것이다. 그리고 대부분의 인기 분석 라이브러리는 bfcache 복원을 새로운 페이지뷰로 추적하지 않고 있었다.

Chrome의 bfcache 활성화로 인해 페이지뷰 개수가 감소하지 않도록 하려면, pageshow 이벤트를 리스너에서 persisted 속성을 확인하면 bfcache 복원을 페이지뷰로 보고할 수 있다(추천하는 방법이다).

다음 예제는 Google Analytics를 사용하여 이 작업을 수행하는 방법이다. 다른 분석 툴도 비슷한 로직일 것이다.

// 페이지가 처음 로드될 때 페이지뷰 전송.
gtag('event', 'page_view');

window.addEventListener('pageshow', function(event) {
  if (event.persisted == true) {
    // bfcache에서 페이지가 복원된 경우 또 다른 페이지 뷰로 보고
    gtag('event', 'page_view');
  }
});

성능 측정

bfcache는 또한 현장에서 수집된 성능 지표, 특히 페이지 로드 시간을 측정하는 지표에 부정적인 영향을 미칠 수 있다.

bfcache 탐색은 새로운 페이지 로드를 시작하지 않고 기존 페이지를 복원하므로, bfcache를 '사용함'으로 설정하면 수집된 페이지 로드의 총수가 감소한다. 그러나 중요한 것은, bfcache 복원으로 대체되는 페이지 로드가 데이터 집합에서 가장 빠른 페이지 로드가 될 수 있다는 점이다. 정의에 의하면, 앞/뒤 탐색은 반복 방문이며, 반복 페이지 로드는 처음 방문자의 페이지 로딩(앞에서 언급한 HTTP 캐싱으로 인해)보다 일반적으로 빠르기 때문이다.

그 결과 성능 측정한 데이터 집합에서는 빠른 페이지 로드 수가 줄어들게 된다. 사용자가 경험하는 성능이 향상되었음에도 불구하고, 로딩 속도가 느려지는 것으로 데이터 집합이 망가진 것이다!

이 문제에 대처하는 방법이 몇 가지 있다. 하나는 모든 페이지 로드 메트릭에 탐색 타입 주석(navigate, reload, back_forward, prerender와 같은 각 탐색 유형)을 다는 것이다. 이렇게 하면 전체 분포가 음수인 경우에도 탐색 유형 내에서 성능을 계속 모니터링할 수 있다. 이 접근방식은 TTFB(Time to First Byte)와 같은 비-사용자 중심의 페이지 로드 메트릭에 권장된다.

Core Web Vitals와 같은 사용자 중심 메트릭의 경우, 사용자가 경험하는 것을 정확히 나타내는 값을 보고하는 것이 더 좋다.

주의: Navigation Timing API의 back_forward 탐색 유형을 bfcache 복원과 혼동해서는 안 된다. Navigation Timing API는 페이지 로드에 대한 주석만 제공하는 반면 bfcache 복원은 이전 탐색에서 로드된 페이지를 다시 사용하고 있다.

Core Web Vitals에 미치는 영향

Core Web Vitals은 다양한 차원(로드 속도, 상호작용성, 시각적 안정성)에 걸쳐 웹 페이지의 사용자 경험을 측정하며, 사용자는 bfcache 복원을 기존 페이지 로드보다 빠른 탐색으로 느끼므로, Core Web Vitals 메트릭이 이를 반영해야 한다. 사실, 사용자는 bfcache가 적용되었는지에는 관심이 없고, 그저 탐색 속도만 빠르면 장땡이다.

Core Web Vitals 메트릭을 수집하고 보고하는 Chrome 사용자 환경 보고서와 같은 도구들은 데이터 집합에서 bfcache 복원을 별도의 페이지 방문으로 처리하도록 곧 업데이트될 것이다.

bfcache 복원 후 이러한 메트릭을 측정하기 위한 전용 웹 성능 API는 (아직은) 없지만, 기존 웹 API를 사용하여 값을 대략 추정할 수 있다.

• Largest Contenful Paint(LCP)의 경우, 프레임의 모든 요소는 동시에 그려지기 때문에 pageshow 이벤트의 타임 스탬프와 다음 paint될 프레임의 타임 스탬프 사이의 차이를 사용할 수 있다. bfcache 복원의 경우 LCP와 FCP가 동일하다는 점에 유의하자.
• First Input Delay(FID)의 경우, pageshow 이벤트에 이벤트 리스너(FID 폴리필에서 사용하는 것과 동일한 리스너)를 다시 추가하고, bfcache 복원 후 첫 번째 입력의 지연으로 FID를 보고할 수 있다.
• Culumulative Layout Shift(CLS)의 경우 기존 성능 Observer를 계속 사용할 수 있으며, 현재 CLS값을 0으로 재설정하기만 하면 된다.

bfcache가 각 메트릭에 미치는 영향에 대한 자세한 내용은, 개별 Core Web Vitals 메트릭 가이드 페이지를 참조하면 된다. 이러한 메트릭의 bfcache 버전을 코드로 구현하는 방법에 대한 구체적인 예는 web-vitals JS 라이브러리에 추가하는 PR을 참조하면 된다.

v1을 기준으로, web-vitals JavaScript 라이브러리는 bfcache 복원을 지원해서 그것을 보고해준다. v1 이상을 사용하는 개발자는 코드를 업데이트할 필요가 없다.

추가 리소스

• Firefox 캐싱(Firefox의 bfcache)
• 페이지 캐시(Safari의 bfcache)
• 뒤로/뒤로 캐시: 웹 노출 동작(브라우저 간 bfcache 차이)
• bfcache 테스터(다른 API와 이벤트가 브라우저에서 bfcache에 어떤 영향을 미치는지 테스트)

FE Weekly Picks는 FE개발랩의 기술 활동으로,
프론트엔드관련 아티클을 직접 작성하거나 관심있는 영문 아티클을 선정하여 번역하고 공유합니다.

저작권 및 라이선스

• 이 문서는 CC BY 4.0을 따릅니다.

  • 저자 Philip Walton의 원 저작물'Back Forward cache'을 한국어로 번역한 문서입니다.