CSR&SSR

CSR&SSR

* 영상 출처: https://www.youtube.com/watch?v=YuqB8D6eCKE

CSR&SSR을 이야기 하기 전에

먼저 SPA,MPA에 대한 이야기를 해야한다.

오늘 날, 웹페이지 개발을 할 때는 react,vue 등 js 기반 SPA로 작성하게 된다.

SPA란 "Single Page Application"의 약자로 하나의 페이지로 구성된 웹 어플리케이션 이다.

어플리케이션을 이용할 때 Header는 고정되어 있고

메뉴를 선택하면 메인화면 부분,혹은 클릭한 부분만 바뀌는 그런 사이트.

(00:48)

(00:49)

이러한 웹사이트들이 SPA이다.

반면 MPA란 "Multi page Application"의 약자로

탭을 이동할 때마다 서버로부터 새로운 HTML을 새로 받아와서 페이지 전체를 새로 렌더링하는

전통적인 웹 페이지 구성 방식이다.

이와 같이 여전히 MPA를 사용하는 사이트들이 있기는 하지만

매번 새로운 HTML을 서버로부터 받아오고, 전환 시마다 화면 깜빡이는 단점들이 있기에

AJAX가 등장하고 나서 부터는 원하는 부분만 클라이언트에서 동적으로 갈아끼울 수 있고

화면 깜빡임도 없는 SPA를 사용하게 되었다.

(01:36)

일반적으로 SPA에서는 렌더링 방식으로 CSR을

MPA에서는 렌더링 방식으로 SSR을 사용한다.

SPA는 웹 어플리케이션을 필요한 정적 리소스를 초반 한 번에 모두 다운로드 하고

그 이후 그 이후 새로운 페이지 요청이 있을 때 갱신에 필요한 데이터만 전달받아서 클라이언트에서 페이지를 갱신하기 때문에 자연스럽게 렌더링 방식으로 CSR을 사용하게 되고

MPA는 새로운 요청이 있을 때마다 서버에서 이미 렌더링된 방식으로 SSR을 사용하게 된다.

리액트,뷰,앵귤러를 사용해서 SPA를 만들고 특별한 목적을 가지고 렌더링 방식을 변경하지 않는다면 자연스럽게 CSR을 사용하게 되고,

PHP나,JSP로 MPA를 만들면 자연스럽게 SSR을 사용하게 된다는 것이다.

(02:34)

대부분의 웹어플리케이션 가장 많이 사용되는 렌더링 방식은 CSR인데.

가장 좋은 렌더링 방식이기 때문에 사람들이 가장 많이 사용하는 걸까? 본격적으로 알아보자. CSR이란 Client side Rendering의 약자로 클라이언트 측에서 렌더링하는 방식이고

SSR이란 Server side Rendering의 약자로 서버측에서 렌더링하는 방식이다.

말 그대로 어느 쪽에서 Render을 준비하는지에 따라 나뉘는 개념이라고 할 수 있다.

CSR과 SSR을 공부할 때, SSG도 함께 언급되곤 하는데

SSG는 Static site Generation의 약자로 Static Rendering이라고도 불리는 방식이다.

(03:23)

서버에서 HTML을 보내준다는 측면에서는 SSR과 비슷하지만

언제 만들어 주느냐에 차이가 있다.

(03:30)

(03:39)

동작 과정이 구체적으로 어떻게 다른지? 그리고 그에 따라 나타나는 특징에 대해 알아보자.

CSR의 동작 과정과 중요 특징.

(04:42)

JS 파일을 다운로드 받아 동적으로 페이지를 만들어서 띄운다는 부분.

CSR은 브라우저가 JS 파일을 다운로드 받고 동적으로 DOM을 생성하는 시간을 기다려야 하기 때문에 초기로딩 속도가 느리다.

하지만 초기로딩 이후에 페이지 일부를 변경할때는 서버에 해당 데이터만 요청하면 되기 때문에

이후 구동 속도는 빠르다는 장점을 가지고 있다.

또 하나,서버가 빈 뼈대만 있는 HTML을 넘겨주는 역할만 수행하면 되기 때문에

서버측에 부하가 적다.

이밖에도 클라이언트 측에서 연산,라우팅 등을 모두 직접 처리 하기 때문에 반응 속도가 빠르고 UX도 우수하다는 장점이 있다.

