[BUG] 닉네임이 안바껴요!

[BUG] 닉네임이 안바껴요! - bfcache

문제 상황

얼마 전, Mac/iOS Safari에서만 발생하는 이슈가 등록되었는데
한마디로 '닉네임 수정이 안돼요' 라는 내용이었다.

카모아에서 닉네임을 수정하는 정상적인 플로우는 다음과 같다.

Safari에서는 닉네임을 수정 완료한 후 [내정보 수정] => [마이페이지] 이동(마지막 화살표)했을 때, 수정 전 닉네임이 노출되는 것이 문제의 핵심이었다.

원인 찾기

나는 재현 케이스를 짚어보며 정확한 문제점을 찾아 딱 필요한 수준의 해결방안을 적용하는 것을 지향한다.

이번 케이스를 재현하기 위해서는 다음 전제조건이 성립해야 했다.

Safari 브라우저 (Mac/iOS 전부)
페이지 간 뒤로가기 동작 (위 이미지에서 '설정 완료' 버튼이 있는 뷰는 모달이다)

추가적으로 뒤로가기 했을 때 JS가 실행되지 않고 기존 페이지를 그대로 보여주고 있어서
전체 페이지가 캐싱된 것으로 추측하고 'Safari page cache' 키워드부터 시작해 구글링을 시작했다.

진짜 범인은? bfcache

범인의 이름은 Back/Forward Cache(bfcache).

뒤로가기/앞으로가기 동작을 할 때, 전체 페이지(JS 힙 메모리까지)를 캐싱해두는 역할을 한다.

문제상황에서는 bfcache에 의해 캐싱된 페이지를 노출했기 때문에
닉네임을 요청하는 스크립트를 다시 실행하지 않고 그대로 보여줬던 것이다.

해결방식

bfcache는 브라우저 단에서 구현된 것이기 때문에
사용자의 단말기를 뺏어서 bfcache를 비활성화하지 않고는 귀찮더라도 공존하는 방식을 찾아야한다.

bfcache의 로드/언로드 시점을 잡아낼 수만 있다면,
필요한 정보만 재요청하면서 캐시의 성능상 이점을 챙길 수 있게 된다.

pageshow / pagehide 이벤트를 활용한 캐싱 감지

가장 보편적인 해결방안은 pageshow/pagehide 이벤트를 이용하는 것이다.

해당 이벤트 객체에는 persisted라는 boolean 프로퍼티가 있는데,
이를 통해 캐시에 저장되는지(pagehide), 캐시로부터 복원되는지(pageshow) 구분할 수가 있다.

window.addEventListener('pageshow', (e) => {
  if(e.persisted) {
    console.log("Nice to meet you. I'm from bfcache.");
  }
}

window.addEventListener('pagehide', (e) => {
  if(e.persisted) {
    console.log("Bye.. I have to enter bfcache");
  }
}

그런데.. 왜 사파리에서만 캐싱이 됐을까

여기서 '새로운 지식을 얻었다 헤헿' 하고 끝내기엔 한가지 찝찝한 구석이 있는데,
바로 사파리에서만 해당 캐싱이 발생하고 있다는 점이다.

사파리에서만 bfcache가 지원되고 있어서 그런걸까?

web.dev 문서에서는 Safari/Firefox는 예전부터 지원하고 있었다고 한다.

'그럼 그렇지!' 하면서 파이어폭스에서 테스트해보니 역시 같은 캐싱이 일어났다.

그런데 문제는 그 다음 줄,

버전 86부터 Chrome은 소수의 사용자를 위해 Android에서 사이트 간 탐색을 위해 bfcache를 활성화했습니다. 후속 릴리스에서는 추가 지원이 천천히 롤아웃되었습니다. 버전 96부터 bfcache는 데스크톱 및 모바일의 모든 Chrome 사용자가 사용할 수 있습니다.

버전 96부터 bfcache는 데스크톱 및 모바일의 모든 Chrome 사용자가 사용할 수 있습니다.
...
.
bfcache는 데스크톱 및 모바일의 모든 Chrome 사용자가 사용할 수 있습니다.
...
.
bfcache는 모든 Chrome 사용자가 사용할 수 있습니다.

??!