서버사이드렌더링(SSR) & 클라이언트사이드렌더링(CSR)

본 게시글은 아래의 글을 필사하였습니다.

https://velog.io/@zansol/%ED%99%95%EC%9D%B8%ED%95%98%EA%B8%B0-%EC%84%9C%EB%B2%84%EC%82%AC%EC%9D%B4%EB%93%9C%EB%A0%8C%EB%8D%94%EB%A7%81SSR-%ED%81%B4%EB%9D%BC%EC%9D%B4%EC%96%B8%ED%8A%B8%EC%82%AC%EC%9D%B4%EB%93%9C%EB%A0%8C%EB%8D%94%EB%A7%81CSR

[주니어탈출기] 서버사이드렌더링(SSR) & 클라이언트사이드렌더링(CSR)

왜

모바일의 시대에 등장한 클라이언트 사이드 렌더링 Single Page Application(SPA)!

고려해야할 점들이 있다.

SPA는 최초 한 번 페이지 전체를 로딩한 후 데이터만 변경하여 사용할 수 있는 애플리케이션을 의미한다.

렌더링 방식

SPA는 클라이언트 사이드 렌더링 방식이다.

기본적으로 페이지 로드가 없고, 모든 페이지는 단순히 HTML5 History에 의해 렌더링될뿐!

그래서 언제 새로운 데이터를 불러와야할지 스스로 정해서 구현해야한다.

전통적인 웹 방식(SSR)은 이 SPA방식에 비해 성능문제 이슈가 있었다.

전통적인 웹 대부분은 서버 사이드 렌더링 방식이었다. 즉, 브라우저에 나타나는 형태 그대로를 HTML로 만들어 제공하고 , 브라우저는 HTML을 표시하는 방식이었다. 이런 방식을 사용하다가 일부 HTML과 Script만 브라우저로 전달하고, 브라우저에서 Script를 실행시켜 서버에서 데이터를 조회하여 HTML을 생성하는 방식을 사용하게 되었다.

요즘은 웹에서 제공되는 정보가 정말 많기 때문에 전통적인 방식은 성능문제에 이슈를 낳았다. 요청시 마다 새로고침이 일어나며 페이지를 로딩할 때마다 서버로부터 리소스를 전달받아 해석하고 화면에 렌더링하는 방식이기 때문이다. 예를들어 현재 주소에서 동일한 주소를 가리키는(갖고있는) 버튼을 눌렀을 때, 설정페이지에서 필요한 데이터를 다시 가져올 수 없다. 

이것은 사용자와 인터랙션이 많은 요즘 웹앱에게 충분하기 않는 방법일 수 있다. 렌더링을 서버쪽에서 하는 것은, 그 만큼 렌더링을 위한 서버 자원이 사용되는 것이고, 불필요한 트래픽도 낭비되는 것이다.

반면 클라이언트 사이드 렌더링은 사용자의 행동에 따라 필요한 부분만 다시 읽어들이기 때문에 서버측에서 렌더링하여 전체 페이지를 다시 읽어들이는 것보다 빠른 인터렉션을 기대할 수 있다. 서버는 단지 JSON파일만 보내주고, html을 그리는 역할은 자바스크립트를 통해 클라이언트측에서 수행한다.

뷰 렌더링을 유저의 브라우저가 담당하도록 하고, 먼저 웹앱을 브라우저에 로드한 다음에 정말 필요한 데이터만 전달받아 보여주는 클라이언트 사이드 렌더링은 트래픽을 감소시키고, 사용자에게 더 나은 경험을 제공했다.

SPA는 한 종류의 화면만 존재하는 것이 아니다!

화면에 따라 다른 주소를 가진다. 주소가 있어야 사용자들이 북마크도 가능하고, 서비스에 구글을 통해 유입될 수 있기 때문이다.(SEO).

주소에 따라 다른 뷰를 렌더링하는 것을 라우팅이라고 한다. React자체에는 이 기능이 내장되어 있지 않기 때문에 라이브러리 react-router를 사용해서 설정해야한다.

클라이언트 사이드 렌더링의 장점 / 단점

1. 장점

