CSR vs SSR 바로 잡기

시작하며

Vue와 React는 대표적인 Single page application(이하 SPA) 프레임워크로 Client Side Rendering(CSR) 방식으로 뷰를 만든다. 이와 대조적으로 PHP는 Multi page application(MPA)으로 Server Side Rendering(이하 SSR) 방식으로 뷰를 만든다.

과제를 수행하면서 CSR과 SSR의 차이를 이해하고 요청 시 발생하는 패킷을 분석해보려고 한다.

SPA vs MPA

https://www.hestabit.com/blog/single-page-vs-multi-page-web-apps/

MPA(Multi Page Application)

반면 MPA는 탭을 이동할 때마다 서버로부터 새로운 HTML을 새로 받아와서 페이지 전체를 교체하는 식으로 작동하게 된다.

SPA(Single Page Application)

하나의 페이지로 구성된 웹 애플리케이션. 어플리케이션을 이용하면서 헤더는 고정되어 있고 메인이나 클릭한 부분만 변경되는 식으로 작동한다.

CSR vs SSR

SPA에서는 주로 CSR로 렌더링하고, MPA에서는 주로 SSR로 렌더링한다.

하지만 SPA === CSR, MPA === SSR 이라는 말은 성립하지 않는다.

SPA, MPA는 페이지의 개수, CSR, SSR은 렌더링 위치에 따라 서로 다른 개념을 의미한다는 것을 알아야 한다.

CSR은 Client Side Rendering의 약자로, 클라이언트 측에서 렌더링 하는 방식이고, SSR은 Server Side Rendering의 약자로, 서버 측에서 렌더링 하는 방식이다. 말 그대로 어느 Side에서 렌더링을 준비하느냐에 따라 나뉘는 개념이다.

CSR(Client Side Rendering)

CSR 방식은 브라우저에서 js 파일에 의해서 뷰를 동적으로 생성한다.

장점

• 화면 깜빡임이 없음
• 초기 로딩 이후 구동 속도가 빠름
• TTV(Time to View) 와 TTI(Time to Interact) 사이 간극이 없음
• 서버 부하 분산

단점

• 초기 로딩 속도가 느림
• SEO(검색 엔진 최적화)에 불리함
  • HTML이 텅텅 비어있는 것처럼 보이기 때문

SSR(Server Side Rendering)

SSR 방식은 웹 서버에서 뷰를 생성하고 페이지가 전환될 때마다 클라이언트가 뷰를 요청하고 서버는 그것을 생성한 뒤 클라이언트에게 보낸다.

장점

• 초기 구동 속도가 빠름
• SEO에 유리

단점

• 화면 깜빡임이 있음
• TTV와 TTI 사이 간극이 있음
• 서버 부하가 있음

내가 만드는 서비스는 무엇을 써야할까?

CSR

• 유저와 상호작용이 많다
• 대부분이 고객의 개인정보로 이루어진 페이지들이라 검색엔진에 노출될 필요는 없다

SSR

• 회사 홈페이지여서 홍보나 상위노출이 필요하다
• 누구에게나 항상 같은 내용을 보여준다
• 업데이트가 빈번해 해당 페이지 데이터가 자주 바뀐다

SSG

• 회사 홈페이지여서 홍보나 상위노출이 필요하다
• 누구에게나 항상 같은 내용을 보여준다
• 업데이트를 거의 하지 않는다

Universal Rendering (초기 렌더링으로는 CSR + 이후 SSR)

• 사용자에 따라 페이지 내용이 달라진다
• 빠른 interaction과 화면 깜빡임이 없어야 한다
• SEO를 포기할 수 없어 상위노출이 되면 좋겠다

MPA와 SPA의 패킷 비교

이 경우 MPA 는 SSR 방식으로, SPA는 CSR 방식으로 구현

MPA

MPA에서 GET 요청에 대한 응답으로 200 OK 가 날아왔다.

사진에서 응답의 body로 html이 그대로 전달된 것을 볼 수 있다. 즉 SSR 방식으로 이미 렌더링 된 파일이 클라이언트로 전달되었다.

이후 a 페이지와 b 페이지를 번갈아가면서 접속해보면

a페이지와 b페이지에 대한 요청이 서버로 전달되고 응답이 오는 것을 확인해볼 수 있다.

SPA

SPA는 MPA에 비해서 엄청 많은 응답이 날아왔다.

html이 날아오고 나서 js 및 static 파일을 다운받고 있는 것을 확인할 수 있다.

TCP 응답을 살펴보면 위의 사진과 같이 javascript 함수가 전송된 것을 확인할 수 있다. 이렇게 전송된 javascript 함수를 통해서 클라이언트는 동적으로 페이지를 생성한 뒤 뷰를 볼 수 있게 된다.

이후 B페이지에 대한 요청을 보내면 B페이지를 위해서 필요한 js 파일이 전달되고 그 이후에는 A, B 페이지에 대한 요청을 반복해서 보내도 추가로 요청/응답이 일어나지 않는 것을 볼 수 있다.

HTTP 패킷 구조 분석

심화과제로 HTTP 패킷 구조에 대한 분석을 진행했다.

Http 패킷은 요청과 응답 라인으로 나눠볼 수 있다.

헤더는 그 내용에 따라서 다음과 같이 분류할 수 있다.

• General header: 요청과 응답 모두에 적용되지만 바디에서 최종적으로 전송되는 데이터와는 관련이 없는 헤더.
• Request header: 페치될 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더.
• Response header: 위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 갖는 헤더.
• Entity header: 컨텐츠 길이나 MIME 타입과 같이 엔티티 바디에 대한 자세한 정보를 포함하는 헤더.

요청 라인

• 요청 메소드 방식과 http 버전에 대해서 처음에 서술하고
• 요청에 대한 정보를 담고 있는 것을 확인할 수 있다.
• 호스트 주소, 연결 상태, 응답으로 받을 형식 등을 지정하고 있는 것을 확인할 수 있다.

응답 라인

• 응답 라인에서는 HTTP 버전과 응답 코드를 확인할 수 있다.
• 기본적인 정보와 함께 Content에 대한 타입, 길이를 확인할 수 있는데 이를 통해서 몇개의 패킷이 함께 전달되어야 하는지 등을 알 수 있다.