CSR vs SSR vs SSG vs ISG

리액트에서 Next.js로 옮겨가면서 가장 많이 햇갈렸던 것이 랜더링 방식의 차이였다. 물론 이름을 곧이곧대로 받아들여서 대강의 차이 정도는 알고 있었지만, 어느 시점에 뭐가 어떻게 돌아가는 건지 정확히 알고 있다고는 말할 수 없었다. 따라서 이를 ─ 마침 심한 몸살 감기로 인해 조금 붕 뜨는 시간을 통해 ─ 간단하게라도 정리해보려 한다

 

CSR (Client-side Rendering)

순수 리액트는 SPA이고 CSR을 이용한다. 이는 사용자가 페이지를 요청하면 서버는 거의 비어있는 HTML을 보내주고, JS 파일을 통해 DOM에 각종 노드를 추가하는 방식으로 렌더링이 이루어진다는 의미이다. 클라이언트 쪽에서 자바스크립트를 사용한 HTML 연산 작업이 진행되기 때문에 서버 부하가 적게 발생한다. Full page load(새로고침) 없이 라우팅이 가능하다.

구글과 같은 검색 엔진은 '크롤러'라는 봇을 사용해 웹 사이트를 긁는데, CSR은 JS를 실행해서 동적으로 콘텐츠를 생성해야 데이터를 수집할 수 있기 때문에 SEO 측면에서 불리하다. 또한, SPA의 경우 처음에 페이지 접근할 때 서버로부터 전체 페이지에 대한 JS 번들파일과 CSS 파일을 받아야 하므로 실제 유저가 사용하기까지의 시간이 오래 걸린다.

 

SSR (Server-side Rendering)

사용자가 페이지를 요청하면 서버에서 리퀘스트에 맞는 HTML을 즉시즉시 만들어서 리스폰스로 보내주는 방식이다. CSR과 장점과 단점이 각각 반대라고 보여진다. 서버에서 어느정도 만들어서 보내다보니 유저가 사용하기까지 걸리는 시간이 CSR에 비해 빠르고, Hyderation 되기 전에도 유저에게 무언가 보여지기는 한다. 이미 구조상 완성된 HTML을 보내기 때문에 SEO 측면에서도 유리하다. 하지만 짧은 시간에 많은 요청을 받을 경우 HTML을 만드는 연산 작업이 서버에 많은 부하를 줄 수 있다. 또한 라우팅할 때마다 새로고침이 발생하여 잠깐이지만 빈 화면이 보이게 된다.

 

SSG (Static Site Generation)

사용자의 요청과 별개로 미리 HTML 파일을 만들어서 서버에 배포해두고, 리퀘스트가 들어오면 미리 만들어둔 HTML 파일을 리스폰스로 보내준다. 때문에 랜더링 속도가 앞의 두 방식과 비교해 더 빠르다. 또한 SSR처럼 완성된 페이지를 보내주기 때문에 SEO 측면에서도 유리하다.

이렇게만 이야기하면 가장 좋은 방식 같지만 여기에도 단점은 있다. 모든 URL에 대해 개별 HTML 파일을 생성해주어야 하는데, url을 미리 예측할 수 없거나 양이 너무 많을 경우에는 적용하기 쉽지 않다. 또한 페이지 내의 데이터가 수시로 바뀌는 경우에도 적용해주기가 쉽지 않다.

 

ISG (Incremental Static Generation)

증분 정적 생성 방식은 Next.js에서 제공하는 기능으로, 정적 사이트 생성(SSG) 방식을 확장한 형태이다. SSG와 달리 ISG는 빌드 시에 모든 페이지를 미리 생성하지 않고, 필요할 때마다 페이지를 업데이트하여 효율적으로 정적 콘텐츠를 제공한다. getStaticProps가 리턴하는 객체에 revalidate 프로퍼티를 통해 데이터 갱신 주기를 추가하면, build 이후에도 설정한 주기마다 데이터 갱신 여부를 확인하고 업데이트 된 데이터로 페이지를 다시 정적 생성한다.