최종 수정 : 2024-05-31
Next.js가 지원하는 렌더링 방식과 이를 바탕으로 기존 리액트로 개발된 프로젝트에 비해 갖게 되는 이점은 무엇인가?
React는 클라이언트에서만 렌더링할 수 있다(CSR)는 문제가 있다. 이는 자바스크립트 번들을 다운로드하는 데 시간이 오래 걸리고 검색 엔진 최적화가 잘 안 된다. 이 문제는 애플리케이션이 커질수록 점점 부각된다.
클라이언트에서만 렌더링 할 수 있던 문제가 SSR을 통해 해결된다. 쿠키(Cookie), 주요 API, 데이터 검증 같은 작업을 서버에서 처리하므로 중요한 정보를 클라이언트에 노출할 필요가 없기에 더 안전하다. 또한, 클라이언트에서 서버가 렌더링한 HTML 콘텐츠를 받기 때문에 검색 엔진 웹 문서 수집기가 페이지를 렌더링할 필요가 없어서 SEO 점수가 높아진다.
그러나 CSR의 한계를 SSR이 극복하는데, 도움을 주지만 만능은 아니다. SSR을 사용할 경우, 페이지에 대한 요청을 처리하는 시간이 길어진다. 따라서, 브라우저 전용 API를 사용해야 하는 컴포넌트가 있다면 해당 컴포넌트를 반드시 브라우저에서 렌더링하도록 명시적으로 지정해줘야 한다. 클라이언트 컴포넌트와 서버 컴포넌트로 구분해줘야 한다.
또 다른 렌더링 전략으로는 SSG가 있다. 일부 또는 전체 페이지를 빌드 시점에 미리 렌더링함으로 정적 페이지 형태로 만들어 제공하는 것에 탁월하다. SSG는 SSR 및 CSR과 비교했을 때 다음과 같은 이점이 있다.
1) 정적 페이지는 단순 HTML 파일이므로 CDN을 통해 파일을 제공하거나 캐시에 저장하기 쉬워 별도의 연산없이 정적 자원 형태로 제공되므로 서버에 부하를 거의 주지 않아 확장이 쉽다.
2) 그로인해, 각 요청별로 발생할 수 있는 지연 시간을 최소화할 수 있다.
3) 하지만, 정적으로 생성한 페이지는 빌드 시점에 미리 렌더링되어 정적 자원처럼 제공되기 때문에 작은 수정에도 필요한 데이터를 가져오고 정적 페이지를 다시 생성해야 하는 과정을 수반한다는 불편함이 있다.
이런 불편함을 해결할 수 있는 렌더링 전략이 바로 ISR이다.
'프론트엔드 > Next.JS' 카테고리의 다른 글
Next.js의 정해진 함수(SSG, SSR) (0) | 2024.05.31 |
---|---|
Next.js 개발모드, 빌드, 실행 그리고 배포 (0) | 2024.05.31 |
page router의 구조 (0) | 2024.05.31 |
Next.js 프로젝트 만들기 (0) | 2024.05.25 |
Next.JS 타입 (0) | 2024.05.24 |
댓글