parallel route 사용했더니 First Load JS가 🔴200kb -> 🟢80kb대로

parallel route에 대해서

next.js 13부터 parallel route(병렬 라우팅) 기능이 생겼다. 이것이 뭐냐?? 말 그래도 병렬적으로 라우팅 한다는것!!!
한 레이아웃에서 여러 페이지를 병렬적으로 렌더링 할 수 있다는 것이다.

next.js 참고

next.js에서 제공한 이미지를 보면 layout.js라는 한 레이아웃에서 team 페이지와 analytics페이지를 병렬적으로 렌더링 하고 있다.
그러니까 한페이지에 team과 analtics가 개별적으로 렌더링이 되고 있다는것!
병렬적으로 렌더링 하고 싶은 파일은 @폴더/page.js 로 만들어주어야 하는 규칙을 가지고 있다.
@폴더/page.js로 만들어진 파일은 layout.js파일에서 props로 받을 수 있다.
사용법은 이게 끝이다. ㅎ

next.js 참고

만약 병렬적으로 렌더링이 필요한 파일들이 로딩이나 에러가 따로 필요하다면 해당 폴더에 넣어주면 자동적으로 적용된다. 개꿀!!!! ㅋㅎ

 

 

 

그래서 얻을 수 있는 효과는?

한 페이지에 3개의 데이터를 불러오는 컴포넌트가 있다고 하자. 그 3개의 컴포넌트들이 데이터 fetch가 완료 될때까지 페이지는 계속 로딩될 것이다. 로딩시간이 길어진다는 것. 파일 크기도 커질 수 밖에 없다.
pallal route를 사용함으로써 이 문제들이 해결된다. 우리는 페이지의 로딩을 기다리지 않고 A가 로딩되고 있어도 로딩이 완료된 B를 확인 할 수 있다. 이것은 성능적으로 큰 효과를 얻을 수 있다.

 

 

 

내 프로젝트에 적용

 

collection 페이지가 list데이터와 user데이터를 동시에 같이 가져오고 있었는데 이것을 parallel route방식으로 바꿨다.
기존에는 바로 collection으로 라우팅 됬을때 보여지는 page파일에 user정보와 list를 fetch하도록 했다.
user정보과 list가 fetch가 완료되기 전까지는 페이지 라우팅의 로딩시간이 길어졌었다.

// 기존코드 예시
const Collectionpage = async () => {
    const user = await fetchuser();
    const list = await fetchList();
    
	return (
    	user && <component..>
    	list && <component..>
    )
}

더군다나 이 페이지는 탭클릭했을때 쿼리가 바뀌면서 페이지가 렌더링 되므로 list 부분만 렌더링 되는것이 필요했다.
이 부분은 user 정보를 가져오면서 미들웨어와 관계가 있어 탭 클릭했을때 로딩이 3-4초 길게는 5초까지 걸렸었다 ;;
parallel route와 미들웨어를 같이 개선하면서 즉각적으로 반응하도록 개선했다. 지금은 클릭시 0.1~0.5초 정도 걸리는거 같다.
✔️블로그에 이부분도 정리를 해야할것 같다.

 

패럴 라우팅을 적용한 @tab,@list를 layout으로 받았다.

 

 

 

build 결과

collection페이지를 보면 First Load JS가 80kb대로 내려가 초록불이 되었다. (원래 200kb대로 빨간불이였음.)
60%이상은 파일 크기가 감소했다.