뒤로 및 앞으로 캐시

Philip Walton
Barry Pollard

뒤로-앞으로 캐시 (또는 bfcache)는 즉각적인 뒤로/앞으로 탐색을 사용 설정하는 브라우저 최적화입니다. 특히 네트워크나 기기가 느린 사용자의 경우 탐색 환경이 크게 개선됩니다.

이 페이지에서는 모든 브라우저에서 페이지를 bfcache에 맞게 최적화하는 방법을 설명합니다.

브라우저 호환성

bfcache는 수년 동안 데스크톱과 모바일을 통해 Firefox와 Safari에서 모두 지원되었습니다.

Chrome은 버전 86부터 일부 사용자를 대상으로 Android의 크로스 사이트 탐색에 bfcache를 사용 설정했습니다. 후속 출시에서는 추가 지원이 천천히 배포됩니다. 버전 96부터 데스크톱과 모바일의 모든 Chrome 사용자에게 bfcache가 사용 설정됩니다.

bfcache 기본사항

bfcache는 사용자가 다른 페이지로 이동할 때 페이지의 전체 스냅샷을 저장하는 메모리 내 캐시입니다. 메모리에 전체 페이지가 있는 경우, 브라우저에서는 사용자가 페이지를 로드하는 데 필요한 모든 네트워크 요청을 반복할 필요 없이 페이지를 빠르게 복원할 수 있습니다.

다음 동영상은 bfcache로 탐색 속도를 얼마나 높일 수 있는지 보여줍니다.

bfcache를 사용하면 뒤로/앞으로 탐색 중에 페이지가 훨씬 더 빠르게 로드됩니다.

Chrome 사용 데이터에 따르면 데스크톱 탐색 10개 중 1개, 모바일 탐색 탐색 5개 중 1개는 뒤로 또는 앞으로입니다. 따라서 bfcache를 통해 많은 시간과 데이터 사용량을 절약할 수 있습니다.

'캐시'의 작동 방식

bfcache에서 사용하는 '캐시'는 반복 탐색의 속도를 높이는 데 고유한 역할을 하는 HTTP 캐시와 다릅니다. bfcache는 자바스크립트 힙을 포함한 메모리에 있는 전체 페이지의 스냅샷이지만 HTTP 캐시에는 이전에 실행한 요청의 응답만 포함됩니다. 페이지를 로드하는 데 필요한 모든 요청이 HTTP 캐시에서 가능한 경우는 매우 드물기 때문에 bfcache 복원을 사용한 반복 방문은 가장 최적화된 비 bfcache 탐색보다 항상 더 빠릅니다.

그러나 메모리에 있는 페이지의 스냅샷을 만들려면 진행 중인 코드를 보존하는 최선의 방법이 몇 가지 복잡합니다. 예를 들어 페이지가 bfcache에 있는 상태에서 제한 시간에 도달하는 setTimeout() 호출을 어떻게 처리해야 할까요?

브라우저에서는 JavaScript 작업 대기열의 거의 모든 대기 중인 작업을 포함하여 bfcache의 페이지에 관한 대기 중인 타이머 또는 해결되지 않은 프로미스를 일시중지하고 페이지가 bfcache에서 복원되면 처리 작업을 재개하는 것입니다.

제한 시간 및 프로미스와 같은 일부 경우에는 위험도가 낮지만 다른 경우에는 혼동되거나 예기치 않은 동작으로 이어질 수 있습니다. 예를 들어 브라우저가 IndexedDB 트랜잭션에 필요한 작업을 일시중지하면 여러 탭에서 동시에 동일한 IndexedDB 데이터베이스에 액세스할 수 있으므로 같은 출처의 다른 열린 탭에 영향을 미칠 수 있습니다. 따라서 브라우저는 일반적으로 IndexedDB 트랜잭션 중에 또는 다른 페이지에 영향을 줄 수 있는 API를 사용하는 동안 페이지를 캐시하려고 시도하지 않습니다.

API 사용이 페이지의 bfcache 자격요건에 미치는 영향에 관한 자세한 내용은 bfcache의 페이지 최적화를 참고하세요.

bfcache 및 단일 페이지 앱 (SPA)

bfcache는 브라우저 관리 탐색에서 작동하므로 단일 페이지 앱 (SPA) 내의 '소프트 탐색'에서는 작동하지 않습니다. 하지만 bfcache를 사용해 SPA에서 나갔다가 다시 돌아올 때도 계속 도움이 될 수 있습니다.

bfcache를 관찰하는 API

