기존에 리액트에서는 CSR 방식을 이용해서 렌더링을 하였다면 요새는 SSR 기반의 Next.js가 유행을 하는 것 같은데 SSR이 뭔지, 왜 SSR 기반의 프레임워크인 Next.js가 유행하고 있는지에 대해 더 자세하게 알아보자.
Client Side Rendering
특징
대표적인 CSR를 사용하는 리액트를 예시로 들어본다면, React는 페이지에 필요한 "최소한"의 HTML 페이지와 JS를 다운로드 하고 JS에서 DOM을 업데이트하고 페이지를 렌더링하는 방식을 활용한다.
React를 기준으로 보면 <div id="root">라는 element에다가 모든 것을 JS를 이용해 렌더링 시키는 방식이기 때문에 JS를 모두 렌더링할 필요가 있고, 그 전까지는 아무것도 보이지 않는 상태가 되어 버린다.
장점
- 초반에 모든 리소스를 다운로드 한 이후로 부터는 페이지 이동 속도 및 렌더링 속도가 매우 빨라진다.
- 즉 초반에만 조금 기다린 이후 부터는 거의 기다림 없이 새로운 페이지 렌더링이 된다고 볼 수 있다.
- 서버 자원이 필요하지 않다.
- 서버 구축 비용이 줄어들고, 운영 비용이 줄어든다.
- 클라이언트에서 UI를 구축하기 위한 계산 비용을 모두 클라이언트에서 지불한다. (서버 부담도 없다)
단점
- SEO에 불리하다.
- React 기준으로는 하나의 div가 나와있는 사이트처럼 노출되기 때문에 SEO에서 정상적으로 인지하기 힘들다. (Google 엔진의 경우 JS도 분석하기에 렌더된 HTML을 보긴 하지만 그래도 불리하긴 하다)
- 초기 렌더링 비용이 크다.
- SEO 에서 중요한 초반 렌더링(Time To First Byte) 즉 TTFB 속도가 느리기 때문에 SEO에서 불리하다.
- 거대한 JS 번들
- 모든 HTML을 구축하는 JS들이 전부 들어가기에 필요한 JS만이 아닌 모든 리소스를 가져와야 하기에 JS 번들 사이즈가 크고 그것을 불러오는데 시간이 걸린다.
Server Side Rendering
특징
SSR은 Dynamic Rendering, 즉 동적 렌더링이라고도 부르는데 페이지에서 요청 마다 페이지 HTML을 서버에서 렌더링하고 클라이언트에게 전달해주는 방식이다.
Next.js 기준으로 SSR에는 여러 종류가 있어 더 알아보자.
SSR
특징
가장 기본적인 SSR의 형식으로 서버 측에서 먼저 (Next.js 기준) getServerSideProps로 우선 HTML 렌더링에 필요한 JS 역할을 수행한다. (보통 API 호출)
즉 CSR과는 다르게 처음부터 HTML 페이지를 로드해줄 수 있다는 것이 큰 특징이다.
장점
- SEO에 유리하다.
- CSR과는 다르게 처음부터 HTML을 렌더해주기 때문에 SEO에서 해당 페이지에 대해 읽기 더 유리해진다.
- 빠른 초기 렌더링
- SEO에 유리해지는 이유 중 하나로, 필요한 JS 번들 파일과 HTML을 그려서 렌더해주면 되기 때문에 번들 사이즈가 작고, 빠르게 렌더가 가능하다
단점
- 과도한 서버 리소스가 필요해진다.
- 어찌됬든 SSR은 즉 서버를 필요로 한다.
- 요청이 많아지면 과부하가 심해질 수 있어, 서버 스케일링이 필요해진다.
- 유지보수 비용이 높아진다.
- CSR과는 다르게 서버와 클라이언트를 둘다 이해하고 작업해야하기 때문에 둘다 어느정도 이해할 수 있는 개발자가 필요해진다.
- 그리고 서버와 클라이언트를 둘다 관리해야하기 때문에 관련된 유지보수 비용이 증가하게 된다.
- hydration 간극이 발생하곤 한다.
- SSR에서는 처음에 HTML을 렌더시키고 그 이후 JS 파일을 통해 추가로 렌더가 될 수 있어 간혹 UI 틀어짐이 발생하곤 한다.
- hydration(JS 렌더 동기화)가 발생하게 되면 간혹 에러를 일으켜 유저 입장에서는 장애로 판단되기도 한다.
SSG
특징
어떻게 보면 SSR의 단점을 보완하기 위해 나오기 시작한 렌더 방식 중 하나로 Static Site Generation 즉 빌드 시점에서 HTML을 만드는 렌더 방식이다.
장점
- 서버가 필요하지 않다.
- SSR의 장점에 추가로 빌드 시점에서 이미 HTML을 렌더하기 때문에 서버 측에서 계산을 할 필요가 없다.
- 빠른 속도
- 이미 빌드된 HTML 파일이기 때문에 어디서도 렌더를 별도로 할 필요가 없다.
단점
- 이미 렌더링 됨
- 빌드 시점에서 렌더링을 한다라는 것은 즉 수정을 하기 위해선 다시 빌드를 해야한다라는 것이다.
- 서버 데이터 동기화 이슈
- SSG를 이용해 사전에 데이터 API를 기반으로 빌드했지만 데이터 갱신을 위해서도 다시 빌드해야 한다.
- 위 2가지 이유로 인해 SSG는 주로 마켓팅 페이지, 규약 페이지 같은 변하지 않는 페이지에 사용한다.
ISR
특징
위 SSG의 단점을 또 보완해서 나온 방식으로 Incremental Static Regeneration, 증분형 정적 재생성 방식이라고도 한다.
SSG처럼 빌드 시점에서 HTML을 생성하는 방식까지는 동일하나, cache-time을 줌으로써 cache-time 만큼 시간이 지나게 되면 해당 페이지를 다시 빌드해두는 기능이다.
장점
- 속도가 빠르다.
- cache time을 기반으로 미리 빌드해두고 필요한 페이지들을 미리 렌더해 속도가 매우 빠르다.
- 추가 빌드가 필요하지 않다.
- SSG랑 다르게 cache-time이 지나면 서버에서 재 빌드하는 작업(ISR 페이지만) 을 거치기에 SSG의 단점인 데이터 갱신 시 재빌드가 필요하다를 완벽하게 해소했다.
- 외부 API를 이용해도 재갱신이 가능해 어드민 업데이트를 통해 재갱신 하는 것 또한 가능하다.
- ISR 빌드 실패에 대한 처리
- ISR 재빌드에 실패해도 이전 캐싱된 (빌드된) 파일을 보여주기 때문에 API 에러 등으로 빌드에 실패되도 장애 발생으로 이어지지 않는다.
- 동적 path 지원
- 단순히 한 페이지 뿐만 아니라 특정 page 들에 대해 동적으로 할당하는 것이 가능하고, 만약 빌드되지 않은 페이지여도 대응이 가능하다. (fallback 처리 기능)
단점
- 어찌되었든 실시간성 데이터를 지원하지는 못한다. (이 경우는 CSR로 대응해야함)
