🚍 1. 작성 계기
에전 블로깅 내용에서 뒤로가기, 앞으로가기에 대해 막는 방법에 대해서 회고를 남긴 적이 있었다.
그 때에 여러가지 검색 결과, 보안 상 어쩔 수 없이 history를 비우는 행위를 하지 못하도록 막아놨기 때문에 결국 조건부로 어떤 데이터가 존재하는지 아닌지에 따라 useEffect로 처리를 하도록 만들었었다.
근데 솔직히 이렇게 처리하고 나서도 조금 찝찝했던 것이, 앱이 리랜더링이 되는 과정에서 redux 상태가 초기화되는 경우가 있었으므로 해당 예외적인 처리까지 해줘야 하는 부담감 + 지저분함은 나의 마음에 살짝 남은 상태로 넘어가고 있었었다.
그런데, 오늘 면접준비를 위해 performance API라는 것을 파보다가 좋은 것을 발견하게 되어 누군가 이 글을 볼 사람을 위해 기록을 남겨둔다
🚍 2. performance API?
상당히 생소한 이 존재는 브라우저가 제공하는 성능측정관련 API이다.
가장 대표적인 프로퍼티가 memory와 naviagtion, 그리고 timing인데 대략 개발자 콘솔에 performance라고 쳐보면 해당 내용을 확인할 수 있다.
여기서 보면 memory는 js가 실행되면서 얼마나 많은 힙메모리를 사용하고 있는지도 볼 수 있고,
timing을 통해 서버로부터 리소스가 받아진 이후, DOM이 생성되어 load가 완료되는 시점까지의 정보를 보여준다.
참고로 이 프로퍼티가 있기 전까지 개발자들은 단순하게 Date를 이용한 로드 측정을 했었다. 예를들어, 스크립트 최상단에 변수로 Date.now()를 통해 선언해둔 뒤, 최하단에 다시금 Date.now()를 호출한 결과와 빼줘서 측정한다는... 그런 방식이었으나 이는 전혀 정확하지 않은 정보였다. ( 일단 JS에서 Date자체가 완벽하게 정확하지 않을 뿐더러 해당 코드가 실행되므로 인해 페이지 로드가 느려짐에 따라 측정 오차가 발생하며, 가장 최악으로 네트워크의 속도 변화로 인해 리소스가 받아지는 시간이 늦어지는 것에 대한 자료를 제공하지 못한다는 점이다.)
그러나 window가 제공하는 performance.timing은 탭이 생성되면서 window 객체가 만들어지는 순간부터 시작하여 DOM이 load가 완료되는 그 순간까지 모든 정보를 담아두고 있기 때문에 더 정확한 측정이 가능하다.
대표적으로 timing 프로퍼티를 통해 확인해볼 수 있는 내용은 다음과 같다
- 네크워크의 지연시간 : responseEnd - fetchStart
- 서버에서 페이지를 받고 처리 후 로드까지의 걸린시간 : loadEventEnd - responseEnd
- 전체 처리과정의 걸린시간 : loadEventEnd - navigationStart
만약 특정 기준에 대해 걸린 시간을 확인하고 싶다면 해당 상위 내용에서 확인할 수 있는 Navigation timing 권고안 그림을 참고하여 차이를 빼서 확인해보면 된다.
앗... 그러고보니 지금 내용은 timing이 메인은 아니었다... 이야기하다보니 잠시 옆길로 세버렸다
여튼, 여기서 navigation은 이 페이지에 어떻게 접근했는가? 를 설명해주는 프로퍼티이다.
여기서 존재하는 두개의 속성은 다음과 같다
- redirectCount : 리다이렉트를 했던 횟수를 카운트해준다
- type : 페이지를 로딩한 탐색의 종류를 의미한다.
여기서 오늘 말하고 싶었던 핵심, 과연 history를 이용해서 뒤로가기나 앞으로가기로 페이지를 이동했을 때에 제약을 걸고 싶으면 어떻게 해야하는가... 에 대한 내용이 이 "type"을 이용하면 확인할 수 있다
type은 3가지 값을 갖는데
- "0" 일 경우, 그냥 바로 해당 주소로 들어왔을 경우를 뜻한다. ( 즉, 히스토리가 없음 )
- "1" 일 경우, 페이지를 새로고침해서 들어왔을 경우를 뜻한다.
- "2"일 경우, 히스토리를 이용해서 뒤로가기나 앞으로가기로 들어왔을 경우를 뜻한다.
여기서 3번이 아주 매력적이지 않은가.
만약 어떤 사용자가 페이지를 이동했다가 다시 뒤로가기를 통해 특정 페이지를 접근했을 경우, window.performance.navigation은 아래와 같은 결과를 보여준다.
즉, useEffect로 특정 불완전한 스토리지 데이터를 조회해서 리다이렉트시키는 것이 아니라 그냥 완전히 이 페이지를 히스토리로 이동해왔다면 리다이렉트하도록 만들면 되는 것이다.
만, 여기엔 함정이 있다.
아니 의사양반 이게 무슨소리요... depricated라니?
그렇다. 해당 프로퍼티는
더이상 쓰지 말라고 Navigation Timing Level 2 specification 에서 처리되었던 것이다.... 아니 왜 이렇게 좋은걸 못쓰게 만드는건가...
그러나, 뜻이 있는 곳에 답이 있다고 이것을 대체해서 사용하는 방법을 확인할 수 있었다.
위의 코드는 스텍오버플로우 형아가 알려준 코드이다. 권고안에 따르면 Performance 생성자를 통해서 뭔가를 하라고 하기는 했는데 실패했었고 스택 형이 알려준 방법은 정확하게 결과를 보여주었다.
여기서 주목해야 할 부분은 'type'인데, 여기서 navigate이라는 뜻이 바로 url에 주소를 입력하는 등을 이용하여 처음으로 해당 페이지에 접속했을 때를 뜻한다.
그렇다면 만약, 여기저기서 라우팅을 해놓은 다음에 뒤로가기 등으로 페이지에 접근하면 저 내용이 어떻게 변하게 될까?
정확하게 "back_forward"라고 변경되는 것을 확인할 수 있다.
이것이 바로 말해주는 바는 "응, 지금 페이지 히스토리 이용해서 접근했어" 라고 알려주는 것이다.
그러므로 이제는 불완전한 redux store의 정보 유무에 따라 리다이렉트를 할 것이 아니라 이렇게 performance를 이용하여 정확하게 확인한 후 리다이렉트 처리를 하는 방법을 알게 되었다. 너무 재미있었다.