bfcache는 브라우저에서 자동으로 실행하는 최적화지만 개발자가 페이지를 최적화하고 그에 따라 모든 측정항목 또는 성능 측정을 조정할 수 있도록 발생 시점을 파악하는 것은 여전히 중요합니다.

bfcache를 관찰하는 데 사용되는 기본 이벤트는 대부분의 브라우저에서 지원하는 페이지 전환 이벤트 pageshow 및 pagehide입니다.

최신 페이지 수명 주기 이벤트인 freeze 및 resume는 페이지가 bfcache에 진입하거나 나갈 때뿐만 아니라 CPU 사용량을 최소화하기 위해 백그라운드 탭이 멈추는 등의 일부 다른 상황에서도 전달됩니다. 이러한 이벤트는 Chromium 기반 브라우저에서만 지원됩니다.

페이지가 bfcache에서 복원되는 시점 관찰

pageshow 이벤트는 페이지가 처음 로드될 때 그리고 페이지가 bfcache에서 복원될 때마다 load 이벤트 직후에 실행됩니다. pageshow 이벤트에는 persisted 속성이 있으며 이 속성은 페이지가 bfcache에서 복원된 경우 true, 그렇지 않은 경우 false입니다. persisted 속성을 사용하여 일반 페이지 로드와 bfcache 복원을 구분할 수 있습니다. 예를 들면 다음과 같습니다.

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    console.log('This page was restored from the bfcache.');
  } else {
    console.log('This page was loaded normally.');
  }
});

Page Lifecycle API를 지원하는 브라우저에서는 페이지가 bfcache에서 복원될 때 (pageshow 이벤트 직전) 및 사용자가 정지된 백그라운드 탭을 다시 방문할 때 resume 이벤트가 실행됩니다. 페이지가 고정된 후 (bfcache의 페이지 포함) 상태를 업데이트하려면 resume 이벤트를 사용하면 됩니다. 하지만 사이트의 bfcache 적중률을 측정하려면 pageshow 이벤트를 사용해야 합니다. 경우에 따라서는 둘 다 사용해야 할 수도 있습니다.

bfcache 측정 권장사항에 관한 자세한 내용은 bfcache가 분석 및 성능 측정에 미치는 영향을 참고하세요.

페이지가 bfcache에 진입하는 시점 관찰

pagehide 이벤트는 페이지가 언로드되거나 브라우저에서 bfcache에 배치하려고 할 때 실행됩니다.

pagehide 이벤트에는 persisted 속성도 있습니다. false이면 페이지가 bfcache에 진입하지 않는다고 확신할 수 있습니다. 하지만 persisted가 true라고 해서 페이지가 반드시 캐시되는 것은 아닙니다. 브라우저가 페이지를 캐시intends 하지만 캐시할 수 없는 다른 요인이 있을 수 있습니다.

window.addEventListener('pagehide', (event) => {
  if (event.persisted) {
    console.log('This page *might* be entering the bfcache.');
  } else {
    console.log('This page will unload normally and be discarded.');
  }
});

마찬가지로 persisted가 true인 경우 pagehide 이벤트 직후에 freeze 이벤트가 발생하지만 이는 브라우저가 페이지를 캐시intends한다는 의미일 뿐입니다. 나중에 설명할 여러 가지 이유로 인해 여전히 삭제해야 할 수 있습니다.

bfcache에 관한 페이지 최적화

모든 페이지가 bfcache에 저장되는 것은 아니며, 페이지가 bfcache에 저장되더라도 계속해서 저장되지는 않습니다. 다음 페이지에서는 페이지에서 bfcache를 사용할 수 있도록 하는 방법을 간략하게 설명하고, 캐시 적중률을 높이기 위해 브라우저의 페이지 캐시 기능을 최대화하기 위한 권장사항을 추천합니다.

unload 대신 pagehide 사용

모든 브라우저에서 bfcache에 맞게 최적화하는 가장 중요한 방법은 unload 이벤트 리스너를 사용하지 않는 것입니다. 대신 pagehide를 수신 대기하세요. 페이지가 bfcache로 전환될 때와 unload이 실행될 때마다 모두 실행되기 때문입니다.

unload는 원래 사용자가 페이지에서 나갈 때마다 트리거되도록 설계된 이전 기능입니다. 이는 더 이상 사실이 아닙니다. 하지만 많은 웹페이지는 브라우저가 이러한 방식으로 unload를 사용하고 unload가 트리거되면 언로드된 페이지가 기존을 중지한다는 가정하에 작동합니다. 이로 인해 브라우저가 로드되지 않은 페이지를 캐시하려고 하면 bfcache가 손상될 수 있습니다.

