SSR vs CSR 그리고 SPA

서버 사이드 렌더링과 클라이언트 사이드 렌더링에 대해서 알아보자

SSR(서버 사이드 렌더링)은 페이지에 변화가 있을때 마다 새롭게 전체 페이지를 다시 로드해야한다. ajax가 나온 이후에 바뀐 부분만 특정해서 변화가 가능했지만 그것 또한 손이 많이 갔고, 서버에서 HTML,CSS,JS 파일을 렌더링 한다는 것은 서버에 부담을 준다는 소리이다. 반면 CSR(클라이언트 사이드 렌더링)의 경우 클라이언트에서 렌더링을 하기 때문에 서버에 부담을 덜어줄 수 있다. 그리고 서버에서 렌더링된 HTML파일을 받아오는게 아니기 때문에 CSR의 경우 바뀐 부분만 서버로 부터 받아서 렌더링 하면 되기 때문에 더 효율적이다.

SSR은 CSR과 비교했을때 SEO(검색 엔진 최적화)가 가능하고 첫 로딩 속도가 빠르고 페이지 캐싱도 가능하다 정도가 있고 단점의 경우 페이지를 요청할때 마다 서버쪽에서 렌더링 해야 한다는 부담, 페이지 깜박이는 문제, 다른 플랫폼과 서버를 공유할 수 없는 비효율적 문제점등이 있다.

SPA(Single Page Application)

SPA의 대표적으로 리액트, 앵귤러, 뷰 가 있는데 업계 순위는 앵귤러가 치고 나가다가 요즘은 리액트가 선두를 달리고 그 뒤로 뷰가 따라오고 있는 추세다. SPA가 이렇게 수요가 폭발적으로 늘어난건 그만한 이유가 있다. SPA의 경우 자바스크립트 기반으로 모든 컴포넌트를 렌더링 한다. 이게 무슨 소리냐 실제로 보고 있는건 하나의 빈 페이지 인데 자바스크립트가 V-DOM(Virtual DOM)을 렌더링 하면서 유저에게 여러가지 페이지를 보여준다. SPA의 경우 기본적으로 CSR이다. 그 이유는 위에 설명했듯 SSR의 경우 서버에서 HTML파일을 받아서 렌더링 하는데 CSR의 경우 클라이언트에서 자바스크립트 코드를 받아서 동작을 하기 때문이다.

그럼 SPA는 CSR을 기본으로 하고있는데 SEO랑 첫 로딩속도도 느리고 페이지 캐싱문제도 있는데 이걸 감안하고 쓸 수 있는가?

SEO의 경우 서비스 입장에선 매우 중요한 문제이다. CSR의 경우에 SEO를 적용해놔도 크롤링하는 로봇이 잘 모른다. 구글은 Js파일을 기다려서 렌더링 다 한다음 읽을 수 있다고 하지만 아직 이게 완벽하지 않은거 같다. (잘 될 수도 있지만 안될 수도 있다.)

이 문제를 보안하기 위해서 Prerender.io 를 추천한다. Prerender는 리액트 코드를 문자열 형태로 변환하는게 아니라 자바스크립트 렌더링 엔진을 가지고 있어서, 자바스크립트 코드를 실행시켜 뷰를 렌더링한 결과값을 반환해준다. (렌더링 속도는 빠르지 않고 오직 검색엔진 최적화를 위해서만 사용된다. 크롤러 봇일 경우에만 대신 렌더링을 해줘서 반환해주는 것)

페이지 캐싱은 SPA의 경우 JS가 돌아서 렌더링을 해야지 페이지가 나오기때문에 서버에서 페이지가 올때는 빈 페이지기 때문에 캐싱이 잘 안된다. 여기서 캐싱이 잘 된다면 장점의 경우 데이터 비용을 아낄 수 있는 등 여러 장점이 존재한다.

Isomorphic App

CSR과 SSR의 장점을 다 모아놨다! 예를 들어 Next.js가 있다. Next를 사용하면 SSR으로 React 할 수 있다.

Next.js에는 Static Site Generator 기능이 있는데 이 기능을 사용하면 첫 요청을 하면 SSR로 요청을하고 그 다음 Link를 할 경우 CSR을 하게 된다. SSG의 경우 위에 제시했던 문제들(SEO, 첫로딩, 캐싱)을 SSG로 해결을 하고 있다.