개념

Client Side Rendering과 Server Side Rendering의 약자.

CSR은 데이터를 받아 브라우저에서 랜더링하고, SSR은 서버에서 모든 HTML파일을 랜더링해서 가져옴.

SCSR의 탄생과정을 보자. 유저가 url을 입력하면 서버로 요청이감. 서버는 페이지를 만들어서 응답을 보냄. 유저는 페이지를 볼 수 있음. 유저가 보는 페이지는 브라우저가 렌더링한 것이고, 실제 서버로부터 받은 데이터는 HTML형식임. 서버는 유저에게 렌더링이 다된 HTML을 준 것임. 이것이 SSR, Server Side Rendering.

JQuery와 JQueryTable은 JSON을 데이터로 받아 렌더링을 해줌. 서버에서 HTML이 아닌 JSON을 보내주면 클라이언트에서 데이터를 받아 렌더링함. CSR, Client Side Rendering의 시초라고 볼 수 있음.

JQuery처럼 요소들만 렌더링하지 않고 웹페이지 전체를 렌더링하려는 아이디어에서 나온 것이 SPA(Single Page Application).

흔히 볼 수 있는 SPA의 HTML파일의 구조. head의 내용은 일반적이지만, body는 내용이 적고, JS로딩하는 부분과 #root로 나뉨. #root를 포인팅해서 이를 기반으로 모든 컴포넌트를 JS로 렌더링함. 보고있는 페이지는 아무것도 없는 하나의 빈 페이지이지만, JS가 Virtual DOM을 랜더링해서 여러가지 페이지를 navigate하고있는 착시를 줌. JS가 렌더링하는 것은 당연히 Client Side에서 일어남. Server Side에서 받아온 것은 JS코드들 뿐임.

장점

CSR을 사용하게 되면서 SSR보다 빠르고 효율적인 부분이 생김. 이를테면, 다음페이지 버튼을 눌렀을때 추가적인 버튼을 띄우는 화면의 경우, SSR은 모든 페이지를 새로 렌더링해야해서 파란버튼들을 중복 렌더링하게됨. CSR은 초록버튼들만 추가적으로 API요청을 보내 렌더링 할 수 있음.

단점

하지만 CSR은 첫 로딩이 느린 단점이 있음. SSR은 요청한 페이지만 불러오면 되지만, CSR은 Clinet Side에서 모든 페이지를 다 렌더링하기 때문에 다른 페이지에 대한 정보를 담고있는 JS코드를 다 불러와야 함.

또다른 단점으로 페이지 캐싱이 잘 안된다는 단점이 있음. 이는 속도와도 관련이 있음. 일반적으로 캐싱을 할 때 Cloud flare, Cloud front 등과 같은 캐싱시스템을 사용하는데, 이들의 장점은 첫 바이트가 빠르게 온다는 점. 엣지 네트워크가 다 설정이 되어있기 때문에 그럼. 첫 바이트가 왔을 때 SSR의 경우 첫 바이트부터 다음 렌더링까지 걸리는 시간이 거의 없음. 하지만 CSR은 화면을 client에서 렌더링하기 때문에 캐싱을 할 수 있는 방법(기억할 방법)이 없음. JS가 돌기 전까지는 blank페이지이기 때문. 캐싱이 잘되면 데이터 비용 절감 가능성이 생기고, 데이터 센터의 집중화가 가능함.

SEO 최적화가 잘 되지않는 단점도 있음. SEO는 Search Engine Optimization의 약자로 검색엔진 최적화임. 웹사이트를 제작하면 그것이 검색엔진에서 잘 노출이 되어야 함. 검색엔진의 크롤링로봇이 웹사이트를 분석해 키워드에 적합한 내용인지를 판단함. 그런데 CSR은 처음 페이지가 빈 페이지라 로봇의 성능에 따라 크롤링이 잘 이루어지지 않을 가능성이 있음.

이를 극복하기 위해 CSR와 SSR의 장점만 모은 Isomorphic App이 등장하게됨. Next.js가 이에 속하는데, CSR을 React로 하면서 서버에서 HTML코드를 초기에 보내주는 형태로 코드 작성 가능.(SSG, Static Site Generation) 이로써 CSR의 단점(캐싱, SEO, 첫로딩)을 개선하고, 첫 렌더링 후에는 CSR로 동작해 동작속도를 빠르게 유지할 수 있음.