데스크톱에서 Chrome 및 Firefox는 unload 리스너가 있는 페이지에서 bfcache를 사용할 수 없도록 하여 위험을 줄이지만 많은 페이지가 캐시되지 않아 훨씬 느리게 새로고침됩니다. Safari는 unload 이벤트 리스너로 일부 페이지를 캐시하려고 시도하지만 잠재적인 서비스 중단을 줄이기 위해 사용자가 다른 곳을 탐색할 때 unload 이벤트를 실행하지 않으므로 unload 리스너를 신뢰할 수 없습니다.

모바일에서 Chrome 및 Safari는 unload 이벤트 리스너로 페이지를 캐시하려고 시도합니다. 모바일에서 unload의 불안정성으로 인해 손상 위험이 낮아지기 때문입니다. 모바일 Firefox는 unload를 사용하는 페이지를 bfcache의 대상이 아닌 것으로 취급합니다. 단, iOS는 예외로, 모든 브라우저에서 WebKit 렌더링 엔진을 사용해야 하므로 Safari처럼 작동합니다.

페이지의 JavaScript가 unload를 사용하는지 확인하려면 Lighthouse에서 no-unload-listeners 감사를 사용하는 것이 좋습니다.

unload를 지원 중단하는 Chrome의 계획에 대한 자세한 내용은 로드 취소 이벤트 지원 중단을 참조하세요.

권한 정책을 사용하여 페이지에서 로드 취소 핸들러가 사용되지 않도록 방지

일부 서드 파티 스크립트 및 확장 프로그램은 페이지에 로드 취소 핸들러를 추가하여 bfcache를 사용할 수 없도록 하여 사이트 속도를 저하시킬 수 있습니다. Chrome 115 이상에서 이를 방지하려면 권한 정책을 사용하세요.

Permission-Policy: unload()

beforeunload 리스너는 조건부로만 추가

beforeunload 이벤트로 인해 페이지에서 bfcache를 사용할 수 없는 것은 아닙니다. 하지만 이 방법은 불안정하므로 꼭 필요할 때만 사용하는 것이 좋습니다.

beforeunload 사용 사례의 예는 사용자가 페이지를 닫으면 저장되지 않은 변경사항이 손실된다고 사용자에게 경고하는 것입니다. 이 경우에는 다음 코드와 같이 사용자에게 저장되지 않은 변경사항이 있을 때만 beforeunload 리스너를 추가하고 저장되지 않은 변경사항이 저장된 직후에 삭제하는 것이 좋습니다.

function beforeUnloadListener(event) {
  event.preventDefault();
  return event.returnValue = 'Are you sure you want to exit?';
};

// A function that invokes a callback when the page has unsaved changes.
onPageHasUnsavedChanges(() => {
  window.addEventListener('beforeunload', beforeUnloadListener);
});

// A function that invokes a callback when the page's unsaved changes are resolved.
onAllChangesSaved(() => {
  window.removeEventListener('beforeunload', beforeUnloadListener);
});

Cache-Control: no-store 사용 최소화

Cache-Control: no-store는 응답을 HTTP 캐시에 저장하지 않도록 브라우저에 지시하는 응답에 설정할 수 있는 HTTP 헤더 웹 서버입니다. 로그인이 필요한 페이지와 같이 민감한 사용자 정보가 포함된 리소스에 사용됩니다.

bfcache는 HTTP 캐시는 아니지만, 지금까지 Cache-Control: no-store가 페이지 리소스 (하위 리소스가 아닌)에 설정된 경우 브라우저는 bfcache에서 페이지를 제외했습니다. Chrome은 사용자 개인 정보를 보호하면서 이 동작을 변경하기 위해 노력하고 있지만, 기본적으로 Cache-Control: no-store를 사용하는 페이지에서는 bfcache를 사용할 수 없습니다.

bfcache에 최적화하려면 캐시하면 안 되는 민감한 정보가 포함된 페이지에서만 Cache-Control: no-store를 사용하세요.

항상 최신 콘텐츠를 제공하되 민감한 정보는 포함하지 않으려는 페이지에는 Cache-Control: no-cache 또는 Cache-Control: max-age=0를 사용하세요. 이는 콘텐츠를 제공하기 전에 브라우저에 알려주며 페이지의 bfcache 적합성에 영향을 미치지 않습니다. bfcache에서 페이지를 복원할 때는 HTTP 캐시가 포함되지 않기 때문입니다.

