이번에는 듣기는 자주 들었지만 그 실체는 제대로 알지 못했던 CSR/SSR 렌더링 방식에 대해 알아볼 것이다. 렌더링 방식은 프론트엔드 개발자라면 필수적으로 알아야 하는 것으로, 자신이 구현한 코드가 어떤 방식으로 웹 브라우저가 읽어와서 사용자들이 접근할 수 있는 형태로 뿌려주는지에 대한 것이다.
CSR(Client Side Rendering) vs SSR(Server Side Rendering)
먼저 렌더링(Rendering)이라는 용어의 정의부터 짚고 넘어가보자. 렌더링은 웹 브라우저가 코드를 읽어와서 사용할 수 있는 형태로 화면에 뿌려주는 작업을 의미한다. 이 작업은 브라우저에 내포된 렌더링 엔진이 수행하게 된다. 파싱, 변환, dom트리 구축, 렌더트리 구축 등등 여러 과정을 거쳐 화면이 완성되는데, 이에 대해서는 자세히 설명한 글이 있으니 따로 설명하지 않겠다.
그러면 렌더링 방식이란 화면에 HTML을 누가 주축이 되어 배치하느냐 로 갈리게 된다. 만약 클라이언트(브라우저)측에서 수행하면 CSR(Client Side Rendering)이 되는 것이고, 서버측에서 수행한다면 SSR(Server Side Rendering)이 된다.
이해를 위해 모던 프레임워크인 리액트를 예로 들어 설명하도록 하겠다. 만약 다음과 같이 index.html이 웹서버에 존재한다고 해보자.
// index.html
<html>
<head>
<title>Title</title>
</head>
<body>
<div id="app"></div>
</body>
</html>위와 같은 코드를 뼈대라고 부르겠다. 웹 브라우저는 실제로 이 뼈대 하나만 다운받게 된다. 그리고 <div id="app"></div>를 통해 자바스크립트 파일들이 실행되고, dom이나 스타일등이 적용되게 되는 것이다.
다음은 최종적으로 유저가 보는 화면의 index.html이다.
<html>
<head>
<title>Title</title>
</head>
<body>
<h1>Hello World!</h1>
<p styled="font-size: 12px;">이것이 최종적으로 화면에서 보고 있는 내용입니다.</p>
</body>
</html>쉽게 설명하자면. 뼈대만 받고 브라우저(Client)에서 DOM을 그린다면 CSR이고, 위처럼 이미 다 그려진 DOM을 받는다면 SSR이다.
CSR
CSR은 많이 들어본 만큼 우리 주변에 가깝게 위치하고 있다. 리액트든, 뷰든, 빌드를 기본 세팅에서 바꾸지 않고 빌드를 수행하게 된다면 CSR로 코드가 나오게 된다. 그리고 이 코드를 웹서버에 올리는 작업이 바로 배포이다. 브라우저는 웹서버에 올라간 파일을 다운받아서 실행하게 되고, index.html에서 js파일을 실행하게 되며 dom을 그리게 되는 방식이다.
웹 사이트에 접속했을때, 가장 처음에는 모든 js파일을 다운받아줘야 하기 때문에 시간이 좀 걸린다. 하지만 모든 파일을 다운받고 난 후에는, 서버에 의존하지 않고 브라우저에 다운받은 파일만 가지고 dom을 그려줄 수 있게 된다. 서버와의 딜레이가 존재하지 않기 때문에(api request를 제외하고) 빠른 화면전환이나 부드러운 페이징, 인터렉션등을 구현하는 것이 가능하다.
하지만 가장 초기에는 index.html만 떡하니 있기 때문에 검색 엔진이 크롤링하기 어렵고, SEO측면에서 SSR보다 밀린다는 단점이 존재한다. 이 단점에 대해서는 글의 후반부에서 소개하도록 하겠다.
SSR
SSR이 CSR과 다른점은 단 하나이다. 브라우저에서 js파일을 실행시켜 dom을 그리는 것이 아니라, 서버에서 모든 로직을 수행하고 완성된 HTML을 브라우저로 전달하는 점에서 다르다.
비유를 들자면 어른(server)이 퍼즐판이랑 퍼즐을 아이(browser)한테 줘서 직접 만들게 하는게 CSR이고, 어른(server)이 이미 모든 퍼즐을 맞춘 퍼즐판을 아이(browser)한테 주는 것이 SSR이다.
이처럼 이미 dom이 모두 구성된 파일을 브라우저가 받기 때문에 dom을 그려야할 필요가 없다. 따라서 초기 구동속도가 빠르고, 이미 완성된 파일이기 때문에 검색 엔진들이 크롤링할때에 정확한 정보를 받아가게 되서 SEO에 더 유리하다.
CSR, SSR에 대한 사실들
- CSR보다 SSR이 더 빠르다?
- 동적인 컨텐츠가 더 많다면 CSR이 더 유리하다. 왜냐하면 동적 컴포넌트를 렌더링하는데 서버보다 브라우저가 더 특화되어 있기 때문이다. 가게에서 부대찌개를 요리해서 배달로 보내는 것과, 부대찌개 밀키트를 사서 요리하는 것의 차이라고 할 수 있겠다.
- 이와 반대로 정적인 컨텐츠가 더 많다면 서버에서 연산을 해서 보내주는 SSR이 속도면에서 더 유리하다고 할 수 있겠다.
- CSR은 SEO에 취약하다?
- 많은 사람들이 CSR은 SEO가 잘 안된다고 알고 있지만, 그 이유에 대해서는 정확히 알고있지 못하다. 한국에서 가장 많이 사용되는 포털 사이트는 네이버와 구글이다. 구글의 Google Bot 크롤러의 경우 자바스크립트를 지원하기 때문에 CSR로 웹사이트를 구현한다고 해서 검색시에 노출이 되지 않을지 걱정할 필요가 없다.
- 하지만 한국에서는 구글보다 네이버를 쓰는 사람이 더 많기 때문에 네이버의 크롤러 봇을 무시할 수 없겠다. 네이버의 봇 또한 CSR을 지원하지만, SSR을 색적하여 페이지 우선순위를 매기는것보다 더 많은 컴퓨팅 비용이 필요하기 때문에 SSR을 사용하는 것을 '권장'하고있다.
- 이 말은 CSR를 쓴다고 해서 노출이 안된다는 뜻이 아니다. 만약 CSR를 사용할 경우 주요 정보의 경우 SSR을 사용하라고 알려주고 있기도 하고 말이다. 그대로 CSR을 사용하겠다면 검색상의 디스어드밴티지는 감안해야 할 것이다.
SPA(Single Page Appliaction) vs MPA(Multi Page Application)
용어의 설명 그대로 해석하면 된다. SPA는 말 그대로 하나의 페이지로 구성된 웹이고, MPA는 여러개의 페이지로 구성된 웹이다.
MPA는 페이지 별로 해당 페이지에 필요한 HTML, CSS, JS을 다운받아 매번 페이지를 새롭게 생성한다.
SPA는 일종의 트릭을 사용한다. HTML, CSS, JS파일을 매번 새로 다운받는게 아니라, 필요한 모든 파일을 다운받고 dom만 수정하는 방식이다. dom이 수정되고 나면 브라우저의 url을 강제로 변경하여 실제로 방문한적도 없는 url로 이동시킨다.
MPA와 SPA에는 이런 근본적인 차이점이 존재한다. 만약 MPA를 사용할 경우, 해당 url로 이동하면서 필요한 모든 파일(HTML, CSS, JS)을 다운받아야 하기 때문에 FOUC(Flash Of Unstyled Content)현상이 발생한다.
그래서 뭘 사용해야 하는 거냐?
사실 SPA, MPA를 선택한다기 보다 사용하는 프레임워크에 종속된다는 표현이 더 정확하다. 최신 프론트엔드 프레임워크인 React, Vue는 기본적으로 SPA를 지원하며 CSR을 사용하고 있다. nextjs와 같은 프레임워크는 특정 페이지를 SSR로 사용하는 기능도 제공하고 있다.
최신 방식이 SPA&CSR이고 과거의 방식이 MPA&SSR이기 때문에 둘이 묶여서 사용되는것처럼 말하는 것이다. 실제로는 SPA&SSR, MPA&CSR과 같은 조합으로도 사용하는것 또한 가능하다. 하지만 최신 프레임워크는 빌드를 했을때 기본적으로 HTML, CSS, JS가 한개씩 나오기 때문에 SPA가 기본값으로 잡혀 있는 것이다.
사실 아키텍쳐적인 부분은 뒤로하고 프론트엔드에서 가장 크게 느껴지는 차이점은 MPA는 페이지 이동시 화면이 깜빡거리고, SPA는 그렇지 않다는 것이다. 이 한번의 깜빡임이 사용자에게는 큰 경험 변화를 불러올 수 있게 된다. 최근에는 모바일 웹이 대중화 되면서 깜빡거리는 화면이 더 큰 프론트엔드 이슈로 대두되었고, SEO적 측면에서 이상적이지 않음에도 불구하고 SPA방식이 표준으로 자리잡은것으로 생각된다.
레퍼런스
SPA vs MPA와 SSR vs CSR 장단점 뜻정리 - 하나몬
SPA 그리고 SSR과 CSR
CSR/SSR, SPA/MPA, PWA | 위펄슨 기술 블로그
왜 CSR(Client Side Rendering)에서 SEO가 단점일까?
