모바일에서 웹은

2010년 이전 webkit이 공개 되기 전의 환경, 곧 스마트폰이 없었을 때의 환경에 비하면 현재의 모바일 상황은 매우 많이 진화했다.

“약전 지역” 이라는 말도 없어졌고, 이미지나 리소스를 어떻게 최소로 받아야 할지 더 고민하지 않는 것 같다. 더욱이 스크립트의 실행상태에 대해서도 큰 고민이 없다.

그때의 생각에는 거의 무한대의 메모리와 네트워크 대역대를 가지고 있기 때문에다.

그럼에도 불구하고 무언가 최적화 하려는 노력은 계속 되는 것 같다. 그중 하나가 BFCache(Back Forward Cache)이다.

BFCache 란?

Using_Firefox_1.5_caching 이 내가 알고 있는 표준스러운 문서 이다.

BFCache를 짧게 요약하면 html 문서나 css 문서등을 저장했다가 네트워크 요청을 안하는 수준이 아니고, html 파싱 등 페이지를 구성하는 동작 자체를 하지 않도록 javascript 상태까지 저장했다가 다시 되돌려 보여주는 기능을 이야기 한다.

보통 데스크톱에서는 기능이 꺼져 있고, iOS를 사용하는 기기에서 기능을 사용하고 있다.

캐쉬가 속도의 만병 통지약은 아니다. 실시간으로 반영해야 할 사항이라든지 여러가지 요소들이 많이 있다.

하지만 어느 정도 규칙을 가지고 실시간에 대한 문제가 없음을 검증할 수 있다면 빠르게 웹 페이지를 볼 수 있을 것이다.

그럼 무엇이 문제 인가?

BFCache 로 동작하면 네트워크 요청도 없을 뿐만 아니라, 페이지를 만드는 동작도 이루어지지 않는다.

곧 load 이벤트가 오지 않는 상황이 발생한다.

대신 pageshow 와 pagehide 이벤트가 발생하여 페이지 이동을 알리게 된다.

어떻게 BFCache 로 페이지가 이동 되었는 지 알 수 있는가?

  window.onpageshow = (event) => {
    if(event.persisted === true)
      console.info("BFCache 를 통해 페이지 전환")
  }

event 객체에 persisted 라는 프로퍼티를 통해서 BFCache 되었는지 아닌지 확인할 수 있다.

최근 이슈가 있어서 디버깅을 진행해본 경험을 정리하면 BFCache가 활성화 되어 있다고 해서 뒤로가기를 누르면 항상 케쉬를 하는 것은 아니다.

아무래도 메모리 제약도 있고 페이지의 완료 상황도 다르기 때문에 그러할 것이라고 추척해본다.

그럼 도대체 무엇이 문제인가?

load 에 걸 자바스크립트를 몽땅 pageshow 로 옮기면 간단히 해결될 상황이 아닐까 싶다.

하지만 시점상의 이유로 인라인으로 들어가 있는 자바스크립트가 실시간 반영을 해야할 경우는 약간 머리가 아파온다.

  <div id="me">
    <script>
      document.write("<iframe>.....</iframe>")
    </script>
  </div>

그리고 굳이 리소스를 다시 받아올 필요가 없음에도 pageshow에서 ajax를 이용하여 무언가 다시 로드하는 경우에는 굳이 BFCache를 하여 최적화하려는 브라우저에게 미안한 일을 하게 되는 꼴이 된다. 이미 자바스크립트 상태까지 캐시하였기 때문에 다시 요청하지 않아도 될 사항들이 엄하게 다시 실행되는 결과를 볼 수 있다.

결론

내가 생각한 결론은 다음과 같다.

• 인라인 자바스크립트는 왠만하면 줄이자.
• 리소스를 순서를 가지로 요청하는 경우에는 기존의 load 를 그대로 사용하자
• 만약 실시간 갱신이 필요한 것들에 대해서만 pageshow 를 사용하자

그렇게 해야만 BFCashe 의 이점을 최대한 누리는 페이지를 구성할 수 있을 것으로 보인다.

번외 - 왜 굳이 다들 다루고 마친 이슈를 이야기 하는가?

인라인 스크립트도 되어 있는 일이긴 하지만 BFCache 상황에서 특정 iframe 에 대해서 사용자 이벤트가 올라오지 않는 문제가 있었다.

해당 수정 사항을 이야기 하기 위해서 모두가 알고 있는 사항에 대해서 풀어 놓아 보았다.