Nextjs란?

emit·2021년 9월 12일

https://www.jackherrington.com/csr-ssr-and-ssg-on-nextjs/
이 글의 번역 요약글입니다. 잘못된 부분이 있으면 댓글 부탁드려요

Nextjs

Nextjs는 React의 SSR(Server Side Rendering)을 쉽게 구현할 수 있게 도와주는 간단한 프레임워크

SSR vs CSR

일반적인 React 렌더링 방식은 render() 함수가 먼저 실행되고, 그다음 ComponentDidMount()
함수를 통해 데이터를 가져와서 다시 한번 렌더링이 됩니다.
반면에 Next는 getInitialProps() 라는 함수를 사용하기 때문에 데이터를 먼저 가져와서
한번에 렌더링을 해줍니다 (pre-rendering)

SSR은 한번에 렌더링이 되기 때문에 초기로딩 속도는 빠르지만, page 이동 시에는 CSR보다 느립니다. 왜냐하면 page를 요청할 때마다 중복되는 파일을 내려 받아야하기 때문입니다.

하지만 CSR은 초기 로딩 속도는 느리지만, 첫 페이지 로딩 때 모든 파일을 내려받기 때문에 페이지를 이동할 때 마다 해당 페이지에서 필요한 데이터만 불러서 사용하면 됩니다.

정리

SSR의 경우, 초기 로딩 속도가 빠르고 SEO에 유리하지만, View 전환시 서버에 계속 요청을 해야하므로 서버에 부담이 크다.
CSR의 경우, 초기 로딩 속도는 느리지만 초기 로딩 이후에는 서버에 다시 요청할 필요없이 클라이언트 내에서 작업이 이루어지므로 빠른속도와 자연스러운 사용자경험을 제공하지만 SEO문제가 있다.

Nextjs 특징

정적 및 서버 렌더링

Next.js는 기본적으로 빌드 시에 만든 모든 페이지를 미리 렌더링을 하여 사용자에게 빠르게 보여준다. (전형적인 SSR 방식)

그 후 페이지에 필요한 최소한의 자바스크립트 코드를 불러와 페이지를 사용할 수 있게 해준다.

그리고 정적 파일을 제공해 편리한게 페이지에서 정적으로 사용하고 있는 이미지의 대한 path도 따로 설정해 줄 것도 없이 이미지 파일 이름만으로도 바로 설정이 가능해 정말 편리하다.

Typescript 지원

Next.js는 기본적으로 Typescript를 지원하고 있어 따로 모듈을 설치하지 않고도 바로 Typescript를 사용할 수 있다.

스마트 번들링

기본적으로 웹팩이나 바벨을 사용하고 있어 따로 설정을 해주지 않고도 바로 사용할 수 있다.

라우트 프리페칭

React.js에서는 Routing을 하기 위해서는 항상 'react-router'라는 모듈을 사용하였다. 항상 route라는 자바스크립트 안에 라우팅할 페이지들의 경로를 설정해주고 기타 props들을 설정해 주는 과정을 하면서 route path를 항상 찾거나 맞지 않다면 번거롭게 수정을 해야되는 문제가 종종 있었다.

하지만 Next.js는 파일 시스템 기반 라우팅을 사용하므로 폴더 경로에 따라 만들어준 페이지의 경로가 설정되어 따로 path를 잡아줄 필요도 없다.

Nextjs에서 CSR vs SSR vs SSG 적용

1. CSR (클라이언트 사이드 렌더링)

일반적인 컴포넌트의 작동 방식이고, getServerSideProps 메서드가 없다고 가정할 때 페이지를 렌더링 하는 방법이기도 하다.

장점

서버에서 빠름
- 빈 페이지만 렌더링하므로 렌더링 속도가 매우 빠릅니다.
정적 지원
- 빈 페이지는 정적으로 생성되고 S3와 같은 것에서 제공될 수 있으므로 훨씬 더 빨라집니다.
단일 페이지 응용 프로그램 지원
- 클라이언트 측 렌더링은 단일 페이지 응용 프로그램 또는 SPA를 지원하는 유일한 모델입니다.

단점

초기 렌더링 없음
- 고객에게 빈 페이지를 보내고 있습니다. 따라서 앱이 크거나 고객의 연결 속도가 느린 경우 이상적이지 않습니다.