콘텐츠가 분 단위로 변경되는 경우 대신 pageshow 이벤트를 사용하여 업데이트를 가져와 다음 섹션에 설명된 대로 페이지를 최신 상태로 유지합니다.

bfcache 복원 후 오래된 데이터 또는 민감한 정보 업데이트

사이트에서 사용자 상태 데이터를 유지하는 경우, 특히 데이터에 민감한 사용자 정보가 포함된 경우 페이지가 bfcache에서 복원된 후에 업데이트하거나 삭제해야 합니다.

예를 들어 사용자가 공용 컴퓨터의 사이트에서 로그아웃하고 다음에 사용자가 뒤로 버튼을 클릭하면 bfcache의 오래된 데이터에는 첫 번째 사용자가 로그아웃했을 때 지워질 것으로 예상했던 비공개 데이터가 포함될 수 있습니다.

이러한 상황을 방지하려면 event.persisted가 true인 경우 항상 pageshow 이벤트 후에 페이지를 업데이트하세요.

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    // Do any checks and updates to the page
  }
});

일부 변경사항의 경우 대신 전체 새로고침을 강제 실행하여 앞으로 탐색의 탐색 기록을 보존할 수 있습니다. 다음 코드는 pageshow 이벤트에 사이트별 쿠키가 있는지 확인하고 쿠키를 찾을 수 없으면 새로고침합니다.

window.addEventListener('pageshow', (event) => {
  if (event.persisted && !document.cookie.match(/my-cookie)) {
    // Force a reload if the user has logged out.
    location.reload();
  }
});

광고 및 bfcache 복원

페이지에서 뒤로 탐색 또는 앞으로 탐색 시 새로운 광고 세트를 게재할 수 있도록 bfcache를 사용하지 않는 것이 좋을 수 있습니다. 하지만 이는 사이트 성능에 좋지 않으며 광고 참여를 지속적으로 증가시키지는 않습니다. 예를 들어 사용자가 페이지로 돌아가 광고를 클릭하려고 할 수 있지만 페이지가 bfcache에서 복원되는 대신 다시 로드되면 다른 광고가 표시될 수 있습니다. A/B 테스트를 사용하여 페이지에 가장 적합한 전략을 결정하는 것이 좋습니다.

bfcache 복원 시 광고를 새로고침하려는 사이트의 경우 이 Google 게시 태그 예와 같이 event.persisted가 true일 때 페이지 성능에 영향을 미치지 않고 pageshow 이벤트의 광고만 새로고침할 수 있습니다. 사이트 권장사항에 대한 자세한 내용은 광고 제공업체에 문의하세요.

window.opener 참조 피하기

이전 브라우저에서는 rel="noopener"을 지정하지 않고 target=_blank이 있는 링크에서 window.open()를 사용하여 페이지를 연 경우 여는 페이지에 열린 페이지의 창 객체에 관한 참조가 포함됩니다.

null이 아닌 window.opener 참조가 있는 페이지는 보안 위험이 있어 bfcache에 안전하게 저장할 수 없습니다. bfcache에 액세스하려는 페이지가 손상될 수 있기 때문입니다.

이러한 위험을 방지하려면 rel="noopener"를 사용하여 window.opener 참조 생성을 방지하세요. 이는 모든 최신 브라우저의 기본 동작입니다. 사이트에서 창을 열고 window.postMessage()를 사용하거나 창 객체를 직접 참조하여 제어해야 하는 경우에는 열린 창과 오프너 모두 bfcache를 사용할 수 없습니다.

사용자가 다른 곳을 나가기 전에 열려 있는 연결 종료

앞서 언급했듯이 페이지가 bfcache에 배치되면 예약된 모든 JavaScript 작업이 일시중지되고 페이지가 캐시에서 삭제될 때 다시 시작됩니다.

이러한 예약된 JavaScript 작업이 DOM API 또는 현재 페이지에 격리된 다른 API에만 액세스하는 경우 페이지가 사용자에게 표시되지 않을 때 작업을 일시중지해도 문제가 발생하지 않습니다.

그러나 이러한 작업이 동일한 출처의 다른 페이지에서도 액세스할 수 있는 API에 연결된 경우 (예: IndexedDB, 웹 잠금, WebSocket) 일시중지하면 해당 페이지의 코드가 실행되지 않아 페이지가 손상될 수 있습니다.

따라서 다음 중 하나가 있는 경우 일부 브라우저에서는 bfcache에 페이지를 넣으려고 하지 않습니다.

