CSR (Client Side Rendering)

CSR

클라이언트 사이드(브라우저)가 App을 렌더링 하는 것

• Rendering 이란

  요청받은 내용을 화면에 표시하는 것

클라이언트 사이드(브라우저)가 App 을 렌더링 하는 것

SPA 또한 CSR

• 동작 과정 : HTML 다운로드 -> JS 다운로드 -> JS 실행 -> 서버로부터 데이터 받기 -> Contents 풀 로드

• 장점

  사용자의 행동에 따라 필요한 부분만 다시 데이터를 받기 때문에 SSR 보다 조금 더 빠른 인터렉션 가능

  page 전체를 요청하지 않고 페이지에 필요한 부분만 렌더링하기 때문에 모바일 환경에서도 빠른 속도로 렌더링 가능

  lazy loading 지원 (lazy loading 이란 페이지 로딩 시 중요하지 않은 리소스의 로딩을 늦추는 기술)

  SSR 이 따로 필요하지 않기 때문에 일관성 있는 코드 작성 가능

• 단점

  검색 엔진에 노출되지 않음 (HTML 만 읽어들이고 JS는 작동하지 않기 때문)

  페이지를 읽고 JS 가 렌더링을 마쳐야 콘텐츠가 완전히 보여지기 때문에 JS 에 영향을 받음

• 해결책

  코드 스플리팅

  SSR 과 혼합

• SPA 프레임워크, 라이브러리 의 등장 전

  클라이언트 단에서는 새로운 페이지를 요청하고 서버에서는 템플릿을 이용하여 렌더링하고 완성된 페이지 형태로 응답하는 SSR(MPA multiple page application) 방식이 많았음

  SPA 는 구현은 가능했지만 표준화되지 않았고 생태계 또한 미비했기 때문에 사용량이 적었음

  • 문제점

    페이지 이동 시 화면을 로드해야 하기 떄문에 깜빡임

    페이지 이동시 마다 서버에 페이지를 요청하므로 불필요한 요청이 많음

    서버가 렌더링까지 하므로 부하가 걸림

    모바일 앱 개발시 추가적인 작업 필요

• SPA 프레임워크, 라이브러리 의 등장

  SPA 프레임워크, 라이브러리의 등장으로 CSR 이 웹 렌더링의 패러다임이 됨

  UX 향상, 서버 부하 덜어내기 등을 가능하게 해줌

  하지만 SPA 는 JS 로 컴포넌트들을 로드하기 때문에 초기 렌더링이 느림

  다시끔 SSR 이 등장하며 처음의 렌더링을 SSR 로 진행하고 JS 를 다운 받는 형태인 CSR, SSR 혼합 방식을 택해서 UX 개선, 빈 화면 시간 감소 등을 진행함

다음 글(SSR)에서 이어짐