[Browser] SSR, CSR 그리고 SPA

SSR (Server-Side-Rendering)

• 서버에서 사용자에게 보여줄 페이지를 모두 구성하여 사용자에게 페이지를 보여주는 방식

대표적으로 JSP/Servlet이 이를 사용하고 있다.

SSR Flow

SSR 동작 방식

1. 사용자가 Website 요청을 보냄
2. Server는 리소스 체크, 컴파일 후 즉시 렌더링 가능한 html 파일을 만듬
3. 클라이언트(Browser)에 전달되는 순간 즉시 렌더링 진행하여 사용자에게 웹페이지를 보여줌.
   (하지만 사이트 자체는 조작이 불가능하다. JavaScript가 읽히기 전이기 때문이다.)
4. 클라이언트가 JavaScript를 다운받음
5. 다운되는 동안 사용자는 컨텐츠를 보고 상호작용을 진행할 수 있지만, 실제 동작되지는 않음.
   대신 사용자의 상호작용을 기억함.
6. 클라이언트가 JavaScript 프레임워크를 실행시킴
7. JavaScript가 성공적으로 컴파일되고 기억하고 있는 사용자의 상호작용이 실행되며 웹페이지는 상호작용에 맞게 동작이 가능해짐

CSR (Clinet-Side-Rendering)

• 서버는 요청을 받으면 클라이언트에 HTML과 JavaScript를 보내줌.
• 전달받은 HTML과 JavaScript로 클라이언트를 렌더링을 시작함.

CSR Flow

CSR 동작 방식

1. 사용자가 Website 요청을 보냄
2. CDN이 HTML 파일과 JavaScript로 접근할 수 있는 링크를 클라이언트로 보냄
   (CDN : 유저의 요청에 "물리적"으로 가까운 서버에서 요청에 응답하는 방식)
3. 클라이언트는 전달받은 링크로 HTML, JavaScript를 다운로드 받음
   (이때 사용자는 아무것도 보지 못함)
4. 다운이 완료된 JavaScript를 실행시며 데이터를 불러오기 위한 API가 호출됨.
   이때 사용자는 미리 설정되어 있는 placeholder를 보게됨.
5. 서버가 클라이언트의 요청(API)으로 부터 응답함
6. 요청에 대한 응답으로 받아온 Data를 기반으로 하여 placeholder 자리에 넣어줌.
   이제 웹페이지는 상호작용에 맞게 동작이 가능해짐.

두개의 대표적인 차이점

• 웹페이지 로딩 시간
• SEO(Search Engine Optimization)

웹페이지 로딩 시간

• 최초로딩
  CSR의 경우에 HTML과 CSS, 모든 스크립트를 한번에 불러오기 때문에 느리다.
  반면 SSR의 경우에 필요한 부분의 HTML과 CSS, 스크립트만을 불러온다.
  때문에 최초 로딩은 SSR이 CSR에 비해 상대적으로 빠르다.
• 나머지로딩(페이지 이동시)
  SSR은 다른 페이지를 불러올 때 렌더링 과정을 정확하게 처음부터 다시 수행한다.
  반면 CSR은 초기 로딩시 모든 정보를 불러왔기에 바로 렌더링이 진행된다.
  때문에 나머지 로딩은 CSR이 SSR에 비해 상대적으로 빠르다,.

SEO(Search Engine Optimization)

검색엔진은 자동화된 로봇인 '크롤러'를 통해 웹사이트를 읽는다.
CSR은 JavaScript를 실행시켜 동적으로 컨텐츠가 생기기 때문에 JavaScript가 실행되어야 Metadata가 변경이 된다.

하지만 SSR은 서버에서 모두 생성 후 클라이언트로 보내기 때문에 SEO에 용이하다.

(업체 내에서 사용할 CMS(Private 하게 사용하게 될 경우)라면 SEO를 신경 쓸 필요가 없다.)

 

크롤러들은 JavaScript Engine이 존재하지 않아 CSR의 경우 빈 페이지로 인식된다.
(사용자의 요청 이후에 JavaScript를 다운로드 받고 실행시키니 빈 페이지로 인식하는 것이다.)

 

하지만 구글의 크롤러인 'Google Bot'은 JavaScript Engine이 적용되어 있어 CSR도 문제 없이 SEO가 지원된다.

최신버전의 경우 ES2015 이상 문법도 지원하고 있다.

 

CSR의 SEO 문제를 해결하기 위해 SSR with Hydration 기법이 나왔다.

Server-Side에서 최초 렌더링을 진행하고, 이 후 CSR을 이용하는 방식이다.

대표적으로 Next.js(React 생태계), Nuxt.js(Vue 생태계)가 사용하고 있다.

SSR 사용이 권장되는 환경

• Network가 느릴 때
  (CSR은 모든 정보를 한번에 불러오지만, SSR은 각 페이지마다 필요한 정보만 불러오기 때문이다.)
• SEO가 필요할 때
  (Google에서는 CSR도 SEO를 지원하고 있고, SSR with Hydration 기법을 이용하게 된다면 CSR로도 문제 없이 SEO를 구현할 수 있지만, 결국 SSR이 더 용이한 것은 맞다.)
• 최초 로딩이 빨라야 할 때
• 메인 Script가 크고 로딩속도가 느릴 때
  (CSR은 메인 Script가 로딩이 끝나면 API로 데이터를 요청한다.
  하지만, SSR은 한번의 요청으로 즉시 렌더링이 가능한 페이지가 돌아오기 때문이다.)
• 웹사이트 내에서 상호작용이 적을 때
  (최초 로딩시 사용자에게 UI/UX는 노출된다. 사용자는 이를 페이지가 완전히 로딩 됐다고 생각하여 상호작용을 하게 될텐데, 이 때 SSR의 특성상 JavaScript 다운로드가 늦게 된다면 상호작용이 그만큼 늦게 진행되는 것이니 사용자 경험이 떨어지게 된다.)

CSR 사용이 권장되는 환경

• Network가 빠를 때
• 서버의 성능이 좋지 않을 때
  (SSR을 이용하게 되면 서버에 부담이 그만큼 더 갈텐데, 이를 클라이언트로 돌리는 것이다.)
• 사용자에게 보여줘야 하는 데이터의 양이 많을 때
  (로딩창을 띄워 사용자 경험을 더 좋게 할 수 있다.)
• SEO가 필요 없을 때
• 웹사이트 내에서 상호작용이 많을 때
  (오히려 Rendering이 되는 것을 막아 사용자의 상호작용을 막는 것이 사용자 경험 측면에서 더 좋다.)

 

하지만 요즘 SPA(Single Page Application)이 대두되면서 CSR이 각광받기 시작했다.

SPA(Single-Page-Application)

한개의 페이지를 가진 Application이다.

SPA는 CSR이긴 하나, CSR === SPA는 성립되지 않는다.

• 사용자 친화적이다.
  페이지 이동이 존재하지 않으니 사용자 경험 측면에서 상당히 유리하다.
• CSR이기 때문에 서버에 부담을 줄일 수 있다.
• Virtual DOM을 이용해 빠른 Rendering이 가능하다.
• FE, BE 분리로 개발 업무 분업화 및 협업이 용이하다.
• 개발이 효율적이다.