페이지에서 이러한 API를 사용하는 경우 pagehide 또는 freeze 이벤트 중에 연결을 닫고 관찰자를 삭제하거나 연결 해제하는 것이 좋습니다. 이렇게 하면 브라우저가 열려 있는 다른 탭에 영향을 미칠 위험 없이 페이지를 안전하게 캐시할 수 있습니다. 그런 다음 페이지가 bfcache에서 복원되면 pageshow 또는 resume 이벤트 중에 해당 API를 다시 열거나 다시 연결할 수 있습니다.

다음 예는 pagehide 이벤트 리스너에서 열린 연결을 닫아 IndexedDB를 사용하는 페이지에서 bfcache를 사용할 수 있는지 확인하는 방법을 보여줍니다.

let dbPromise;
function openDB() {
  if (!dbPromise) {
    dbPromise = new Promise((resolve, reject) => {
      const req = indexedDB.open('my-db', 1);
      req.onupgradeneeded = () => req.result.createObjectStore('keyval');
      req.onerror = () => reject(req.error);
      req.onsuccess = () => resolve(req.result);
    });
  }
  return dbPromise;
}

// Close the connection to the database when the user leaves.
window.addEventListener('pagehide', () => {
  if (dbPromise) {
    dbPromise.then(db => db.close());
    dbPromise = null;
  }
});

// Open the connection when the page is loaded or restored from bfcache.
window.addEventListener('pageshow', () => openDB());

페이지를 캐시할 수 있는지 테스트하기

Chrome DevTools를 사용하면 페이지가 bfcache에 최적화되어 있는지 테스트하고, 페이지 로드에 방해가 되는 문제를 식별할 수 있습니다.

페이지를 테스트하려면 다음 단계를 따르세요.

  1. Chrome에서 해당 페이지로 이동합니다.
  2. DevTools에서 애플리케이션 > 뒤로-앞으로 캐시로 이동합니다.
  3. Run Test 버튼을 클릭합니다. 그러면 DevTools가 페이지를 bfcache에서 복원할 수 있는지 판단하기 위해 페이지에서 나갔다가 다시 돌아오려고 합니다.
DevTools의 뒤로-앞으로 캐시 패널
DevTools의 뒤로-앞으로 캐시 패널

테스트가 성공하면 패널에 '뒤로-앞으로 캐시에서 복원됨'이라고 표시됩니다. 실패하면 이유가 패널에 표시됩니다. 전체 이유 목록은 Chromium의 복원되지 않은 이유 목록을 참조하세요.

이유가 개발자가 해결할 수 있는 문제인 경우 패널에 실행 가능이라고 표시됩니다.

DevTools에서 bfcache에서 페이지를 복원하지 못함
실행 가능한 결과가 포함된 bfcache 테스트 실패

이 이미지에서 unload 이벤트 리스너를 사용하면 페이지에서 bfcache를 사용할 수 없습니다. unload에서 pagehide를 사용하도록 전환하여 이 문제를 해결할 수 있습니다.

의견을 제시하지
window.addEventListener('pagehide', ...);
금지사항
window.addEventListener('unload', ...);

또한 Lighthouse 10.0에는 유사한 테스트를 실행하는 bfcache 감사가 추가되었습니다. 자세한 내용은 bfcache 감사 문서를 참조하세요.

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

애널리틱스 도구를 사용하여 사이트 방문을 추적하는 경우 Chrome에서 더 많은 사용자에게 bfcache를 사용 설정하므로 보고되는 총 페이지 조회수가 감소할 수 있습니다.

실제로 대부분의 인기 분석 라이브러리에서 bfcache 복원을 새 페이지 조회수로 추적하지 않기 때문에 bfcache를 구현하는 다른 브라우저의 페이지 조회수가 이미 과소평가되고 있을 수 있습니다.

페이지 조회수에 bfcache 복원을 포함하려면 pageshow 이벤트의 리스너를 설정하고 persisted 속성을 확인하세요.

다음 예는 Google 애널리틱스로 이 작업을 수행하는 방법을 보여줍니다. 다른 분석 도구도 비슷한 로직을 사용할 수 있습니다.

// Send a pageview when the page is first loaded.
gtag('event', 'page_view');

window.addEventListener('pageshow', (event) => {
  // Send another pageview if the page is restored from bfcache.
  if (event.persisted) {
    gtag('event', 'page_view');
  }
});

bfcache 적중률 측정

