CSR과 SSR의 설명 및 장단점

우리는 브라우저에서 웹 페이지를 볼 수 있습니다. 이 웹 페이지를 사용자에게 보여 줄 때, 즉 웹 페이지를 랜더링 하는 방식에는 여러가지가 있는데요. 그 중 가장 많이 거론되는 CSR과 SSR 관한 포스팅입니다.

CSR

• FCP: First Contentful Paint - 요청 콘텐츠(기사 본문 등)가 표시되는 시점
• TTI: Time To Interactive - 페이지가 상호작용 가능하게 될 때까지의 시간 (이벤트 발생 등).

CSR(Client Side Rendering)은 JavaScript를 사용하여 브라우저에서 페이지를 직접 렌더링하는 것을 의미합니다. 맨 처음 서버로 HTML를 응답 받습니다. 그 다음 HTML에 링크 된 js 파일들을 다운로드 받게 되는데요. 예시로 위 이미지를 보시면 bundle.js를 요청하면서 받아오게 오면서 중간에 FCP단계가 되는 것을 확인 할 수 있습니다. 이제 받아온 js에서 render와 같은 로직 함수들이 실행하게 되고 이와 같은 모든 단계가 끝나게 되면 TTI에 도달하게 되고 사용자는 웹 페이지를 확인 할 수 있으며 상호작용이 가능하게 됩니다.

장점

• 트래픽 감소와 빠른 인터랙션이 있다. SSR과는 다르게 웹 페이지 전체를 받는 방식이 아닌 일부 DOM만 컨트롤하는 방식을 채택 할 수 있다. 필요한 부분만 서버에 요청하고 받아와서 랜더링이 가능하기 때문이다.

단점

• 응용 프로그램이 커짐에 따라 필요한 JavaScript의 양이 증가하게 되면 서버로 부터 응답받는데 시간이 증가한다.
• SEO(검색 엔진 최적화)이 힘들다. 검색 엔진이 맨 처음 랜더링 되지 않은 텅 빈 HTML를 분석하는데 있어 어려움이 있다.

SSR

SSR은 웹 페이지를 서버에서 만들고 브라우저에서 받아서 바로 랜더링하는 방식인데요. 서버는 필요한 데이터를 모두 가져와서 HTML를 만들게되고 이렇게 잘 만들어진 HTML과 이를 동적으로 제어 할 수 있는 js파일을을 브라우저로 전송합니다. 브라우저는 이를 받아 HTML를 랜더링하게 됩니다.

장점

• 첫 번째 페이지로딩이 빠릅니다. CSR를 HTML를 받고 링크된 JS를 서버로 요청하고 응답 받고 또 실행까지 해야되는 경우가 있어 서버와 요청 왕복이 발생합니다. 하지만 SSR은 랜더링을 위한 잘 만들어진 HTML를 받고 바로 랜더링하기 때문입니다.
• 잘 만들어진 HTML를 받기 때문에 SEO에 유리하다.

단점

• Blinking issue → 웹 페이지를 그대로 받기 때문에 웹 페이지를 이동 할 때마다 깜박이는 좋지 않은 UX가 제공 될 수 있다.
• 서버에서 HTML를 만들어 가져오므로 서버에 과부화가 발생한다.

Refs

https://developers.google.com/web/updates/2019/02/rendering-on-the-web?hl=ko#server-rendering