개요
과거와는 다르게 모던 애플리케이션을 다루는 서비스회사에서 Single Page Application 의 형태로 서비스를 개발하고 있다.
하지만, 최근 React, Vue 의 Client Side Rendering 환경에서 Next.js, Nuxt.js와 같은 프레임워크를 통해서 Server Side Rendering을
적용하는 경우가 많아진 것 같다.
SPA VS MPA에 대한 정보는 사전 포스팅에서 가볍게 포스팅하였다.
이번엔 CSR 과 SSR에 대해서 조금 깊게 알아보려 한다.
Server Side Rendering
서버사이드 렌더링의 경우 정의는 아래와 같다.
서버사이드 렌더링은 서버로부터 완전하게 만들어진 HTML파일을 받아와 페이지 전체를 렌더링 하는 방식이다.
과거 Multi Page Aplication의 경우 SSR을 채택하여 사용하였지만 Single Page Application으로 가면서 CSR을 채택하여 사용하기 시작하였다.
본론으로 돌아가 SSR 의 경우 아래와 같은 과정으로 브라우저에 그려진다.
- 브라우저(User)의 요청
Server에서Render가 완료된HTML파일 전송- 브라우저가
JavaScript를 다운로드 - 브라우저가 프레임워크를 실행하여 페이지 인터렉션이 가능
위 과정으로 SSR이 진행된다.
2-1. SSR 의 장점
검색엔진최적화 라고도 불리는 SEO는 검색엔진이 웹을 크롤링 하면서 페이지에 컨텐츠 색인을 생성하는 과정이다.
- 서버사이드의 경우 모든 데이터가 완성된 채 브라우저에 전달되기 떄문에
SEO에 유리한 장점을 가진다. - 서버로부터 완성된 화면을 전달받아 필수적인 요소를 먼저 가져오기 때문에
빠른 초기 로딩속도를 제공한다.
2-2. SSR 의 단점
앞서 설명한 SSR의 동작 과정을 다시한번 살펴보자.
- 브라우저(User)의 요청
Server에서Render가 완료된HTML파일 전송- 브라우저가
JavaScript를 다운로드 - 브라우저가 프레임워크를 실행하여 페이지 인터렉션이 가능
여기서 각 단계의 중요한 부분을 살펴본다. 이를 살펴보기 이전에 아래 두개의 개념이 필요하다.
TTV(Time To View)
- 사용자가 웹 브라우저에서 내용을 볼 수 있는 시점
TTI(Time To Interact)
- 사용자가 웹 브라우저에서 상호작용(클릭 등) 할 수 있는 시점
여기서 단점이 발생한다.
- TTI 와 TTV 시점 차이간 동작불가
서버가 Render가 완료된 HTML 파일을 전달하게 되면 유저는 완성된 화면을 볼 수 있다. 하지만 버튼클릭 같은 인터렉션 기능은 불가능하다.
이유는 TTV시점의 상태이지만 JavaScript가 다운로드 되기 전이기 때문에 TTI시점까지는 인터렉션이 불가능한 상황이 되기 때문이다.
이러한 현상은 단점으로 생각될 수 있을 것이다.
- 사용자 경험
요청시마다 새로고침이 발생하므로 사용자에게 좋지 않은 서비스 경험을 줄 수 있다.
- 서버 부하
새로운 요청이 발생할 때마다 모든 페이지가 렌더링되기 때문에 서버에 부하가 발생할 수 있다.
Client Side Rendering
Single Page Application 방식은 메인 렌더링 방식으로 Client Side Rendering 을 채택하여 사용되고 있다.
Client Side Rendering 이란 정의는 아래와 같다.
Client Side Rendering 이란 사용자의 요청에 따라 필요한 부분만 응답 받아 렌더링 하는 방식이다.
동작 과정은 아래와 같다.
브라우저(User)요청HTML, JS에 대하여 서버에서 브라우저로 전달- 브라우저가
HTML, JS를 다운로드 - 브라우저 렌더링
위 과정을 통해 CSR은 진행된다.
3-1. CSR의 장점
SSR에 비해 상대적으로빠른 속도와서버 부하 감소
CSR 방식은 변경된 부분과 관련된 데이터만 가져오므로 SSR보다 렌더링이 빠르게 진행된다.
보통 모던 프레임워크(React, Vue)에서는 Router 기능을 통해 실제는 사용하는 메인 파일에서 사용자가 요청하는 다양한 View를 볼 수 있다.
그리고 Router를 통해 컴포넌트가 변경될때마다 필요한 경우 서버와 통신하여 Data를 요청하게 된다.
이러한 점 즉, 필요할때만 서버와 통신하면 되기 때문에 효율적이고 서버에 부담을 줄일 수 있는 부분이다.
- 사용자 친화적
SSR의 단점 중 사용자에게 좋지 않은 UX를 제공할 수 있는 점을 명시하였다.
이와는 반대로 이러한 부분들을 해결할 수 있는 장점이 있다. 페이지 간의 이동에서 서버에 요청하는 부분이 아니기 때문에 깜빡임이 없이 부드러운 페이지 이동을 사용자에게 제공할 수 있다.
3-2. CSR 의 단점
위에서 설명한 TTI, TTV를 적용하여 설명한다.
SEO에 분리하다.
CSR의 경우 Single Page Application이기 때문에 JS가 로드된 후 사용자의 인터렉션에 의해 페이지 내용을 채우게 된다.
이러한 이유로 웹 크롤러가 페이지 컨텐츠를 색인화 하려고 하면 빈 페이지처럼 보이게 된다.
이러한 이유로 SEO에 분리할 수 있다.
최근에는 웹 크롤러가 JS를 실행할 수 있어서 나아진 부분이 있다고는 한다고 한다.
- 초기 구동속도가 느리다.
위에서 설명하였듯이 CSR은 JS를 다운로드 받고 실행하여 페이지 내용을 채우게 된다.
따라서, CSR의 초기 HTML은 텅 빈 페이지라고 생각할 수 있다.
이후 JS가 모두 다운로드되고 페이지내용을 채우게 되면 사용자는 이 시점에 페이지의 내용을 볼 수 있는 것이다.
즉, 사용자가 웹 브라우저 내용을 볼 수 있는 시점 TTV(Time To View) 시점이 SSR보다 느릴 수 밖에 없다.
다만, SSR처럼 TTI와 TTV의 차이로 인해 화면은 보이나 인터렉션이 불가능한 상황은 발생하지 않는다.
최근 SSR 사용 추이(Next.js)
과거 SSR에서 CSR로 대세가 넘어왔다가 최근에는 다시 SSR을 많이 하는 추세인것 같다.
여기에서 한가지 의문이 들었다.
왜 기껏 넘어왔으면서 다시 회기하려고 하지??
그래서 간단하게 Next.js에 대하여 찾아보았는데 이유는 간단하게만 보자면 아래와 같다.
- SEO 의 강점
SSR의 장점에서도 설명하였지만, CSR보다 SSR은 SEO에 큰 강점을 갖고 있다.
이러한 이유로 최근 SSR을 많이 도입하는 것 같다.
SSR과CSR의 장점을 가진 기술의 등장
React의 강력한 프레임워크중 하나인 Next.js이다.
Next.js의 작동원리는 아래와 같다.
- 초기에 사용자가
Server에 페이지 요청을하면SSR방식으로 렌더링을 마친HTML파일을 브라우저로 전달한다. - 브라우저에서
JavaScript를 다운로드하고React를 실행하여 페이지를 채운다. - 사용자가 페이지 인터렉션을 통해 페이지를 이동할때는 기존의
SSR방식이 아닌CSR방식으로 페이지 요청하지 않고 브라우저에서Router를 통해 페이지를 이동한다.
위 내용에서 보면 기존과의 다른점을 알 수 있다.
이전 SSR의 단점이었던 사용자 경험에 불편함을 CSR의 장점을 통해 해소 시킨 SSR이란 것이다.
포스팅을 마치며 Next.js에 대한 자세한건 차차 공부하여 포스팅할 예정이다.