getInitialProps vs getServerSideProps

sy u·2022년 7월 11일

getInitialProps getInitialProps vs getServerSideProps getServerSideProps nextjs

🚪 들어가기

getInitialProps는 서버에서 페이지에 필요한 데이터를 채우고 렌더링한 페이지를 클라이언트에 보낸다. 따라서 SEO에 친화적이다.

그러나 Next 9.3에서 getServerSideProps가 도입되면서 getServerSideProps가 getInitialProps를 대체하게 되었다.

어떻게 getServerSideProps가 getInitialProps를 대체하게 되었을까?
이 글에서는 두 개의 공통점과 차이점을 알아보고자 한다.

⚙️ getServerSideProps와 getInitialProps의 작동 방식

getServerSideProps를 사용하는 페이지는 페이지 요청 마다 해당 요청에 대한 응답 전에 서버에서 페이지를 렌더링한다.

요청마다 서버에서 매번 페이지를 렌더링해야하기 때문에 SSG 보다는 페이지의 로딩 속도가 느려질 수 있지만 CSR을 사용하는 방식 보다는 성능이 좋고 SEO에 친화적이다.

getInitialProps는 getServerSideProps와 거의 비슷하게 작동한다.

그렇다면 왜 getServerSideProps를 사용해야 할까?
getInitialProps보다 getServerSideProps는 뭐가 유용할까?

🔎 getServerSideProps와 getInitialProps의 차이점은 무엇일까?

1. next/link, next/router를 통한 페이지 전환

getInitialProps는 URL을 통한 초기 로드 및 $\lt$ a / $\gt$ 태그의 href속성으로 이동할 경우에는 서버에서 실행되지만 next/link, next/router를 사용한 이동 즉 클라이언트 측에서 페이지를 이동할 경우 서버가 아닌 클라이언트에서 작동한다.

NextJs의 getIntialProps 문서에서도 해당 내용을 확인할 수 있다.

For the initial page load, getInitialProps will run on the server only. getInitialProps will then run on the client when navigating to a different route via the next/link component or by using next/router. However, if getInitialProps is used in a custom _app.js, and the page being navigated to implements getServerSideProps, then getInitialProps will run on the server.
🔖 getInitialProps 공식문서

이렇게 작동하는 것에 가장 큰 문제점은 getInitialProps 내부에 클라이언트 측에서 수행할 수 없는 로직(직접 데이터베이스에 접근하는 등…)이 존재하는 경우 문제가 발생한다.

또한 서버에서만 수행하는 로직만 존재한다 하더라도 클라이언트 측에서도 작동하기 때문에 클라이언트 측 번들에도 포함되어 번들 사이즈가 커지게 된다. 이는 어플리케이션 성능과도 연결된다.

반면 getServerSideProps는 초기 페이지 로드뿐만 아니라 next/link, next/router를 사용하여 다른 페이지로 이동할 경우에도 서버에서 렌더링을 실행하고 결과를 클라이언트 측에 전달한다. 이는 getServerSideProps 내부에서 클라이언트 측에서 수행할 수 없는 로직이 존재해도 문제가 발생하지 않는다는 것을 의미한다.

어떻게 getInitialProps가 클라이언트에서도 작동할까?

나는 어떻게 getInitialProps가 클라이언트에서 작동하는지 궁금해졌다.

테스트를 하기 위해 SSG(getStaticProps), SSR(getServerSideProps), legacy(getInitialProps)를 사용하는 페이지를 같은 내용으로 생성해 실행하고 빌드 해 보았다.

1. 번들 파일 확인하기

아래 사진으로만 확인해도 getInitialProps가 존재하는 페이지의 클라이언트 번들 파일이 큰다고 느껴진다.

2. 빌드 후, /.next/server/pages 폴더 확인하기

실행 후 로드된 js 파일은 SSR(getServerSideProps), legacy(getInitialProps) 만 확인해 볼 예정이다.
내가 테스트로 작성한 파일은 getServerSideProps과 getInitialProps 모두 내부에 lodash를 사용해 보았다.
우리가 공부한 내용에 의하면 클라이언트 측 번들에 lodash가 없어야 한다.
결과는 아래와 같이 getInitalProps에만 lodash가 포함되어 있는 걸로 확인된다.

빌드 후, /.next/server/pages 폴더에 있는 파일은 아래와 같다.

자동 정적 최적화된 파일이다. 해당 내용은 아래에서 살펴볼 예정이다.
getInitialProps를 사용한 파일이다.
getStaticProps를 사용한 파일이다.
getServerSideProps를 사용한 파일이다.

3. 도구를 통해 확인해보기

https://next-code-elimination.vercel.app/
위 사이트는 클라이언트 측 번들 파일에서 서버 측 코드가 사라진 결과를 볼 수 있다.
코드를 수정해 수정도 해볼 수 있다.

아래 사진과 같이 클라이언트 측 번들 파일에 getInitialProps의 내부 로직이 그대로 남아 있는걸 확인할 수 있다.

2. 자동 정적 최적화 (Automatic Static Optimization) 지원 여부

NextJs는 차단 데이터(blocking data) 요청이 없다면 페이지가 정적(사전 렌더링 가능)인지 자동으로 확인한다.
이 확인에는 페이지에 getInitialProps와 getServerSideProps가 없을 때 결정된다.

정적으로 생성된 페이지는 클라이언트 측에서 JS 파일이 로드되고 정적인 HTML에 이벤트 핸들러를 추가하여 (hydation) 완전하게 상호작용이 가능한 페이지가 된다.

자동 정적 최적화의 최대 이점은 서버 측 계산이 필요하지 않으며 CDN에서 사용자에게 즉시 스트리밍할 수 있다는 것이다. 이를 통해 사용자가 페이지를 이용할 때, 빠른 로딩 속도를 경험할 수 있다.

getInitialProps뿐만 아니라 getServerSideProps 또한 페이지 내에 존재할 때, 해당 페이지는 자동 정적 최적화되지 않는다.

자동 정적 최적화 테스트 해보기

빌드 후, /.next/server/pages 폴더에 있는 파일은 아래와 같다.

자동 정적 최적화된 파일이다. 해당 내용은 아래에서 살펴볼 예정이다.
getInitialProps를 사용한 파일이다.
getStaticProps를 사용한 파일이다.
getServerSideProps를 사용한 파일이다.

위의 파일들을 보면 정적 파일 html 파일이 생성된 것은 자동으로 정적 최적화된 aso 파일과 getStaticProps(SSG) 파일이다.

getInitialProps와 getServerSideProps는 .js파일로 빌드 되었다.

커스텀 App 파일에 존재하는 getInitialProps

getStaticProps가 존재하지 않아도 getInitialProps나 getServerSideProps가 존재하지 않는 페이지는 자동으로 정적 최적화가 된다.
그러나 커스텀 App 파일 내부에 getInitialProps가 존재한다면 getStaticProps가 없는 페이지는 최적화가 되지 않는다.