한편 브라우저들이 가지는 웹 크롤러는 HTML을 읽어서 검색 가능한 색인을 만들어내는데

웹 크롤러 봇 입장에서는 본 HTML은 이렇게 텅텅 비어있다.

(05:13)

검색엔진이 색인을 할만한 콘텐츠가 존재하지 않는 다는 것이다.

이 때문에 CSR은 검색엔진 최적화에 불리하다는 치명적인 단점이 있다.

열심히 서비스를 만들었는데 검색사이트에 노출되지 않는 다면 매우 슬플 일이다.

물론 남다르게 똑똑한 구글의 크롤러 봇은 자바스크립트를 실행할 줄 아니까, CSR 웹 크롤링도 가능하다고 하는데

(05:42)

하지만 아직 완벽한 단계가 아니기도하고 구글 측에서도 여전히 크롤러 봇이 JS를 실행하기전에

로봇이 JS 실행하기전에 빠르게 끌어올리는 할 수 있도록 자바 스크립트를 실행할 수 없는 다른 크롤러 봇들을 위해서 SSR 보려 해 보라는 말을 더 붙이고 있다.

그렇다면 이제 SSR에 대해서 알아보자.

(06:25)

유저가 웹사이트에 방문하면 브라우저에서 서버로 콘텐츠를 요청. 서버에서는 즉시 페이지에 필요한 데이터를 얻어와 모두 삽입 하고 css 까지 모두 적용해서 렌더링 준비를 마친 html,js code를 브라우저에 응답으로 전달. 브라우저에서는 바로 전달 받은 페이지를 띄우고. 이어 브라우저가 js code를 다운로드 하고 html에 js 로직을 연결한다

먼저 서버에서 렌더링 준비를 마친 HTML을 브라우저의 응답으로 전달한다는 부분인데

모든 데이터가 이미 HTML에 담겨진 채로 브라우저에 전달되기 때문에 검색엔진 최적화에 유리하다.

JS를 실행 할 줄 모르는 크롤러 봇도 무리 없이 HTML을 읽을 수 있다.

또 하나, 자바스크립트 코드를 다운로드 받고 실행하기 전에 사용자가 화면을 볼 수 있다는 점이다.

JS 다운로드를 기다려야했던 CSR보다 빠를 수 밖에 없다.

하지만 동시에 이것이 치명적인 단점이 되기도 하는데

이 시점에는 사용자가 버튼을 클릭 하거나 이동하려고 해도 아무런 반응이 없을 수 있다.

interaction(상호작용) 가능한 page 처럼 보이지만, 그저 내용과 스타일이 입혀진 껍데기에 불과하고, 실제로 클라이언트 측 JS가 실행되고 이벤트 핸들러가 첨부되어서 JS로직이 모두 연결될때 까지 사용자 입력에 응답할 수 없기 때문이다.사용자 입장에서는 뭔가 보여서 눌렀는데.

사용자 입장에서는 뭔가 보여서 눌렀는데 아무런 반응이 없다면 굉장히 어이 없을 것이다.

(07:24)

이렇게 SSR 안에는 TTV(Time To View)와 TTI(Time To Interact)간에 시간 간격이 존재한다는 것이 단점이다.

(07:31)

반면에 CSR은 JS가 동적으로 DOM을 생성하기 때문에 HTML은 JS 로직이 모두 완전히 연결된

상태라 사용자가 보는 시점과 이용할 수 있는 시점이 동일하다.

(08:21)

그렇다면 현재 대부분의 웹들이 사용하고 있는 CSR의 단점을 보완할 수 있는 방법은 없을까?

(08:37)

code splitting, tree-shaking,chunk 분리를 통해 JS bundle을 줄여서 초기 DOM 생성 속도를 줄이면 초기 로딩 속도를 개선할 수 있다.

(08:50)

Pren-rendering을 통해 SEO를 개선할 수 있는데 라이브러리나 웹팩 플러그인을 통해

각 페이지에 대한 HTML 파일을 미리 생성 해둔 뒤 서버에서 요청자는 자가 만약 크롤러라면 사전에 렌더링 된 HTML 버전 페이지를 보여 주는 방식을 통해 개선할 수 있다.

CSR을 사용하고 있는 SPA에 SSR이나 SSG를 도입하는 것도 방법인데

실제로 CSR의 단점을 상당 부분 보완할 수 있다.

그렇다면 CSR 앱에 SSR/SSG를 어떻게 도입할 수 있는지 방법을 알아보자.

