GlobalNomad 프로젝트 중 사이드 네비게이션을 구현하고 있었다.
전체적인 레이아웃은 내가 선택하는 메뉴에 따라서 우측에 보여지는 컴포넌트를 변경해서 렌더링하는 형식이다.
최초에는 별 생각없이 컴포넌트를 갈아끼우도록 구성했다...ㅋㅋ
React만 열심히 해와서 당연히 이렇게 구성을 했다 😁
그런데 테스트를 하는데 해당 페이지에 접속하는데 천년만년 시간이 걸리는 문제를 발견했다!
(실제로 측정해보진 않았으나 느낌상 한 4~5초 걸렸으려나??)
여튼, 억겁의 시간이 흐르는 것 같은 기분이 들었단 말이다;;;
그리고 또 한 가지 더!
왜❓
그냥 네트워크가 기분이 안좋았을수도 있고, 그날따라 뭔가 안맞았을 수도 있다.
생각해보면,
/mypage/page.tsx 파일에서 위 코드와 같은 처리를 하려다보니, 안그래도 클라이언트 컴포넌트를 사용했는데, 거기다가 import해서 가져오는 컴포넌트들도 많다.
그래서 import하는 애들까지 전부 로드될 때까지 기다려야 해서 그런거 아냐??? 라는 합리적 의심을 하기 시작했다.🤔🤔
그래서 알게된 Next.js에서 제공하는 Parallel Routes (병렬 라우트)를 적용해보기로 했다!
Parallel Routes🤔❓
Parallel Routes는 동시에 또는 조건에 따라 동일한 레이아웃에서 하나 이상의 페이지를 렌더링할 수 있게 해준다.
예를 들어, 대시보드나 소셜 사이트의 피드와 같은 매우 동적인 앱 섹션에서는 병렬 라우팅을 사용하여 복잡한 라우팅 패턴을 구현할 수 있다고 한다.
위 사진에서는 @team 페이지와 @analytics 페이지를 동시에 렌더링할 수 있다.
병렬 라우팅을 사용하면 독립적으로 스트리밍되는 각 경로에 대해 독립적인 오류 및 로드 상태를 정의할 수 있다.
-> 와... 한 페이지 안에서 섹션을 별도로 관리할 수 있다..ㄷㄷ
병렬 라우팅은 인증 상태와 같은 특정 조건에 따라 슬롯을 조건부로 렌더링할 수 있도록 해준다. 이를 통해 동일한 URL에서 완전히 분리된 코드를 사용할 수 있게 된다.
-> 이 점도 프로젝트에 활용하기 좋았다. 모바일과 pc,tablet 환경에 따라서 경로를 다르게 부여할 수 있겠다는 생각도 퍼뜩 들었다😁😁
그래서 슬롯이라는 @를 사용한 디렉토리를 만들어서 layout을 구성하는데, 이 슬롯은 라우팅 경로에 영향을 주지 않았다.
그 외에도 모달, default.js 등 여러 개념들이 있지만, 이건 공식문서 참고하세요!
그래서!
다음과 같은 사항들에 대해서 기대했다🙃🙃
- 페이지 로딩 속도가 향상
- 기존 방식은 모든 자식 컴포넌트가 전부 로드될 때까지 기다려야했다. 물론, lazy() 같은 것을 사용해서 개선할 수는 있었을 것이다. 하지만 병렬 라우트를 사용하면 각 라우트를 독립적으로 로드할 수 있어서 빠르게 보이는 부분부터 렌더링이 가능할 것 같았다.
- UX 개선
- 빠르게 보이는 부분부터 렌더링된다는 점에 의해서 사용자가 빈 화면을 보게 되는 시간이 줄어들게 될 것이다.
- 비동기 데이터 가져오기에 최적화?!
- 자식 컴포넌트가 API 요청 때문에 늦어지면 보통 다른 페이지에도 영향을 주는데, 병렬 라우팅은 영향을 주지 않을 것이기에 렌더링 성능에서 우위를 점할 수 있을 것 같다.
적용해보자!😨
사실 좀 어려웠다. 문법(?)이 사람 헷갈리게 하는 묘한 매력이 있었다
ㅂㄷㅂㄷ
경로는 app/mypage 내부에 @menu, @side 슬롯을 잡아주었다.
@menu에서는 사이드 네비게이션에서 선택하는 메뉴에 해당하는 컴포넌트를, @side에서는 사이드 네비게이션을 보여주도록 했다.
그래서 만약 사이드 네비게이션에서 '내 정보'를 선택한다면, /mypage/myinfo로 경로가 잡히면서 myinfo 디렉토리 내부의 페이지를 가져오도록 했다.
그리고 모바일 환경일때는 라우팅을 다르게 주어서 모달을 활용한 프로젝트에서 유용하게 활용할 수 있었다.
-> 일반적인 모달을 띄웠다면 경로가 없기에 '뒤로 가기' 버튼을 누르면 mypage에서 벗어날 것이다. 이러면 사용자 입장에서는 굉장히 불편할 수 밖에 없다.
그래서 성능 개선되었나❓
씁... WebPageTest 사이트에서 mypage까지 접속하는데 성능 테스트를 해봤다.
<병렬 라우팅 적용 전>
<병렬 라우팅 적용 후>
배포 버전으로 테스트 하느라 그간 추가된 코드들이 있어서 완벽하게 동일한 상태에서 비교를 한 것이 아님을 감안했을때, FCP나 Start Render, page Weight 값이 근소하게 줄어들었음을 확인할 수 있었다.
(LCP는 이미지 최적화와 코드 분리로 다뤄보자ㅋㅋ🤣🤣)
그리고 '적용 후' 버전에서는 로그인 상태 체크 후 지정된 경로로 이동하는 것 까지 측정이 되었기에 테스트가 끝나는데 시간이 조금 더 필요했을 것이다.
결론
사실 큰 프로젝트도 아니고, 비교적 프로젝트 초기 단계에서 테스트한 내용이라 큰 차이가 없을 수 있다. 그리고 체감적으로도 다이나믹한 성능 개선 효과가 있었느냐? 라고 한다면 잘 모르겠다.
하지만 수치상으로 근소하나마 유의미한 결과물을 보니 우리 프로젝트에서 적용해보길 잘했다는 생각이 든다.
- 대시보드 페이지처럼 사이드바와 메인 컨텐츠가 한 번에 보여주거나,
- 프로필 페이지처럼 사용자 정보도 불러오고, 팔로워 리스트도 따로 불러오고, 게시글도 불러와서 보여주거나,
- 상페 페이지에서 상품 정보와 리뷰 같은 것들를 따로 렌더링 하고 싶거나,
- 동일한 레이아웃 안에서도 각각의 다른 ui마다 경로를 부여하고 싶을때
- 개인적으로는, 모달에 뒤로가기 해도 경로가 유지된다는 점이 좋았다
병렬 라우팅을 사용한다면 좋을 것 같다! 낯설지만 재미있는 친구였다.👍👍👍
출처: https://rocketengine.tistory.com/entry/NextJS-13-Routing-Parallel-Routes-병렬-라우트 [OIL:티스토리]