1-1. 트래픽 감소

필요한, 변경된 데이터만 받아서 그림

1-2. 사용자 경험

새로고침이 발생하지 않아 사용자가 네이티브 앱과 비슷한 경험을 할 수 있다.

2. 단점

2-1. 검색엔진

자바스크립트 위주로 돌아가는 프로젝트는 자바스크립트 엔진이 돌아가지 않으면 원하는 정보를 표시해주지 못함. 크롬에서 react로 만든 웹앱의 소스를 확인하면, 내용이 비어있다. 그렇기 때문에 검색엔진 크롤러가 데이터들을 제대로 수집하지 못한다. 하지만 짱짱맨 구글의 검색엔진은 자바스크립트 엔진이 내장되어 있다. 하지만 네이버, 다음 등의 검색엔진은 제대로 크롤링하지 못하기 때문에 서버 사이드 렌더링을 따로 구현해야한다.

서버 사이드 렌더링의 장점 / 단점

1. 장점

1-1. 검색엔진최적화(SEO) 가능

서버 사이드 렌더링을 통해 얻을 수 있는 가장 큰 이점!

1-2. 성능 개선

첫 렌더링된 html을 클라이언트에게 전달해주기 때문에 초기로딩속도를 많이 줄여줄 수 있다. 자바스크립트 파일을 불러오고 렌더링 작업이 완료되기 전에 사용자가 사이트 콘텐츠를 이용할 수 있게 된다.

2. SPA에서 서버 사이드 렌더링을 적용시켰을때 단점

2-1. 프로젝트의 복잡도

React 에서 서버 사이드 렌더링을 구현할 경우 Router와 Redux를 함께 사용하다보면 복잡해질 수 있다.

2-2. 성능의 악화 가능성

서버 사이드 렌더링을 하게 될 때는, ReactDOMServer.renderToString함수를 사용한다. 이 함수는 동기적으로 작동한다. 그래서, 렌더링하는 동안은 이벤트루프가 막히게 된다. 하지만..! 라이브러리를 통하여 비동기식으로 작동하게끔 코드를 작성할 수 있다.

3. 대안

3-1. 메타태그만 넣어주기

서버쪽에서 라우트에 따라 필요한 메타태그만 넣어주는 것. 그러면, 크롤러에선 해당 페이지에 대한 기본 정보는 얻어 갈 수 있게 된다.

3-2. Prerender

이 서비스는 오직 검색엔진 최적화를 위해서 사용

왜 react를 선택할까?

• 코드의 구조화(Component)가 잘 되어있고, 이해하기 쉽다.
• ES6 지원 : Class기반 개발
• 그리고 내가 클라이언트 사이드 렌더링을 하는 React에 대한 경험이 있음

과거방식과 SPA의 구동방식 비교

1. 전통방식

html link tag의 href를 통해 주소를 바꾸고 해당 리소스를 서버에 요청한다.

이때 서버는 html로 화면을 표시하는데 부족함 없는 완전한 리소스를 클라이언트에 응답한다.

브라우저는 응답한 html을 수신하고 렌더링 한다.

이때 이전 페이지에서 수신된 html로 전환하는 과정에서 전체 페이지를 다시 렌더링하게 되므로 새로고침이 발생한다.

각 페이지마다 고유 URL이 존재하므로 history관리 및 SEO 대응에 문제가 없다.

=> BUT 중복된 리소스를 요청마다 수신해야하며, 전체 페이지를 다시 렌더링하는 과정에서 새로고침이 발생하면서 사용성이 좋지 않다.

1. SPA

• APP에 필요한 리소스 모든 정적 리소스를 최초에 한번 다운로드한다.
• 새로운 페이지 요청 시, 페이지 갱신에 필요한 데이터만 전달받아 갱신한다.

전체적인 트래픽 감소, 새로고침이 발생하지 않아 네이티브 앱과 유사한 사용자 경험

=> BUT link처리에 대한 고민이 필요하다.

마무리

프로젝트에 따라 정말 필요한지 고려해보고 도입하자!

개인적으로 공부한 내용이므로 틀린부분이 있다면 많은 지적바랍니다!