(09:18)

1.먼저 프레임워크없이 도입하는 방법이다.

우선 프론트엔드 개발자에게 상대적으로 친숙한 Express.js로 별도의 서버를 직접 운영하는 방법이 있다.

타입스크립트 설정이 걱정된다면 기본적으로 타입스크립트를 지원하는 NestJS를 사용할 수도 있다.

하지만 이 방법들은 서버 환경 구성이나 빌드 등의 작업이 생소한 프론트엔드 개발자에게는 복잡하고 헷갈리는 부분이 많아서 다소 진입장벽이 있다. 이를 위해서 SPA에서

보다 쉽게 SSR이나 SSG를 적용할 수 있도록 해주는 프레임워크들이 있다.

먼저 Next.js는 리액트 SSR이나 SSG를 사용할 수 있게 해주는 프레임워크로

페이지의 성격 별로 SSR을 사용할 것인지 미리 정해 주는 것도 가능하다.

(10:06)

Gatsby는 SSG에 최적화,다양한 플러그인이 특징이다.

CSR,SSR,페이지 로딩 등도 지원하고

무엇보다 굉장이 다양한 플로그인들을 제공하는 것이 장점이다.

빌드 시점에 스태틱 HTML들을 만들어 주는 것이기 때문에

페이지가 적고, 작은 서비스라면 확실히 좋은 수단이 될 수있다.

Nuxt.js는 뷰를 위한 프레임 워크인데

(10:30)

Next.js에 영감을 받아서 만들어졌다고 한다.

(10:39)

Angular 유니버셜은 앵귤러에서 SSR을 가능하게 해주는데

원래 프레임워크로 시작했지만 앵귤러4 부터는 앵귤러 자체에 포함되어 있다고 한다.

엄밀히 말하면 더 이상 프레임워크가 아니다.

이러한 프레임워크들이 CSR에 SSR이나 SSG도입을 훨씬 편하게 만들어 주는 것은 사실이지만 프레임워크를 사용하더라도, 일반 SPA, 즉 CSR 개발에 코드 복잡도는 올라간다. 또 프레임워크를 사용하면 당연히 감수해야할 부분이긴 하지만

직접 제어할수 없는 블랙박스 영억도 존재한다는 것이다.

이렇게 CSR에 SSR 혹은 SSG를 도입하는 방법을 알아보았다.

(11:19)

이렇게 초기 렌더링 방식으로 SSR을 사용하고 그 이후에는 CSR을 사용하는 앱이나

그 렌더링 방식을 부르는 용어도 있다.

(11:30)

Isomorphic App은 서버와 클라이언트에서 동일한 코드가 동작하는 어플리케이션이라는 의미로 해석할 수 있다.

클라이언트와 서버가 모두 같은 코드로 돌아가기 때문에

(11:41)

예상과는 다른 결과를 마주할 가능성도 있지만 초기 로딩속도와 SEO를 해결하면서도

CSR의 장점을 그대로 가져갈수 있는 좋은 대안이 되기 때문에 최근 많이 사용하고 있는 추세이다.

(11:50)

CSR도 단점이 있고 SSR도 단점이 있다.

(11:57)

그리고 그것을 보완하려고 조합해 사용해도 단점이 있다.

그렇다면 대체 어떤 방식을 사용하는 것이 좋을까?

정답은 서비스 성격에 따라 달라진다. 만약 사용자와의 상호작용이 많고

대부분 개인정보 데이터를 기준으로 구성되는 서비스라면

검색에 상위노출되는 것보다 오히려 고객의 데이터를 보호하는 것이 더 중요할 수 있다.

모든 서비스에 SEO가 필요하지는 않다는 의미이다.

이런 서비스의 경우 SSR보다 CSR이 더 적합하다.

(12:07)

만약 회사 홈페이지이기 때문에 상위노출이 되어야하고 누구에게나 동일한 내용을

노출 하고 있다면 그리고 만약 그 페이지 데이터가 자주 바뀐다면 SSR이 더 적합할 것이고

내용을 업데이트 하는 일이 거의 없다면 SSG가 더 적합할 것이다.

만약 사용자에 따라 페이지 내용도 달라지고 빠른 인터랙션도 중요하고 검색엔진 최적화도 포기할 수 없다면 그때는 유니버셜 렌더링을 고려해보면 좋을 것이다.

(12:48)