2. SSR (서버 사이드 렌더링)

서버 측 렌더링 모델에서 Nextjs 서버는 먼저 getServerSideProps 페이지 파일에서 내보낸 메서드를 호출. 이 메서드는 props를 반환한 다음 구성 요소로 전송됩니다. 서버는 해당 데이터를 페이지 구성요소를 렌더링하고 이를 HTML 문자열로 변환하여 클라이언트에 다시 보냅니다.

getServerSideProps 메서드 사용

장점

즉시 사용 가능한 콘텐츠
- 렌더링된 HTML을 클라이언트에 보내기 때문에 고객은 거의 즉시 콘텐츠를 보기 시작할 것입니다.
추가 클라이언트 가져오기 없음
- 이상적으로 서버 렌더링 프로세스는 데이터를 가져오는 데 필요한 모든 호출을 수행하므로 클라이언트에서 추가 서비스 호출을 수행하지 않습니다. 적어도 사용자가 페이지를 조금 가지고 놀기 시작할 때까지는.
SEO에 적합
- HTML 콘텐츠와 같은 검색 엔진. 클라이언트 측 렌더링만 사용하는 경우 Javascript를 실행하는 검색 엔진에 의존하고 있으며 이는 발생할 수도 있고 발생하지 않을 수도 있습니다.

단점

서버에서 더 느림
- 페이지를 서버에서 한 번, 클라이언트에서 한 번, 두 번 렌더링합니다. 또한 페이지를 렌더링하기 위해 서버에서 서비스를 호출할 수도 있습니다. 이 모든 작업에는 시간이 걸리므로 HTML을 클라이언트로 처음 보내는 것이 지연될 수 있습니다.
일부 UI 라이브러리와 호환되지 않음

-원하는 UI 라이브러리가 창을 사용하는 경우 노드에 window 글로벌 변수가 없기 때문에 이를 수정하거나 다른 것을 사용해야 합니다.

3. SSG (정적 사이트 생성)

정적 사이트 생성은 요청 시간 대신 빌드 시간에 페이지를 렌더링한다는 점을 제외하고 서버 측 렌더링과 비슷합니다.
다음 세계에서는 NextJS 빌드 프로세스가 먼저 페이지 자바스크립트 파일에서 내보낸 getStaticPaths 메서드를 호출하여 렌더링해야 하는 모든 경로의 인벤토리를 가져옵니다.
그런 다음 빌드 프로세스는 각 경로에 대한 getStaticProps 메서드 를 호출하고 서버 측 렌더링에서와 동일한 방식으로 페이지를 렌더링합니다.

장점

즉시 사용 가능한 콘텐츠
- 렌더링된 HTML을 클라이언트에 보내기 때문에 고객은 거의 즉시 콘텐츠를 보기 시작할 것입니다.
추가 클라이언트 가져오기 없음
- 이상적으로 서버 렌더링 프로세스는 데이터를 가져오는 데 필요한 모든 호출을 수행하므로 클라이언트에서 추가 서비스 호출을 수행하지 않습니다. 적어도 사용자가 페이지를 조금 가지고 놀기 시작할 때까지는.
SEO에 적합
- HTML 콘텐츠와 같은 검색 엔진. 클라이언트 측 렌더링만 사용하는 경우 Javascript를 실행하는 검색 엔진에 의존하고 있으며 이는 발생할 수도 있고 발생하지 않을 수도 있습니다.
놀라운 빠른 제공
- 정적 콘텐츠는 미친 듯이 빠르게 제공됩니다. 당신은 또한 그것을 아주 깔끔하게 에지 캐시할 수 있습니다.
서버 없음
- 서버를 실행할 필요가 없습니다. 따라서 해당 서버를 모니터링할 필요가 없으며 훨씬 적은 호출기 듀티 핑을 얻을 수 있습니다.

단점

대규모 사이트를 재구축하는 데 느릴 수 있음
- 수만 개의 경로가 있는 경우 속도가 느려질 수 있습니다 . NextJS 팀이 증분 재구축 작업을 하고 있지만.
일부 UI 라이브러리와 호환되지 않음

-원하는 UI 라이브러리가 창을 사용하는 경우 노드에 window 글로벌 변수가 없기 때문에 이를 수정하거나 다른 것을 사용해야 합니다.