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

신원준·2022년 4월 16일
1

트러블슈팅 일지

목록 보기
1/1
post-thumbnail

문제 상황

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

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

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

원인 찾기

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

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

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

추가적으로 뒤로가기 했을 때 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 사용자가 사용할 수 있습니다.

??!

크롬도 bfcache를 지원한다니, 근데 왜 우리 서비스는 안됐던 거지?

혼란스러움도 잠시 다행히 금방 결론을 찾을 수 있었다.

크롬은 언제 bfcache를 적용할까?

결론부터 말하자면, 크롬은 bfcache에 최적화된 사이트만 캐싱하려고 노력하는 것으로 보인다.

web.dev 문서에는 bfcache를 최적화하는 방법에 대한 설명도 있으니 참고하면 될 것 같다.

가장 중요한 우리 사이트가 얼마나 최적화 되어 있는지 알아보기 위한 방법으로는
프론트엔드 개발자의 빛과 소금, 크롬 개발자 도구를 이용하는 것이다.

개발자 도구 > Application > Back/forward cache

이 곳에서 현재 bfcache가 적용되는 페이지인지 테스트해볼 수 있고,
안된다면 어떤 이유에서 적용하지 않는지 친절하게 설명해준다.

Pending Support, Not Actionable 등의 최적화를 위한 힌트를 주고 있다.

마무리

앞으로 제 벨로그에는 개인 프로젝트와 회사 프로젝트의 트러블슈팅과 프론트엔드 TIL 위주로 포스팅할 예정입니다. 성장에 도움되는 다양한 지적과 조언은 언제든지 환영합니다!

참고자료

https://web.dev/bfcache/
https://ui.toast.com/weekly-pick/ko_20201201
https://goddaehee.tistory.com/266

profile
뚝딱뚝딱

0개의 댓글