아직 bfcache를 사용하지 않는 페이지를 식별하려면 다음과 같이 페이지 로드의 탐색 유형을 측정하세요.

// Send a navigation_type when the page is first loaded.
gtag('event', 'page_view', {
   'navigation_type': performance.getEntriesByType('navigation')[0].type;
});

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    // Send another pageview if the page is restored from bfcache.
    gtag('event', 'page_view', {
      'navigation_type': 'back_forward_cache';
    });
  }
});

back_forward 탐색 및 back_forward_cache 탐색 횟수를 사용하여 bfcache 적중률을 계산합니다.

뒤로 또는 앞으로 탐색에서 bfcache를 사용하지 못할 수도 있는 이유는 다음과 같습니다.

  • 브라우저를 종료한 후 다시 시작합니다.
  • 탭 복제.
  • 탭을 닫고 복원합니다.

이러한 경우 중 일부에서는 뒤로 또는 앞으로 탐색이 아니더라도 브라우저에서 원래 탐색 유형을 유지하고 back_forward 유형을 표시할 수 있습니다. 탐색 유형이 올바르게 보고되더라도 bfcache는 메모리 절약을 위해 주기적으로 삭제됩니다.

따라서 웹사이트 소유자는 모든 back_forward 탐색에서 100% 의 bfcache 적중률을 기대하기 어렵습니다. 그러나 비율을 측정하면 bfcache 사용을 방지하는 페이지를 식별하는 데 도움이 될 수 있습니다.

Chrome팀은 페이지에서 bfcache를 사용하지 않는 이유를 드러내 개발자가 bfcache 적중률을 높일 수 있도록 돕기 위해 NotRestoredReasons API를 개발하고 있습니다.

실적 측정

bfcache는 필드에서 수집되는 성능 측정항목, 특히 페이지 로드 시간을 측정하는 측정항목에 부정적인 영향을 미칠 수도 있습니다.

bfcache 탐색은 새 페이지 로드를 시작하는 대신 기존 페이지를 복원하므로 bfcache를 사용 설정하면 수집되는 총 페이지 로드 수가 감소합니다. 하지만 bfcache로 대체된 페이지 로드는 데이터 세트에서 가장 빠른 페이지 로드 중 하나일 가능성이 높습니다. 뒤로 및 앞으로 탐색을 포함하여 페이지 로드가 반복되고 일반적으로 HTTP 캐싱으로 인해 첫 번째 페이지 로드보다 느리기 때문입니다. 따라서 bfcache를 사용 설정하면 사용자의 사이트 성능이 개선되더라도 애널리틱스의 페이지 로드 속도가 느려질 수 있습니다.

이 문제를 처리하는 방법에는 여러 가지가 있습니다. 하나는 모든 페이지 로드 측정항목을 각각의 탐색 유형(navigate, reload, back_forward, prerender)로 주석 처리하는 것입니다. 이렇게 하면 전체 분포가 음수로 편중되더라도 이러한 탐색 유형 내에서 성능을 계속 모니터링할 수 있습니다. 이 방식은 첫 바이트까지의 시간 (TTFB)과 같은 사용자 중심이 아닌 페이지 로드 측정항목에 권장됩니다.

코어 웹 바이탈과 같은 사용자 중심 측정항목의 경우 사용자 환경을 더 정확하게 나타내는 값을 보고하는 것이 더 좋습니다.

코어 웹 바이탈에 미치는 영향

코어 웹 바이탈은 웹페이지의 사용자 환경을 다양한 측정기준 (로드 속도, 상호작용성, 시각적 안정성)으로 측정합니다. 코어 웹 바이탈 측정항목은 사용자가 기본 페이지 로드보다 더 빠른 탐색으로 bfcache 복원을 경험한다는 사실을 반영하는 것이 중요합니다.

Chrome 사용자 환경 보고서와 같이 코어 웹 바이탈 측정항목을 수집하고 보고하는 도구는 데이터 세트에서 bfcache를 별도의 페이지 방문으로 처리합니다. bfcache 복원 후 이러한 측정항목을 측정하기 위한 전용 웹 성능 API는 없지만 기존 웹 API를 사용하여 값의 근사치를 얻을 수 있습니다.

bfcache가 각 측정항목에 미치는 영향에 관한 자세한 내용은 개별 코어 웹 바이탈 측정항목 가이드 페이지를 참고하세요. 이러한 측정항목의 bfcache 버전을 구현하는 방법에 관한 구체적인 예는 web-vitals JS 라이브러리에 이를 추가하는 PR을 참고하세요.

추가 리소스