CSR & SSR

강종연·2021년 6월 8일
0

FrontEnd

목록 보기
5/6
post-thumbnail

우리가 웹을 개발하고 서버에 올린 후 누군가가 이 사이트를 연다면 렌더링은 누가 담당하는지 생각해보았나. 대부분은 당연히 서버에서 받아오지라고 생각하겠지만 꼭 그렇지만은 않다.

오늘은 렌더링의 방식들을 알아보고 비교를 해보고자 한다.

Rendering?

우선 그러기 위해선 렌더링에 대해서 알아야 할 것이다. 렌더링이란 html문서를 웹 브라우저에 올리는 것을 의미한다. 결국에는 렌더링의 과정은 html문서를 처리하는 것으로 될 것이다.

그러면 브라우저에 렌더링을 하기 위한 2가지 방법을 알아보도록 하자.

CSR(Client Side Rendering)


클라이언트 사이드 렌더링이란 브라우저에서 애플리케이션을 렌더링하고 이후에 필요한 부분들이 있으면 그 부분만 클라이언트 내에서 처리한다. 우리가 사용하는 리액트, 즉 SPA방식이 이 클라이언트 사이드 렌더링을 이용하는 것이다. (하나의 메인파일만 불러오고 나머지는 사용자의 동작에 의한 필요에 따라서...)

장점으로는 전체 리로딩 할 필요 없이 필요한 부분만 받아오므로 전체 페이지를 렌더링 하는 것보다 빠른 상호작용을 기대할 수 있다.

하지만 단점으로는 자바스크립트 코드를 읽고 화면에 모두 완성이 되어야 사용자에게 보여지기에 처음의 렌더링 속도가 느리다.

SSR(Server Side Rendering)


서버 사이드 렌더링이란 사용자가 웹 페이지에 접근할 때, 서버에 페이지에 대한 요청을 한 후 모든 파일들(html, js...)을 다 다운받아 렌더링하는 방식이다. 듣기만 해도 느릴 것 같다..

실제로 단점으로도 페이지의 이동마다 전체 리로딩이 되어 효율적이지 못하고 (이 부분에서 CSR보다 느림.) 화면이 CSR보다는 빨리 켜지나 아직 js파일이 다운로드 되지 않아 모두 다운로드 되기 전까지 클릭 등 특정 동작을 수행하지 못 할수도 있다는 것이 있다.

그럼에도 SSR은 왜 써?

가장 중요한 이유는 검색엔진최적화의 적용에 유리하다.

CSR같은 경우에는 Google bot 등에 검색 노출이 되지 않는다.
하지만 SSR같은 경우에는 모든 검색 노출이 가능하므로 SEO같은 전략에 되게 유리하다.

그리고 페이지의 모든 파일을 다운로드 하긴 하나 페이지가 다 다운로드 되기 전부터 사용자에게 보여지므로 모두 완성되어야 보여지는 CSR보다 초기구동속도는 빠르다.(그 이후에는 CSR이 빠르지)

글을 마무리하며

오늘은 렌더링 방식 2가지를 알아보았다.

대표적인 CSR의 예시로는 React로 SPA를 목적으로 하는 리액트와 너무 잘 맞다.

SSR의 대표적인 프레임워크는 Next.js, Gatsby.js ... 로 CSR(ex. 리액트...)를 사용했을 때의 단점을 보완할 수 있다. (webpack과 내부 설정들을 이용해서 react에서도 SSR의 개발이 가능하나 복잡하고 힘들다.)

내가 최근에 진행했던 한 프로젝트에서 트러블 슈팅의 방법으로 Gatsby.js를 도입했었다. 조만간 Gatsby.js에 대해서 간략하게 소개를 해볼 예정이다.

(그림 출처 : https://medium.com/walmartglobaltech/the-benefits-of-server-side-rendering-over-client-side-rendering-5d07ff2cefe8)

profile
TypeScript, Next.js를 좋아하는 프론트엔드 개발자입니다:)

0개의 댓글